This page briefly describes a Java implementation of a NEO simulator. An example applet (and application) is provided that shows how to create entities and decision makers to interface to the simulator and set up a simple experiment. Environments are automatically generated based on a user's input specifying the numbers of locations, transports, evacuees, and safe destinations.
To run the simulator applet from your browser, you may need to install the Java Plug-in for running Java 1.1.x applets. As of 5/6/99 there is no plug-in yet available for MacOS. If you can't run the applet, you can download the application and run it. If you don't already have the Java Development Kit (JDK 1.1.x) installed on your platform, you can get the smaller Java Runtime Environment (JRE 1.1) in order to run the application. (The JDK & JRE for MacOS are available here.) You can get the application as a jar file (you will also need the swing library), and run the application from the same directory with "java -classpath .:/usr/java/lib/classes.zip:coabs_sim.jar:swing.jar SimulatorStartFrame" if you have the JDK or with "jre -cp coabs_sim.jar:swing.jar:/usr/java/lib/classes.zip SimulatorStartFrame" if you have the JRE. (This assumes your version of Java is installed in /usr/java on a unix machine.) To get the application and source code, download and unpack the tar file with all of the .java and .class files. There are included "run" and "compile" scripts for unix environments for those with the JDK.
The example applet launches three different simulations to evaluate different strategies for transports involved in evacuations. The purpose of this is only to demonstrate how an experiment can be easily constructed to compare different control strategies.
The locations are simply placed and connected in a rectilinear grid with additional random diagonal routes; the transports, evacuees, and safe destinations are distributed randomly. In the graphical depiction, the large circles are locations; medium-sized circles are transports; and small circles are evacuees. The transports each have identical decision makers and move through the network and stop for evacuees to get on and off. Transports have "mean trip times" associated with them; the number of steps for a transport to traverse a route varies based on this parameter and a "standard deviation." Evacuees are controlled by a single decision maker, board the first transports that come their way, and disembark (never to reboard) when they reach safe locations (colored green in the graphics). All routes are "two-way" in that there is no restriction on travel in opposite (or same) directions across them. However, they can be initialized as one-way routes where transports will fail when traversing the same route in opposite directions. Although not yet fully implemented, transports, locations, and routes could have a capacity for entities they can contain or service, and could become unavailable as specified or due to failure.
In the supplied code, the transports and evacuees are controlled by simple decision-making agents written in Java. Take a look at the code for these decision makers at DecisionMakerForEvacuees.java, TransportDecisionMaker.java, SmarterTransportDM.java, and SmartestTransportDM.java. Agents like these can be implemented in Java to participate in the simulation; however, we expect to provide a CORBA interface to the simulator so that agents can be programmed in other languages with a similar interface.
You can define test scenarios by writing a Java application or applet that initializes the environment with entities and decision makers and starts the simulator. Documented code for initializing the environment with specified numbers of entities as seen in the applet is given in the main() method of the Java class, Simulate.java. This is a simplified version of the undocumented applet code in SimulatorStartFrame.java that additionally contains code for the "Simulator Parameters" window where the numbers of entities are entered. All of the code referred to above was written to interface to the simulator package. If you want access to the directory of the mostly undocumented code for the simulator, click here. The simulation is controlled by a Control object. Take a look at the control loop to get an idea of what happens on each cycle.
What follows is a summary of some of the initial design rationale for the simulator. While some of these decisions are outdated, and others will need to be revisited, this should give a flavor of the structure of entities and actions in the simulation.
Entities and Actions for an Evacuation Domain
=============================================
The entities and actions of the domain are organized in a class hierarchy below. The location, evacuee, transport and route classes are derived from an entity class. These classes can in turn act as base classes for other derived classes. For example, a specific kind of transport such as an aircraft would be derived from the transport class.
All actions are performed by decision-making agents. Future specifications of the domain may allow (or rather constrain) a decision-making agent to be one of the entities of the domain. For example, an decision-making evacuee agent may be able to command some set of other evacuees and transports, but may have limited perception based on location and must communicate with other decision-making agents.
Although not listed explicitly, there will be accessor methods defined for each attribute of each entity. Accessor methods will be used to set, get, or manipulate an attribute's data structure. These, along with any public method, can also be treated as actions. In particular, "get" methods can be treated as sensing actions. All public actions have an associated time delay. These may be defined in extra attributes, built into the methods for executing the actions, or specified by the agent executing the action. In addition, constructors defined for each class will be used to initialize the environment and dynamically add new entites,
Entity
------
* id : unique identifier
* Display() : method for drawing object graphically--must be redefined in
child class
Location
--------
* evacueeList : list of evacuees at this location
* transportList : list of transports at this location
* resourceList : list of resources at this location
* evacueeCapacity : maximum capacity of evacuees
Evacuee
-------
* priority : priority of rescuing this evacuee
* destination : target destination of this evacuee
* preferredTransport : preferred mode of transport
* curLocation : current location (if not in transit)
* curTransport : current transport (if in transit)
* injured : whether evacuee is injured
* probabilityInjury : probability of evacuee getting injured
* GetRoute() : get the route from transp (if in transit)
* Embark(transport) : get into a transport
* Disembark() : get out of a transport
Transport
---------
* evacueeList : list of evacuees currently on this transport
* curLocation : location of this transport (if not in transit)
* curRoute : current route (if in transit)
* routeList : list of routes on which this transport can operate
* evacueeCapacity : maximum capacity for carrying evacuees
* evacueeCapacityLeft : remaining capacity for carrying evacuees
* status : available/unavailable/etc.
* probabilityFail : probability of failure
* Move(location, route) : move to an adjacent location via a particular
route (evacuees inside are moved as well)
* DestroyRoute(route) : the transport destroys a route and makes it
unavailable for traversal
* MoveAndDestroy(location, route) : the previous two actions combined
Route
-----
* status : available/unavailable
* endpt1 :
* endpt2 : endpoints of the route
* transportList : list of transports currently on this route
* meanTripTime : mean trip time
* probabilityFail : probability of failure (unavailability)
* GetEvacueeList() : get list of evacuees on this route from tlist
* Destroy() - the route is destroyed and made unavailable for traversal
For simulating concurrent actions, we will wish to model the intermediate effects of actions as well as their permanent effects. For this reason, there may be two methods defined for each action to update the environment: one for updating the intermediate effects and one for later updating the permanent effects.
Discrete Event Simulator
========================
The purpose of the discrete event simulator is to provide an environment within which the interactions of multiple agents can be analyzed and displayed graphically for domains of problems of interest to the CoABS group. Decision-making agents interface to the simulator to solve a problem for a specified domain by
- creating objects and initializing the environment for the problem,
- executing actions that manipulate objects in the environment, and
- sending messages to other agents.
At each time step of the simulator's clock, each connected agent is polled for commands and message delivery. After polling each of the agents, the simulator collects all messages and actions and "executes" them in parallel. Because different actions have different execution time specifications, the state of an object in the environment may be updated at a later time step as a result of the effect of an action. For simplicity, the intermediate effects of an action will be updated at the start of the action, and effects will be realized at the end of the action's execution. When the state is updated, calls will be made to also update a graphics display for illustrating the current state of the environment. In addition, statistics about the computation and execution time of agents are collected.