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 FrameworkAs 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