Towards Dynamic Federations Björn Möller Vice President, Pitch Technologies Vice Chairman, HLA IEEE 1516-2007

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

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.”

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

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

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 95 96 97 98 99 00 01 02 03 04 05 06 ... 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

What’s New in HLA Evolved HLA Evolved is the working name for the next version of HLA, with the formal name IEEE 1516-2007 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

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

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”

Modular FOMs

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

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,

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

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”

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

Simulations Can be Provided as Services Virtual Training Center Internet http://mytraining.army.mil/PSOscenario User: GI5532 Password: *********

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”?

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

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

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

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

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”?

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

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

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?

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

Fault Tolerance Support

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

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.

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!

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

Smart Update Rate Reduction

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.

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

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

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

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