Alite Overview » History » Version 48
Alite is a software toolkit helping with particular implementation steps during construction of multi-agent simulations and multi-agent systems in general. The goals of the toolkit are to provide highly modular, variable, and open set of functionalities defined by clear and simple API. The toolkit does not serve as a pre-designed framework for a complex purpose, it rather associates number of highly refined functional elements, which can be variably combined and extended into a wide spectrum of possible systems.
Creator is responsible for initialization of whole environment, entities, visualization etc. The class must implement Creator interface. The whole application is started by passing appropriate creator to the Alite Main class the rest of the command-line options is passed to the creator.
Configuration describes an initial setting of the application. Alite contains an API interface for unifying various configuration backends.
- ConfiguratorInterface - General interface to a configuration system which provides methods for loading a configuration file and getting configuration parameters
- Configurator - Provides static access to a ConfiguratorInterface implementation instance, methods for type safe conversions and for default values of undefined parameters
- configurator/configreader (module) - Config Reader is a implementation of
ConfigurationInterfacebacked by Groovy Config Slurper. It provides type-safe easy way of integrating configurations into java code (see Config Reader).
- configurator/templategroovy (module) - Groovy-based implementation of
ConfigurationInterfaceusing templates and functional concepts (see Template Groovy Configurator). Fully scriptable in Groovy.
(Common) Event Queue¶
An event queue can be used for any queued processing of discrete-time events. The API provides methods for adding and handling of events. Additionally the events are prioritized by their time and processed in this particular order. Events with same timestamps are treated as simultaneous and the particular ordering of their processing has to be considered as random (or simultaneous if they are processed concurrently).
An event loop is a repetitious process. It is started by a newly added event into an event queue. The respective handling process of the event then adds the same event into the queue at the end of its processing, which invokes next iteration of the same process.
An entity is an object with a name encapsulating bounded phenomenon. The purpose or usage of entities is not restricted. Entities can represent agents, simulation embodiments, parts of other entities, information mediating objects and so on.
(Common) Capability Register¶
A capability register associates various capabilities with identities (e.g., entities). Both the identity and the capability is represented by a String. The main functionality of a register is to filter all identities by one capability.
Environments in Alite consist of three main building blocks: (a) state storages, (b) actuators, and (c) sensors. A typical full control loop consists of (sensor -> behavior -> actuator -> storage -> sensor -> ...) cycle. The behavior is typically an agent, or another entity representing behavior of an element in the environment (traffic light, moving wind, growing three, etc.).
A storage holds data structures representing a state of the elements in the environment (position of a person, velocity of a car, etc.). There are two typical approaches how to slice the environment state using the storages. One is grouping of the element features according to the element type and the other is grouping of the element features according to the data representations of the features. (An example of the first one is: PersonStorage, CarStorage, WindStorage, TreeStorage; an example of the other one is: GraphStorage, PositionStorage, KeyValueStorage, RelationDBStorage).
Actuators are responsible for changes of the data in storages. Actuators can be chained, and should form various levels of abstraction upon the environment state described in the storages. Actuators can use sensors to form shortened control loops (sensor -> actuator -> storage -> sensor -> ...), which can represent implicit mechanics of the environment (a rock falls even if it is not explicitly moved).
Sensors mediate information of the environment to the decision making algorithms (entities, agents, actions, other sensors). The sensors can be also chained and should form abstraction layers of the received information. There are two types of sensors we consider: push and pull. The push sensors are based on callbacks implemented in the scope of the decision making (e.g., an agent implements reaction on a perceived change in the environment) and the callbacks are invoked by the sensor (storage -> sensor -> behavior). The pull sensors are called by the decision making code and the perceived information is returned by the method call (behavior -> sensor -> storage ..> sensor ..> behavior).
Both the actuators and the sensors can use simulation events to postpone change/perception of the world for a delay. It represents the duration of an action or of the perceiving process. See  for processing of a (actuator -> storage -> sensor) loop.
The design is a simplification of the Distributed World Model proposed in .
A core of the simulation is an event queue. Each event is created with specified time when the event has to happen and it is stored in the priority event queue with this time as priority. When the simulation is started the first event in the queue is drawn the time of event is set as time of simulation and event is passed to its handler. When the handler is done the next event is drawn. Every handler must implement EventHandler interface.
Additionally the simulation queue is extended by methods for pausing, stopping and delaying of the queue processing to provide variable speed of simulation.
Each element of the simulation can use the events as it wants. For example there can be processes in the environment which duration is mathematically computed and the time of the event differs according to the needs of the process. Together with such processes there can be regular event loops ticking each N milliseconds. And finally, there can be also processes which are triggering complex hierarchies of events dependent on each other to simulate dichotomies in the simulated phenomenons.
The communication package serves as a tool for inter-agent messaging. Each agent has to implement two basic features – communicator and at least one communication channel. It can also use an instance of agent directory.
To be able to communicate any agent need to implement Communicator interface. It allows the agent perform basic operations such as sending and receiving messages. Any communicator needs at least one instantiated communication channel (one communicator can be attached to more communication channels). The communication channel is responsible for physical message exchanges between communicators. The structure of the package is:
Agent layer provides simple send/receive message methods, protocols implementation (CNP, Query, Request ...) or more complex negotiation models.
Platform layer is composed by platform-to-agent support - Communicator, Directory, etc.
Transport layer provides various communication channels (direct, asynchronous direct, event-based ...).
There is a module for encoding Alite messages using Google Protocol Buffers encoder (see protobuf module) and an implementation of Alite comminication channel with ZeroMQ/JeroMQ middleware (see zeromq module).
This communication sub-package provides abstract allocation-based problem solver (straightforward and iterative) based on task allocation and delegation. the architecture is based on task-base (allocation, delegation, ...), plan-base (planner integration), and plan-execution (execution simulation).
- spatial maneuver 3D path planner for CTOL planes using multi-granular discretization of a continuous planning space
- general planner using A* for forward-chaining of grounded operators (generalization of spatial maneuver planner)
There is a module with helper structures, RRT* and A* planners and codes for description of various path types and trajectories (see trajectorytools module) and a module for trajectory deconfliction algorithms (see deconflictiontools module).
Low-level visualization tools in Alite Core:
- vis - lite 2D visualizer using Java2D backend, one drawing window and canvas, hierarchically organized set of layers drawing on the canvas separated sets of similar visual elements (circles, lines, points, sprites, ...), providing zooming and panning of the displayed area
- Google Earth connector (see kmlvisio module)
- vis3d - 3D visualizer using Java Monkey Engine as a backend, similarily to (2D) vis, there is one drawing window, a set of layers preparing and controling objects in the 3d scene with basic game-like controls for zooming, panning of the displayed area and 3rd-person camera (see vis3d module)
Higher-level packages (mostly) based on Alite Core visualization tools:
- Visualizer2D - convenience "framework" layer for Alite Vis2D (see vis module).
Alite currently contains an adapter to AGlobe multi-agent platform.