CHAPTER 6
RUNAGENCY
In a Web and component-based simulation environment, everything used to build the simulation application is a software component. In JSIM, every simulation component is a Java bean. In the case of model agents, they are not only a software component but also intelligent agents. They can perceive what happen around them, for example, notifying that some buttons are clicked. They also can communicate with other agents and beans using the Event/EventListener framework. Most importantly, they have decision-making abilities.
The simulation analyst can use a visual builder tool to assemble these beans into an application, execute the simulation and get the output data s/he needs. In a non-integrated environment, several problems have to be solved in order to allow a simulation analyst, who may not know anything about programming and Java, to figure out some important features related to the simulation.
For example, what are the properties of the simulation model and how does one modify these properties? What kind of output data analysis method is available in the existing simulation components, referred as model agent in following text? What are the properties of these data model agents and how does one modify them? How can one model bean work with different model agents and how can one model agent bean work with different models? How does the simulation analyst find and specify the location
where the data will be collected? To keep the data persistent, what kind data storage is available? Which component can support database accessing?
6.1 Perception and Communication Properties
In the visual build tool like bean box, the model agents stay at toolbox as a GUI icon. Because it is a child class of a java.awt.Panel, or javax.swing.JPanel, it has all the properties of these classes. It can perceive all GUI events like mouse movement, mouse entered or mouse double-click. Due to bean’s properties, it can fire events to take action or receive event sent by other beans or agents.
The model agent’s perception and communication ability can be described by a typical application. A user builds an application in the following way: In the visual builder tool like bean box, the user selects a model bean, a model agent bean, and a scenario bean from the toolbox and puts them into a bean box. S/he can assemble the beans visually and hook them together. After everything is done, S/he clicks the button on the model bean Panel. The model will fire an AdvertiserEvent to export its properties. The model agent is listening to the event, and will receive the event and add its properties to the event and fire the event again. The ScenarioAgent will receive the event and display all the properties from model and model agent to a GUI. The simulationist can modify these properties and select a desirable location to collect data. After the user finishes modifying those properties, s/he clicks the Run button on GUI of the ScenarioAgent. A ScenarioEvent will be fired and all the modified model and model agent properties will be carried by this event. The model agent gets the event and fires ModelActionEvent to the model. The simulation process starts. The model can send back the output by firing ModelReportEvent. The model and model agent will ‘talk’ to each other using ModelActionEvent and ModelReportEvent ‘languages’ until the simulation is over. Therefore, the model agent can ‘speak’ ModelActionEvent, and AdvertiserEvent ‘languages’. It also can ‘listen’ to ModelActionEvent, AdvertiserEvent, and most of GUI events. Model agents also can take action by ‘talking’ to other beans and agents to do something. For example, they can ‘ask’ a model bean to start the simulation and collect a specific amount output data.
If the user wants to store the output data and related properties of model and model agent to database, he or she can link the database bean with model and model agent. All the data will be sent to database when the simulation is over.
A model agent also is autonomous. It can work with model without a ScenarioAgent. In this case, the user connects the model bean and the model agent together, and then makes use of bean box’s property sheet to modify the properties of model and model agent. S/he can start the simulation by clicking the button on the model agent Panel.
6.2 Decision-Making Ability
The decision-making ability in intelligent agents can range from hardcoded procedural or object-oriented logic to sophisticated reasoning and learning capabilities. In the case of the model agent, the application domain determines that the model agent does not need sophisticated reasoning and learning abilities. What it needs is how to represent the algorithm of simulation output analysis. In most cases, these algorithms can be hardcoded in Java program language.
To make the data collected by a model useful, effective output analysis methods are essential to bring the unbiased result for the simulation. As discussed in the chapter 3, the most popular methods used in output data analysis are independent replications and batch means. Two types of model agents are currently implemented in JSIM, BatchMeansAgent and ReplicationAgent. The model agents not only implement the algorithm of output data analysis but also are components. Therefore, each model is able to work with different kinds of models and provide output data analysis. The code of ModelActionEvent, ModelActionEventListener, ModelReportEvent, and ModelReportEventListener are included here:
public class ModelActionEvent extends EventObject
{
Vector data;
/*****************************************************
* Construct a ManageEvent using a passed-in vector of
* data
*/
public ModelActionEvent ( Vector data )
{
super (data.toString ());
this.data = data;
} // ModelActionEvent
public Vector getData ()
{
return data;
} //getData
} //class
public interface ModelActionEventListener extends
EventListener
{
/*****************************************************
* A method to consume ModelActionEvent
*/
public void managerIsReady (ModelActionEvent mevt);
} // interface
/********************************************************
* An event created when a batch data are collected.
*/
public class ModelReportEvent extends EventObject
{
double[] data;
/****************************************************
* Construct a BatchEvent using a passed-in array of
* data
*/
public ModelReportEvent (double[] data)
{
super ("ModelReportEvent");
this.data = data;
} // ModelReportEvent
public double[] getData ()
{
return data;
} //getData
} //class
public interface ModelActionEventListener extends
EventListener
{
/****************************************************
* A method to consume ModelActionEvent
*/
public void modelAgentIsReady (ModelActionEvent mevt);
} // interface
A model agent must implement ModelReportEventListener in order to listen to ModelReportEvent. It is the ModelReportEvent that carries the data collected by the model to the model agent. It also needs to define the AdvertiserEventListener to be able to receive the AdvertiserEvent and properties of the model. The model agent must be able to fire ModelActionEvent to pass instructions to the model. The model agent also must be able to fire AdvertiserEvent to inform the ScenarioAgent its properties and the model properties.
6.3 BatchMeansAgent
For the batch means model agent, the initial transient period, minimum batch size, number of batches, relative precision and the level of confidence are the necessary properties. The default values of these properties must be displayed on the GUI of ScenarioAgent or property sheet of the bean box.
After the user modifies these properties, BatchMeansAgent passes the ModelActionEvent to the model. Basically, ModelActionEvent contains two types of data. One is controlling data, which can inform the model to start a new simulation or quit the current simulation. The other is batch means data, which includes the transient period, number of batch, and size of each batch. When the model gets the ModelActionEvent, it extracts control data and starts a new simulation process. The model skips all the output data in the initial transient period and then collects a specific number of batch data with a given batch size. Then, the model fires ModelReportEvent, which is composed of an array of floating values as its data attribute. The elements of the array are the batch mean values of the batches it has collected so far. The BatchMeansAgent obtains the event and its array, and extracts batch mean values. It calls the method testCorrelation to test the correlation among batches. The main part of testCorrelation is shown as following:
private boolean testCorrelation ()
{
double Cl;
double var;
double test;
Cl = 1 - bMeanCol.getSumSquBatch () /
(2 * (double) nBatch * bMeanCol.variance());
var = getVariance( nBatch );
test = Cl/Math.sqrt(var);
double t = - InverseT.tValue(independentConf, nBatch);
if(( Math.abs(test) > t )||(!testPrecision () )){
if( nBatch >= 2 * halfSize ){
nBatch = halfSize;
setBatchSize( 2 * getBatchSize () );
return doubleBatchSize( localArray );
}
else
return false;
}
else
return true;
}; // testCorrelation
If batch means are not deemed to be autocorrelated, then the model agent will call the testPrecision method to test if the relative precision goal has been reached. If any of previous two conditions has not been reached, the model agent will fire ModelActionEvent again to ask the model to collect two batches, with current size of batch, if the minimum number of batch is even. Otherwise, it will ask the model to collect one batch. The model agent will test the autocorrelation and relative precision conditions again when it gets the additional data. At any moment, if both conditions are satisfied, BatchMeansAgent will ask the model to quit. Otherwise, it is going to collect additional batch mean values until the number of batch collected is twice the minimum number of batches. BatchMeansAgent will double the size of the batch, test the conditions, and collect more data if necessary.
The following piece of code is the testPrecision method:
private boolean testPrecision()
{
double precision = relativePrecision /(1.0 +
relativePrecision);
/*************************************************
* Check the relative precision
*/
double relPrecision = bMeanCol.confidence () /
bMeanCol.mean ();
return relPrecision <= precision;
}; // stoppingRule
When simulation is over, the batch means model agent can fire PrimaryReportEvent to store the final output data and the model agent’s properties to database.
6.4 ReplicationAgent
For the ReplicationAgent, the initial transient period, size of each replication and relative precision are the necessary properties. The default values of these properties must be displayed on the GUI of ScenarioAgent or property sheet of bean box.
After the user modifies these properties, the ReplicationAgent passes the ModelActionEvent to the model and asks it to skip all the output data in the initial transient period and then collect a specific number of replication data with a given replication size. When the model gets the data from the model, it calls testPrecision to test if the relative precision goal has been reached. If it is not, it will ask the current model to quit and repeat the same procedure again to run another replication. The simulation continues until the relative precision of the simulation is less than the precision specified by user. The sequential estimation method is used to test the relative precision too. When simulation is done, the replications model agent can fire PrimaryReportEvent to store the final output data and model agent’s properties to database.
Because each entity in the JSIM models is a thread, at any time, there could be several threads running at the same time. When ReplicationAgent fires the ModelActionEvent to stop the current replication. It actually just stops the threads in all the Source nodes that generate new entities. The current replication stops when the Sinks of the model catch every living entity of the model. The ReplicationAgent must be able to detect that moment and start the next replication to avoid the race conditions and preserve the independence among the replications. To do so, in the ModelBean, a particular control thread is implemented. The run method is included below.
From this code, the control thread keeps checking the number of live entities from the current replication. It will start a new replication only if ReplicaitonAgent gives the instruction and live entities of previous replication is zero. The control thread stops when the relative precision goal set by user is achieved
/**********************************************************
* Run the control thread. The control thread waits for
* The display thread of model to die. When it is dead,
* controlthread starts another display thread until entire
* simulation is done.
*/
public void run ()
{
try {
/***********************************************
* Sleep and repaint the canvas until the simulation
* is over.
*/
while ( ! stopReplication ) {
while ( model.getDisplayThread ().isAlive ()
||(! model.liveEntity.isEmpty () ))
try {
thr.sleep(WAITING_TIME);
}catch (InterruptedException e) {
System.out.println
("run: Interrupted Exception");
}; // try
if(restart){
model = new Model (label, false);
model.setReplication( true );
model.setModelReportEventListeners
(modelActionEventListeners);
model.setStatReportEventListeners
(statReportEventListeners);
model.setEntityEventListeners
(entityEventListeners);
startSim ( true );
setDataCollectLocation( location );
model.setBatchSizeAndNo(replSize, 1);
}; // if
restart = false;
}; // while
} catch (StopException se) {
System.out.println("run: caught StopException");
}; // try
System.out.println ("fireStatReportEvent");
model.fireStatReportEvent();
}; // run
6.5 Scenario Agent
To simplify the user’s work, a special agent, ScenarioAgent, is created exclusively to handle the communication with the user. The ScenarioAgent not only has the ability to guide the user to select the proper simulation properties related to the model and model agent, but also gives the user an integrated GUI no matter what models and model agents are involved. This means the GUI is generated dynamically according to the specific model and model agent selected by user. The following diagram shows a snapshot of ScenarioAgent’s GUI with Emergency Room model and BatchMeansAgent model agent selected.
The ScenarioAgent can communicate with a user by noticing the GUI events like Button clicked by user, Choice selected by user, or TextArea entered by user. It also can perceive, collaborate, and communicate with other agents and beans. It receives
Figure 1. ScenarioAgent GUI with Eroom model and BatchMeansAgent model agent
AdvertiserEvent
to get all the properties from a model and a model agent. It can fire ScenarioEvent to send the modified properties back to the model and the model agent, and start the simulation. It is also designed to consume the PrimaryReportEvent from model agent and display the final results of the simulation on the TextArea of the GUI when simulation is done.ScenarioAgent
’s intelligence is its ability to give some guidance to the user about how to get information about the simulation and how to customize the simulation properties and how to start it. Figure 1 shows a typical environment the ScenarioAgent usually gives.ScenarioAgent
also has the ability to analyze the user’s input, detects several types of errors including:Number of Freedom, Maximum Customers, Maximum simulation time, etc.
These values must have non-negative values.
A ScenarioAgent can figure out some input errors related to simulation semantics. For examples, The maximum simulation time must be larger than transient period. The maximum customer is bigger than replication size. The minimum batch size is greater than zero.
The ScenarioAgent can check these errors and give some error messages on the TextArea (See Figure 2). It only allows the simulation to start when all these errors are corrected. This not only helps user to manage the simulation, but also enhances the quality of the simulation.
To implement the ScenarioAgent’s integrated GUI, the ScenarioAgent declares a variable of ScenarioWin class. The ScenarioWin is composed of four GUI components. They are ModelPanel, AgentPanel, ButtonPanel, and TextArea. When the ScenarioAgent receives an AdvertiserEvent, it obtains the properties of model and model agent from the data area of AdvertiserEvent. ScenarioWin is initialized with the data.
Figure 2. ScenarioAgent GUI with Eroom model and ReplicationAgent model agent
To display the model properties, ScenarioWin retrieves the property data of the model, exams the data and dynamically generates the GUI components for the model. Figure 3 is the ModelPanel window of the bank model.
The ScenarioWin deals with the different model agents exactly the same way as it does to models. Except it uses AgentPanel instead of ModelPanel. Figure 4 and figure 5 are screen shots of two model agents.
Figure 3: Screen shot of ModelPanel window of Bank model
For simple properties of the model and model agent, pairs of Label and TextField are used. Label specifies the name of the property and TextField contains the default value. Therefore, a user can identify these properties easily and modify their default values. The distribution is displayed in a Choice component. Below the distribution Choice, there are eight TextFields, which contain the corresponding names
Figure 4: Screen shot of AgentPanel window of batch means model agent
and default values of the distribution. If the user chooses another distribution from Choice, the corresponding names and default values of the distribution will change accordingly. The distribution Choice and the eight TextFields have the same color, which is different from the background color. This makes it easy to notice the relationship among them. The data monitoring location is also a Choice with a Label in front of it. Model agents currently only use the data collected in monitoring location for the stopping rule.
The remaining GUI components are TextArea and three Buttons. The cancel Button can dispose the GUI window and quit the simulation, and the reset Button resets all the default values of properties. When the start Button is hit, ScenarioWin extracts all the property values from GUI and checks these values. If something is wrong, error messages will show up in the TextArea. If everything is fine, the ScenarioEvent is initialized by the data. The ScenarioAgent will fire the ScenarioEvent and start the simulation.
Figure 5: Screen shot of AgentPanel window of replication model agent