Framework

SimMobility is developed as a multi-level, integrated, activity based modeling platform. It is multi-level because it comprises three different simulators: the ST simulator represents high spatial temporal resolution (i.e. in the order of tenth of a second) events and decisions, such as lane-changing, braking and accelerating, individual and crowd pedestrian movement, agent to agent cell-phone communications. The MT simulator represents daily activity scheduling, mode, route, destination and departure time choices on a multi-modal network. Its temporal resolution is in the order of seconds or minutes. The LT simulator represents long-term choices such as house and job relocation or car ownership. SimMobility is also integrated because it simultaneously simulates demand and supply at each level, as well as interactions between different levels. Figure 1 reflects these interactions. SimMobility is designed using activity-based modeling paradigm. The LT simulator is influenced by activity-based accessibility measures, which are provided by the MT. The MT demand model is a full-fledged activity-based model, that incorporates pre-day activity-scheduling together with destination, departure time, route and mode choice (and rescheduling and re-routing during the day). The ST model receives trip-chains and activity-schedules as inputs and can also do re-routing and activity plan changes in simulation run time. Each of the three levels is modular and autonomous, and we can apply each one in isolation, by providing the appropriate inputs. I.e., the tight coupling is not mandatory. On the other hand, to take full advantage of its potential, SimMobility demands a tight coupling integration. For example, consider a policy scenario where an area is restricted to autonomous vehicles. The original macroscopic fundamental diagrams may no longer apply at the MT level simulation, which would demand running simulations at the ST level (to capture the updated performance parameters). At the MT level, plenty of changes would be observable in the restricted and neighbour areas due to mode shift, new routes, destination and activity choices. This would imply new accessibility measures, with implications for the LT. All of these feedback loops would occur multiple times in SimMobility .
Figure. SimMobility Framework
As a second example, let’s consider a major disruption due to an accident/harsh weather/road blockage. Agents would need to opportunistically reschedule and/or re-route. This would deem available network performance parameters invalid in focus areas, and demand ST level simulation. At the MT, agents would need to do within-day re-routing and rescheduling. As a one-time event, it wouldn’t affect the LT, however one could use SimMobility as a scenario exploration tool: “what network/land-use characteristics would bring more network resilience in such events?". In this sense, SimMobility could allow multiple runs with multiple parameters at the LT level.
Both scenarios involve interactions between different levels and between supply and demand models, at different moments in time. While it is in theory possible to use the loose coupling approach for combining different available models, to our knowledge none is designed to implement these cases without considerable adaptation. In terms of its software design, SimMobility relies on three concepts: one database shared by all models; a hybrid simulation mechanism, with demand being event-based and supply time-step based; a parallel and distributed architecture.
 

One database

The same database is shared by all levels. This implies that our modelling platform keeps track of household, and individual preferences and choices across levels: an agents' specific long term attributes, such as car ownership, is linked to her/his mode availability at the MT and eventually to individual driving behavior attributes specification, such as reaction time or desired speed. In this way, one can model demand consistently at the disaggregate level, keep track of a multi-level individualized history, and avoid complicated book-keeping necessary to maintain consistency of loosely coupled models. SimMobility’s database is fully implemented in a Postgres SQL database, which works on relational paradigm.  
 

Event-based demand, time-step supply

Agents need only be active when they make decisions, which happens when triggered by their perception. The perception is represented as the reception of an event information that is relevant for the agent. An event can be “arrival at intersection", “arrival at the destination bus stop", “taxi in sight", “trip delay greater than threshold", “changes in current job/school for kids", “changes in neighbourhood accessibility", etc. Thus, there can be events at any level of SimMobility. To implement these events, we use a publish/subscribe mechanism where agents subscribe to potential future awakening events before getting into an auto-pilot mode. This auto-pilot mode is where agents spend most of their simulation time: each decision that is made (e.g. route choice, relocation choice, execution of an activity) is translated into a plan that is executed by the simulator. Until this plan is complete or a subscribed event occurs, the agent is in the auto-pilot mode. Figure 2 represents the simulation cycle of our agents in each of the levels.
In the LT, real estate transactions model, a household will be non-active (auto-pilot) most of the time until some event (e.g. a job change or launch of new household estates) wakes it up. It will then enter a state of scanning the market for suitable housing. If the household finds potentially suitable housing among the listings, it will enter a bidding process with the sellers until converging to a choice or giving up (for at least several months). During the scanning and biding phases, there may be multiple message exchange events between the sellers and the households. At the MT level, agents will be sensitive to events both during activities and during trips. Such events may trigger rescheduling decisions, re-routing, early starting of trips (e.g. activity ends abruptly due to weather; due to emergency situation) or any other decision that is modeled in the system. Similar to MT, the ST uses same notion e.g lane/road closure at particular point in the road network. An agent that subscribed this event, may react to this and re-route well before reaching to closure point, where only limited options are available.
In practice, this mechanism allows for computationally very efficient interaction between supply and demand. The supply side, always time-step based, simply picks the latest plan information for each agent and executes it. A global events manager module, checks at each time step, which subscribed events occur and wakes up the respective agents. If the agent changes its plan due to an event, it will be reflected for the next time step, which will be executed by the supply simulator. This publish/subscribe mechanism is fundamental for opportunistic activity scheduling, as suggested in (24). For example, an agent could subscribe to an event to "wake him up if he’s 5 minutes to a supermarket".
 

Parallel and distributed architecture

SimMobility is entirely developed in C++, using boost threads library, for parallelization, and MPI (message passing interface) library, for distribution. It is able to do runtime load balancing by taking advantage of individual agent’s context (e.g. neighbor agents can be grouped together; agent of similar type can be grouped together). It also allows network decomposition with MPI distribution. Sim Mobility achieves parallelism by separating Agents into multiple worker and then running through each Worker's list of agents in parallel. Essentially, the millions of agents of SimMobility will be computed in parallel by many instance of the simulator on different processors. Put together, SimMobility takes advantage of state-of-the-art computational efficiency tools to increase scalability.
We will now describe in more detail each of the three SimMobility levels. This paper aims to present the general framework, with emphasis on the inter-level interactions, the benefits and challenges of a fully integrated approach. We will occasionally redirect the reader for available and upcoming literature for further details.
Figure . Events simulation cycles in relation with three Simulators