<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">CLUSTERING AGENT OPTIMIZATION RESULTS IN DYNAMIC SCENARIOS</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">André</forename><surname>Restivo</surname></persName>
							<email>arestivo@fe.up.pt</email>
							<affiliation key="aff0">
								<orgName type="department">Faculdade de Engenharia</orgName>
								<orgName type="institution">Universidade do Porto</orgName>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Paulo</forename><surname>Luís</surname></persName>
						</author>
						<author>
							<persName><surname>Reis</surname></persName>
							<email>lpreis@fe.up.pt</email>
						</author>
						<author>
							<persName><forename type="first">Roberto</forename><surname>Frias</surname></persName>
						</author>
						<author>
							<persName><forename type="first">Porto</forename><surname>Portugal</surname></persName>
						</author>
						<author>
							<affiliation key="aff1">
								<orgName type="laboratory">Laboratory of Artificial Intelligence and Computer Science</orgName>
								<orgName type="institution">Alegre</orgName>
								<address>
									<addrLine>Rua, Campo</addrLine>
									<postCode>823, 4150-180</postCode>
									<settlement>Porto</settlement>
									<country key="PT">Portugal</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">CLUSTERING AGENT OPTIMIZATION RESULTS IN DYNAMIC SCENARIOS</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">6E27B88F1EAC400C8239A8FC60506763</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T14:53+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>The application of optimization algorithms to parameter driven simulations and agents has been thoroughly explored in literature. However, classical optimization algorithms do not take into account the fact that simulations normally have dynamic scenarios.</p><p>This paper analyzes the possibility of using the classical optimization methods, combined with clustering techniques, in order to optimize parameter driven agents, in simulations having dynamic scenarios.</p><p>This will be accomplished by optimizing the agents in several random static scenarios and clustering the optimum results of each of these optimizations in order to find a set of typical solutions for the agent parametrization problem. These typical solutions can then be used in dynamic scenario simulations as references that will help the agents adapt to scenario changes.</p><p>The results of this approach show that, in some cases, it is possible to improve the outcome of simulations in dynamic environments while still using the classical methods developed for static scenarios.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Agents normally have parameters that can be changed in order to tweak their performance. Finding the parameters that yield the best results is a recurrent problem that anyone developing agents has already faced.</p><p>Several optimization algorithms have been developed and studied over the years such as: Simulated Annealing, Tabu Search and Genetic Algorithms <ref type="bibr" target="#b6">[7]</ref>. However, most of the times, these algorithms will only optimize agent parameters for a certain static scenario <ref type="bibr" target="#b0">[1]</ref>. If the scenario being analyzed by the agents changes, the optimum parameters will probably also change.</p><p>Simulation scenarios are often also defined by a set of parameters. In cases where this does not happen, parameters describing the scenario can sometimes be extracted. In this way, it can be said that a simulation normally has two sets of parameters that will influence its outcome: environment, or scenario, parameters (that are normally out of the agent's control) and agent parameters that can be changed in order to get better results.</p><p>One way of optimizing agents living in dynamic simulations, would be to run the optimization process against several different static scenarios and then have the agent constantly use the optimum parameters found for the scenario that most resembles the current one. This solution has several drawbacks like, for example, the overhead caused by the constant changing of parameters. The proposed way, described in this paper, of tackling this problem is to use clustering algorithms in order to minimize the number of different parameter sets, thus minimizing the number of times parameters need to be changed without losing responsiveness or efficiency. We will show that, in certain simulations, using this minimized set of parameter configurations can improve agent performance. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Clustering</head><p>Clustering can be defined as grouping sets of elements that are similar in some way. A simple way of achieving this objective is by obtaining maximum intra-cluster similarity and maximum inter-cluster dissimilarity.</p><p>Clustering methods have to deal with two different problems: membership (whether an element belongs to a certain cluster or not) and how many clusters to create. Most methods only deal with the first of these problems but some strategies have been developed to determine the number of clusters and cluster membership at the same time <ref type="bibr" target="#b2">[3]</ref>.</p><p>To develop an agent optimization system that can cope with scenario changes, solutions from an optimization problem must be grouped together, having in mind that different solutions apply to different initial conditions of the simulation. The objective is to find out which different kinds of solutions exist and to which type of problems each one of them can be applied (see Figure <ref type="figure" target="#fig_0">1</ref>). To implement the aggregation of scenarios, the K-Means clustering algorithm was used <ref type="bibr" target="#b3">[4]</ref>.</p><p>The K-Means algorithm starts with the creation of k clusters with initial centroids estimated using some kind of heuristic. Elements are then assigned to the cluster with the nearest centroid (usually using simple euclidean distance measurements). New cluster centroids are then calculated and the process repeats until convergence is met (i.e. no element changes cluster).</p><p>The major drawbacks of this method are: the fact that the number of clusters must be predetermined; having a poor performance as distances to the cluster centroids must always be recalculated in each step; and its results being very dependent of the initial choice of cluster centroids.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Scenario Clustering</head><p>Optimizing n different scenarios for a simulation S, will produce a set of results − → R , in the form − → R = (r 1,..., r n ). Each one of those results r is the union of three other values r = ( − → s , − → p , v), where − → s is a set of environmental parameters, in the form − → s = (s 1 , . . . , s m ), − → p is a set containing the agent parameters that optimize that scenario, in the form − → p = (p 1 , . . . , p k ), and each v is the best value achieved in that optimization. The values n, m, and k represent, respectively, the number of different scenarios optimized, the number of different environmental parameters and the number of different parameters optimized in each scenario.</p><p>If we take all − → p from the set − → R we get a set − → P containing all good solutions for the problem (although each solution is optimum only for a specific scenario). Having the same approach we can derive a set − → S from all the − → s values from − → R .</p><p>Hypothesis: In certain simulations, given a set − → P , containing the optimum solutions for a set of representative scenarios − → S , it is possible to construct subsets − → P 1 , . . . , − → P q whose elements are similar, inside each one of those subsets, but dissimilar to elements of the other subsets.</p><p>In other words, what we are stating is, that for some simulations, classes of solutions should emerge from the set of all possible solutions. It is important to notice that some simulations do </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Scenario Adaptation</head><p>One way of implementing scenario adaptation will be by simply listing all scenarios tested with their optimum parameter as calculated by the optimizer in the form:</p><formula xml:id="formula_0">S(i) = s i1 , . . . , s in , p i1 , . . . , p im<label>(1)</label></formula><p>Agents could then just find the scenario from the listing that is nearest to the present simulation conditions (see Figure <ref type="figure" target="#fig_1">2</ref>). A simple metric, like the euclidean distance, could be used to determinate the correct scenario. This approach, although simple, has some disadvantages:</p><p>• The scenario listing might be to extensive. This could make finding the best scenario computationally impossible.</p><p>• In some simulations constantly changing parameters can be complicated or undesired. This method would force simulations to change their parameters only due to small scenarios fluctuations.</p><p>The second problem could be solved by only changing the agent parameters in regular intervals (see Figure <ref type="figure" target="#fig_2">3</ref>). This would unfortunately cause other problems:</p><p>• In simulations where conditions do not change often, at least not dramatically, but that need a swift response when they do, this method could cause a slow reaction to environmental changes.</p><p>• Even if not as regularly this method would force configuration changes even when not strictly necessary.</p><p>A different approach would be to only change the configuration when the current scenario had an optimum configuration that differed significantly from the current one (or when the current scenario changed dramatically).</p><p>The problem with this approach is how to evaluate if a configuration/scenario differs greatly from another one. With no sense of scale it becomes tricky to make any type of decision on when to change to another parameter configuration. One solution would be to first analyze, for example, average distances between elements. A better one would be to classify the solutions and group them according to their similarity.</p><p>A different method of implementing adaptiveness could be developed by using the optimum parameter and scenario classes that the aggregator module produces. This could be done, if for every scenario class we had a representative parameter configuration. This configuration could be To use this method we would need the aggregator to output its results in the following form:</p><formula xml:id="formula_1">S(i) = sc i1 , . . . , sc in , p i1 , . . . , p im<label>(2)</label></formula><p>Where sc ij is the coordinate j of the centroid of scenario class i and p ik is the value of the parameter k that was found to be optimum for that same scenario class.</p><p>Some different methods can be used to find which parameter configuration to use for each scenario class:</p><p>• Test all parameters configurations found for that class against all scenarios. This method might reveal impracticable due to performance reasons;</p><p>• Find the nearest tested parameter configuration to the class centroid;</p><p>• Select a sample of the parameter configurations of that class and test them against the class scenarios;</p><p>• Select random parameter configurations nearer the class centroid and test them against the class scenarios;</p><p>• Apply an optimization algorithm but this time use the average result from the complete scenario class instead of testing one scenario at a time.</p><p>The advantages of this method over the Nearest Scenario approach are that we can react to sudden changes quickly and, at the same time, we are not changing the simulation configuration constantly as a reaction to small environmental changes.</p><p>Then main concern one has to have when using the Nearest Aggregate approach, is to be sure that the parameter configuration chosen for each scenario is good enough for all the elements in that scenario. This can be easily done by testing that configuration against all representatives of the scenario class. As we do not know the scale of the simulation results, we need some kind of input from the user to be able to determine how much of a loss is admissible.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Test Case Scenario</head><p>In order to find a simulation that allowed the testing of all the desired aspects of the implemented system, several characteristics were sought:</p><p>• Different Scenarios -The simulation had to have different scenarios that required completely different parameter configurations. This would allow testing the optimization module, as well as the aggregation module; The optimum configuration of these parameters should depend on the current scenario;</p><p>• Dynamic Scenarios -It should be possible to create a dynamic scenario. In this way the simulation would experiment different parameter configuration needs during each run. This would allow testing the scenario adaptation capabilities of the system;</p><p>• Simulation Speed -A simulation run should not take too long in order to allow the maximum number of tests possible;</p><p>• Stochasticity -A stochastic simulation would allow testing if the simulation adapted well to this type of situations.</p><p>Several possible simulations were considered, and in the end the choice was to implement a very simple traffic simulation system. This simulation has all the characteristics listed previously and was fairly easy to implement. The model chosen was very simple:</p><p>• Several roads, each with only one lane in either direction;</p><p>• Roads could be either vertical or horizontal;</p><p>• Each car would enter the city in a certain lane and exit the city in that same lane. Lane changing, or turning, were not considered to keep the simulation simple;</p><p>• Traffic lights at each road intersection. A traffic light could be in one of three states: open for vertical traffic, open for horizontal traffic or changing states (yellow light);</p><p>• Cars would follow the car in their front according to a simple driver model <ref type="bibr" target="#b7">[8]</ref>.</p><p>Besides having the characteristics just listed, in this simulation it was expected that classes of solutions (containing different agent parameter configurations) would emerge.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6">Tool Implementation</head><p>A generic optimization system has been implemented to validate the ideas behind this paper. Four main points are behind the construction of this prototype:</p><p>• In the simulation optimization field, researchers often develop their own optimization systems.</p><p>This happens mainly because it is relatively easy to develop a fairly decent optimizer from scratch. However having a generic optimization system available would allow the researcher to optimize his simulation with several, and perhaps more advanced, optimization methods and use some already developed analysis tools. Figure <ref type="figure">5</ref>: Generic Optimizer and Aggregator Architecture</p><p>• No system is ever generic enough for everyone. So, having the possibility of extending a system is crucial when developing a generic system. In particular this optimization system should allow new optimization methods to be added easily.</p><p>• Simulation based optimizations are always, or almost always, CPU intensive. This happens because optimization algorithms need to run simulations, which sometimes are already CPU intensive, numerous times, in order to achieve good results. An usable optimization system must take this into account.Distribution is the most obvious way of working around this problem, so a good optimization system should allow the distribution of workload across different machines.</p><p>• Simulations are used many times to optimize a set of parameters that will be later used in the real world. Most optimization systems approaches do not take into account the fact that there are environment changes occurring every time in real life applications.</p><p>As explained before, a simulation normally receives a set of parameters and outputs a set of results. Besides that, most simulations have a set of environment parameters that can be user adjusted or randomly selected.</p><p>A generic optimization system must cover as many different configurations as possible. However, creating a system that is to complicated to use should be avoided. So, a few concessions had to be made in order to keep the system simple. However, the system allows different simulation configurations to be used by means of system extensibility.</p><p>The system is composed by several modules that will be introduced in the following paragraphs and are explained in full detail in <ref type="bibr" target="#b4">[5]</ref>.</p><p>To begin, a module that will interact with the different type of simulations was needed. This module is, first of all, distributable so we can have several instances of it running in different machines. It should also be able to receive a binary file for a certain simulation, instructions on how to run it with different parameters and how to gather results from it.</p><p>A second module, that works closely with the one just described, is responsible for evaluating simulation runs. Another task of this module is to mask the fact that simulations are normally stochastic in nature.</p><p>Optimization is obviously the major goal of the system so an optimization module is essential. This module uses the evaluator module in order to get the results from various simulation runs and use these results to find the optimum parameters for a given scenario.</p><p>A final module aggregates and analyzes results from the optimizer, in order to create dynamic optimization schedules for the simulation, and allow the user to better understand how parameters and scenarios influence each others. The clustering module receives the optimum parameters for each scenario from the optimizer and outputs the dynamic optimization schedules that are then used by a simulation having dynamic scenarios. Figure <ref type="figure">5</ref> captures the various modules and their interaction. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="7">Results</head><p>Several different scenarios were randomly generated with an optimization algorithm (in this case a Genetic Algorithm <ref type="bibr" target="#b1">[2]</ref>) applied to each one of them. This generated approximately one hundred different scenarios and their respective agent optimum parameters.</p><p>These results were then aggregated into several representative clusters using the K-Means algorithm. This step, produced a set with only nine different scenarios.</p><p>An altered version of the traffic light simulator was developed, that instead of receiving a static traffic light schedule, would receive a set of scenario and agent parameter configuration pairs. This version of the simulator would constantly select the scenario, from that set, that most resembled the current scenario and use the traffic light configuration that was considered as the best for that particular case. This setting was run with three different configuration files:</p><p>• The complete set of scenarios (one hundred) and their optimum parameter configurations.</p><p>• A significantly smaller set of scenarios created with base in the larger set using the aggregation process.</p><p>• A single optimum parameter configuration that was calculated as being the best for an average scenario.</p><p>Table <ref type="table" target="#tab_1">1</ref> captures the most important results from each test run. Using a smaller subset of results, one would expect fewer changes in the used configuration. In fact Table <ref type="table" target="#tab_1">1</ref> shows exactly that. Using the complete set of results the simulation changed parameters 1116 different times against 162 times using the clustered subset.</p><p>As less information was available, theoretically the simulation could not adapt as well as in the previous method. However, using the clustered results did not affect the simulation performance and even made it more efficient. There is a simple reason that explain this, at first glance, awkward behaviour. This happened because constantly changing parameters can lead to a loss in performance. In this particular case each time the parameters changed the timing of the traffic lights would be affected momentarily causing smaller, or longer, traffic light patterns than the optimum ones. In other scenarios the cost of changing parameters could be even higher (e.g. if the agents had to change their planning every time the parameters changed).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="8">Conclusions</head><p>Agent based simulations, involving complex and dynamic scenarios, have poor results when single static configurations are used. One way of coping with this problem is to have a large set of configurations that will be used in each specific scenario. The problem is that some simulations do not cope well with configuration changes. This can be true either because changing the configuration is expensive or because a period of instability is created when the configuration is changed.</p><p>In this paper, it has been shown that using clustering algorithms to create smaller, but still meaningful, sets of configurations is a valid method that can be used to minimize the number of possible configurations thus minimizing the number of configuration changes. In the particular simulation tested it has also been shown that using this same method, better results can be achieved. The K-Means clustering algorithm has been shown as an effective clustering algorithm for this particular problem. More complex simulations might require different clustering algorithms.</p><p>Other tactics to minimize the number of times the configuration is changed have been discussed like, for example, only changing the configuration when the current scenario differed significantly from the last scenario where the configuration has been changed. It has been explained that this alternative can create some other problems, like estimating how much change is needed for a scenario to be significantly different from another. Other problems would exist if two close scenarios needed radically different approaches. Another approach would be to analyze if a configuration change is needed from time to time. This alternative approach would not work well if the simulation was very dynamic and quick responses were needed when the scenario changes.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="9">Future Work</head><p>The only clustering method implemented as support for this dissertation has been the K-Means algorithm. Further testing could be done with different clustering algorithms or with variations of the used algorithm.</p><p>In this paper it has been assumed that clusters always have a n-dimensional spherical form. This is not always true. Optimization results can form very different types of clusters like ellipsoids and stripes or even have a completely different formations that can only be defined mathematically. In the later case, clustering algorithms would no longer be useful and other methods had to be studied.</p><p>The method presented for scenario adaptation is just one of many different possible approaches. Several other methods could be researched. One obvious problem that needs to be tackled is that of simulations where it is hard to make runs in static scenarios and are difficult to assess using small time sections of the simulation. For example, in the Robo Soccer Simulated League <ref type="bibr" target="#b5">[6]</ref>, the scenario could be seen as a set of different parameters, representing things like the behavior of the other team, remaining time or ball position. In this case it would be impossible to run the simulation with a static scenario as some of these parameters would change throughout the simulation.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Figure 1 :</head><label>1</label><figDesc>Figure 1: Optimum Agent Parameters per Scenario (clustered)</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Figure 2 :</head><label>2</label><figDesc>Figure 2: Continuous scenario selection</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Figure 3 :</head><label>3</label><figDesc>Figure 3: Time based scenario selection</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head>Figure 4 :</head><label>4</label><figDesc>Figure 4: Traffic Simulation Interface</figDesc><graphic coords="5,185.52,85.15,226.70,163.01" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head>Table 1 :</head><label>1</label><figDesc>Adaptative Simulation Results</figDesc><table><row><cell></cell><cell>Avg/Max Waiting Time</cell><cell>Max Queue Size</cell><cell>Configuration Changes</cell></row><row><cell>Single</cell><cell>28/87s</cell><cell>610 cars</cell><cell>0</cell></row><row><cell>Complete</cell><cell>30/94s</cell><cell>130 cars</cell><cell>1116</cell></row><row><cell>Clustered</cell><cell>23/82s</cell><cell>17 cars</cell><cell>162</cell></row></table></figure>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="10">Acknowledgements</head><p>This work was partially supported by FCT Project FCT/POSC/EIA/57671/2004 (ABSES -Agent Based Simulation of Ecological Systems).</p></div>
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">A tutorial on simulation optimization</title>
		<author>
			<persName><forename type="first">Farhad</forename><surname>Azadivar</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">WSC &apos;92: Proceedings of the 24th conference on Winter simulation</title>
				<meeting><address><addrLine>New York, NY, USA</addrLine></address></meeting>
		<imprint>
			<publisher>ACM Press</publisher>
			<date type="published" when="1992">1992</date>
			<biblScope unit="page" from="198" to="204" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Evolutionary computation: An overview</title>
		<author>
			<persName><forename type="first">Thomas</forename><surname>Bäck</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Hans-Paul</forename><surname>Schwefel</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of 1996 IEEE International Conference on Evolutionary Computation (ICEC &apos;96)</title>
				<editor>
			<persName><forename type="first">T</forename><surname>Fukuda</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">T</forename><surname>Furuhashi</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">D</forename><forename type="middle">B</forename><surname>Fogel</surname></persName>
		</editor>
		<meeting>1996 IEEE International Conference on Evolutionary Computation (ICEC &apos;96)<address><addrLine>Nagoya; Piscataway NJ</addrLine></address></meeting>
		<imprint>
			<publisher>IEEE Press</publisher>
			<date type="published" when="1996">1996</date>
			<biblScope unit="page" from="20" to="29" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">How many clusters? Which clustering method? Answers via model-based cluster analysis</title>
		<author>
			<persName><forename type="first">C</forename><surname>Fraley</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">E</forename><surname>Raftery</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">The Computer Journal</title>
		<imprint>
			<biblScope unit="volume">41</biblScope>
			<biblScope unit="issue">8</biblScope>
			<biblScope unit="page" from="578" to="588" />
			<date type="published" when="1998">1998</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">Data clustering: a review</title>
		<author>
			<persName><forename type="first">A</forename><forename type="middle">K</forename><surname>Jain</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">N</forename><surname>Murty</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><forename type="middle">J</forename><surname>Flynn</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Computing Surveys</title>
		<imprint>
			<biblScope unit="volume">31</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="264" to="323" />
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<monogr>
		<title level="m" type="main">Dynamic scenario simulation optimization</title>
		<author>
			<persName><forename type="first">André</forename><surname>Restivo</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2006">2006</date>
		</imprint>
		<respStmt>
			<orgName>Faculdade de Engenharia da Universidade do Porto</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Master&apos;s thesis</note>
</biblStruct>

<biblStruct xml:id="b5">
	<monogr>
		<ptr target="http://www.robocup.org/" />
		<title level="m">Robocup international homepage</title>
				<imprint>
			<date type="published" when="2006">2006</date>
		</imprint>
	</monogr>
	<note>RoboCup</note>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">A survey of simulation optimization techniques and procedures</title>
		<author>
			<persName><forename type="first">J</forename><surname>Swisher</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Hyden</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Jacobson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">L</forename><surname>Scruben</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the 2000 Winter Simulation Conference</title>
				<editor>
			<persName><forename type="first">K</forename><surname>Kang</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">J</forename><forename type="middle">A</forename><surname>Joines</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">R</forename><forename type="middle">R</forename><surname>Barton</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">P</forename><forename type="middle">A</forename><surname>Fishwick</surname></persName>
		</editor>
		<meeting>the 2000 Winter Simulation Conference</meeting>
		<imprint>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Congested traffic states in empirical observations and microscopic simulations</title>
		<author>
			<persName><forename type="first">Martin</forename><surname>Treiber</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Ansgar</forename><surname>Hennecke</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Dirk</forename><surname>Helbing</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Physical Review E</title>
		<imprint>
			<biblScope unit="volume">62</biblScope>
			<biblScope unit="page">1805</biblScope>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
