A FLAMES-based application is a computer program that makes use of one or more of the services resident in the FLAMES Kernel and conforms, as appropriate, to the specifications defined by the Kernel. The Kernel does not require modification as new applications are developed and is the same for all applications. Nearly all of the application-unique software in most FLAMES-based applications is resident in what are referred to as "models."
This section of Ternion's Web site describes the basic structure of
many of the different types of models supported by FLAMES. Other sections
of this Web site provide information on the services
of the FLAMES Kernel and on developing custom
FLAMES-based applications.
The word model is used most often in FLAMES to refer to a specific section of software that is intended to represent the functionality, or a subset of the functionality, of some real-world entity such as a vehicle, a building, or a human. Models are implemented as distinct, object-oriented classes each of which inherit one of the primary model classes defined by the Kernel. The primary model classes establish the high-level structure of all model classes, the interfaces by which the Kernel manages each of the objects created from a model class, and many of the interfaces by which model objects interact with each other.
FEntity is a primary class defined by the FLAMES Kernel. FEntity is inherited by all FLAMES primary model classes and, as such, defines methods and attributes that are common to all model classes. Many of the common services of the Kernel interact with and manage application-specific objects through the methods defined by FEntity. The primary classes that inherit FEntity define additional methods and attributes that are common only to the corresponding "type" of entity.
Many of the methods of the primary classes are defined for use exclusively by the Kernel. But several other methods are also defined that can be, and often are, used by objects as they interact with each other. These methods make up a large part of the model-to-model interface specification defined by FLAMES. This specification can be extended by application developers to include custom interface standards by defining "intermediate" model classes. Intermediate classes are those that inherit a FLAMES primary class or some other more abstract intermediate class and define additional attributes and methods. Any model that inherits one of these intermediate classes will be "plug-and-play" compatible with all other models that inherit the same intermediate class. The definition of intermediate classes thus makes an important contribution to ensuring interoperability between sets of custom models developed by independent organizations.
Models can be implemented at almost any fidelity imaginable. There are limits, of course, to the degree to which models of one fidelity can meaningfully interact with models of another fidelity. While the Kernel can all but guarantee that properly implemented models will be interoperable from a software and database standpoint (physical interoperability), it cannot guarantee that the models will be compatible from a fidelity and algorithm standpoint (functional interoperability). The ultimate responsibility for ensuring model interoperability rests with model developers. However, model class hierarchies and the model management features of the Kernel provide the developing organizations with the required mechanisms that clearly define and even enforce interoperability rules.
The Kernel maintains lists of all objects that exist within the simulation based on the primary class to which each object belongs. Using these lists and the knowledge of the processing requirements of each primary class, the Kernel is able to manage all execution flow within a FLAMES-based application by giving each object the opportunities to perform its required processing at the proper times. This includes not only the functional processing, such as moving or sensing, but also the bookkeeping and maintenance processing. For example, the Kernel knows when the object should be created and destroyed, when each object must read or write its internal data to the FLAMES database, and when the input parameters of the object need to be displayed in a window. The Kernel provides a consistent and common execution environment for all FLAMES models, which relieves application developers from the burden of writing and maintaining the large amounts of code required to manage execution.
Though the Kernel manages all execution flow and is, as such, the initiator of all processing that occurs within a program, nearly all processing that occurs takes place within the models. The amount of processing resources required by the Kernel to maintain lists and invoke methods is hardly measurable. More importantly, nearly all model-to-model interaction takes place directly between the models without involving the Kernel. The result is very efficient processing with negligible overhead imposed by the Kernel.
Many of the models that FLAMES supports can be grouped into one of three categories: those that model some aspect of the functionality of the participants being simulated (called "Units" in FLAMES); those that model real-world messages that are transmitted by some type of communication device; and those that model some aspect of the simulated environment (either natural or man-made). The subsections that follow describe each of these three categories of FLAMES models.
A FLAMES scenario is a description of a situation to be simulated that includes a description of all the participants in the scenario and the environment in which the scenario takes place. Every independent, interactive participant in a FLAMES scenario is referred to as a "Unit." A Unit is, by default, an empty husk that is not capable of performing any function whatsoever. The functionality of a Unit, including its ability to move, sense, communicate, influence other Units, and think, is defined completely by the models that are attached to it. By attaching different types of models, a Unit can represent an aircraft (including the pilot, crew, and all onboard subsystems), the aggregated functionality of an entire armored battalion, an individual missile on its way to a target, an automobile traveling down an interstate, an alien on a distant planet, or almost any other individual or combination of entities.
All models are attached to specific Units in a FLAMES scenario through user inputs. This allows a FLAMES users to "compose" the functionality of each Unit in the scenario without writing software. FLAMES users are thereby given a great deal of control over the definition of the scenario without any requirement for computer programming proficiency. Further, because Unit and model composition is specified through user inputs, no particular composition must be hard-coded in the models themselves. This is one of the many features of FLAMES that supports model plug-and-play compatibility.
There are two main types of models that can be attached to a Unit. Equipment models are generally responsible
for modeling the functionality of the many types of physical devices that
are used by a Unit to interact with its environment and with other Units.
Cognition models are responsible for modeling
human behavior and decision processes. The sections that follow provide
an overview of each of these very important types of FLAMES models.
All FLAMES equipment models are implemented as separate and distinct classes that are derived from one of the eight primary equipment classes. Each of the primary equipment classes inherits a single class called the FEquipment class, which in turn inherits the FEntity class. The Kernel remains completely independent of all equipment models by interacting with each model through the polymorphic methods defined by either FEntity, FEquipment, or one of the primary equipment classes. As a result, equipment models can be modified or added without modification to the Kernel. In other words, the task of integrating new models into a FLAMES-based application, a task that is usually quite onerous in most simulations, is essentially nonexistent.
As has been mentioned, equipment models are generally responsible for simulating the functionality of physical devices. Based on the primary equipment classes, models of almost any type of physical device operating in any domain (land, air, sea, and space) and implemented to almost any level of fidelity can be created. Models can represent the functionality of a complete physical system (such as a fixed-wing aircraft) or of a subcomponent of a device (such as the antenna of a sensor system).
The processing that occurs within equipment models is managed and initiated by the FLAMES Kernel. The various subroutines of equipment models are executed at the appropriate times by the Kernel as the Kernel invokes the methods of the primary class inherited by the model. Methods that are to perform functional processing are usually executed in a time-step fashion at intervals specified by scenario input data. Event-based processing is also supported at the discretion of the model developer.
For example, the FPlatform class, the class inherited by the models that represent various types of platforms and that are responsible for moving Units, defines a "Move" method. Each platform model implements a class-specific version of the Move method in accordance with the performance and motion characteristics of the particular type of platform being simulated. The Kernel maintains a list of all platform objects that exist within the simulation as it executes. (From the standpoint of the Kernel, the list is composed of objects that are all members of the FPlatform class. The specific class identity of each object is unknown to the Kernel.) At regular time intervals, the Kernel loops over and invokes the Move method for all the platform objects in its list. Each platform is then responsible for moving the Unit to which it is attached to the current time.
The bulk of the processing that takes place within a simulation usually takes place within the equipment models. Further, most Unit-to-Unit interaction is simulated through the interaction that takes place between the equipment models attached to Units. Such interaction takes place directly between equipment models without the involvement of the Kernel.
Equipment models can be of almost any resolution or fidelity imaginable. Detailed, engineering-level models or simplistic, stochastic models, and everything in between, can be supported naturally. Through the interface specifications established by the FLAMES primary equipment model classes and by custom intermediate classes, large libraries of reusable, plug-compatible model classes can be established. These classes can then be assembled in various combinations to match the specific modeling and simulation requirement at hand.
Users of FLAMES applications work with equipment models through the friendly graphical user interface provided by the Kernel. Multiple equipment model "templates" can be defined, each of which specify a particular model class and a set of input parameter values appropriate to that class. Templates are used to attach a given configuration of an equipment model to specific Units in a scenario and, thereby, allow a configuration to be used over and over again without redundant data entry. Equipment models can be attached to a Unit in any combination and quantity.
Flexible and powerful simulation of human behavior and decision-making processes has proven to be an elusive goal to simulation developers for many years. However, a simulation that does not adequately represent human behavior has, and will continue to have, very limited application. How to model human behavior was one of the more difficult challenges faced by the developers of FLAMES. The solution took many years to develop and evolve as many different approaches, including the more popular approaches such as expert systems and rule-based schemes, were tested and then abandoned as being inadequate for one reason or another.
A very special class of model called a cognition model forms the foundation for FLAMES human behavior modeling. The methods of a cognition model are referred to as "process methods." Process methods are individual routines written to perform a single, usually relatively simple function that is representative of a function performed by real humans. Like humans, process methods store and process information, generate messages to be transmitted to other Units, process messages received from other Units, make decisions that require other functions to be performed, process information provided by local equipment, and control the equipment to carry out the Unit's assigned tasks.
All cognition model classes inherit the FLAMES FCognition class. Like the other base model classes supported by FLAMES, the FCognition class inherits the FLAMES FEntity class. However, unlike other classes of models, the process methods of cognition models are attached individually to a Unit through scenario inputs.
The Kernel controls process method execution in an event-based environment that supports forward and backward branching, simulated multithreaded processing, situation-based model execution, and input-defined conditional and unconditional branching. This processing environment allows the simulation of almost any conceivable human behavior or decision process, regardless of its complexity. Just as important, the Kernel introduces negligible overhead into the system and allows computer processing resources to be available for use by the process methods themselves.
The scenario inputs that attach a process method to a Unit are actually adding a completely new method directly to the Unit and, at the same time, are also specifying the routine that will be used to execute the method if and when it is invoked. Specifying the methods of an object using input data rather than code is called "data-defined binding." Data-defined binding was pioneered by the designers of FLAMES to provide the capabilities required to model human behavior that even the runtime-binding mechanisms of object-oriented programming could not provide.
Data-defined binding is what allows the Kernel to be fully aware of the human behavior methods that each Unit can support, an awareness that is necessary to control the method execution. Because the Kernel is aware of the methods and in control of all execution, the Kernel is able to intermingle the decisions of real humans with the processing of threads in a manner that is completely transparent to cognition models. This capability forms the basis of one aspect of FLAMES' ability to support distributed, interactive execution.
Through data-defined binding, the Kernel gives scenario developers complete control over the behavior of each Unit in the scenario, something that almost all scenario developers eventually crave. Such control allows nonprogrammers to specify the behavior of Units without the continual requirement for modifications to the software. Further, the Kernel allows the behavior of Units to be altered in the midst of scenario execution by allowing process methods to be added or removed from a Unit dynamically.
Process methods not only give FLAMES-based applications powerful, flexible, and user-controllable human behavior modeling capability, they also provide a very understandable and relatively simple environment for software developers who are responsible for writing simulations that include human behavior. Each process method is structured the same, and the Kernel provides a rich set of services to support all typical process method activity, including message generation and processing, equipment model access and control, and data management. The result is that process methods can be implemented with relatively few lines of code (often less than 200) and can be enhanced and maintained with little effort.
Cognition models are typically designed to make their decisions based upon "perceived truth" rather than actual truth. Much of the perception of the world around a Unit is gathered through the equipment attached to a Unit, such as its sensors. However, a significant part of the perceived situation can be formed through the information that is communicated from one Unit to another. The accurate simulation of the processes that form the perceived situation is often just as important as the accuracy of the decision processes that operate on the perceived situation. Hence, support for the explicit modeling of communications is a must.
FLAMES provides robust support for communications modeling by first supporting models of communication devices, one of the primary equipment model types. Communication device models can represent the functionality of the most complex real-world communication devices. They can also be quite simple in the cases where message transmission is not a critical part of a scenario.
A special class of model, called a message model or sometimes simply a message, is also supported by FLAMES to represent the content of actual voice and data messages that are transmitted between real-world entities. By convention, all information passed between Units must be passed using FLAMES messages with real content if the information would be transmitted through messages in the real world. The result is a greatly increased level of realism in the simulation and an increased level of credibility in the results.
Messages are usually generated as a result of processing that takes place within a process method attached to a specific Unit. A newly generated message is given to one or more of the communication device models attached to the Unit where the message will be transmitted to a communication device model of the receiving Unit. From there, the message will be passed to a message processing model of the receiving Unit, a special type of process method used specifically to process incoming messages. The messages that a Unit can generate, the communication devices attached to a Unit, the messages that a Unit can receive, and the message processing methods used to process each received message are all specified through user inputs.
All messages inherit the FLAMES FMessage class, a class that provides the interfaces necessary for the Kernel to manage message-related processing. The Kernel knows nothing about the specific content of any message and does not need to be modified as new messages are added to an application. Model developers are free to develop any number of messages and to implement any real-world message set desired.
A FLAMES scenario is a description of a situation to be simulated that includes a description of all the participants (Units) in the scenario and the environment in which the scenario takes place. Unit Models described the types of models supported by FLAMES to represent the functionality and behavior of Units. Environment models simulate the natural and man-made environment in which Units act and interact.
FLAMES supports several types of environment models. As with most other FLAMES models, environment models are implemented as distinct, object-oriented classes which each inherit one of the primary FLAMES environment model classes. Each of the primary classes inherits the FLAMES FEntity class.
Users developing scenarios define each object in the initial environment through the graphical user interfaces provided by the FLAMES Kernel. User inputs define the location, size, and shape of each environment object as well as the attributes associated with each object. These objects might include roads, bridges, bodies of water, clouds, rain, and perhaps even storms. The specific types of environment objects that can be defined depend upon which classes of environment models are included in the application. Once defined, environment objects are usually stored in the FLAMES database where they can be used as the basis of scenarios.
Sometimes environment data is available from third parties in computer readable form such as the data supplied by the Defense Mapping Agency (DMA). To reduce the amount of manual data entry required to define a scenario, special FLAMES-based applications can be developed by any FLAMES developer to import this data and create FLAMES environment objects automatically. These objects can then be stored in the FLAMES database along with other manually created objects.
Some aspects of the environment change over time. Wind may change direction, and speed or clouds might move. All such changes would be modeled within the software of the environment model as implemented by the model developer. As with other types of objects, the Kernel maintains lists of all environment objects and gives each object the opportunity to update its own state as simulation time elapses. The Kernel also provides mechanisms whereby environment objects can be created dynamically as a result of some scenario event. Examples might be an explosion resulting from the detonation of a bomb or condensation trails formed from aircraft exhaust.
With a few exceptions, environment objects are passive participants in a scenario. Usually, the models associated with Units, particularly equipment models, loop over the environment objects present in a scenario and extract the information they need to support their own processing.
Some aspects of the environment, such as the terrain and the shape of the earth, are represented by services of the Kernel rather than by models. See the section on the Services of the FLAMES Kernel for more information.
Features represent natural features, such as forests, rivers, and soil, as well as man-made features, such as buildings and runways. While facilities can be developed to import digital feature analysis data (DFAD) as supplied by the DMA, feature models are usually quite a bit more than the simple data available in DFAD. For example, a runway model would typically contain the location and size of the runway along with the algorithms to determine the damage caused by various weapons effects and the methods to repair the damage. A model of a body of water might contain sea state data and algorithms for updating the sea state as wind conditions change over time.
Any part of the environment that is induced as a result of some scenario event and that must exist for a finite period of time is usually best modeled as an effect. During their existence, effect objects can be detected and can cause damage to Units. Effects can also create other effects. Examples of effects might be smoke, explosions, and fire.
Effect objects are not usually defined directly during the definition of a scenario. Rather, templates for effects, like equipment model templates, are defined from which effect objects may be created as a result of a scenario event. For example, an explosion effect template might be created to define the characteristics of an explosion resulting from a particular type of bomb. This template could then be attached to a bomb model which would then create the effect when it detonated. This type of effect would likely become an active participant in the scenario and cause damage to other objects in the scenario.
Atmosphere models, due for official release in a future version of FLAMES, represent atmospheric conditions in a given volume of space. Such conditions can include pressure, density, temperature, humidity, and wind speed, among others. The size, shape, and position of the volume, as well as the conditions within, can change with time, depending on the implementation of the model.
Airspace models are used to describe volumes in space or areas and lines on the ground that have relevance to the processing occurring within other models in the scenario, particularly process models. Missile engagement zones and transit corridors are examples of airspace models.