Welcome to the RimSim Response! project page.

The Pacific Rim Visualization and Analytics Center coordinated at the University of Washington, known as the PARVAC to other regional centers, has been working on developing improved shared artifacts for communicating during community-wide first response activities. We have come to realize the magnitude of the cognitive load involved in maintaining situation awareness for effective first responder behavior. We have studied successful distributed cognition methods for embedding mission-critical knowledge in shared visualization tools. We have studied the embodied mind model that suggests humans need a wide arrange of external thinking tools in order to embody an internal model for effective action. And, we have studied the emerging model for augmented cognition – a model that looks to improve social cognition between humans given solid shared artifacts and computation support with which to share situation awareness.

Through our journey to understanding emergency response, emergency operation centers, and first responders, we have seen a wonderful opportunity for developing emergency response scenario simulators with software that can be used by anybody who would participate in a cross-jurisdictional crisis management scenario. Although we couldn’t justify pursuing a process whereby every emergency response role play a simulation simultaneously, we could justify pursuing a process whereby crisis management roles were embedded in software with the help of software-based agents that could perform the roles of those first responders who were not able to play their role synchronously with others.

The result is a software base we call RimSim Response! This software has been created with the intent of sharing code and experiment results with others who are interested in running emergency response scenario experiments. This page, albeit long and cumbersome perhaps at first glance, is where we want people to come to obtain our latest code and learn how to use it so they can participate in future development. There are three sections to this document: software download and install instructions; software run instructions; and, an application explanation primer.

RimSim Response!: Base Software

Software releases of the RimSim Response! are available for download from the RSR team. All downloads are archived as .zip files which are named RSR_MonthDay-Year.zip where MonthDay is the month and day the code was frozen for the bundling. Dates are removed when they are no longer supported by the RSR team. The RimSim Response! application is currently a Java application being built with kind Open Source assistance from Java World Wind, JOGL - the Java Open Graphics Library, and PostgreSQL code communities. To extend our code, you must abide by their license agreements. Please see their websites for more information.

Downloading RimSim Response!

Please get the latest .zip file from the RSR team. We recommend placing the archive on your computer desktop initially. Consult your Web browser documentation for other ways to download files from a file directory residing on the World Wide Web.

Installing RimSim Response!

Please expand the .zip archive you recently downloaded from our Web-based repository. If you don't have decompression software installed on your system, consider using WinZip which is available here for Windows, or WinRAR for most popular operating systems (including Mac and other Linux flavors) here. When you expand the .zip archive, you should find five directories within the archive: bin, config, data, lib, and src. The bin directory includes the RimSim Response! binary code you can use to run RSR. The config directory contains configuration files that identify emergency response scenarios to simulate and runtime batch files you can use to launch RSR with a pre-defined configuration. The data directory holds the results of optimization model runs you make whenever you make them. The lib directory includes both the Java-based components and native Mac and Windows libraries for other code on which our code is based. The src directory contains the source code for the World Wind contribution to the application - the code the PARVAC team has manipulated for our needs (see the org.nasa.worldwind.rsr package for the PARVAC contribution).

Running RimSim Response!

You can run RimSim Response! using your operating system command prompt from the directory directly above the bin, config, data, lib, and src directories (meaning the one parent directory (folder) in which those subdirectories (subfolders) are visible). You can name that directory whatever you please, but make note of where it exists on your system storage hierarchy. If you want to run via the command line, use your Java Runtime Environment (JRE) software to run our demonstration. Any version of Java 1.5 or Java 1.6 works fine (the appropriate Java command to verify your Java run-time version is: java -version).

Eventually you will be able to run the RimSim Response! from within your Web browser through a link to our services located on servers on the Web. You might never want to use the remote services though if your Web browser is bloated with other code you will never need to run the RimSim Response! software. Instructions to run from the Web will appear on this page when the service is developed and working to our satisfaction (the World Wind team is helping us improve performance on the Web page launch). At that time, you will be able to run RSR with the help of your Web browser (perhaps without even knowing you are run Java in the meantime). That's the future - you'll need to learn how to run Java outside of your browser for RimSim Response! at this point in time.

You can run Java from a command prompt in almost any computer terminal. Versions of Windows provide a command prompt through the cmd.exe executable (which means you can launch a command prompt from the Start menu - just click on Start, then Run and enter cmd in the dialog box that requests a program name). If cmd.exe is not on your system, try using command.exe instead. Versions of Mac OS X and other Linux flavors provide a command prompt through the Terminal application. Use your application finder to find Terminal on your non-Windows based system and launch that software.

Once you have a command prompt available to you, change to the directory on your system where you have placed the bin, config, data, lib, and src folders. Use the cd command to change directories (see an example here). Typically, when you launch a command prompt, you launch it either in your Desktop directory of the directory above it. If you see you are already at your Desktop in the command prompt text that appears, you should be able to change to the directory on your Desktop where you put the RimSim Response! files. If you aren't at your Desktop, try going there with the command: cd Desktop. Then, change to your directory. For me, I run the command: cd rsr because I put my bin and lib directories in a folder named rsr on my Desktop. You can verify you are in the right directory from wiith in your command prompt. Either the ls or dir command (or both) should give you a listing of your files in the current directory.

Once you are in the right place, try launching RimSim Response! by using the appropriate Java command shown below (you can copy and paste the command to a command prompt). For a Windows-based computer system, you likely will need to run the following command (the -mx flag opens 512 MB of memory to your Java runtime system; the -cp flag sets the classpath to pick up the other libraries the software requires; the -D flag points to java native libraries needed to operate your graphics hardware; the DemoMain class is currently the launch class within the software):

java -mx512m -cp bin;lib/BasicDemo.jar;lib/postgresql.jar;lib/gluegen-rt.jar;lib/jogl.jar -Djava.library.path=lib gov.nasa.worldwind.rsr.DemoMain

For a Linux or Mac-based system (or both), you likely will need to run this command (copy and paste to your command prompt):

java -mx512m -cp bin:lib/BasicDemo.jar:lib/gluegen-rt.jar:lib/jogl.jar:lib/postgresql.jar:lib/worldwind.jar -Djava.library.path=lib gov.nasa.worldwind.rsr.DemoMain

If your Java runtime is not available from your directory, you will need to set an environment variable that points to your Java installation. Or, perhaps you don't have a Java runtime installed? You can get Java runtimes for free download from http://www.java.com/en/download/manual.jsp. Learn about environmental variables here.

The application should come up in run mode when you enter the appropriate command above, but there is an alternative way to run the RimSim Response! software. You can launch a runtime file (examples are located in the config folder). Config files end in and .rt extension (scenario variables are stored in .xml files). You can add the name of a config file to the launch command above in order to run that specific configuration without having to provide the start-up dialog box configurations. For example, to run with the 4rr.rt configuration on a Mac, you would run with the command:

java -mx512m -cp bin:lib/BasicDemo.jar:lib/gluegen-rt.jar:lib/jogl.jar:lib/postgresql.jar:lib/worldwind.jar -Djava.library.path=lib gov.nasa.worldwind.rsr.DemoMain -f 4rr.rt

The -f switch tells RSR to launch from a file instead of asking for launch options interactively from you as a user.

Understanding RimSim Response!

Scenario Editor

We create and edit emergency response scenarios using a scenarioEditor, a tool that allows a scenario designer to add player regions, identify forbidden regions, draw visible boundaries, move incidents around the region, change resource requirements for each incident, and to locate resources for an initial configuration. A designer can also request that the scenarioEditor place incidents and resources according to a distribution function – choosing from a number of probability distributions both for the spatial placement of incidents and resources, and for the temporal injection of active incidents. Regardless of whether the incidents are placed randomly or by hand, descriptive statistics of the incident placement and timing are available to the user in real time, as shown in the Figures 1 and 2 below.

Figure 1. A screen capture of the scenarioEditor showing a randomly created set of incidents.The incidents were created using a Lorenzian distribution with g=0.01 for their spatial characteristics, and a Poisson distribution with l=1 for their temporal characteristic.

  
(a)                                                 (b)                                                  (c)
Figure 2. Examples of scenarios generated using the scenario editor, representing regional incident management in (a) Detroit, (b) Vancouver, CA, and (c) Christchurch, NZ.

Player Roles

An RSR-based simulation affords multiple roles to be attempted simultaneously in game sessions using a specific scenario designed by the scenarioEditor described in the previous section. One player plays one role per session. Although we have studied and designed roles for other participants in an EOC, we have focused our simulation sessions to date on a dispatcher role. Although each role can be attempted by a human player (in either stand-alone or networked mode) or a software-based computer agent, our discussion here is limited to simulations run where all player roles are agent-based dispatchers.

Dispatcher

A dispatcher directly controls the movement of all resources that start in her assigned geographic region, and allocates those resources to meet emerging incident demands. All players see all incidents as visible icons within the complete scenario, but a dispatcher only sees their own resources – those within their assigned geographic region.

Dispatchers use the geographic game map pane to visually analyze resource locations and incident statuses. Each resource can be dragged to a new location temporarily to query the cost of moving that resource. The cost of moving the resource appears as an integer value, representative of the amount of time it will take the resource to move to the new location. If acceptable, the dispatcher confirms the movement and the simulation engine moves the resource visually from current location to requested location. If the dispatcher selects the location where an incident is in progress, the simulation engine updates the incident appropriately. Should the dispatcher reassign the resource before it completes its tasks at the incident, the incident is reset to remove the benefit of the resource that had been applied.

Dispatchers can control their viewpoint to center their view on any longitude-latitude (Lonlat) coordinate. Dispatchers can also set their current viewpoint altitude to study the emerging crisis at any height. Dispatchers need not view the crisis from directly overhead – they can choose their pitch and yaw to focus their distant view in any direction.

Figure 3. A sample dispatch player screen shot

Rules of Play

The objective of the RSR game is to minimize the number of active incidents on the board at any given time. Each dispatch role player has control over a number of independent resources, each of which has a type (red, yellow, green or blue) and a spatial location that begins within that player's geographic region, though players can move their resources outside their region whenever they desire. Each incident provides players an arbitrarily assigned incident number with which to identify it, a starting location, and a specified integer resource demand number for each of the four resource types.

Dispatchers are responsible for allocating their resources among the incidents that demand resources in order to be defused. Each computer-based agent that performs a dispatch role has the ability to interrogate an incident through requests processed immediately by the simulation engine. Each such agent can also interrogate the cost of moving a resource to that incident – again the simulation engine responds immediately. Instead of delaying a response, the simulation services component limits the number of turns an agent can take per time slice. The waiting period between turns can be reduced to simulate faster players or increased to slow down the pace of play for the benefit of beginners watching a session in action.

At any time, a dispatcher can apply any free resource to any active incident, at which time it begins moving toward the selected incident. The player can reroute a resource to another location while it is still en route, but once a resource reaches an incident, it becomes unavailable for application to other incidents until its current incident has been handled.

As resources are assigned to incidents, the demand for that resource type is decremented on the incident icon. When the number of resources of each type that have been applied to an incident is equal to the incident's resource demand for that type of resource, the incident is considered “handled” and is defused – its visual icon disappears from the board, and the resources that had been applied to it become available to dispatchers for assignment to other incidents.

Currently, because the RSR requires that all of an incident's needs must be satisfied before any of the resources assigned to it are free for reassignment, we note that there is a danger that a player can run out of resources. If a player is facing ten incidents each with a requirement of 2 red, 2 yellow, 2 green, 2 blue, having at his disposal ten resource units of each color, assigning one resource of each color to each incident will result in no incidents handled and all resources unavailable while sitting at the incident.

Dispatchers communicate between themselves via freeform text and specific contextual messages relevant to multi-player cooperation. Contextual messages currently implemented include the request for resources to an incident within a dispatcher’s geographic region, and the offer of a specific number and type of resource to another dispatcher. A dispatcher must wait for confirmation of the intent to help meet a request from another dispatcher before the requesting dispatcher can be sure he is taking the request into his own resource allocation accounting. Likewise, a dispatcher must accept an offer for help before the offering dispatcher can be sure he is taking the offer into his own resource allocation accounting.

Scoring Rubric

All players share a simulation session score that the simulation engine updates as incidents are handled. Currently, the score displayed for live players takes into account only the proportion of total cumulative resource demand satisfied so far. The more resource demand met in all jurisdictions, the higher the score.

Game End Conditions

A typical game session is played for either a pre-determined length of time or until the final incident in a scenario is introduced.

Resources

Resources are divided into four abstract types (red, yellow, green, blue), and are represented as circular icons, in accordance with NIMS conventions. Resources of each type are allocated to each region according to the rules of the scenario.

Resources are placed at starting locations by the scenario designer. A good scenario designer should clump resources near physical locations where those resources are likely to exist – for example, if blue resources are meant to represent a police resource, the designer should place them near police precinct headquarters. A good scenario designer also considers the typical movement of resources when the community is not in crisis – for example, if red resources are meant to represent medical supplies, they should only be located at starting positions along the route between a warehouse and medical facility with the probability they would be in transit during a non-crisis time period.

Incidents

Incidents are represented by a 4-tuple of resource needs at a fixed geographic location. When and where they appear is under the control of the scenario designer. Incidents are currently stationary, and the resource demand level for each resource type is fixed (although mobile and dynamic demand levels will be available shortly). The geographic location of an incident defines which player region is primarily responsible for that incident, making that region’s dispatcher its implicit “owner”. Incidents appear on the board either once every n seconds, or at specific times relative to the start of play, depending on the runtime configuration.

Incidents are placed at starting locations by the scenario designer. A good scenario designer should clump incidents near physical locations where those incidents are likely to exist – for example, if the scenario is based on a physical stress model, incidents should occur near buildings and roads that are known to respond poorly to physical stress. A good scenario designer also considers the typical timing of incidents as being congruent with the incident distribution of that scenario – for example, fires are known to have a known distribution based on weather conditions and the materials of the structures that are likely to burn.

Agents

In order to test scenario designs without requiring help from human-based players, all or most roles can be played by computer-operated agents, which play according to predefined strategies. Because human players neurons fire much slower than computing transistors, and human players can only attend to pieces of the visual interface at one time, we have limited the agents to be able to assign one resource every turn – with turn-taking time set by a simulation designer or agreed upon by the players at start up.

The behavior of the agents that have been implemented thus far are described in terms of three parameters: (1) their predetermined guiding policy on sharing resources with neighboring jurisdictions, (2) their strategy for determining which incident should be addressed next, and (3) their strategy for determining which resource to assign the targeted incident.

As mentioned above, we have limited the behavior of agents to a turn-taking model in order to slow them down to better reflect reasonable human mental processing speed. During each turn:An agent figures out its resource surplus (how many resources it has free, minus the number of unmet resource demands from incidents in its jurisdiction). Call this number R (note: R is occasionally negative).

We interrogate the agent’s R-level willingness to help. Call this number HiWat.
If R > HiWat, the agent looks at the requests for help that have been made by other players. If there is an open request and we are willing, the agent chooses a resource according to its Resource Selection Strategy (RSS) and send it to the incident specified in the request. This ends a turn.

We interrogate the agent’s R-level willingness to ask for help. Call this number LoWat.
If R < LoWat, the agent chooses the last incident on our priority list (if there is one; priority as determined by our ISS) and broadcasts a request for help on that incident. This also ends a turn.

The agent chooses an incident according to its Incident Selection Strategy (ISS) subject to its Resource Sharing Policy (RSP). This RSP provides a primary ordering of the incidents according to jurisdiction, the ISS provides a secondary ordering in case of ties (usually there will be lots of ties). If there are no incidents, this ends a turn.

The agent chooses a resource to send to the incident we have chosen, according to our RSS. Sends that resource to the incident we chose in step 4.

To reiterate, the agent behavior-defining parameters include:

We note that we have only implemented four of the logical eight (ISS, RSS) pairs based on our observations of emergency response drills and congruence with our common sense.

Resource-Sharing Policy

An agent's policy describes under what conditions it will voluntarily respond to incidents outside its given geographic region. Five policies are defined, though perhaps only the first three are interesting:

• Sociopathic - Will never volunteer aid to another region.
• Selfish - Will prefer incidents in its own region, but will volunteer aid to another region if there are no active incidents in its own region.
• Equal - Does not take geographic region into account when determining which incident to handle next.
• Selfless - Will prefer to volunteer for incidents in another region, but will handle incidents in its own region if there are no outside incidents to handle.
• Altruistic - Will never handle its own incidents, but will always volunteer for incidents outside its region.

Incident Selection Strategy

Within the broader resource-sharing policy, there is still the question of which incident to handle first, since there might be many active incidents within a single geographic region at any given time. Which incident is selected in the end depends first on policy and then on incident selection strategy. We have four incident selection strategies available at present :

• First Fit - Chooses the incident with the lowest incident number regardless of other considerations. Computationally, this is far the simplest of the strategies.
• Round Robin - Chooses the incident that has been active the longest.
• Lottery - Gives each incident a number of tickets equal to the total number of resources it requires, and chooses a ticket at random. The incident holding the winning ticket is selected.
• Greedy - Considers the resources that would have to be applied to each incident, and chooses the incident that could be handled most quickly (that is, on the basis of the furthest required resource).

Resource Selection Strategy

Once an incident has been identified, the agent must choose resources to assign to that incident to resolve it. There are likewise multiple strategies for choosing resources to send. Currently we have the following resource selection strategies:

• First Fit - Chooses the free resource with the lowest resource number.
• Closest - Chooses the free resources closest to the incident.

Agent Types

The agent types that are currently available for play are a combination of these elements, particularly the two selection strategies, since the policy can be supplied as a parameter for every agent type. Currently available named combinations are:

• LocalAgent: First Fit incident selection, First Fit resource selection.
• RoundRobinAgent: Round Robin incident, Closest resource.
• LotteryAgent: Lottery incident, Closest resource.
• GreedyAgent: Greedy incident, Closest resource.

Communications Policy

An agent’s behavior is further modified by its inter-player communications policy:

• Rational - Requests help for specific incidents from other players if he ‘thinks’ they have available resources and can afford to offer them. Agent responds to requests for help from other players if he has the resources and thinks he can offer them without getting into a desperate state.
• Desperado - Requests help on all incidents he currently is not handling and does not respond to any outside requests, assuming no one will come to his aid if he asks or not.
• Paranoid - Does not ask for nor respond to help for fear of ‘looking bad’ to other people.
• Optimist - Does not ask for help but responds to all requests for help assuming others will come to his aid when necessary without asking.
• Pessimist - Asks for help on all incidents he currently is not handling, but only responds to outside requests if he has the resources to spare (and bringing them back ASAP if that changes).

Data Logging and Performance Metrics

In addition to the score displayed for live users, all incident-handling actions are time-stamped and logged to a session file. Researchers can thus derive a variety of performance metrics, depending on their research interests. Examples of potentially useful derived metrics might include average and cumulative latency to meet incident demand, incident handling “throughput” during a session, time to completion of all incidents, bonuses for resource sharing and penalties for idle resources, among others.