History
In 1990, theContributions
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 (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
AALSP 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 Combinatorial search#Lookahead, lookahead characteristics.Object management
The ACM administers attribute database and filter information. The attribute database maintains objects known to the simulation, either owned or ghosted, and attributes of those objects that the simulation currently owns. For any object class, attributes may be members of * ''Create set.'' Attributes minimally required to represent an object * ''Interest set.'' Useful, but not mandatory, information * ''Update set.'' Object attribute values reported by a simulation to the confederation Information flow across the network can be further restricted through filters. Filtering provides discrimination by (1) object class, (2) attribute value or range, and (3) geographic location. Filters also define the interactions relevant to a simulation.If (an update passes all filter criteria) , If (the object is known to the simulation) , , Send new attribute values to simulation , Else (object is unknown) , , If (enough information is present to create a ghost) , , , Send a create message to the simulation , , Else (not enough information is known) , , , Store information provided , , , Send a request to the confederation for missing data Else (the update fails filter criteria) , If (the object is known to the simulation) , , Send a delete message to the simulation , Else , , Discard the update dataThe ownership and filtering information maintained by the ACM provide the information necessary to coordinate the transfer of attribute ownership between simulations.
ALSP Broadcast Emulator (ABE)
An ALSP Broadcast Emulator (ABE) facilitates the distribution of ALSP information. It receives a message on one of its communications paths and retransmits the message on all of its remaining communications paths. This permits configurations where all ALSP components are local to one another (on the same computer or on a local area network). It also permits configurations where sets of ACMs communicate with their own local ABE with inter-ABE communication over wide area networks.Communication Scheme
The ALSP communication scheme consists of (1) an inter-component communications model that defines the transport layer interface that connects ALSP components, (2) a layered protocol for simulation-to-simulation communication, object management, and time management, (3) a message filtering scheme to define the information of interest to a simulation, and (4) a mechanism for intelligent message distribution.Inter-component Communications Model
AIS employs a persistent connection communications modelBoggs, D.R. Shoch, J.F., Taft, E.A., and Metcalfe, R.M. (1979). "PUP: An Internetwork Architecture," Report CSL-79- 10, XEROX Palo Alto Research Center, July. to provide the inter-component communications. The transport layer interface used to provide inter-component communications was dictated by simulation requirements and the transport layer interfaces on AIS-supporting operating systems: local VMS platforms used shared mailboxes; non-local VMS platforms used either Transparent DECnet or TCP/IP; and UNIX-like platforms use TCP/IP.ALSP Protocol
The ALSP protocol is based on a set of orthogonal issues that comprise ALSP's problem space: simulation-to-simulation communication, object management, and time management. These issues are addressed by a layered protocol that has at the top a simulation protocol with underlying simulation/ACM, object management, time management, and event distribution protocols.Simulation Protocol
The simulation protocol is the main level of the ALSP protocol. It consists of four message types: * ''Update.'' Objects in ALSP are defined by a unique id number, a class, and a set of attributes associated with a c1ass. As a simulation changes the state its objects, it sends update messages to the ACM that provide initial or changed attribute values. The ACM then distributes the information via AIS to other simulations in that have indicated interest. * ''Interaction.'' Interactions between objects are identified by kind. Interaction kinds are described by parameters, just as objects are described by attributes. When a simulation's object engages either another simulation's object or a geographic area, the simulation sends an interaction message to the ACM for further dissemination to other interested simulations. * ''Refresh request.'' A simulation can request an update of a set of attribute values for any object or class of objects by sending a refresh request message to the confederation. * ''Delete.'' When a simulation causes one of its objects to cease to exist, the simulation sends a delete message to inform other simulations. The simulation protocol is text-based. It is defined by anSimulation/ACM Connection Protocol
The simulation/ACM connection protocol provides services for managing the connection between a simulation and its ACM and a method of information exchange between a simulation and its ACM. Two services control distribution of simulation protocol messages: events and dispatches. Event messages are time-stamped and delivered in a temporally-consistent order. Dispatch messages are delivered as soon as possible, without regard for simulation time. Additional protocol messages provide connection state, filter registration, attribute lock control, confederation save control, object resource control, and time control services.Object Management Protocol
The object management protocol is a peer-level protocol that sits below the simulation protocol and provides object management services. ACMs solely use it for object attribute creation, acquisition, release, and verification (of the consistency of the distributed object database). These services allow AIS to manage distributed object ownership. Distributed object ownership presumes that no single simulation must own all objects in a confederation, but many simulations require knowledge of some objects. A simulation uses simulation protocol update messages to discover objects owned by other simulations. If this simulation is interested in the objects, it can ghost them (track their locations and state) and model interactions to them from owned objects. Locks implement attribute ownership. A primary function of the object management protocol is to ensure that a simulation only updates attributes for which it has acquired a lock. TheTime Management Protocol
The time management protocol is also a peer-level protocol that sits below the simulation protocol. It provides time management services for synchronizing simulation time among ACMs. The protocol provides services for the distributed coordination of a simulation's entrance into the confederation, time progression, and confederation saves. The join/resign services and time synchronization mechanisms are described in Section earlier. The save mechanism provides fault tolerance. Coordination is required to produce a consistent snapshot of all ACMs, translators and simulations for a particular value of simulation time.Message Filtering
The ACM uses simulation message filtering to evaluates the content of a message received from the confederation. The ACM delivers messages to its simulation that are of interest, and pass filtering criteria and discards those that are not of interest. The ACM filters two types of messages: update messages and interaction messages. ''Update messages.'' The ACM evaluates update messages based on the simulation's update message filtering criteria that the simulation provides. As discussed in earlier, when an ACM receives an update message there are four possible outcomes: (1) the ACM discards the message, (2) the ACM sends the simulation a create message, (3) the ACM sends the simulation the update message, or (4) the ACM sends the simulation a delete message. ''Interaction messages.'' An ACM may discard interaction messages because of the kind parameter. The kind parameter has a hierarchical structure similar to the object class structure. The simulation informs its ACM of the interaction kinds that should pass or fail the interaction filter.Message Distribution
To minimize message traffic between components in an ALSP confederation, AIS employs a form of intelligent message routing that uses the Event Distribution Protocol (EDP).Weatherly, R.M., Wilson, A.L. and Griffin, S.P. (1993). "ALSP - Theory, Experience, and Future Directions," In: ''Proceedings of the 1993 Winter Simulation Conference,'' pp. 1068-1072, Los Angeles, CA, 12–15 December. The EDP allows ACMs to inform the other AIS components about the update and interaction filters registered by their simulations. In the case of update messages, distribution of this information allows ACMs to only distribute data on classes (and attributes of classes) that are of interest to the confederation. The ABE also use this information to send only information that is of interest to the components it serves. For interaction messages, the process is similar, except that the kind parameter in the interaction message determines where the message is sent.Further reading
* Anita Adams, Gordon Miller, and David Seidel, November 1993References
{{reflist Applications of distributed computing Distributed computing architecture Application layer protocols Simulation software Mitre Corporation