The Aggregate Level Simulation Protocol (ALSP) is a protocol and supporting software that enables simulations to interoperate with one another. Replaced by the High Level Architecture (simulation) (HLA), it was used by the US military to link analytic and training simulations.
ALSP consists of: ALSP Infrastructure Software (AIS) that provides distributed runtime simulation support and management; A reusable ALSP Interface consisting of generic data exchange message protocols; and Participating simulations adapted for use with ALSP.
History In 1990, the Defense Advanced Research Projects Agency (DARPA) employed The MITRE Corporation to study the application of distributed interactive simulation principles employed in SIMNET to aggregate-level constructive training simulations. Based on prototype efforts, a community-based experiment was conducted in 1991 to extend SIMNET to link the US Army's and the US Air Force's Air Warfare Simulation (AWSIM). The success of the prototype and users' recognition of the value of this technology to the training community led to development of production software. The first ALSP confederation, providing air-ground interactions between CBS and AWSIM, supported three major exercises in 1992.
By 1995, ALSP had transitioned to a multi-Service program with simulations representing the US Army (CBS), the US Air Force (AWSIM), the US Navy (RESA), the US Marine Corps (MTWS), electronic warfare (JECEWSI), logistics (CSSTSS), and intelligence (TACSIM). The program had also transitioned from DARPA's research and development emphasis to mainstream management by the US Army's Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI)
Contributions ALSP developed and demonstrated key aspects of distributed simulation, many of which were applied in the development of HLA. No central node so that simulations can join and depart from the confederation at will Geographic distribution where simulators can be distributed to different geographic locations yet exercise in the same simulated environment Object ownership so each simulation controls its own resources, fires its own weapons and determines appropriate damage to its systems when fired upon A message-based protocol for distributing information from one simulation to all other simulations. Time management so that the times for all simulations appear the same to users and so that event causality is maintained – events should occur in the same sequence in all simulations. Data management permits all simulations to share information in a commonly understood manner even though each had its own representation of data. This includes multiple simulations controlling attributes of the same object. An architecture that permits simulations to continue to use their existing architectures while participating in an ALSP confederation.
Motivation In 1989, the Warrior Preparation Center (WPC) in Einsiedlerhof, Germany hosted the computerized military exercise ACE-89. The Defense Advanced Research Projects Agency (DARPA) used ACE-89 as a technology insertion opportunity by funding deployment of the Defense Simulation Internet (DSI). Its packetized video teleconferencing brought general officers of NATO nations face-to-face during a military exercise for the first time; this was well received. But the software application of DSI, distribution of Ground Warfare Simulation (GRWSIM), was less successful. The GRWSIM simulation was unreliable and its distributed database was inconsistent, degrading the effectiveness of the exercise.
DARPA was funding development of a distributed tank trainer system called SIMNET where individual, computerized, tank-crew trainers were connected over local area networks and the DSI to cooperate in a single, virtual battlefield. The success of SIMNET, the disappointment of ACE-89, and the desire to combine existing combat simulations prompted DARPA to initiate research that lead to ALSP.
Basic Tenets
DARPA sponsored the design of a general interface between large, existing, aggregate-level combat simulations. Aggregate-level combat simulations use Lanchestrian models of combat rather than individual physical weapon models and are typically used for high-level training. Despite representational differences, several principles of SIMNET applied to aggregate-level simulations:
Dynamic configurability. Simulations may join and depart an exercise without restriction. Geographic distribution. Simulations can reside in different geographic locations yet exercise over the same logical terrain. Autonomous entities. Each simulation controls its own resources, fires its own weapons and, when one of its objects is hit, conducts damage assessment locally. Communication by message passing. A simulation uses a message-passing protocol distribute information to all other simulations.
The ALSP challenge had requirements beyond those of SIMNET: Simulation time management. Typically, simulation time is independent of wall-clock time. For the results of a distributed simulation to be "correct," time must be consistent across all simulations.Lamport, L. (1978). "Time, Clocks, and the Ordering of Events in a Distributed System," Communications of the ACM, 21(7), pp. 558-565, July. Data management. The schemes for internal state representation differ among existing simulations, necessitating a common representational system and concomitant mapping and control mechanisms. Architecture independence. Architectural characteristics (implementation language, user interface, and time flow mechanism) of existing simulations differed. The architecture implied by ALSP must be unobtrusive to existing architectures.
Conceptual Framework A conceptual framework is an organizing structure of concepts that facilitates simulation model development.Balci, O., Nance, R.E., Derrick, E.J., Page, E.H. and Bishop, J.L. (1990). "Model Generation Issues in a Simulation Support Environment," In: Proceedings of the 1990 Winter Simulation Conference, pp. 257-263, New Orleans, LA, 9–12 December. Common conceptual frameworks include: event scheduling, activity scanning and process interaction.
The ALSP conceptual framework is object-based where a model is composed of objects that are characterized by attributes to which values are assigned. Object classes are organized hierarchically in much the same manner as with object-oriented programming languages. ALSP supports a confederation of simulations that coordinate using a common model.
To design a mechanism that permits existing simulations to interact, two strategies are possible: (1) define an infrastructure that translates between the representations in each simulation, or (2) define a common representational scheme and require all simulations to map to that scheme.
The first strategy requires few perturbations to existing simulations; interaction is facilitated entirely through the interconnection infrastructure. However, this solution does not scale well. Because of an underlying requirement for scalability, the ALSP design adopted the second strategy. ALSP prescribes that each simulation maps between the representational scheme of the confederation and its own representational scheme. This mapping represents one of the three ways in which a simulation must be altered to participate in an ALSP confederation. The remaining modifications are:
Recognizing that the simulation doesn't own all of the objects that it perceives. Modifying the simulation's internal time advance mechanism so that it works cooperatively with the other simulations within the confederation.
In stand-alone simulations, objects come into (and go out of) existence with the passage of simulation time and the disposition of these objects is solely the purview of the simulation. When acting within a confederation, the simulation-object relationship is more complicated.
The simulation-object ownership property is dynamic, i.e. during its lifetime an object may be owned by more than one simulation. In fact, for any value of simulation time, several simulations may own different attributes of a given object. By convention, a simulation owns an object if it owns the "identifying" attribute of the object. Owning an object's attribute means that a simulation is responsible for calculating and reporting changes to the value of the attribute. Objects not owned by a particular simulation but within the area of perception for the simulation are known as ghosts. Ghosts are local copies of objects owned by other simulations.
When a simulation creates an object, it reports this fact to the confederation to let other simulations create ghosts. Likewise, when a simulation deletes an object, it reports this fact to enable ghost deletion. Whenever a simulation takes an action between one of its objects and a ghost, the simulation must report this to the confederation. In the parlance of ALSP, this is an interaction. These fundamental concepts provide the basis for the remainder of the presentation. The term confederation model describes the object hierarchy, attributes and interactions supported by a confederation.
ALSP Infrastructure Software (AIS)
The object-based conceptual framework adopted by ALSP defines classes of information that must be distributed. The ALSP Infrastructure Software (AIS) provides data distribution and process coordination. Principal components of AIS are the ALSP Common Module (ACM) and the ALSP Broadcast Emulator (ABE).
ALSP Common Module (ACM)
The ALSP Common Module (ACM) provides a common interface for all simulations and contains the essential functionality for ALSP. One ACM instance exists for each simulation in a confederation. ACM services require time management and object management; they include:
Coordinate simulations joining and departing from a confederation.. Coordinate simulation local time with confederation time. Filter incoming messages, so that simulations receive only messages of interest. Coordinate ownership of object attributes, and permit ownership migration. Enforce attribute ownership so that simulations report values only for attributes they own.
Time management
Joining and departing a confederation is an integral part of time management process. When a simulation joins a confederation, all other ACMs in the confederation create input message queues for the new simulation. Conversely, when a simulation departs a confederation the other ACMs delete input message queues for that simulation.
ALSP time management facilities support discrete event simulation using either asynchronous (next-event) or synchronous (time-stepped) time advance mechanisms.Nance, R.E. (1971). "On Time Flow Mechanisms for Discrete Event Simulations," Management Science, 18(l), pp. 59-93, September. The mechanism to support next-event simulations is
A simulation sends an event-request message to its ACM with a time parameter corresponding to simulation time T, (the time of its next local event). If the ACM has messages for its simulation with timestamps older than or the same as T, the ACM sends the oldest one to the simulation. If all messages have timestamps newer than T, the ACM send a grant-advance to the simulation, giving it permission to process its local event at time T. The simulation sends any messages resulting from the event to its ACM. The simulation repeats from step (1).
The mechanism to support time-stepped simulation is: The simulation processes all events for some time interval . The simulation sends an advance request to its ACM for time . The ACM sends all messages with time stamps on the interval to the simulation, followed by a grant-advance to T+?T. The simulation sends any messages for the interval to the ACM. The simulation repeats from step (1).
AIS includes a deadlock avoidance mechanism using null messages. The mechanism requires that the processes have exploitable lookahead characteristics.