Next: Simulation System Behavior Up: Framework for Arcology Simulation Previous: Simulation Tool Use Cases Contents
We used the Umbrello UML tool to create diagrams in this and subsequent chapters[21]. While its code generation capabilities are not as comprehensive as that of the commercial tools such as I-Logix Rhapsody, it can generate class stubs for several languages including Python objects (which is used for the simulation), and XML Schema (which might be used eventually to help validate data interchange).
The prototype framework depicted in Figure 3.1 consists of three major parts: scenario generation, simulation, and schedule optimization. These components are wrapped around a scenario generation and post-processing framework that creates a directory tree of scenarios, each with slightly different initial conditions for factorial analysis.
Implementation Approach. The simulation code written in Python
makes heavy use of the SimPy module, [43] while the solution of
the schedule optimization problem occurs using the LP-solve mixed
integer linear program solver[8]. Python is a high-level
programming language supporting object oriented programming. Its clear
syntax and various interface modules make it ideal for rapid
prototyping.
The schedule optimizer formulation was first prototyped in Perl before being ported to Python. While Python typically has a much better reputation than Perl in terms of code readability, Perl's in-line variable output syntax made its code terse and much easier to read and debug than the equivalent Python code.
Being the ``brains'' of this framework, the more complicated optimization problem imposes a few major constraints that help simplify the way we'd model our transit network. The transit system must consist of a network of ``station'' nodes representing the entry, exit, and transfer points for passengers and cargo. Passengers and cargo can only move between nodes on vehicles, which can transfer them between any two connected stations or waypoints at regular, synchronized intervals. The simulation can handle several vehicle types, which can differ in passenger capacity per vehicle, cost per transit segment, connectivity graph between nodes, the maximum number of vehicles allowed to visit a station at the same time, and a host of other measures and constraints.
Modeling Difficulties.
The most crippling part of the model deals with timing. Time is dealt
with in terms of synchronized discrete timesteps, during which the state
of the entire system can be represented at one point in time by a
complete set of variables. At each time step, the state of the system
must be such that every vehicle is located at a station or waypoint
node. By the next time step, all passenger transfers must have been made
and all vehicles must have completed their transit toward the next
station node (or else stayed in place at their current station). When
the simulation translates these actions to events in continuous time,
this means that all stations synchronously act in unison, where every
vehicle practically departs simultaneously, travel all at the same time,
and offload passengers at their destinations, and wait for passengers to
transfer to make connections. They all must act in rhythm to the beat of
a central drummer. While this obviously constrains the flexibility of
the model in a big way, this arrangement allows the schedule optimizer
the flexibility it needs to balance hub-and-spoke transfers with more
direct routes, depending on the capacity and economics of the vehicles
made available.
Therefore, the model used in this analysis is that of equal-time segments separating transit stations and waypoints. Each and every vehicle must wait for passenger transfers to complete before they continue on to their next destination. The result is that, in reality, some amount of time is bound to be wasted under this model as all vehicles must stop and wait for the next beat of the synchronization drum before proceeding. A vehicle that is running a little bit late might have to skip a beat completely.
