OBJS Technical Note

HLA Simulations vs. Agents

Mark Palmer
Object Services and Consulting, Inc.
July 1998

This note is an attempt to compare agent architectures (as exemplified by current ACLs such as KQMO) with the Defense Modelling and Simulation Office (DMSO) standard for simulation software, known as HLA (High Level Architecture). It is intended as a complement to Venu Vesudevan's overview of ACLs.

HLA in brief

The HLA supports harnessing multiple existing simulation programs to create a larger simulation by specifying distribution and communication mechanisms, as well as providing a means by which instances and changes in state can be communicated to other members of a simulation. New simulations produced using HLA share a common architecture, and existing simulations can be wrapped to participate in larger scenarios. A collection of communicating simulations is called a Federation; each individual member is a Federate. Each Federate is responsible for maintaining and publishing the object model (the Simulation Object Model, SOM) it needs to conduct its operations. SOM Classes have attributes that can be updated during state exchanges. Class Attributes can be "owned" by different Federates; the granularity of data exchange is relatively fine and data-oriented.

A standard repository of known HLA classes (Object Model Templates, OMT) exists for use in developing simulations. HLA also specifies a set of rules that federates must obey; these are largely enforced by the HLA API.

HLA Federations communicate across a shared "message bus" using a standard API - HLA RTI language bindings are available for C++, C, ADA, and Java.

A federation execution proceeds in a series of phases for each Federate:

  1. Join an execution
  2. Establish data requirements (subscribe and publish class metadata)
  3. Register and Discover Object Instances
  4. update attribute values, advance clock
  5. delete objects
  6. resign from federation

RunTime Infrastructure (RTI) and services

The RTI API is broken into the following categories:

HLA Federates as agents

In some ways, each Federate might be considered an agent: it is long-running, has some degree of autonomous behavior, and communicates with others to achieve its goals. It reacts to changes in its environment and effects changes to the environment in reponse. Each Federate maintains its own subset world-model, comparably to FIPA-ACL.

However, it would be difficult to make a Federate communicate with agents using KQML or FIPA-ACL by attempting to convert HLA to these ACLs. The set of RTI services ("performatives" in the agent world) is quite low-level. There is no assumption that Federates can conduct goal-directed, intelligent behavior. A Federate may indeed behave intelligently, but the HLA RTI provides no mechanism for one Federate to communicate to another about its reasoning processes - only the resulting changes to shared state matter.

Most of the operations in the RTI service set correspond to "wrapper" or communication primitives in ACLs. The focus of RTI services is on controlling message delivery and time synchronization, etc. The HLA "content language" consists of operations to publish and receive changes to attributes of class instances once they have been discovered. There is an operation "send interaction", but the interactions are defined as part of the SOM class definitions, and are not a universally understood, as are performatives in ACLs. '

The HLA distribution model too differs from those assumed by the ACLs. Agents find other agents via a naming directory and communication is then point-to-point, asynchronous, on a peer basis. An agent may be communicating with several other agents simultaneously. Messages are implemented as parseable ASCII. In HLA, Federates publish updates to the Federation, and any Federate can register to receive updates on a per-instance/attribute basis. Messages are communicated as serialized object packets. A set of services control "routing", allowing messages to be delivered only to some subset of Federates who have registered for messages within a given dimensional space. Apparently a Federation can exist over the internet, without requiring a LAN.

In HLA, each update is potentially synchronous with respect to a shared virtual time. Federates need to be able to synchronize their operations with the progress of a virtual clock such that one Federate can delay execution of others while it completes an action that must occur at time T1, before anyone advances to time T2. This last capability might prove useful for certain agent applications, but to date the agent architectures seem to omit virtual clock or time synchronization functions.

Some HLA global directives such as "save federation state" - which causes all Federates to save their current state - might be useful additions to an agent environment as well.

HLA as a potential environment for agent operation

While HLA itself seems to provide an inadequate substrate for implementing agents, it may serve as a useful environment within which agents can operate. For example, we may want to develop agents that cooperate within a battle terrain. Lacking a real battlefield and real military vehicles in our virtual office, we could consider using HLA for testing - agents would communicate with each other using an ACL such as KQML, while interacting with their simulated environments via HLA. I see no immediate impediment to mixing the two architectures in this way, but have found no references to an existing implementation.

It might require significant work to get an interesting HLA simulation environment up and running, due to the low level of the primitives. Perhaps a worthwhile sub-project would be to simply evaluate the use of HLA with one of the ACL toolkits, to verify that they can work together.