Information on Passing Information and Coordinating Simulations
This is a quick review of the common methods used to combine JFORCES execution with the execution or results of other models. It does not directly reference the gateway method for linking to operational systems.
When evaluating acceptable methods to combine JFORCES with other simulations, we generally find that the methods break down into one of the following categories.
DATA COUPLING - Using the results of execution from one or more models as input to another. Often this takes the form of table look-ups with a number of independent variables used as indices.
MICRO-INTEGRATION - Using selected processes (algorithms and/or subroutines) from one model in combination with selected processes from a second model and combining them into a single execution stream.
MESSAGE COUPLING - Tightly coupling the functions of various models via message stimuli. This usually involves shared or distributed Object and Environmental data and employment JFORCES Executive controlled gateways. These gateways are asynchronous processes that provide two-way communications with an exec-based simulation and offer interfaces for common clock controls. They also handle the marshaling of data for external systems or for insertion into a JFORCES execution by using the ICD library.
CONFEDERATION - Loosely-coupled multiple models with asynchronous execution facilitated via a well defined interface. This is done using DIS or HLA standards and by assigning the ownership/master-control of individual assets to autonomous Physical or Logical nodes.
Somewhere I have a formal write up of a few pages on each of these and I’ll pass it along when (and if) I can find it in my archives. But I know that you’re short on time, so let me informally describe each of these methods in terms of what they are, how they’re invoked, and whether I see them applicable to December demo.
Data Coupling – This is essentially a formalized approach to the standard “tennis shoe interface” of plugging data from one model into the other. The two models do not run concurrently, instead the one models (or a series of models) are run to prepare an input set of data for the final model. This is a common method across most of the simulation community that reduces runtime in large models where the values gained by actual integration do not warrant the costs. But this cost is saved at the expense of being able to dynamic changes situations within the limits established by the dataset.
JFORCES offers a number of SQL-based procedures to provide quick incorporation of external datasets in to the simulation as well as a standardized library of techniques to exploit the data, making data coupling easy.
Micro-integration – This is simply taking a simple model and incorporating it in total into JFORCES (or any other simulation). Where possible, this can be very beneficial because you take a (normally) proven set of code and surround it with a much more robust environment, sensor, threat and so forth environment to better understand the how the functions it represents interact with the real world. The model is called s appropriate to the execution (e.g. legacy sensor models are called every sensor scan). The multi-language, multiplatform architecture of JFORCES was initially largely written to implement this approach.
Message Passing – This is a true peer-to-peer approach for running clusters of simulations along with range articles, live systems, trainers and so forth. I believe that this is where we should concentrate our efforts for this demo. Basically, when modeling real systems, the simulation models send messages with operationally reasonable contents at times commiserate with that system. So if a sensor would send a detection report message at a given time to a C2 the sim would connect to the entity (or entities) that should receive that message and transmit it. Comments:
This method is the most appropriate for interacting on a non-disruptive basis with live systems
When required, the actual message format is also employed. But generally this is not the done because it creates extra time to marshal and unmarshal the data as well as requiring extra coding.
Typically, the simulation timing differ slightly relative to the real world. In most cases we try to deliver sensor messages within the same scan frame (where appropriate). JFORCES also attempts to deliver operational messages within 10 seconds of when they’re supposed to be delivered. So if a message is supposed to be immediate we attempt to deliver it within 10 seconds, if the message would typically be delivered in 15 minutes (900 seconds) JFORCES would attempt to deliver it within 890 to 910 seconds. But these delivery tolerances can be tightened at need, this is just the default.
This system is very useful for delivering false alarms and other messages representing the fog of war.
If the true message formatting is not used it is acceptable to incorporate additional information to support data analysis. For example, a field of a sensor report might identify whether the report relates to a simulated asset or is a false alarm. But this type of information is not passed to any intelligent agents (including operators) during the scenario execution.
There are many benefits of employing this integration approach. The only downside is that polite conventions must be observed (as is common when integrating simulations). For example, generally it must be assumed that if an asset did not originate from a local simulation its control is managed elsewhere and changes should not be made directly to that asset, although it's OK to send it commands (e.g. head north) or request the host perform maintenance tasks (e.g. kill it based on an engagement result).
To summarize, messages logically originating from an asset (e.g. position or sensor reports) are typically sent from the host computer for that asset (or a combination of the gateway software and player for non-simulated assets). They are sent in the most operationally realistic manner consistent with performance execution and study objectives. Within software controlled by the exec they're sent to the application instance associated with that asset, when bridging to external connections the information is sent to the associated gateway (which looks list an application instance to the rest of the sim). The gateway is then responsible for forwarding the message. This can include changing transfer media (e.g. going to a serial port or a radio, or a non-exec controlled LAN socket) as well as remarshaling the data as appropriate for the destination.
Confederation – This is the standard HLA/DIS approach to combining multiple sims. I’m not going to take must time here to discuss it since these methods are well covered in the literature. JFORCES has a 1278.1 compatible gateway to DIS , although (as with most simulations) only the PDUs required for a limited prior study have been implemented. This includes detonation messages, entity states, freeze_stop, start_resume, fire and acknowledge.
The HLA RTI employed by JFORCES is version 1.3NTv4. The FOMs employed have been built around confederating with the Virtual Interactive Target simulation that provided CAD/CAM quality diagrams of the results of a weapon impacting a building. Since HLA confederations are FOM-specific, no significant time will be spent explaining the details beyond stating that the either the FOM would have to be negotiated for new HLA confederation or the RPR FOM could be wrapped around the DIS interface.
It should be mentioned that neither HLA or DIS are reasonable methods for integrating with real-world systems. This is simply because they're simulation-centric. Operational systems should not be modified to fit into executions. While some people believe that it's no different than employing gateways, gateways do not affect the operational system and typically run remotely from that system. This permits the operational system to run just as it would in live operations.