Domain-Specific Middleware for Modelling and Simulation: HLA RTI
Mike Dean
Division Computer Scientist
BBN Technologies / Verizon
CptS 464/564 Guest Lecture
Washington State University
30 October 2000
linked from class web page
$Id: all.htm,v 1.3 2000/11/06 02:46:32 mdean Exp $
Overview
- HLA RTI Technical Details and Design Tradeoffs
- Motivations and Experiences Using HLA RTI
HLA RTI Background
Distributed Interactive Simulation (DIS) Protocol
- developed in 1980's for BBN's SIMNET program,
linking hardware-in-the-loop tank simulators
- unreliable, broadcast messaging
- standard Packet Data Unit (PDU) formats
- ghosting/projection to deal with packet loss
- real time
- IEEE Std 1278
- see http://www.sisostds.org/doclib/doclib.cfm?SISO_CID_16
Aggregate Level Simulation Protocol (ALSP)
- developed by
MITRE in early 1990's to link existing
warfare and training simulations
- reliable, text-based protocol
- stream interface (no API)
- higher-level abstractions (inheritance, attribute-level subscriptions)
- time management
- most projects developed a framework on top of ALSP primitives
- see http://alsp.ie.org/alsp/
HLA RTI
- essentially union of DIS and ALSP capabilities
- abstractions
- objects and attributes -- persistent (create, update, remove)
- interactions with parameters -- transient
- communication
- reliable / unreliable
- time-stamp-ordered / receive-ordered
Key HLA RTI Features
- Time Management
- each federate can be time-constrained and/or time-regulating
- optimistic / pessimistic
- Data Distribution Management (Regions)
- Ownership Management
- Management Object Model
HLA RTI API
- ambassadors -- 2 C++ objects per federate
- federate calls RTIAmbassador
- RTI invokes callbacks on specialization of FederateAmbassador
- C++ API, wrapped by Java, Ada, etc.
Interesting RTI Design Choices
- expects use of a framework
- "hello world" example is ~2000 lines
- I developed a set of RTIHelper classes for Java, C++, and Common Lisp
reducing this to ~30 lines
- attribute and parameter values are uninterpreted sequences of bytes -- up to higher layers to standardize and interpret
- Federation Object Model (FOM) provides detailed specification,
but currently mostly documentation
Our Application
- DARPA-sponsored research program investigating the applicability of control theory to air operations
- 14 groups developing controllers for different portions of the problem
- 2 groups (including us) developing competing enterprise models (plant)
- different data requirements for all 28 pairs
- multiple programming languages: C++, Java, Lisp, MATLAB
Desired Solution
- standard interface to both enterprise models
- publish/subscribe
- simulation time management
- ability to run over the Internet (if necessary)
Besides ...
- both enterprise model teams were using simulation engines that
already worked with HLA
Things Change ...
- working with both EMs seems onerous: 7 controller developers assigned
to each enterprise model
- controllers aren't as mature as hoped -- enterprise models may not be needed: other enterprise model cancelled -- 3 controllers assigned to us, then 2
Experience
- HLA RTI did the job we asked it to
- expended 2-3x effort expected
- performance became a concern
- poor ability to integrate RTI with another event loop -- had to poll
- inability to call native interface from Lisp -- source code not available
- investigations
- RTILite: in-memory subset
- RTIff: Lisp foreign-function interface direct to C++
My New Project: DARPA Agent Markup Language (DAML)
Questions?