initial demand execution
(mobsim) scoring analysis
replanning
Figure 4.3: The building blocks of the Multi-Agent Transportation Simulation (MATSim)
e agents try to learn from their experience and to optimize their day plans.
For this to happen, some feedback must be provided from the physical world to the mental world (see Fig. 4.1). is usually includes information about the state of traffic at certain times of day at certain locations, or some data about how much the actual day deviated from the day plan. With this information, agents can try to improve their day plan, maybe switching routes to avoid traffic jams, leaving work earlier so they arrive at the shop while it is still open, and so on. e new day plans will again be executed by the traffic flow simulation, and the agents will learn if their new plans were better or not accounting for the interaction with other agents, and may optimize again. is constitutes a loop between mental and physical world, in which the agents iteratively try to optimize their day plan. One round in the loop is usually called oneiteration of the simulation.
Fig. 4.3 shows the schematic control flow of the Multi-Agent Transportation Simulation (MATSim, [66]). It starts with the initial demand that describes an initial set of day plans for the simulated population. is initial set of day plans is thenexecuted by the traffic flow simulation or mobility simulation (mobsim). e performance of the day plans is evaluated during scoring, such that agents can try to optimize their day plans during replanning. e plans are then executed again.
is iterative loop continues until some criterion is met. In the end, it is possible to analyze the data in regards to traffic state or behavior of the agents. e following sections will take an in-depth look at the mentioned building blocks, starting with the Controler which is responsible for the data flow and interaction between the different parts.
4.2. Controler
string all the blocks (in the following also calledmodules) together and ensure that the correct data is handled at the right time by the right module is done by the so-called “Controler”¹. It builds the center piece of MATSim that holds all the single parts together and ensures that complete simulations with multiple iterations can be run. In earlier implementations of MATSim, Perl scripts or stand-alone tools were used to connect the various, at that time also stand-alone, tools together [95].
But to reduce the Controler to a simple “iteration manager” would be an un-derstatement. e requirements for the Controler are very different and change from one simulated scenario to the next one. Especially as the power of agent-based simulation is researched within MATSim, the Controler needs to adapt to different needs without interfering with the work of other people that are—for example—doing production runs. Examples of applications and their influence on the Controler are:
• Road-Pricing scenarios: Compared to a “regular” simulation, the simu-lation of road-pricing scenarios requires additional input (the definition of the toll schemes) and produces additional output (e.g. toll-related analyses).
But it also influences the scoring part (agents may have to pay money for a toll) and the replanning part (agents may prefer non-tolled routes).
• Simulating retailer behavior: Why should only “normal” agents try to op-timize their plans, maybe by changing shopping locations? Why not let the shop owners themselves change places, looking for higher frequented loca-tions such as to optimize sales [26]? So not only normal agents need to do scoring and replanning, but also other kinds of agents which may not even be known to the traffic flow simulation.
• Environmental research: is topic ranges from the simple calculation of emissions [44, 106] up to specialized replanning and analysis of effectiveness of electric cars [41]. e Controler must be able to deal with additional analyses, that may also influence the replanning parts.
• Evacuation simulation: Evacuations may have different movement char-acteristics, and may make use of additional input data (when and where is something bad going to happen? are there safe areas/shelters?) [62]. Not all of this information can be coded into the initial demand, so the Controler must be able to deal with additional input data, auxiliary analyses, modified replanning, and other extensions.
¹Likely based on some misunderstanding, MATSim uses the wrong spelling “Controler” instead of the correct “Controller” since its beginning. In order to be consistent with the software, I use the wrong spelling knowingly in this thesis.
initial demand execution
(mobsim) scoring analysis
replanning
1 Simulation Starts ("Startup") 2 Iteration Starts
5 Scoring 6 Iteration Ends 3 Before Plans Execution
4 After Plans Execution
7 Replanning
8 Simulation Ends ("Shutdown") 2
1 3 4 6
5
8
7
2
Figure 4.4: Extension points offered by the MATSim-Controler
Just from the few examples above, plenty of non-standard requirements can be detected that a Controler should be able to fulfill.
First experiments with an object oriented software design allowed many meth-ods to be overwritten—and the original functionality thus being replaced or ex-tended—, but did not bring a lot of success as the inheritance constraints in Java did not allow to easily combine two extensions together at a later stage. In addition, it was rather error-prone by the fact that it was never clear if an overwriting method should call the original super-method, effectively extending a certain functional-ity, or not call the original super-method, replacing the functionality. is led to problems where critical functionality was no longer available because the essential method was overwritten but the original method no longer called, or that certain aspects were executed twice if the overwriting method did very similar things than the original one that was still called.
An analysis of the structure and data flow within the Controler showed eight different places where it made sense to offer extension points such that additional functionality could be added in a modular way. Fig. 4.4 shows these identified ex-tension points in the MATSim-Controler. e exex-tension points were implemented using the Observer pattern [42], sometimes also called Event listener or Publish-Subscribe pattern. For each of the extension points, the Controler offers events to which interested extensions can subscribe to be informed when that specific state in the Controler flow has been reached. Extensions can subscribe to one or more Controler events.
e observable events are:
• Startup: Describes that the simulation starts up and that extensions should load any additional data they may require to function properly.