What’s the problem?

Modern simulations are a complex combination of models. Some of the models represent military vehicles and weapons systems. Others represent the land, sea and air. Each may be composed of many inputs, calculations and outputs. Nevertheless, all the models must work together in simulations to produce the intended results.

But, all too often, the land, sea, and air models don’t work together. Increasing wind doesn’t create higher waves. Currents and waves aren’t affected by the shoreline. As a result, the models don’t appear to obey the physical laws of nature. Further, the interaction between vehicle/system models and land/sea/air models don’t reflect real world experience. Ship motion doesn’t increase as wave height increases. Atmospheric effects that should double, or halve, the range of radars and sonars aren’t reflected in the weapon system model results.

Sometimes the inconsistencies in results are obvious, but more often they are hidden by the complexity of the simulation. As complexity increases, it’s often difficult to determine where and why models aren’t working together. And it is always much more difficult to correct inconsistencies after the fact than to prevent them when models are being selected and combined. For these reasons it’s better to insure, from the start, that models intended to be combined into simulations are engineered to work together.

In the past, a proactive approach was made easier because a few model builders worked closely together to build a simulation from scratch. Often each modeler understood every aspect of both the military system and its interaction with land, sea or air. The overall perspective of each modeler largely prevented inconsistencies from even being considered, much less modeled.

Now, however, larger teams of specialized modelers are needed to create the more complex simulations being used today. There are specialists in modeling ships, vehicles and aircraft; specialists in modeling sensors and weapons; and specialists in modeling terrain, the sea surface, and the atmosphere. Also, because simulations are more expensive and time-consuming to build, they are being reused for purpose that the original modelers hadn’t intended. In some cases, the original model builders have moved on to other projects, and are no longer part of the simulation team. As a result, it’s all too easy to stumble into the kind of hidden inconsistencies that destroy the credibility of simulation results.

Today, good engineering practice is needed to develop consistent simulations that produce credible results. [top]

What’s good engineering practice to solve the problem?

Our solution is two-fold.

First we uncover the assumptions that are built into the models used to represent the real world of land, sea and air. We also uncover the interactions between the land, sea and air models and military systems models. We work with the modelers and their design documentation, before models are built. Now, expensive existing models are often reused, and we examine existing software documentation to determine the engineering assumptions that were built into the model. Sometimes we find it necessary to review the published technical literature in addition to the documentation, to determine the capabilities and limitations inherent in choosing a particular algorithm as the basis for a model. On occasion, the lack of documentation forces us to inspect the software code. This process of uncovering assumptions and interactions can be structured for greater effectiveness, but always depends on skilled analysts with relevant engineering experience and an understanding of the simulation-wide implications of individual model characteristics.

Second, we document our findings so that they can reused in the same way that models are reused. For modern, complex simulations, a new approach is needed to ensure the desired consistency. We didn’t originally intend to create a new approach. However, as we began to work with the complex simulations now being developed, we realized that we couldn’t achieve our solution without a fresh approach.

We also realized that modern software engineering practice provided new capabilities; and we tailored them for our needs. Our documentation approach required the most tailoring, leading us to create a new type of documentation product, the Environment Concept Model. [top]

What’s an ECM?

The Environmental Concept Model, ECM is our new approach to documentation. The term “environment” refers generally to the terrain, to weather and to ocean conditions and phenomena. The term “concept model” refers to the modern software engineering practice of developing detailed, multi-faceted descriptions of software using specialized descriptive formats. The ECM addresses land/air/sea modeling at a requirements and design level.

The ECM is a process-based product in the form of an electronic document. The process is described above. The resulting document is composed of three major sections.

First, the document describes the real world scenario(s) the simulation will represent. The military systems and personnel are identified, as well as the actions they perform. Often, the scenarios are broken down into smaller vignettes, to clarify the representations.

The document’s second section describes the land/sea/air modeling needed to satisfy all the needed terrain, weather, and ocean phenomena. The ECM documents the independent and dependant variables, algorithms, and logic used to model land, air, and sea.

The document’s third section revisits the second section’s need-based description, from a different perspective. The third section describes the land/sea/air modeling as actually implemented, with limitations imposed by science understanding as well as project schedule and budget considerations. Limitations might include substituting more readily available data, models using algorithms that execute quickly, or perhaps an acknowledgement that not every scenario can be fully modeled to the same level of detail.

The ECM document makes use of the formalism of a modern software design language. As a result, all or part of one ECM can be reused in a later ECM, or the contents of several ECMS can be combined to create more detailed and complex land/air/sea descriptions. [top]

What are the technical foundations of the ECM? And why is this important?

The ECM is a response to the challenge of modern land/sea/air modeling. It’s also a tailored application of three practices in software engineering: object oriented analysis, standardized analysis and design “languages”, and concept models. Because the ECM uses these powerful capabilities, the ECM is a durable product that easily integrates into modern software engineering practice.

Object oriented analysis is a powerful way of describing the real world in a structure that can still be seen in the resulting software. When the real world situation is complex, the resulting software simulation is often so complex that it’s hard understand, let alone maintain and modify. For any complex effort, good engineering practice suggests that the whole should be subdivided into smaller, clearly identified components with clearly defined connections. If the real world situation is clearly subdivided into groupings of physical objects, and the resulting software groups those object representations into similarly subdivided code components, then the organization and logic of the real world helps organize the software. For instance, if a city is to be modeled in software, then there would be software components identified as streets, buildings, traffic, populations, and services. Like the real world, building components might be subdivided into offices, homes, shops, etc. In each case, the pertinent characteristics of physical offices, homes, etc. would be modeled in the office software component, the home component, etc. Over time, rules for “translating” the real world into software have evolved into analysis and design languages.

Analysis and design languages help the modeling experts specifically describe all the characteristics of the software code, which is the end product of simulation development. Like any spoken or written language, these analysis and design languages have a vocabulary, and a grammatical structure. However, because analysis and design languages often use diagrams in addition to structured text descriptions, so they also have set of graphical symbols and rules about how to lay out and combine the symbols in diagrams of an agreed format. Like spoken/written language, the analysis and design languages are successful because they have the breadth and flexibility to clearly communicate complex ideas. In addition, the most widely used analysis can design languages have standardized their vocabulary and grammar by common software community agreement. Today, analysts and software developers are using analysis and design languages to create many kinds of software engineering documents. [top]

The concept model is one form of descriptive document that bridges the gap between the visible, touchable real world and the hidden behaviors of software in models. When the real world situation is very complex, a concept model documents reality’s most important characteristics, so that software developers aren’t overwhelmed and confused by the real world complexity. A concept model describes the important values, behaviors, and interactions between real world objects. A concept model is not yet a detailed software design; it stops short of specifying the details of coding in a particular machine-executable software language like Fortran, C, or Java. (Thus, concept models are said to be code-independent.) Concept models do more, however, than record real world characteristics that must be reflected in software models. Concept models also speak to software designers in a way they understand, by using an analysis and design language as the documentation language. Thus, the contents of a concept model can easily be incorporated into a detailed software design document.

The ECM was specifically developed as a documentation product to respond to the challenge of describing complex terrain, weather and ocean phenomena. It uses object oriented analysis to ensure that real world complexity is directly reflected in the structure of the eventual software models. ECMs are built to communicate clearly with software engineers, using the analysis and design languages they themselves understand and use. Because the ECM is a concept model, it has a ready-made place on modern software engineering practice. This is the kind of solid technical basis needed to ensure that ECMs developed today will continue to be usable for years to come, by an ever-growing number of modelers and software engineering professionals. [top]

Who would use an ECM?

Because the ECM is an aid to good engineering practice, it is most often used by subject matter experts and system engineers participating in simulation design and implementation. In addition, parts of the ECM are reusable for different simulations, and those descriptive parts may be used by land/sea/air modelers and data managers to develop standardized, widely used models and data sets. [top]

How do you know when you are achieving a solution?

Good engineering practice is reflected in the confidence of simulation users in the simulation output.

Earlier, as models are being assembled into simulations, engineers should be able to (1) determine the inputs, algorithms and outputs for all land, sea and air modeling, (2) determine the probable interactions of terrain, weather and ocean with military systems, and (3) document them in a form understand by both software engineers and systems experts. Fundamentally, if there is continuing insight into the capabilities and limitations of the data and models being assembled into simulations, then our approach is achieving its goals.

After simulations are built and tested, pieces of those simulations should be available to be reused. If the documentation of land, sea and air modeling from one simulation can be adapted, extended, or combined to create new model descriptions, then our approach is achieving its goals. If the pieces that are most often reused can be codified as standard descriptions and widely distributed, then our approach is achieving its goals. [top]

Glossary Terms

Object Oriented Software Development Terminology

Object Oriented Analysis: An approach to describing a real world scenario by representing people, activities or equipment separately and distinctly. The representations are abstractions of real world items. Typically, object oriented design uses an agreed-upon format to describe the abstractions and their relationships to one another. The goal of object oriented analysis is to arrive at an clear description, often for the purpose of designing software that will eventually be used in the real world scenario.

Object Oriented Design: A methodology that takes advantage of the fact that real world abstractions, and their relationships to each other, lends itself to a type of software implementation that creates small, distinct modules of code that tend to represent the separate and distinct abstractions of the real world scenario. The goal of the methodology is to

Analysis and Design Language: Analysis and design languages are intended to be a standard way of developing “blueprints” for software. Each language has “grammar” consisting of agreed upon formats and syntax (usually have rules for text and graphical symbols) for describing abstractions of real world scenarios. However, unlike blueprints, the format and syntax of some languages make it possible to automatically create some software directly from the software specification.

Unified Modeling Language (UML): An object oriented analysis and design language for visualizing, specifying and documenting software systems. The Unified Modeling Language, or UML, is a combination of three older languages; its grammar is managed by the industry-based Object Management Group as a community-wide standard for specifying software systems. The UML is a part of the U.S. Department of Defense’s Joint Technical Architecture.

UML Model View: A partial description of a software system that emphasizes a particular aspect of the total system development. One view might describe the functions and behaviors of a system; another might describe the system configuration; a third might describe the system’s delivery and installation. Model views divide descriptions of complex software projects into more easily understood chunks. The UML uses five views to describe a system development:
- Use case view
- Design view
- Process view
- Implementation view
- Deployment view

UML Diagram: UML diagrams are the graphical building blocks of UML. (UML model views are made up of one or more UML diagram types). Together, the diagram types can completely describe the software as it moves from an idea to executing code. Each diagram type uses specific shapes and connectors, with parameter fields. Each model view uses different diagram types to describe a part of the system development.

Use Case Diagram: The UML specifies a several types of graphical diagrams to describe different aspects of a software system. The use case diagram shows the people and activities included in the real world scenario to be developed in software.

Interaction Diagram: The interaction diagram shows the timing and sequence of information of information exchanged between different pieces of software.

Class Diagram: The class diagram shows the information and calculations performed by a piece of software, and also shows relationships between different pieces of software. In object oriented software, different pieces of software often share information or calculations, and the class diagram shows this sharing.

Interface Diagram: The interface diagram shows what types of information are exchanged between different pieces of software. (Interface diagrams are often used in conjunction with Interaction diagrams to convey a complete story about the what/when/how of information exchange between software pieces.)

Package Diagram: The package diagram shows what pieces of software are assembled into larger packages. Packages are often assembled for ease of management, or to be installed on multiple pieces of hardware.

Objects: A general term used for a discrete thing in the real world that will be represented by a distinct piece of software. The accompanying description includes parameter values that describe the object’s characteristics, and calculations that describe the object’s actions.

Class: A software term used to describe the software description of a group of objects that share the same characteristics.

Superclass: A software term used to describe the generalization of a group of objects. Superclasses include the characteristics and calculations that are common to all the generalized objects.

Subclass: A software term used to describe specialized objects that have additional characteristics and/or calculations different from their “parent” objects.

Attributes: A software term describing the parameter values used in a class.

Operations: A software terms describing the calculations used in a class.

Message: A software term that specifies the communication among classes.

Stereotype: A UML term that means an addition to the UML language grammar, based on elements of the existing UML grammar. Stereotypes are used to help designers describe and specify software in ways not accommodated by the existing UML grammar.

Package: A UML term for a grouping of software classes. Classes may be grouped into packages when they should be managed in the same way, or installed on the same hardware platform, or released as a particular version.

Component: In software, a physically replaceable part of a software system that can be distinguished by a set of specific interfaces.

Expose: In object oriented software development, to make the characteristics of a piece of software available for use by other pieces of software. For instance, attributes of software classes can be designated to be private to (only accessed and used by) one class, or public (accessable) by other software classes. Public attributes are said to be exposed, or made available, for general use. [top]

Environment Concept Model Terminology

Environment Representation: The description of the land, air and sea characteristics of interest. terrain, weather, and the ocean. Characteristics also include, environment effects like background noise, scattering, and transmission loss and other phenomena. Finally, characteristics include environment impacts from military systems such as shell craters, wakes from passing ships, or vapor trails created by aircraft. These characteristics can be described by constants, parameters, trending curves regressed from data, physics-based calculations, or even rule-of-thumb heuristics. Thus the environment representation includes data and calculations used to describe both snapshot measurements and dynamic behaviors.

Concept Model: In software, a framework, a particular approach to describing the real world in software. Often the framework is described in terms of basic building blocks, rules for how the blocks are used, and additional guidance. Once used, concept models are like completed templates, whose predefined structures are tailored to solve a defined range of problems.

Environment Concept Model (ECM): A framework, based on the grammar of an object oriented design and analysis language, designed to document all aspects of an environment representation. The Environment Concept Model, or ECM, forces a thorough consideration of environment from several perspectives. It allows descriptions of environment characteristics, effects and impacts. It allows the environment representation to include data, calculations, and heuristics. By using an existing object oriented design language, the ECM speaks to software developers in their own language and allows ECMs to be tailored and reused.

Inferred Environment: In the ECM, a model view (see definition above) that documents the environment that logically accompanies the battlespace described in the use case. The inferred environment model view is a stereotype (see definition above) extension using the UML grammar.

Implemented Environment: In the ECM, a model view (see definition above) that documents the environment to be used at runtime. This environment representation includes the compromises necessary to deliver an environment representation on time and within budget. The implemented environment model view is a stereotype (see definition above) extension using the UML grammar.

Consistent Environment: In the ECM, a standard for determining that an inferred environment view has been correctly and successfully documented. The standard is that the consistent synthetic natural environment:
- Obeys the laws of nature and physics
- Changes from state to state in a continuous manner, due to an underlying nature or physics-based causality
- Replicates the real environment that it models.
- Exhibits the above qualities at an agreed feature level of detail, time step, and length scale.
- Exhibits an agreed smooth transition at any boundary between differing levels of fidelity.

Complete Environment: In the ECM, a standard for determining that an inferred environment view has been correctly and successfully documented. The standard is that that simulation objects that are sensitive to environment change state when the causal environment state changes. Implicitly, there is a degree of state change that is agreed to be of operational significance. [top]

Simulation Terminology

Model: A mathematical or otherwise logical representation of physical systems, natural phenomena, or processes.

Simulation: A machine-executable representation, over time, of physical systems, phenomena, or processes.

Federation: A group of simulations tailored to execute together. The term “federation” is often used specifically to refer to groups of simulations that comply with the standards of DoD High Level Architecture, and coordinate their execution via a High Level Architecture-compliant runtime infrastructure.

Federate: An individual member simulation of a Federation. This may include federation managers, data collectors, real world ("live") systems (e.g., combat systems or platforms, instrumented ranges, sensors), simulations, passive viewers and other utilities.

High Level Architecture (HLA): The High Level Architecture is general purpose architecture for simulation reuse and interoperability. The HLA is composed of three components: a set of 10 basic rules that describe the defining principles of HLA, a description of the functional interfaced between simulation components (federates) and the runtime infrastructure and a specification of the common format and structure for documenting HLA models. The HLA was developed under the leadership of the Defense Modeling and Simulation Office (DMSO) to support reuse and interoperability across the large numbers of different types of simulations developed and maintained by the DoD. The HLA was adopted as the Facility for Distributed Simulation Systems 1.0 by the Object Management Group (OMG) in November 1998. The HLA was approved as an open standard through the Institute of Electrical and Electronic Engineers (IEEE) - IEEE Standard 1516 - in September 2000. The HLA MOA was signed and approved in Nov. 2000.

Runtime Infrastructure (RTI): Because the HLA is an architecture, not software, use of runtime infrastructure software is required to support operations of a federation execution. The RTI software provides a set of services used by federates to coordinate their operations and data exchange during a runtime execution.

Federation Development and Execution Process (FEDEP): The FEDEP defines a generic, common sense systems engineering methodology, in six steps, for HLA federations that can and should be tailored to meet the needs of individual applications.

Institute for Electrical and Electronic Engineers (IEEE): The Institute of Electrical and Electronics Engineers, Inc., helps advance global prosperity by promoting the engineering process of creating, developing, integrating, sharing, and applying knowledge about electrical and information technologies and sciences. The IEEE is the standards certification body in the U.S. for electrical and electronic engineering and design standards. The IEEE is the also the “gateway” organization for U.S. standards being proposed to the International Standards Organization as international standards.

Object Management Group (OMG): The OMG is an open membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications. The OMG’s membership roster includes virtually every large company in the computer industry. The OMG is now responsible for the maintenance of the Unified Modeling Language specification.

Defense Modeling and Simulation Office (DMSO): In 1991 the Undersecretary of Defense for Acquisition established the Defense Modeling and Simulation Office (DMSO) to provide a full-time focal point for information concerning DoD modeling and simulation activities. DMSO promulgates policies and guidelines, fosters cooperation, develops requirements, and identifies high priority modeling and simulation objectives. [top]