Stephen T' Bachinsky

1
Using the IEEE 1516.1 RTI C API

Stephen T. Bachinsky Frank J. Hodum SAIC Inc.
J. Russell Noseworthy OSC Inc.
2
What is the HLA C API?

• The components of the HLA are
• Rules - general tenets on HLA usage
• Interface Specification - functional service
  descriptions
• Object Model Template - representation format for
  public data
• An Application Programmers Interface (API)
  defines how software components invoke operations
  and exchange information
• The HLA APIs rigorously define the Interface
  Specification services using the particular
  programming language constructs
• C, Java, Ada, and CORBA languages are supported

3
IEEE C API Changes

• Modifications due to Interface Specification
  changes
• Modified Header File Structure
• Usability and Robustness Improvements
• Standard C Constructs
• Implementation Extensibility
• Unspecified tick behavior

4
Overview of IEEE Interface Specification Changes

• Major Changes
• Publication/Subscription Semantics
• DDM Single Routing Space
• Callback Mechanism
• Minor Changes
• Object Instance Handles
• required to be unique across federation
• Time Stamps
• supported for non-time managed federates
• Management Object Model (MOM)
• using XML for representation
• Federation advisory switches

5
Header File Layout Changes

• RTI_SpecificConfig.h
• Hides type definition details associated with
  particular platforms or compilers
• RTI_SpecificTypedefs.h
• Contains definitions that are exposed to the
  users, but are specific to the particular RTI
  implementation

RTI_Typedefs.h
RTI_1516.h
RTI_SpecficConfig.h
RTI_SpecificTypedefs.h
RTI_FederateAmbassadorServices.h
RTI_RTIambassadorServices.h
6
Usability and Robustness Improvements

• Consistent Interface and Behavior for Container
  Classes
• Standard interface and behavior for container
  support classes
• Opaque Support Classes
• Implementation details of support classes are
  hidden from the user to avoid exploiting
  non-standard behavior
• Strict Memory Semantics
• Programming constructs used to ensure proper
  memory management between the federate and the
  RTI
• Strong Type Safety
• Type wrappers are used to provide compile time
  safety, previously a user could provide invalid
  data types to the RTI

7
Standard C Library

• C defines a number of standard support classes
• containers, iterators, and algorithms (formerly
  STL)
• iostreams
• string
• Part of the international standard (ISO/ANSI)
• work began in Dec 1989, approved in Sept 1998
• Current Status
• compiler vendors and third party library vendors
  have been tracking standards process and some are
  compliant
• a number of freeware packages exist that support
  the key elements of the standard C library

8
Pros/Cons with using Standard C Library in RTI
API

• Pros
• a well defined standard with emphasis on
  performance
• reuse existing code that is well tested and
  maintained
• HLA standard should be forward thinking
• Cons
• implementations are not fully standard compliant
• learning curve associated with STL operations

9
Standard C Library Usage Issues

• Lack of Compiler Support
• can use existing commercial or free libraries
• can port existing libraries to obscure platforms
• can develop required classes
• Additional Programmer Complexity
• standard will become mainstream
• educate proper usage through example applications
• Federate Use of Different Library Implementation
• compiler has library -- no problem
• federate not using library -- no problem
• in other cases, attempt to use common library
  implementation or have the RTI scope its library
  elements

10
Standard C Support Classes

• bool Type
• used for logical true / false values
• exception Class
• standard base exception has a single method
• string Class
• replaces char construct from C programming
  language
• handles memory operations more efficiently
• auto_ptr Template Class
• disambiguates memory semantics
• automatically frees memory when it is appropriate

11
Standard C Containers

• Standard Template Library
• generic programming, separates data from
  algorithm
• containers hold the data
• lists, sets, maps, pairs, etc.
• iterators index the data in the container
• RTI Containers
• FederateHandleSet, AttributeHandleSet, RegionSet,
  Region
• replace with setltHandlegt, setltRegiongt,
  setltExtentgt
• AttributeHandleValuePairSet, ParameterHandleValueP
  airSet
• replace with mapltHandle, Valuegt

12
Implementation Extensibility

• HLA API Objectives
• Support diverse RTI implementations
• Ensure that a compliant federate will operate
  properly with a compliant RTI
• RTI Implementation Diversity
• RTI vendors may implement data types differently
• IEEE API attempts to separate interface from
  implementation
• Template specialization used to provide
  compile-time type safety for RTI implementation
  details

13
Current Unspecified Tick Mechanism

• tick method
• provides two independent functions
• signals the RTI to invoke callbacks
• provides processing cycles to the RTI
• Problems with the previous approach
• not specified which hinders standardization
• federate unable to determine how frequently to
  tick
• requirements are dynamic depending on RTI load
• RTI may require cycles, but federate not prepared
  for callbacks
• polling mechanism is inefficient
• IEEE standards separates the necessary
  functionality into two areas
• obtain callbacks
• provide RTI processing cycles

14
Callback Services

• Added the following services to the specification
• evokeCallback(minTime)
• invokes single pending callback
• waits up to minTime if no pending callbacks exist
• evokeMultipleCallbacks(minTime,maxTime)
• invokes all pending callbacks handled within
  maxTime
• waits up to minTime if no pending callbacks exist
• enableCallbacks(), disableCallbacks()
• locking primitive, the above services check if
  callbacks are enabled
• Callback services have no more to do with giving
  the RTI processing cycles than any other service

15
RTI Processing Issues

• Three Approaches
• polling model (similar to tick)
• federate unable to determine the required polling
  frequency/density and the code is littered with
  tick calls
• inefficient use of computer processing
• asynchronous model
• RTI internally determines when processing is
  required
• interrupts federate activities with threads or
  signals (multiple processor machines do not
  require interrupt)
• event unification framework
• efficient handling of all events (timeouts, I/O,
  signals)
• frameworks more complex, underlying OS support is
  non-standard, and multiple frameworks often
  conflict

16
IEEE Impact on Users

• Service Changes
• Some of the existing services have had their
  interface and behavior refined
• Most of these changes are relatively minor, but
  will require modification of existing 1.3
  federate software
• The IEEE changes (e.g., strong type safety) will
  allow the compiler to identify where changes are
  required
• Support Classes
• Federate software must be modified with respect
  to RTI support classes (i.e., those C objects
  transferred between the federate and the RTI)
• IEEE RTI support classes utilize standard C
  constructs in a consistent and memory aware
  fashion

17
IEEE Transition Assistance

• Hyperlinked Transition Document
• Developing a programmers guide that links 1.3
  services with documentation concerning the
  corresponding IEEE service
• Documentation instructs the programmer what has
  changed and suggested approach in handling the
  change
• Transition Script
• Developing a script that parses existing 1.3
  compliant federate software that automatically
  translates simple IEEE conversions and generates
  a report on places in the code that requires
  manual transition

18
Backup Slides
19
Example RTI Data Type

• template ltclass T, int Igt class Handle
• public
• bool operator (T const rhs) return T
  rhs
• bool operator ! (T const rhs) return T !
  rhs
• typedef Handleltlong, 1gt AttributeHandle
• typedef Handleltlong, 2gt ParameterHandle

20
HLA API Evolution
Community Usage and Implementation Experience
prototyping activities and various working groups
IEEE working group and BRC meetings
AMG tiger teams
HLA Initial Definition
Initial IEEE Ballot
HLA 1.3
HLA 1.1
HLA 1.0 Baseline
IEEE Re-circulation
HLA 1.2
21
Example Container Usage

• RTIAttributeHandleSet ahset
• AttributeHandle ah
• ah RTIambassador-gtgetAttributeHandle(attX,
  theClass)
• ahset.insert(ah)
• RTIAttributeHandleSetIterator ahsetIterator
• while (ahsetIterator ! ahset.end())
• cout ltlt RTIambassador-gtgetAttributeName(ahsetIt
  erator)
• ahsetIterator

22
Single Routing Space

• DDM is used to express interests between
  producers and consumers of data
• e.g., federate A sends out stock quotes, federate
  B is only interested in stock quotes for company
  Z when the value falls below a certain threshold
• Previous implementation had an arbitrary number
  of routing spaces with an arbitrary number of
  dimensions
• New approach uses a single routing space with an
  arbitrary number of dimensions
• data interest is applied to a sub-set of the
  dimensions
• each dimension has pre-defined resolution

23
Current Unspecified Tick Mechanism

• tick method
• provides two independent functions
• signals the RTI to invoke callbacks
• provides processing cycles to the RTI
• Problems with the previous approach
• not specified which hinders standardization
• federate unable to determine how frequently to
  tick
• requirements are dynamic depending on RTI load
• RTI may require cycles, but federate not prepared
  for callbacks
• polling mechanism is inefficient
• IEEE standards separates the necessary
  functionality into two areas
• obtain callbacks
• provide RTI processing cycles

24
Callback Services

• Added the following services to the specification
• evokeCallback(minTime)
• invokes single pending callback
• waits up to minTime if no pending callbacks exist
• evokeMultipleCallbacks(minTime,maxTime)
• invokes all pending callbacks handled within
  maxTime
• waits up to minTime if no pending callbacks exist
• enableCallbacks(), disableCallbacks()
• locking primitive, the above services check if
  callbacks are enabled
• Callback services have no more to do with giving
  the RTI processing cycles than any other service

25
RTI Processing Issues

• Three Approaches
• polling model (similar to tick)
• federate unable to determine the required polling
  frequency/density and the code is littered with
  tick calls
• inefficient use of computer processing
• asynchronous model
• RTI internally determines when processing is
  required
• interrupts federate activities with threads or
  signals (multiple processor machines do not
  require interrupt)
• event unification framework
• efficient handling of all events (timeouts, I/O,
  signals)
• frameworks more complex, underlying OS support is
  non-standard, and multiple frameworks often
  conflict