Distributed Simulation of Transport Networks

University of Maryland, College Park

Rowin Andruscavage

Fall 2004 Systems Engineering Master's Thesis

Purpose

This project realizes a distributed simulation designed during the course of the systems engineering master's program. The program will take a systems approach to modeling human habitats and the multi-modal transport networks that keep them running. The premise is that this simulation framework can be used to model a baseline of current day capacity, and be used to model the effects and quantify the benefits of investments in future infrastructure.

The distinguishing characteristics of this simulation framework includes

• a hierarchical level-of-detail organization that allows available data from both top-down parametric models to interact with data generated from clusters of detailed simulation objects. This allows us to seed detailed objects in a subsystem using available aggregate data (e.g. Using data on the total gallons of fuel consumed by an airport per month and distributing that consumption across the aircraft that use that airport) and compare it to data generated by tallying up the individual fuel consumption of those aircraft. This would help calibrate the model by quantifying the effects unknown fuel flows, such as waste or other fuel sources. The hierarchical organization also makes the simulation easier to partition across distributed compute nodes.

• Rigorous balance and accounting for matter, energy, resource, and waste products across control volume boundaries. This is to keep us honest and avoid sweeping data under the rug. All input and output resources going into and out of any subsystem will show up in the final accounting, and conversions and reactions within the subsystem's components will always be balanced according to conservation of matter and energy laws, ensuring that an unwanted waste byproduct is never “dropped” out of the simulation, or energy required to power a conversion or transaction comes out of nowhere. (Of course, it's still possible to simply underestimate the amount of fuel necessary to move cargo from point A to point B, but that's what the calibration against actual data is for).

Inspiration

Well, it all goes back to the meaning of life, doesn't it? We're all hanging around, looking for love or money or happiness, always trying to get the most out of life, and optimize our existence in some fashion. The optimization part is where simulation can be a useful tool, as we often disagree on what systems infrastructure improvements we could make in order to make us happier or richer or work not so far from our loved ones.

Most of our interactions with the urban environment in which we live involve transportation and delivery systems, that range from transit networks, to power, water, and information infrastructure that feeds directly to our homes. Much of this infrastructure is put in place with funding or regulation from government agencies at national, state, and local levels.

During these times of rapid modernization, governments can be a bit slow figuring out what infrastructure to invest in. Simulation can come in handy to help quantify the benefits of different operational concepts. This analysis can be used to answer questions about design options. For example, to see whether the resources saved by restructuring, say, alternate water or package delivery systems justifies the deployment and maintenance expenses.

Implementation Plan

The simulation will be built upon the open-source Dartmouth Scalable Simulation Framework (DaSSF). This provides a solid but flexible core discrete event simulation environment that should also make the simulation portable to other DES engines that adhere to the SSF standard. The SSF standard is primarily used to simulate data networks at the moment, but there's no reason the framework couldn't be used to create simulations of (simpler) physical systems.

I'll shy away from using the Ilogix Rhapsody UML-to-code IDE for developing the simulation, since I no longer have a licensed version of the software, and it was really more trouble that it was worth at the time anyway. Plus it would have involved reverse-engineering hooks into the DaSSF code to do properly. The object-oriented code used to build components will attempt to remain as true to the original UML diagrams as possible, though.

The simulation basically boils down to an accounting of conversion and transaction events that move resources between themselves and their environment. Therefore, most of the coding involves making and managing container objects. Building from the ground up, here's the implementation plan:

1. Resource containers are the most elemetary class. They merely have to choose an identity, and store a number representing how much of this resource the owning object has pooled together. It needs getter and setter functions, and a master dictionary for looking up other useful properties associated with that type of resource (such as density, , market value, etc.) that might be used for various other calculations. Money and information are considered resources as well for tracking purposes, but they basically constitute an “activation energy” for a reaction or transaction to proceed, so are treated somewhat differently.

2. Reactors come in various forms and are intended to provide balanced conversions from one set of resources to others (often waste).

3. Cell objects are the hierarchical units. These will be the most complex but most useful class used in the simulation. They each can contain some combination of:

   1. resources

   2. reactors for converting internal resources from one to another

   3. buffers and constraints on the amount of resources they can hold before having to push them elsewhere

   4. parent, child, and peer cells with which to interact, such as by scheduling transactions and reporting metrics up and down their chain of command.

   5. internal agendas used to schedule reaction and transaction events.

4. Connective meshes define which cells can actually interact with each other, representing the function and capacity constraints of various transport networks that move resources between thecells in the system. They can exact a cost (in terms of money transactions and resources consumed.

5. The instatiation framework is what reads the scenario file and begins to create cell objects and set up the simulation. This is where a modeling language would come in.

6. A reporting engine collects data from the simulation at desired intervals and needs to be programmed to extract useful data and analyses from the simulation.

Operational Concept

References

http://www.ssfnet.org/ Scalable Simulation Framework Research Network

http://www.cs.dartmouth.edu/research/DaSSF/ Dartmouth Scalable Simulation Framework

http://www.crhc.uiuc.edu/~jasonliu/projects/ssfnet/

http://www.renesys.com/research.html Renesys Corporation

https://gradus.renesys.com/exe/Raceway Renesys Raceway