NJL Heavy Industries

Simulating Disney Monorail Throughput


During the evening commute, the MBTA here in Boston will occasionally have deeply frustrating delays. For most of the five stops of my commute, the train will need to wait for traffic ahead to clear until it can move forward. The best case trip is about 17 minutes. The worst case can be closer to 40.

It reminds me of something somebody mentioned to me when I was working at Disney World.

In order to build drama, the Magic Kingdom is almost a mile away from the parking lots, separated by a gigantic man-made lake. Getting across the Seven Seas Lagoon happens one of two ways; a collection of Staten-Island style ferries are available to shuttle folks back and forth, and a pair of monorail loops run around the outside of the lagoon.

The outer loop of the monorail is stressed twice a day. In the morning, as the park is opening, guests are flooding in, and the traffic flow is essentially one-way; from the parking lots to the park. In the evening, as the park closes, the flow reverses. Everyone is going back to their car, and nobody is heading into the park.

The overall throughput of the system was increased by running fewer monorail trains.

Let's simulate what's going on with a little bit of JavaScript. I'll cobble together a bit of D3 (it's been a while) to visualize it.

There is a whole body of work around ensuring two trains don't collide. For light rail systems, such as the Walt Disney World monorail, the most common system is a block system. The track is divided into a collection of segments, called blocks. Various means are then used to notify the operator if the block in front is available for progress. If a block is occupied, the train isn't allowed to enter it. Most systems maintain some sort of spacing, leaving a couple of empty blocks between trains.

We will simplify the Walt Disney World monorail system to be a circle, divided into equal-sized blocks. We'll put a terminal with guests entering at the top, and a terminal with guests leaving at the bottom. We can then see how varying the number of blocks and number of trains can affect overall system throughput. We'll measure passenger loads transported, and see how varying the number of blocks and trains can affect throughput.

These diagrams are highly stylized representations of the congestion on the train loop. A red block has a train in it; orange and yellow blocks are there to ensure proper spacing between trains. Finally, loads of guests are being added at the top and removed at the bottom.

Each "tick", the trains move one block, if the path in front of them is clear. If the path isn't clear, they wait. Finally, it takes three ticks at a station to load or unload passengers. My choice of ticks is arbitrary; a real simulation would involve speed of the trains, and simulate a little more of the physics. For my purposes here, it isn't really necessary.

In this example, we have enough blocks, and the trains move smoothly around the track. The seven trains slowly pull into the lead, moving more loads than the six trains.

When we decrease the number of blocks so that trains need to wait at stations, the problem become clear. Seven trains don't move any more loads than six trains; in fact, they move less. In my simplified model, trains are either moving at full speed or not moving at all. In the real world, with acceleration, deceleration, and all the other assorted messiness of real things moving in real space, this effect is even more pronounced.

Complex things don't need to be made up of complex pieces; a collection of simple parts that give feedback to one another can develop a level of emergent complexity that feels larger than the sum of the parts.