1. Towards Dynamic Federations
Björn Möller
Vice President, Pitch Technologies
Vice Chairman, HLA IEEE

2. It’s All About the Being Dynamic
The requirements of both traditional defense operations and PSO operations are highly dynamic
And so should our solutions be!
We need to develop solutions in a highly dynamic fashion
To meet changing requirements, to evolve over time, to utilize different suppliers, communities and Subject Matter Experts (SMEs)
We need to dynamically compose and extend our fielded solutions
Update our shared picture of environments, resources, services, operations, effects, etc
We need to deploy in a dynamic fashion
Dynamic configurations, local and remote resources, mixing generations of technologies, systems from different suppliers, systems with different requirements for fidelity

3. Federation – Some Definitions
“A form of government in which powers and functions are divided between a central government and a number of political subdivisions that have a significant degree of political autonomy.”
”An alliance which has gone one step further in recognizing that the commonality of objectives is of a continuing nature, and the shared objective can be furthered by giving a stable and formal character to the alliance.”
”A named set of federate applications and a common federation object model that are used as a whole to achieve some specific objective.”

4. About the High Level Architecture (HLA)
All Types Of Simulation
Intelligent Data Distribution
Flexible Information Model
Standard Service API
Open Systems Architecture
Staff-Level Training / CAX
Computer Generated Forces
Run-Time Infrastructure (RTI)
Platform Simulations/Trainers
Interface to Live players & systems
Interface to C4I Systems
Federate = One system that is connected using the RTI
Federation = All federates together

5. Two Topologies for Information Exchange
System to System
Information Bus B A B C A C
Information Bus
Only need to consider the needs of two systems at a time
Adding new systems may require modification of existing systems
Quick development, less reuse, lower scalability
Should define a common information model
New systems can be plugged in without modifying existing systems
Requires more design but gives better reuse and higher scalability

6. Development of the HLA Standard
Baseline
HLA to IEEE
for standardization
First certified 1516 RTI
HLA
Initial definition
HLA adopted
by OMG
First 1516 RTI
1516 to 1.3 interoperability
Older standards:
ALSP
DIS
DoD Masterplan
HLA 1.3 standard
HLA 1516 standard
First 1516 federations
HLA 1516 evolved
HLA 1.3 US DoD standard
IEEE 1516 open standard

7. What’s New in HLA Evolved
HLA Evolved is the working name for the next version of HLA, with the formal name IEEE
Developed as an open, international standard
Major new features
Modular FOMs
Web Services API (including authentication and encryption)
Web Services connection over Internet to a simulation
Includes authentication and encryption
”Connect” operation
enables authentication, encryption, etc
Fault Tolerance support
Evolved Transportation Types
Now we can build RTIs for IPv6, Quality-of-services
Smart Update Rate Reduction
Example: Flight simulator gets updates at 30 Hz, Command and Control system gets updates at 1 Hz

8. Dynamic Feature Chart ● Federations *) Explicit and shared FOM *)
Dynamic Development
Dynamic Composition
Dynamic Deployment
Federations *) ●
Explicit and shared FOM *)
Publish / Subscribe *)
Modular FOMs
Federations as services using the Web Services API
Connect/Authenticate
Fault Tolerance
Update Rate Reduction
Flexible Transportation Types
*) Classic HLA feature

9. Explicit and Shared FOM
The Information Exchange Data Model (IEDM) is explicitly defined using XML format
Supports any domain
May be developed or extended when needed
Loaded at runtime
”The language of the federation”

10. Modular FOMs

11. What Are FOM Modules? The same FOM as before but divided into modules
Human
Italian
LifeForm
HLAObjectRoot
Lamborghini
Car
Ferrari
The same FOM as before but divided into modules
Support for decoupling the development process for different concerns
Example: RPR platform concerns, sensor concerns, federation management concerns
A way to separate standard FOM concepts from local or temporary adaptations
Allows joining federates to extend the Information Exchange Data Model

12. How to Use FOM Modules
Local RPR
Extension
Real Time
Reference Platform
(Standard) FOM
My Federation Management
Data Logger Control
MOM Module
Object & Interaction Roots, Predefined Data Types, MOM
A Module can add new object and interaction classes,

13. Life Span of FOM Modules
time
My FlightSim
Create Federation
Execution
Local RPR Extension
My Federation Management FOM
RPR FOM
My Fed Mgmt
My Federation Management FOM
Standard RPR Viewer
RPR FOM
MOM Module
Once loaded a FOM module will remain available until the federation execution is destroyed

14. Expected Benefits
More efficient development of shared information models
By community / SMEs
For particular purposes
Easier to compose FOMs for each specific purpose
Easier to separate specific parts of a FOM from standard FOMs
Support for long-running federations
”Virtual Arenas”

15. Excerpts from my IITSEC 2007 Tutorial
Web Services API
Excerpts from my IITSEC 2007 Tutorial

16. Simulations Can be Provided as Services
Virtual Training Center
Internet
User: GI5532
Password: *********

17. An External View of an RTI Implementing the WSDL API
WS Federate
Zero or 1000 miles away!
WS Provider
An RTI that intends to provide the WSDL API must provide a Web Service locally or remotely to the federate. This service will be referred to using a Web service address, for example ”rti.company.com:8080”
This is called the Web Service Provider RTI Component (WSPRC)
Should use a comma in 10,000 as oppose to a space.
What does ”This” in second sentence of bullet refer to? ”Service”?

18. Web Service Provider RTI Component
C++ API
Federate
Java API
LRC
WSPRC
CRC
WSDL API

19. Use of https and Server Side Certificates
Virtual Training Center
Internet/ Intranet
CERT
Guarantees training
center not spoofed
User: GI5532
Password: *********
See also ”Connect”
coming later
Encrypted connection
(desired strength)

20. Federates Using Different APIs Can Be Mixed
WSDL API FED
C++ API Fed
Java API Fed
RTI Supporting all APIs
Suggest rewording bullet to ”Federates cannot tell what API other federates are using”.
Transparency: Federates cannot tell what API other federates are using

21. A Comparison Mechanism Calls per second Coupling Call Topology
Transfering 100 bytes on/between Windows 3.6 GHz hosts
Mechanism
Calls per second
Coupling
Call
Topology
Local C++ function call
10,000,000
Tight
Local only
RTI exchange
using C++/Java API
100,000
Loose
Local or
remote
RTI using WS API
3,000
Very loose

22. Building a WSDL Federate
Simulation
Code Generator
WSDL
Call Stubs
HLA1516e.wsdl
Code that makes Web Service calls can be generated automatically
C++, Java, C#, ADA, Visual Basic, Fortran, Cobol, Perl, ...
Sample providers: IBM, Microsoft, Sun, Apache/Axis, IONA, ...
2nd bullet: is it ”this example” or ”these examples”?

23. HLA as an Enterprise Service Bus
Web Services
Web Services
Web Services
Web Services
Web Services
HLA
The next generation of SOA, currently known as ”Contemporary SOA” provides more sophisticated message exchange patterns
One central concept is the Enterprise Service Bus
HLA using Web Services is a good example of such a Bus
Already available
Also provides alternate, high-performing access through C++ and Java APIs

24. Some Engineering Support
Early experimentation:
XMSF Work
During standards development
IITSEC 2005 Federation
Service group tests
Federate in a cell phone
https tests (secure and authenticated)
Real projects
Anti-terrorist scenario simulation (US), not yet public
More underway

25. HLA and Web Services - Conclusions
There are several ways to combine HLA and Web Services. The most powerful one, the HLA Web Services API has been described:
Web Services for M&S creates opportunities for development and deployment in a substantially larger number of environments than before
Programming languages, operating systems, devices network environments, communities, etc
The most important long-term benefit of Web Services is that it promotes the idea of simulations as readily available services.
2nd bullet; opens up what? HLA? M&S?

26. Connect / Authenticate
Federate 1
Federate 2
Federate 3
Connect
Join
RTI
New ”Connect” operation required before joining
Provides arguments for authentication
Open mechanism – can be adapted for different types of authentication like passwords, certificates, biometry, ...
Can be mixed with the Web Services / https

27. Fault Tolerance Support

28. Communications (Network etc)
Fault levels
Users
Federation
Federate
Federate
RTI Component
RTI Component OS OS
Computer
Computer
Communications (Network etc)

29. Faults Federate Federate Federate RTI
Federate Lost!
Federate Lost!
Connection
Lost!
Federate
Federate
Federate
RTI
Some fault detection methods for the RTI are described in my paper.

30. Fault Definitions
A fault is defined as an event that has occurred that prevents the entire federation from executing together in an HLA compliant manner
Fault 1: Federate Lost
A federate was unexpectedly lost from the federation.
This is a fault seen by federates within the remaining federation
May depend on problems in the lost federate, communications, RTI, etc
The RTI will resign this federate using the Automatic Resign Directive
Fault 2: Connection Lost
The federation was unexpectedly lost from a federate
This is a fault seen by an ex-federate that is no longer part of the federation
The RTI will try to signal the problem to the federate. This may or may not be attempted and may or may not succeed. This federate may have crashed!

31. Sample Design Pattern for Fault Tolerance
Active Federate
Stand-by Federate
Federate
Federate
Federate
RTI
Seven design patterns for Fault Tolerant Federations have been developed
Published in SISO paper
Example above

32. Smart Update Rate Reduction

33. What is the Problem?
HLA publish/subscribe and DDM filtering are very powerful but represent a ”binary” approach to the problem of reducing the update rates.
You either get the data or you don’t. No way to control the data rate.
A Real-Life Example
A large federation was under development. One federate was very complex and detailed. Others simulated only a few entities but with high time resolution.
An analysis showed that it would not be possible for the complex federate to accept incoming data at the high time resolution. This would result in the entire federation slowing down.

34. More Aspects of this Problem
Different communities A flight simulator may create position updates at 30 Hz. A C4I system needs these updates but only at 1 Hz.
Focusing on some entities A system wants to get 30 Hz update rate for platforms when they become active threats and 5 Hz otherwise
Highly distributed We want to get updates at 5 Hz from flight simulators that are located in another site but 30 Hz for local simulators

35. Solution
Subscribers should be able to provide the update rate they need when they subscribe.
The RTI can take away unwanted updates and/or
The producer may vary the produced update rate
Can potentially produce updates at 30 Hz. May optionally be able to vary the update rate.
Slow
Subscriber
Fast Subscriber
Publisher
Subscribe
Low (1 Hz)
Subscribe
High (10 Hz)
TurnUpdatesOn
High (10 Hz)
RTI

36. Flexible Transportation Types
HLA originally provided two types of transportation:
Reliable
Best Effort
HLA Evolved adds the opportunity to negotiate additional transportation types and to fall back if they are unavailable. Examples:
Priority Best Effort for certaion updates
Guaranteed 2 Mbps for certain updates
IPv6 if available, otherwise IPv4
Enables quality of service and increased deployment flexibility
Note that the actual availability of a certain transportation may vary between RTIs and deployment environments

37. Summary
A number of new features have been added to HLA in order to support dynamic federations. At the same time the existing capabilities and high performance has been maintained.
Dynamic Development
Dynamic Composition
Dynamic Deployment
Federations *) ●
Explicit and shared FOM *)
Publish / Subscribe *)
Modular FOMs
Federations as services using the Web Services API
Connect/Authenticate
Fault Tolerance
Update Rate Reduction
Flexible Transportation Types