HLA_AGENT is a tool for the distributed simulation of agent-based systems, which integrates the SIM_AGENT agent toolkit and the High Level Architecture (HLA) simulator interoperability framework. HLA_AGENT offers enhanced simulation scalability and allows inter-operation with other HLA-compliant simulators, promoting simulation reuse.

Simulations developed using HLA_AGENT are capable of inter-operating with other HLA-compliant simulators and the objects and agents in the simulation can be flexibly distributed across multiple computers so as to make best use of available computing resources. The distribution is transparent to the user simulation and symmetric in the sense that no additional management federates are required. In addition, HLA_AGENT incorporates a simple solution to the problem of action conflicts in a distributed environment which exploits the existing Ownership Management services of the HLA.

The High Level Architecture

The High Level Architecture (HLA) allows large-scale distributed simulations to be constructed by linking together a number of geographically distributed simulation components (or federates) into an overall simulation (or federation). The federates may be written in different languages and may run on different machines. A federation is made up of:

  • one or more federates
  • a Federation Object Model (FOM)
  • the Runtime Infrastructure (RTI)

Each federate can model a single entity (such as an agent), or a number of entities or it may have some different purpose. For example, a federate might be a data logger or a viewer used to `steer' a simulation, or it might act as a surrogate for a human participant in a simulation, reflecting the state of the larger simulation to some user interface and conveying decisions from the participant to the rest of the simulation.

The FOM defines the types of and the relationships between the data exchanged by the federates in a federation. Each FOM consists of a set of object classes and a set of interaction classes. An object class defines a set of named data called attributes. Instances of these object classes and their associated attribute values are created by the federates to define the persistent state of the simulation. Federates evolve the state of an object instance in simulation time by supplying new values for its attributes. An interaction is a set of named data, or parameters, which forms a logical unit within the federation, e.g., an event within the simulation model. Each federate must typically translate from its internal notion of simulated entities to HLA objects and interactions as specified in the FOM.

The RTI is middleware that provides common services to the federates. All communication between the federates in a federation and between federations is via the RTI. Each federate contains an RTI Ambassador and a Federate Ambassador along with the user simulation code. The RTI Ambassador handles all outgoing information passed from the user simulation to the RTI. Each call made by the RTI Ambassador typically results in a corresponding callback on other federates. For example, updating the value of an attribute of an instance of an object class defined in the FOM on one federate will result in a callback containing the new value on federates which subscribe to the attribute. It is the task of the Federate Ambassador to handle these callbacks and invoke appropriate code in the user simulation, e.g., to update the value of a field or variable representing the attribute. The FOM is passed to the RTI at the beginning of an execution and effectively parameterises the RTI for that federation. The FOM is supplied as data to the RTI at the beginning of an execution.

HLA has been adopted as an IEEE standard (IEEE 1516) and is likely to be increasingly widely adopted within the simulation community. As such, HLA-compliance will be an increasingly important feature of agent simulators, allowing inter-operation with other simulations, re-use of agent simulation components and the distribution of agent and other simulation components across multiple computers to increase the overall performance of a global simulation.


SIM_AGENT is an architecture-neutral toolkit originally developed to support the exploration of alternative agent architectures. It can be used both as a sequential, centralised, time-driven simulator for multi-agent systems, e.g., to simulate software agents in an Internet environment or physical agents and their environment, and as an agent implementation language, e.g., for software agents or the controller for a physical robot. SIM_AGENT has been used in a variety of research and applied projects, including studies of affective and deliberative control in simple agent systems, agents which report on activities in collaborative virtual environments, and simulation of tank commanders in military training simulations.

In SIM_AGENT, an agent consists of a collection of modules representing the capabilities of the agent, e.g., perception, problem-solving, planning, communication etc. Groups of modules can execute either sequentially or concurrently and with differing resource limits. Each module is implemented as a collection of rules, or ruleset, in a high-level rule-based language called PRB. The rule format is very flexible: both the conditions and actions of rules can invoke arbitrary low-level capabilities, allowing the construction of hybrid architectures including, for example, symbolic mechanisms communicating with neural nets and modules implemented in procedural languages. The rulesets which implement each module, together with any associated procedural code, constitute the \emph{rulesystem} of an agent. SIM_AGENT can also be used to simulate the agent's environment, and the toolkit provides facilities to populate the agent's environment with user-defined active and passive objects (and other agents).

Distributing a simulation with HLA_AGENT

To distribute a simulation, the user must define the classes and attributes that constitute the Federation Object Model and, for each federate, provide a mapping between the classes and attributes in the FOM and the SIM_AGENT classes and slots to be simulated on that federate. The additional generic code are loaded as an additional library. If the user simulation is partitioned so that each federate only creates instances of those objects and agents it is responsible for simulating, then no additional user-level code is required. In the case in which all federates use the same simulation code, the user must define a procedure which is used to determine whether an object should be simulated on the current federate. The user therefore has the option of partitioning the simulation into appropriate subsets for each federate, thereby minimising the number of proxy objects created by each federate at simulation startup, or allowing all federates to create a proxy for all non-local objects in the simulation. For very large simulations, the latter approach may entail an unacceptable performance penalty, but has the advantage that distributed and non-distributed simulations can use identical code.

Selected Publications

HLA_AGENT is freely available under the terms of the GPL. (Note however, that you will need an RTI implementation which we can't provide.) For more information contact Brian Logan