Battlefield Simulation - Building Virtual Environments

Introduction

Deep within the Combat information Centre (CIC) of a US Carrier is a Seaman watching his screen and monitoring the vital statistics of an Aircraft 200kms out. The aircraft has experienced an electrical failure and cannot use its onboard systems to locate the carrier. Communication has been affected as well, yet there is some voice contact. In support is an AWACS flying within the target area, the same target area that the troubled aircraft has just left. Both systems now show a rapidly descending blip into ‘unfriendly’ terrain on their respective screens, but both know that that blip represents real people that may not make it. As the tension mounts it becomes clear that the aircraft will run out of fuel before reaching the carrier. The Seaman on the carrier and the Airman on the AWACS as well as others who have now become spectators are beginning to exhibit the stress from watching helplessly as the lone aircraft comes dangerously close to the ground. Communication with the Aircraft is now intermittent but it becomes clear that the crew on the aircraft realise that they are not going to get to the carrier. Finally the ship and AWACS systems indicate that the crew have ejected and that the aircraft has gone down.

The ensuing silence in both command and control areas is totally encompassing. No one talks. Both the Airman and the Seaman did all they could yet they wonder if somehow they could have identified the problem earlier and somehow vectored the aircraft to a waiting tanker or to a ‘friendly’ area. They can only assume that the crew parachuted to safety but that ‘safety’ is well behind friendly lines. Search and Rescue are in route to the crash site. The Seaman and Airman in close cooperation across many platforms have done their ‘best’. Yet, they wonder.

So does the training officer who finally steps forward and notifies all involved that the ‘blip’ was a computer generated aircraft and that debriefing on the exercise will be in 30 minutes.

In this particular situation the ‘crew’ were safe aboard the carrier in a training room from which they provided stimulus to the real systems in the AWACS and CIC. From a training perspective, the systems were real, the operators were real, the ‘environment was real, the stress was certainly real, the situation plausible and believable, but the actual reality created within the virtual training world. This simulated exercise allowed for data to be collected on responses, timing, and situation awareness, which can be used to evaluate performance based on acceptable policy, procedures and doctrine in an after-actions environment. But at a higher level, data was also collected which would provide a measure of the ability of the different system platforms, data processors as well as personnel to interoperate [1] in a joint service operation.

Embedded training on real equipment as depicted above as well as training on simulators (Figure 1) or replications of real equipment have been utilised in many areas of the training community for quite some time. The use of simulation to provide training has been essential in many cases where training must be conducted ‘off-line’ and in a comprehensive realistic setting. Studies [2] have shown that the use of simulation as a training tool is cost-effective and provides a valid training alternative to utilising the real equipment. While embedded training typically stimulates real-world sensors, system replication attempts to model the system, the sensors and the operational environment. Typical system replication is an extension of the basic natures of current simulation practices, which first captures the descriptive nature of the system in terms of functionality and then models the predictive nature of the system for interactive training.

Once training moved from the embedded environment into system replication, issues of how much fidelity and component resolution required serious consideration in order to ensure cost-effective training transfer. In general, the defence community attempts to provide functional and physical ‘copies’ of the particular real-world system in order to ensure that the training is ‘authentic’ and as real as possible. But now with the evolution from system replication towards real-world emulation as defined by systems linked in a digitised virtual environment, issues that were once dealt with by physical and functional accuracy must now be analysed under a different set of criteria.

With the trend towards using simulation to create emulations of the real world well entrenched, it is now necessary to evolve our system and software development practices as well in order to accurately and adequately address the issues of real-world reduction into a digitised Battlespace. While replication produces a simulation that describes a system, emulation attempts to simulate its operational environment in all plausible state changes or interactions. This new nature for simulation, Emulation [3], truly requires additional techniques and methodologies in conjunction with the traditional System/Software Engineering approaches in order to create both valid systems and distributed interactive cost effective environments.

The need for a Simulation Development Process, especially for human-in-the-loop systems, has surfaced in many current programs attempting to create families of simulations that will provide an authoritative representation of a specific environment. This paper focuses on presenting a proposed development methodology, supported by tools and processes. While the focus or application space for this article is training systems, all simulation systems require a more inclusive development process that takes into account the particular challenges facing a simulation program and the staff challenged with producing it.

Background

By way of introducing the focus of this paper, it is probably appropriate to revisit the issues surrounding simulation-based training within the operational domain. Much has been promised with respect to the ability of simulated environments to provide a cost-effective, mistake-space replication of the real world. The US Department of Defence (DoD) and other defence forces have embraced simulation to the point of setting up joint service support offices such as the US Defence Modelling and Simulation Office (DMSO). Each of these activities has published a M&S Master Plan [4] that explain a process of acceptance, standardisation [5] and augmentation. Yet while the focus is on the end game, little has been done to evolve the underlying academic or scientific principals necessary to build and certify these systems.

The hope

Today, with the ability to monitor environments under an umbrella of various digital and analogue information-gathering technologies, we can in fact create a digital representation of the ‘real world’ as defined by its interactive environment—at least in specific areas of interest. Systems can gather traffic information both network and road, monitor environmental conditions, evaluate medical stability of a patient and report the ‘health’ of a Boeing 777—to name a few.

With respect to the modern day battlefield, digitised representation fuses together data from many different sensors to include the intelligence gathered by humans, in order to form a complete ‘picture’ of the real-world situation (Figure 2). Therefore, it is a natural extension of the real-world technology to take the data and create an artificial environment from which we can extract predictive information as well as create a synthetic training environment that is as operationally valid as the real world (Figure 3).

Advances in the simulation supporting technologies such as visualisation techniques and terrain databases have enabled Synthetic Environments (SE) or virtual play boxes to replicate plausible distributed interactive environments for operational training. Currently, these environments can support interaction between live, virtual and constructive (simulators) entities or ‘players’ through all levels of the vertical training ladder.

The ultimate hope as we embrace this technology, is to train personnel from the individual task level to the joint operational domain to include Mission Rehearsal. But of keen importance is that all of the mistakes can be both be studied in an after actions process, critiqued, and action taken to avoided them in the future. The attribute of most significance though, is that mistakes made in simulation can be walked away from.

The current reality

This shift from a systems modelling technique for analysis and/or training to a methodology that supports the creation of an interactive real-time valid operational domain for these systems has to date been primarily technology driven. Unfortunately the discipline for developing these systems has not kept abreast with the changing nature of the simulation domain. Typically, when simulation is used for analysis, variables of interest are identified utilising Experimental Design techniques and then the resultant simulation defined by the required quantitative fidelity (data granularity), and analytical resolution (level of component representation or decomposition).

With the merging of Virtual Reality (VR) and the need for real-time training, the Synthetic Environment (SE) Battlespace was born. Now the variable of interest is the inclusive representation of the operational characteristics of a real-world environment. While interactive training systems have been developed for quite sometime, the emphases has changed from supporting task training to operational training within a valid interactive environment. As an example, flight simulators exist to train individuals how to fly complex aircraft. Within that domain, pilots train on major areas such as emergency procedures, flight dynamics, flight procedures, approaches and landings, air traffic control procedures and navigation. The evolution that we now embrace is intended to let these same pilots ‘fly’ their training systems in an operational domain in order to provide realist representation of what they will face in the real world.

With the recent announcement of the US Air Force to actually give up fuel for networked simulators across all air platforms and air bases, we now embark on training on operational concepts as apposed to defined tasks. More importantly, the concept of high fidelity training environments is no longer a theoretical concept but a recently procured reality on which a major portion of readiness training of US pilots rests. Distributed Mission Training (DMT) as shown in Figure 4, will ultimately prove the utility of this new paradigm. Thus we now attempt to emulate the true nature of the operational environment or in the case of the military, the ‘Fog of War’.

The problem

At the heart of the problem now facing simulation professionals (including developers, users and managers) is the lack of supporting ‘information’ to enable each to fully realise the next generation training system. For the technology pace has outstripped the underlying scientific methodology that currently supports traditional system/software development. Methodologies and standard practices must now be expanded that support system development and certification as well as provide the foundation principals for operational validation and verification of somewhat non-linear real-world phenomena.

The essence of the current problem is that engineers, developers and users must define, design, develop, and certify a system that is functionally valid over an operational domain as opposed to strictly being functionally valid in accordance with a set of system requirements. Finally, users must be able to determine the most cost effective and feasible approach to meeting their training requirements. Given that the ultimate measure of the ‘system’ is training effectiveness, it is now essential to include qualitative analysis in the process that focuses on issues such as moral, motivation, and criticality of training as inputs into the development of the overall system specification.

The high level architecture (HLA)

The basic contributor to the current problem is that traditional system or software development processes are somewhat linear in their approach to product definition and creation, and are targeted at systems constraints and requirements. At odds with the linear transformation of the real world into a computer model is the fact that the real world is not linear at all. Many examples exist that have perceived order yet evade our capability to model, let alone replicate that order [6]. Recent textbooks on Modelling and Simulation acknowledge the use of simulation for training yet still refer to a somewhat linear reduction and creation process for that same system. The typical approach is void of an analysis process required to get to the first phase of the development process [7,8] For example the current US Department of Defence High Level Architecture (HLA) literature [9,10] explains that:

“The HLA is fundamentally an architecture to support component-based simulation, where the components are individual simulations. The architecture also supports building simulations that are distributed across multiple computers, but that is a happy side effect of its support for components.”

Also the developers of the current overarching simulation environment further acknowledge that:

“The HLA is not a model construction environment. It supports the interaction of simulation components at federation execution time and to some extent at design time. But it is not an environment for constructing models.”

In reality, the HLA provides a set of mandated guidelines, standards and architectural requirements which when implemented on a physical network support a plug-and-play distributed interactive training environment. This environment though, is still constrained by interconnectivity and interoperability issues admittedly not addressed by the HLA within the core components that comprise the training environment.

Given that HLA represents the current approach to ‘creating’ simulation environments for training and the issue of component or model definition, design and development is purposely not included further defines the current problem of a lack of sufficient focus on fundamentals model creation.

In contrast to the typical development approaches discussed herein is the essential initial requirement to first establish what reality is before you can replicate that reality in a model and ultimately extend it in a simulated environment. For the most part it is assumed that given the fastest, latest and most technologically advanced system, ‘good’ simulation environments will result. While system modellers may provide an accurate replication of the responses of a system they do not attempt to emulate the environment for which these systems are valid. It is this leap from modelling system performance to modelling an environment for which the system can perform over its operational spectrum that has changed the basic nature and propelled the science of simulation into academically uncharted waters.

Review of traditional development approaches

Traditional software engineering approaches [11, et al] still focus on systems whose fundamental starting block is a well-defined need and a set of ordered requirements from which the system can be specified and consequently evolved. Depending on other underlying system characteristics such as risk, customer involvement, expertise of development staff and so on, a life-cycle model is proposed and used. All ensuing efforts and techniques such as rapid-prototyping are focused on fleshing out either data or action requirements based on a set of constraints and customer requirements for the final product.

Even texts focused at simulation development tend to adopt the proposed structures of the System/Software Engineering phase development process [12,13]. Regardless of its intended application domain (analysis or training), a simulation system must be both authoritatively, replicable, and behaviourally valid. Thus, the ultimate test is validation and not verification—for example, if students are not trained then the system fails regardless of its technical sophistication or process capability. And if the system does meet the objective but at a cost too dear for the customer, the system fails as well. Therefore, traditional system and software engineering approaches need to be both broadened and strengthened for simulation systems attempting to replicate the real world.

Traditional System/Software Engineering Methodologies define the System/Software Process as shown in Figure 5. The initial phase of both methodologies is oriented at capturing customer needs into system/software requirements, Some refer to the initial step within the Requirements Phase as concept exploration and must deal with product feasibility and viability. Simulation systems for training for example must deal with requirements such as learning objectives, training transfer, and training assessment issues before the concept exploration of the resulting system can be initiated.

Thus the real world itself must be defined by a set of constraints, influences, actions and interactions before we can specify the system requirements and constraints, which must upon completion reflect that reality. Therefore, prior to the beginning of the System/Software Specification Phase a methodical Real-World Reduction Phase must resolve issues associated with real-world abstraction. More specifically, the issues of fidelity and resolution must first be defined before the resulting requirements from those initial decisions can be explored in terms of final system viability.

The impact of fidelity and resolution decisions

Fidelity and resolution are abstracted phenomena qualities fundamental to accurately specifying a simulation training system. Once decisions, which describe the system in terms of fidelity and resolution, are specified and implemented, they cannot be easily changed. It is these decisions that actually define the basic nature of the system and give it validity within the intended domain. Furthermore, the design issues linked to fidelity and resolution are the basic cost drivers of the target system.

It has been the experience of this of author that these terms have multiple definitions depending on the project under development. For the sake of clarity and putting a stake into the ground, we shall use as a starting point the American Heritage Dictionary with the appropriate definition for this paper set in brackets.

Fidelity is defined as (3) The degree to which an electronic system accurately reproduces at its output the essential characteristics of its inputs.

Resolution is defined as (5) The action or process of separating or reducing something into its constituent (component) parts.

Fidelity

As stated, fidelity issue directly impact the overall cost of the final system. Since each decision implies an implementation strategy, it is obvious that high fidelity and low cost are mutually exclusive terms.

Design issues impacted by decisions regarding model fidelity include:

• The basic type of data abstraction, which determines the model type—Quantitative/Qualitative/Heuristic.
• The representation of the output data supplied to the operational environment—Intelligent Direction/ Mathematical Analysis/Cause and Effect Reasoning.
• The level of representative detail included in the underlying models for both influences and constraints.
• The degree of accuracy of the model to account for real-world behaviour, reactions and all valid interactions.
• The interactive authenticity of the model in terms of spatial, temporal and behavioural characteristics.

At the system level, fidelity impacts on a training system in two ways:

• The needed supporting physical network and operational architecture—interconnectivity.
• The need for the human-in-the-loop to experience the level of real-world replication sufficient to provide the desired level of training effectiveness and transfer—interoperability.

Resolution

On the other hand, resolution decisions determine the component breakdown required to represent the intended real-world object. For example, an airplane can be represented by a single object or a set of objects combined to represent the aircraft. Each airplane can have articulating parts that are individually modelled and controlled such that flaps, wheels, lights, and so on, are represented by individual models. While each is a separate modelled component of the aircraft they are represented as an aggregated aircraft in the simulated environment. Resolution decisions impact internal processing time as well as network bandwidth requirements.

Proposed simulation development process to support operationally valid training environments

It is proposed by this article that the analysis of the operational domain and the final certification process for that domain are currently not part of the traditional system/software development process. Furthermore, it is postulated that real-world reduction analysis of the phenomena of interest is essential to successfully specify a simulation-based training environment for distributed interactive training. As presented here, each phase of this process is intended to further clarify and define the final system in terms of required interactive and perceptual fidelity.

Real-world reduction process

The Real-world Reduction Process is defined in this article to be a methodology, which deals with real-world abstraction. As shown in Figure 6 the Real-world Reduction Process as presented here is comprised of a set of phases whose output is a specific definition intended to tightly bind and bound the resulting Simulation Specification. The major phases associated with the proposed Real-world Reduction Process are:

Domain Analysis Phase.

Real-world Abstraction Phase.

System Phase.

Technical Phase.

Operational Phase.

Certification Definition Phase.

Each of the phases within the Real-world Reduction Process has a resulting definition, which ultimately provides the necessary input for the System/Software Specification and the Real-world Verification and Validation Process.

During this phase the intended physical system is treated as a black box and analysed for what fidelity of the real-world must be captured so that the resulting output from the ‘black-box’ is both valid and realistic within the target domain. The ultimate goal of the Real-world Reduction Process is to define the resulting system within a specific domain that is representative of the reduced real world system. Furthermore, the reduction process must account for the transformation of non-linear phenomena into valid model constructs.

Domain analysis phase

The Domain Analysis Phase is targeted at identifying the application domain for which the resultant simulation will be valid as defined by the basic nature for which the simulation is intended. As explained earlier this is one of the 4 basic natures to now include emulation. Domain Analysis was initially developed to help foster Software Reuse [14]. The underlying mechanisms though provide a well-documented process for defining the application domain, internal and external technical and policy drivers and a format for evaluating future trends and technology.

Real-world abstraction phase

The abstraction phase focuses on the process of ‘decomposing’ the real world into a set of phenomena to be captured in the model. Upon identification, the phenomena are then defined in terms of influences, stimuli, and constraints. The abstraction process ultimately shapes the level of fidelity and component resolution that will be included in the system. The abstraction process defined by Zeigler [15] provides an initial formalism, when expanded, for deriving operational, technical and system architecture requirements [16] through a reduction process. The functional issues to be addressed during the Real-world Abstraction phase can be defined by four areas of investigation, which are:

• Real-world Reduction into Basic Phenomena.
• Required Fidelity and Resolution.
• Required Interoperability and Interconnectivity constraints.
• Training Certification Criteria.

Real-world abstraction definition

Zeigler in his seminal work was on of the first to recognise that simulation system development was a unique development process from which imitation of a real-world system is identified and created. As has been noted before by this author, Zeigler described a hierarchy process that allows for the reduction of a real-world system into a computer resident replication. He defined five levels of abstraction required to evolve from the real world into a computer-generated replication.

• The Real System is the actual system or source of observable data and or environment of interest.
• The Experimental Frame a set of limited circumstances (interactions) under which the real system may be observed or manipulated (or interacted with).
• The Base Model is a reference model capable of accounting for all of the stimulus, transactions and interactions of the real system in terms of perceived behaviour.
• The Lumped Model is a reduced version of the base or reference model that is still valid for the defined areas of interest in the Experimental Frame.
• The Computer Model is a computer-hosted set of models that implements the Lumped Model, utilising a particular computer language and computer architecture.

System capability phase

During the System Capability Phase the initial system performance criteria are defined as a set of training requirements. Issues impacting Interconnectivity and Interoperability are identified, captured and quantified for inclusion in the System Capability Definition. For this phase of the process, the requirements levied by the training environment such as, real-time interactions, behavioural characteristics, student interface fidelity, data capture and performance criteria are determined. The performance criteria are then captured in conjunction with the training tasks conditions and standards for which the training environment is to be valid, and are documented in terms of a set of training performance metrics.

Technical specification phase

During the Technical Specification Phase, the appropriate standards, policies and guidelines are identified and documented. These standards control issues such as system development, protocols, interfaces, architectures, and reliability. The resulting technical requirements are then documented in the Technical Definition.

Operational concept phase

This phase captures the operation aspect of the training environment. This phase of the overall Real-world Reduction process has in fact, been used on recent acquisitions within the US Defence community. Unfortunately the actual Concepts of Operation (CONOPS) definition is levied on the offerer and not provided by the user.

The true focus of this activity is on the end user of the simulation. It forms the conceptual basis for the human-in-the-loop expectations and requirements of the total training system. This phase defines the system by a set of tasks, capabilities and operational characteristics and standards. The benefit of this phase of the process is the ability for the target audience to define requirements in terms of training standards and not systems requirements.

Certification definition phase

This final phase serves to define the simulation in terms of Measures of Effectiveness and Performance (MOE/MOP) with respect to the attended application domain and audience. To conduct certification, training effectiveness and system performance criteria must be established to show that the intended system does in fact provide the required training at the level of fidelity and resolution commiserate with the interoperability and interconnectivity constraints as identified in the System Capability and Technical Definition Phases.

Conclusion

While the terms interconnectivity (the network requirements) and interoperability (the behavioural, temporal, and spatial requirements necessary to represent an object in the training environment) serve to define the overall system performance and effectiveness, decisions made in response to what is required to provide effective training directly define and quantify these terms. Whether a pilot undergoing individual pilot training needs a $100 million simulator or a $200 dollar Personal Computer ‘game’ which imparts the same basic knowledge, are issues that we can start to explore. First though, we need to develop training effectiveness and performance measures that specify the required ‘system’ in terms of training fidelity and resolution. The proposed methodology is thus intended to serve as a framework for initiating a dialogue among the community and not the end result.

Summary

This article attempts to focus in on the inability of traditional development practices to specify a simulation system whose specific purpose is to operationally emulate a real-world environment for interactive training. Furthermore, the interactions are between components whose only representation into the training environment is via a set of defined protocols, which are then interpreted and projected into that environment, a need exists to determine the underlying fidelity and resolution of the models designed to replicate the real-world. This ‘need’ arises from the initial requirement to provide realistic, authoritatively accurate, real-time training. But the instantiation of this need must be tempered with budgetary constraints.

In formally proposing the need for a methodical initial reduction process prior to the system engineering development process, this author also recognises that the reduction process as outlined in this article involves professionals across many disciplines. The disciplines include, system engineers, software engineers, training psychologists, industrial engineers, knowledge engineers, AI Engineers, computer scientists and so on. The concept of a ‘Professional Simulationist’ thus is an embedded underlying theme within this article. Engineers trained to recognise the reduction issues and propose the model for the right level of data and action fidelity and resolution are a key ingredient in the formulation of a final system specification that is not only feasible but also operationally valid.

Future research

Fundamental to system specification and certification for training is the need to develop a conceptual framework for deriving training MOE and MOP, which in turn determine the systems utility for training. While System issues of effectiveness (that is, visualisation detail) and performance (that is, network reliability) are consistently levied on programs, the underlying requirement in terms of training needs is typically not defined. Thus in most cases there is no correlation between the operational need with respect to training effectiveness and the system requirements.

References

Author

Michael L. Darby is a lecturer in the School of Electrical and Computer Engineering at Curtin University of Technology in Perth, Western Australia with a principal focus on Modelling and Simulation research. Mr. Darby is also the principal Director and Chief Scientist for North Star IT Solutions Pty. Ltd. Mr. Darby has over 20 years of practical simulation experience in training, analysis, and process engineering.