|
|
 |
| |
|
| |
What is a Model or Simulation hierarchy?
|
This topic requires an introduction to the phrase "model or simulation level." The two terms that help clarify this concept are "fidelity" and "aggregation." A model or simulation that is "high fidelity" represents a process or entity with significant detail (a model that is on the bottom, or lower level, of the hierarchy). A model or simulation that is "highly aggregated" does not have much detail; processes and entities are represented in an abstract manner (a model that is on the top, or higher level, of the hierarchy). Therefore, "low fidelity" is equal to "highly aggregated"; combinations of "low," "high," "fidelity," and "aggregation" can be confusing.
|
|
Hierarchies add structure to related models and simulations that are at different levels of fidelity or aggregation and are in the same domain. At the top of the hierarchy (high level) are the abstract models and simulations; these are the low fidelity, high aggregation models and simulations. At the bottom of the hierarchy (low level) are the high fidelity, low aggregation models and simulations. For example, military operations, engineering, and transportation simulations could belong to the following examples of hierarchies.
|
|
|
Where a simulation fits into its domain hierarchy is often referred to as its "level" in the hierarchy. In the military operations the lowest level is often called the "engineering or system level," the next level up is called the "mission level," the next level name usually takes on the designation of the largest unit in the group being simulated, and the highest level is normally referred to as the "theater or regional conflict level."
|
|
There are several ways models and simulations in a hierarchy are linked. It is possible that a higher level simulation is just a combination of all the essential simulations from the level below it, with all the appropriate interfaces that make them communicate properly. This is no trivial undertaking. Even if all the communications work properly, the computational time needed to run the combined simulations may be excessive. In addition, the data needed to run all these detailed simulation can be difficult to gather and maintain. So, what appears on the surface to be good way to build high level models or simulations is not always practical. This approach is more effective for simulations used in training than it is for simulations designed for decision support, design, process analysis and research.
|
|
The most logical and practical way to link the simulations is to identify for the higher level simulation the proper, aggregated representation of detailed processes and/or entities that are already represented in lower level simulations, and then determine if and how the lower level (i.e. high fidelity) simulations can be run to provide the data needed for the more aggregate representation. For example, when engineers want to look at alternative weapons handling systems on an aircraft carrier, they could develop or modify an existing simulation of a weapons handling system. The real measure of effectiveness of the alternative weapons handling systems is how they impact flight operations on the carrier; so it appears that it would be logical to put the weapons handling simulation(s) into an aircraft carrier simulation. This of course takes time and money, and each variation of the weapon handling system simulation must be integrated into the architecture of the aircraft carrier simulation. If all the parameters (inputs and outputs) remain the same for all the variations of the weapons handling simulation(s), this interface can be generalized. This requires time and money and a commitment from the simulation developers that may or may not exist.
|
|
The better approach would start with the carrier simulation. A series of carrier simulation runs can help analysts determine which of the weapons handling output parameters significantly impact flight operations(e.g. time to move each weapon type to the flight deck, delay times when different subsystems fail, etc.). Recognize that almost all weapons handling output will have some impact on flight operations, but not necessarily an impact that is large enough to worry about. Once these parameters are identified, it is possible to develop an "aggregate" model (i.e. representation) of the weapons handling system that relies on the alternative, high fidelity weapon handling simulations to develop needed input data. Normally this input data would be a series of probability distributions for the parameters in the aggregate model. The weapons handling system engineers could then run their high fidelity simulations thousands of times, accounting for the alternative designs, to develop these probability distributions. The aggregate model and the probability distributions can be used in the carrier simulation in a much more efficient manner than the detailed simulation of the weapons handling system. The engineers that know all about the detailed weapons handling system can now concentrate on building weapon handling systems,) and not worry about how they can integrate their simulation(s) into a higher level simulation. More detail is not necessary.
|
|
Unfortunately, not all simulation developers understand why this is often a more practical solution. There are times when a detailed simulation should be integrated with a higher level simulation, mostly in training simulations, but this is the exception rather than the rule. When including the detailed simulation in a higher level simulation is the best approach, it should be noted that the higher level simulation will have aggregated representations of processes or entities that are just as important as the one represented in detail. When this is done, the assumptions made in the aggregate representations may "wash out" some or most of the impact that is induced by the added detail in the high fidelity simulation, making the integration an interesting exercise, but one of no value.
|
|
In summary, model and simulation hierarchies exist to help organize models and simulations in the same domain. In some cases there is no actual link among simulations; the hierarchy is there to help describe how the domain is represented in different simulations. Most often the hierarchy provides the basis for actually defining how simulations are organized, how data is exchanged, and, when applicable, how actual real time joint utilization occurs.
|
| |
| Download as Word Document |
| Download as PDF |
|
|
.gif){kind=spacer}
