Difference between revisions of "Federate Simulation Bridge"
Jump to navigation
Jump to search
| Line 11: | Line 11: | ||
{{quote-diesis|The coupling between the different CI simulators has to be “intelligent” in some way to provide a “bridge” between the different, very heterogeneous simulators. These “bridges” have to be created where physical, logical or [[cyber dependency | cyber (inter)dependencies]] between infrastructures occur. Starting from a basic model of these dependencies, these bridges will be created at runtime to create a [[federated simulation]] between existing simulators dynamically. In order to provide this capability, the bridges have to contain several functions and have to be supported by additional components, including: | {{quote-diesis|The coupling between the different CI simulators has to be “intelligent” in some way to provide a “bridge” between the different, very heterogeneous simulators. These “bridges” have to be created where physical, logical or [[cyber dependency | cyber (inter)dependencies]] between infrastructures occur. Starting from a basic model of these dependencies, these bridges will be created at runtime to create a [[federated simulation]] between existing simulators dynamically. In order to provide this capability, the bridges have to contain several functions and have to be supported by additional components, including: | ||
* a Knowledge Base System (KBS) - shared among the [[federate]] subjects – able to gather, filter and maintain traces of any possible synergic actions driving a [[federated simulation]] | * a Knowledge Base System (KBS) - shared among the [[federate]] subjects – able to gather, filter and maintain traces of any possible synergic actions driving a [[federated simulation]] | ||
| − | * a basic [[model]] to containing a specific scenario (including initial situations, maps, etc) and a description of dependencies. A [[scenario]] can also include some kind of script to | + | * a basic [[model]] to containing a specific scenario (including initial situations, maps, etc) and a description of dependencies. A [[scenario]] can also include some kind of script to introduce faults and attacks into running [[simulation]]s |
* a versatile timing mechanism to manage the synchronism inside the [[federated simulation]].}} | * a versatile timing mechanism to manage the synchronism inside the [[federated simulation]].}} | ||
Revision as of 17:39, 4 September 2014
Contents
Definitions
European Definitions
DIESIS project
The DIESIS project [1] gives the following definition:
The coupling between the different CI simulators has to be “intelligent” in some way to provide a “bridge” between the different, very heterogeneous simulators. These “bridges” have to be created where physical, logical or cyber (inter)dependencies between infrastructures occur. Starting from a basic model of these dependencies, these bridges will be created at runtime to create a federated simulation between existing simulators dynamically. In order to provide this capability, the bridges have to contain several functions and have to be supported by additional components, including:
- a Knowledge Base System (KBS) - shared among the federate subjects – able to gather, filter and maintain traces of any possible synergic actions driving a federated simulation
- a basic model to containing a specific scenario (including initial situations, maps, etc) and a description of dependencies. A scenario can also include some kind of script to introduce faults and attacks into running simulations
- a versatile timing mechanism to manage the synchronism inside the federated simulation.
