The entire FLAMES® product line is completely independent of software that simulates the behavior of humans and real-world systems. Such software resides in components that are stored in component plug-ins. FLAMES applications automatically load, integrate, and make use of the components stored in the designated plug-ins. As a result, with the proper component plug-ins, the FLAMES Runtime Suite can be used to simulate any type of system in any physical domain (land, sea, air, and space) at almost any level of fidelity and resolution imaginable. The Runtime Suite is bundled with many ready-to-use components, and, with the FLAMES Development Suite, you can modify the bundled components and develop new components.
This topic provides an overview of the major types of components supported by FLAMES.
A FLAMES component usually simulates the attributes and behavior of something that exists in the real world, such as a human, vehicle, sensor, communications device, or weapons effect. This type of component is often referred to as a “modeling component” or simply a “model”. Other types of “infrastructure” components are also supported, such as a management service or an interface to an external system.
In every case, a FLAMES component is implemented as an individual software class that inherits one of the FLAMES primary classes. These classes define the overall structure of the components and specify the methods that the components must implement. The primary classes also include built-in functionality for parameter graphical user interface generation and management; storing and retrieving parameter values in the FLAMES Scenario Database; object creation, management, and destruction; player composition; and execution control. FLAMES defines a primary class for every type of component that might be required in a simulation.
Every independent, interactive player in a FLAMES scenario is referred to as a “Unit.” A Unit is, by default, an empty shell 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 composed using FORGE™ by attaching components (models) to the Unit. 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.
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. Models can be created of almost any type of physical device operating in any domain (land, air, sea, and space) and implemented to almost any level of resolution or fidelity. Detailed, engineering-level models or simplistic, stochastic models, and everything in between, can be supported naturally. 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).
FLAMES supports several types of equipment models, each of which is analogous to a real world physical device.
- Communication Devices – simulate the reception and transmission of messages. The content of messages are stored in message models.
- Data Processors – simulate computer devices, such as stand alone computers, command and control systems, and radar data processors.
- Jammers – simulate devices that emit electromagnetic signals in an attempt to disrupt the processing of other electromagnetic devices, such as radars and communication devices.
- Sensors – simulate detection devices, such as radars, infrared sensors, and sonar devices.
- Platforms – simulate air, land, sea, and space vehicles.
- Subsystems – simulate sub-components of larger devices.
- Weapon Systems – simulate systems that fire or launch munitions at targets in an attempt to destroy them.
- Munitions – simulate devices that are fired or launched by weapons systems, such as bullets, artillery rounds, and missiles.
FLAMES initiates and manages the processing that occurs within equipment models by invoking various methods of equipment models at the proper time, usually in a time-step fashion. Event-based processing is also supported at the discretion of the model developer. 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 usually takes place directly between equipment models and is therefore very efficient.
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 popular approaches, such as expert systems and rule-based schemes, were tested and then abandoned as being inadequate.
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 process that is representative of a process performed by real humans. Among other things, process methods control the equipment attached to the Unit, process information provided by the equipment, generate messages to be transmitted to other Units, process messages received from other Units, and make decisions that require other processes to be performed.
FLAMES controls process method execution in an event-based environment that supports multiple, simultaneous thought processes, situation-based model execution, input-defined conditional and unconditional branching, and the seamless integration of decisions made by real human operators. This processing environment allows the simulation of almost any conceivable human behavior or decision process, regardless of its complexity, with negligible management processing overhead.
Attribute models contain additional attribute data that can be attached to and used by another model. One example of an attribute model is a DIS attribute model that contains the parameters needed to describe an entity to other simulations in a DIS exercise. By placing these attributes in a separate model, other entity models can be implemented without concern for the special parameters required for participation in a DIS exercise. Another example of an attribute model is a radar cross-section table. By placing radar cross-section data in an attribute model, this data can be omitted from platform models, and multiple radar cross-section tables (for multiple electromagnetic wavebands) can be associated with a single platform.
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.
A special class of model called a message model, or sometimes simply a message, is 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 is 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 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 attached to the receiving Unit. From there, the message is passed to a process model of the receiving Unit.
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 components (models) simulate the attributes and behavior of Units. Environment components (models) simulate the natural and man-made environment in which Units act and interact.
Some aspects of the environment, such as the shape of the earth, the terrain, and cultural features, are represented by the built-in capabilities of FLAMES. Other aspects of the environment are represented by environment models. FLAMES supports multiple types of environment models, including the following:
- Atmospheres – simulate 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.
- Effects – simulate temporary changes in the environment that are induced as a result of some scenario event, such as the impact of a missile. During their existence, effect objects can be detected and can cause damage to Units. Effects can also generate other effects. Examples of effects might be smoke, explosions, and fire.
- Airspaces – describe volumes in space or areas and lines on the ground that have relevance to the processing occurring within other models in the scenario. Missile engagement zones and transit corridors are examples of airspace models.
View overlays display supplemental information on top of a the 2D and 3D views of FORGE and FLASH. The Draw method of each active overlay for a given view is invoked each time the view is refreshed and immediately after the underlying map or terrain is drawn. Just about anything can be drawn in an overlay, from simple lines and text annotation to full instrumentation for a heads-up display. Each overlay class can also define a view preferences object that will automatically be included in the View Preferences windows of FORGE and FLASH.
Most FLAMES components simulate the attributes and behavior of something that exists in the real world. However, FLAMES also supports other types of “infrastructure” components that can customize and augment the functionality of FLAMES and FLAMES-based applications.
The foundation class for most infrastructure components is the FLAMES FService class. Consequently, infrastructure components are often referred to as “services”. FService is the class from which nearly all FLAMES core services are derived. The same FService class is available in the FLAMES Development Suite to be used as the foundation for custom services.
Custom services can have their own datasets in the FLAMES Scenario Database, and they can have their own windows in FORGE and/or FLASH. They can be included in all the main processing activities performed by FLAMES applications. As a result, custom services can extend the functionality of FLAMES in almost any way imaginable.