The JSAF Control Protocol

1
The JSAF Control Protocol

• Bill Helfinstine
• Christopher Young
• Sheetal Brahmbhatt
• Matthew LeVan

2
The JSAF Architecture

• Distributed Entity-Level simulation
• ModSAF heritage
• Separate GUI and simulator processes
• Operators can collaborate using multiple GUIs
  together
• Computation capacity is assigned to operators as
  necessary

3
The Persistent Object (PO) Protocol

• A ModSAF-heritage protocol for sharing of control
  and resources
• Provides a shared database of small objects
• Convenient metaphor for redundancy and failure
  recovery
• Useful mechanism for checkpointing the state of
  the system
• Provides a fairly simple sharing capability

4
Issues with PO

• The PO protocol is very bandwidth-heavy
• Way more is shared than necessary
• Migration of units for failure recovery doesnt
  work
• JSAF is big and complicated
• JSAF scenarios have scaled way up
• Moores Law has shifted the balances
• The PO protocol is latency-sensitive
• PO is limited in how many computers can be
  grouped
• The PO protocol is opaque and hard to
  interoperate with

5
The JSAF Control Protocol

• A new BOM that provides a control and monitoring
  capability
• Organized into four pieces
• Graphics
• Units
• Unit-associated
• Tasking
• An explicit permission mechanism is also necessary

6
Permissions

• We need to expand the span of control
• Operators are often organized in a hierarchy
  matching the simulated forces
• Simulation controllers need the capability to
  reach in and control things quickly
• Operators need to be able to focus on their
  responsibilities
• We created a flexible hierarchy of permission
  states to mimic this setup

7
Graphics

• Controllable and visible based on permission
• Need to be able to modify on the fly
• HLA ownership management moves the objects to
  where theyre being changed
• Overlays are associated with permission states
• Graphics are associated with overlays
• Lines, points, areas, text

8
Units

• TaskableUnit objects represent collections of
  vehicles that can be commanded
• TaskableUnits are owned by the simulator that
  simulates the vehicles
• GUIs must request they be created or modified
  using interactions
• TaskableUnits are associated with permission
  states

9
Unit-associated Data

• Significantly more data required for simulation
  than is required for monitoring
• This is a way to have data that is not shared on
  the network until requested
• An operator usually only controls one unit at a
  time
• This allows different levels of access to overall
  data and detailed data

10
Tasking

• The sequence of commands issued to a unit is its
  TaskingState
• Kept as unit-associated data
• A number of interactions are used to modify this
  state
• Ease of behavior development important
• XML-encoded data used as a compromise between
  transparency and ease of coding

11
Better Data Descriptions

• The behavior code is processed during build
• A document that describes the behavior interfaces
  is generated
• XML is used to interface to the behaviors without
  the pain of adding to the SOM/FOM

12
Summary

• Hierarchical permission setup
• HLA BOM to describe the main data structures
• XML encoded data for coding flexibility
• Shared ownership for graphics objects
• Requestable simulator-owned objects for simulated
  objects