Any system which allows humans to operate in a simulated or "synthetic" environment and/or interact with simulated entities requires a simulation that can support interactive execution. Training systems and virtual-reality entertainment systems are just two of many examples of such systems. Some of these systems must allow several humans at geographically dispersed locations to interact in and with the simulated environment simultaneously. This requires a simulation that can support both distributed and interactive execution.
One of the most significant drivers in the design of FLAMES was providing support for distributed, interactive execution while continuing to support the more traditional non-interactive (or "batch") execution. The ultimate goal was to allow models developed for batch applications to be used without modification in distributed, interactive applications, and this goal was achieved.
The key to supporting both batch and interactive execution lies in the power of the FLAMES Kernel and the unique relationship between the Kernel and FLAMES models. By allowing the Kernel to be the supervisor and initiator of all processing within a FLAMES-based application, the responsibility for maintaining interfaces with external, manned systems has been moved almost totally from the models to the Kernel. Models can, therefore, be developed without any special consideration for whether they will be executing in a batch or interactive environment. Models can interact with other objects in the simulation without knowing if the objects represent internally simulated entities or external, remotely located and/or human-controlled entities.
FLAMES provides built-in support for distributed, interactive execution using two fundamentally different approaches. The first approach allows all the functionality of the external entity to be represented external to a FLAMES-based application. The second approach allows some portion of the functionality of the external entity to be simulated within a FLAMES-based application. Both approaches support interactive simulation and allow the human participants to be located at geographically dispersed sites. The approaches can be applied in isolation or in concert to provide the capability that best satisfies the requirements of the system.
In addition to the built-in support for distributed, interactive execution,
FLAMES also allows custom services to be added that support custom approaches
to distributed, interactive simulation. Several FLAMES customers have
already exploited this feature of FLAMES in a wide variety of unique applications.
The first approach supported by FLAMES to allow distributed and/or interactive simulation is one that has been applied many times, in one form or another, in a wide variety of applications. In its most basic form, the software of the overall system is divided into separate applications grouped by entity. Each application will execute on a separate computer and will contain all of the software used to model all the functionality of one or more entities. This includes all the models of the equipment associated with the entity as well as the software necessary to support the interface to a human operator, if applicable. Applications communicate with each other by sending information over a network using an agreed-upon protocol, and all such information is transmitted (usually broadcast) directly from each application to all of the other applications in a peer-to-peer fashion with no application acting as a central server. The network of simulations can be considered interactive if one or more of the applications supports an interactive interface to a human operator.
Many protocols have been developed and used over the years by many different organizations to implement this approach to distributed, interactive simulation. In order to allow a larger number of applications to be able to communicate with each other, organizations within the United States Department of Defense developed the Distributed Interactive Simulation (DIS) protocol which is now an IEEE standard. The DIS protocol is arguably the most well-known and heavily used protocol of this type.
Custom services supporting almost any protocol can be developed for FLAMES, and several such services have already been developed. However, the FLAMES Kernel provides built-in support for the DIS protocol. A service within the Kernel called the FDISServer manages all network connectivity and DIS Protocol Data Unit (PDU) communications. A friendly graphical user interface allows DIS exercise parameters and the values that control PDU processing and generation to be specified. The FDISServer provides built-in support for many of the most frequently used PDUs in their most common versions, and it allows FLAMES customers to add support for additional standard and experimental PDUs. And, because most PDU processing software is in models rather than in the Kernel, PDU processing can be customized as desired by any organization developing FLAMES applications.
This approach to distributed, interactive simulation offers many important capabilities, particularly when the DIS protocol is used. A measure of interoperability can be established between many different types of simulations by developing a DIS-compatible interface for each system. Systems that could once execute only in isolation can now interact with many different types of systems. FLAMES capitalizes on this capability and extends it by allowing models developed for different types of FLAMES applications to also be reusable in a network of DIS-compatible applications. Another potential benefit of this approach is its ability to allow multiple computers to be brought to bear on a problem and thereby allow larger scenarios to be simulated.
In certain situations, however, there are some inherent and well-known difficulties associated with this approach. If the number of entities is large and/or the interaction between the entities is complex, the amount of data that must be exchanged between the applications can exceed the capacity of the communications network. When the number of entities is large, a significant amount of the processing resources of each computer on the network must be consumed just to handle network communications and to keep the internal images of external entities up-to-date. The burden this approach places on the network and each of the participating computers can limit the size and complexity of the problems that can be addressed.
One of the biggest strengths of this approach, that being its ability to allow interaction between dissimilar systems, is, in some cases, one of its most significant drawbacks. This approach does very little to advance the cause of reusable software libraries. The software of each application is still completely incompatible with the software of other applications (as are the scenario databases, scenario input user interfaces, and post processing tools). The only way to make use of the capabilities of the software in another application is to connect to the application over a network. For some situations, particularly when the purpose of the simulation is analytical, this approach is either extremely inconvenient or simply incapable of meeting the simulation requirements.
While this approach offers many advantages for some situations, it is not well suited for meeting the requirements of other situations. For this reason, FLAMES supports an alternative approach that addresses some of the limitations of this approach.
The second approach supported by FLAMES to allow distributed, interactive simulation is one that is based on the "client-server" model. The particular implementation of this approach within FLAMES appears to be unique. FLAMES allows the majority of the functionality of all simulated entities (called "Units" in FLAMES) to be represented internally within a single FLAMES-based application which acts as the server. Multiple client applications can then execute simultaneously on the network from remote locations in order to provide the interface to human operators or real-world systems. These client applications allow the human operators and real-world systems to extract information from and exercise control over the Units represented within the server application.
Support for this approach to distributed, interactive simulation is interwoven into nearly every part of FLAMES. The services of the FLAMES Kernel allow any FLAMES-based application that is designed to execute a scenario to act as an execution server. Many different types of client applications can be developed that make use of special services of the Kernel designed specifically for such applications. Using these services, client applications can:
Pause and resume the execution of the server.
Control and configure the server's execution of the scenario in a number of ways, including defining and redefining the execution rate, resetting the scenario stop time, and enabling data recording.
Cause the server to load new data from the FLAMES scenario database.
Request and receive scenario ground truth at regular, user-definable intervals.
Create and delete, kill and revive Units in the scenario.
Redefine the composition of Units in the scenario and alter the tasks that Units are to perform during the course of the scenario.
Directly define the motion of any Unit in a scenario thereby allowing the vehicle dynamics to be simulated in the client rather than in the server (an essential feature for interactive vehicle simulators).
Access and modify the internal data elements of any Unit, particularly the data elements of the equipment models attached to the Unit.
Directly control the processing of the equipment models attached to a Unit.
Monitor, augment, or override any portion of the cognitive processing occurring for any Unit.
Generate a message to be transmitted to any Unit or intercept the message sent to any Unit. This allows real-world communications systems to be integrated into a simulation with very little effort.
Using the services of the Kernel, client applications have been developed that act as master execution controllers and scenario umpires. Other clients have been developed that provide 2-D and 3-D visualization of a scenario as it progresses. Some clients allow real-world surveillance and command, control, and communication systems to be fully integrated into a scenario and to operate just as they would in a real-life situation. Complex vehicle simulators have also been integrated as client applications that take complete control over the motion of a Unit in the scenario and directly interact with and control all of the Unit's equipment.
The services of the Kernel manage and perform all client-server communications in a manner that is largely transparent to both the client and the server. Client applications can be written, in most cases, much like they would be written if they were integrated directly within the server application. Models implemented in the client interact with models implemented in the server using a well-defined set of subroutine calls, in most cases the same subroutine calls used by models in the server. Client software does not need to manage network communications, and there are no network protocols.
This approach eliminates the need to maintain an image of all Units within each application, and there is no need to broadcast state information about each Unit to every application. The network is used primarily to support the interface between human operators and the Unit within the scenario that is being controlled. This interface is usually much less complex than the interface between the models of different Units and can be supported by simple point-to-point network communications rather than resource-intensive broadcast communications. Further, many synchronization and data latency problems are reduced or eliminated.
In addition, this approach exploits the many features of FLAMES that support true reusable software libraries and scenario databases. Using this approach, the same models that support batch execution can also be used to support interactive execution. Also, the same scenario databases, scenario input user interfaces, and post processing tools can be used. Any site possessing a FLAMES simulation capability is able to simulate any scenario and make use of any FLAMES-compatible model using local, stand-alone capability. Any scenario is able to be executed in batch mode or with any combination of automated and interactively controlled Units. Any number of sites are able to participate in joint simulation in any combination without involving other sites.
One of the potential limitations of this approach is the requirement for a large computer to host the server application when large scenarios are being executed. In some situations, this limitation can be addressed by using this approach in concert with the peer-to-peer approach described earlier. This technique would allow the server to be a network of applications rather than a single application, thereby allowing the processing load to be distributed across multiple computers. Another way to address this limitation would be to use a multiple-processor computer, a type of computer that FLAMES is specifically designed to support. Using this type of computer, the execution of the server application is automatically distributed over multiple processors in the same computer without requiring the application to be rewritten to use network communications. This type of distributed processing is often much more efficient than network-based, distributed computing and can lead to support for much larger scenarios. FLAMES also supports server applications executing on a network of multiple-processor computers.
Whatever the situation, FLAMES' support for multiple approaches to distributed, interactive simulation-approaches that can be used in isolation or in combination-will often make FLAMES the best choice for satisfying your simulation requirements.