\chapter{Generic Arcology System Model}
\label{sec:Generic-Arcology-System-Model}

This chapter describes a methodology for decomposing and organizing an
urban area, together with the transportation network that serves as its
circulatory system.  This ``generic system model'' allows for structured
decomposition of the human habitat into groups of subsystems on all
scale levels that interact through the exchange of several resource types.
Performance metrics capture the essential details of resource
flows, which in turn, allow for the comparison of different types of
arcologies to actual living conditions. 
From an implementation standpoint, the ``system model'' can be viewed
as a series of general-purpose templates, each represented as
(conceptual) classes and relationships among classes.

\section{Model of Systems Engineering Development}

\begin{figure}[p]
\epsfxsize=4.0truein
\centerline{\epsfbox{figures/system-development1.eps}}
\caption{Pathway from Operations Concept to
Models of Behavior/Structure to Requirements}
\label{fig:system-development1}
\vspace{0.3truein}\noindent
\epsfxsize=4.0truein
\centerline{\epsfbox{figures/system-development2.eps}}
\caption{Traceability Mappings for the Development Pathway,
Goals/Scenarios through System Evaluation (Source: Austin/Baras \cite{austin2004a})}
\label{fig:system-development2}
\end{figure}

Most complex engineering systems are developed within the framework of
an agreed upon (or established) process.  Figures
\ref{fig:system-development1} and \ref{fig:system-development2}
illustrate the step-by-step procedure for front-end systems development
which will be employed by this project.
Points to note include \cite{austin2004a}:

\begin{description}
\item{\bf 1.}
Systems engineers are the keepers of the processes,
	    methods and tools needed to establish and maintain a shared
	    vision of the problem definition and solution to a system's
	    development.  At the front-end of development, systems
	    engineers are concerned primarily with system functionality
	    and identification of the key environmental conditions
	    within which this functionality must occur.  Therefore,
	    models of system functionality need to describe what the
	    system will do under both normal and abnormal operating
	    conditions.  The answers to these basic concerns are
	    commonly expressed as functional requirements.  Performance
	    requirements describe how well a system should perform these
	    functions.  And economic requirements place constraints on
	    the resources that will be made available to develop and
	    operate the system.  A good system design provides a
	    desirable balance between functionality / performance and
	    economic, reliable operation in a wide range of
	    environments, and ease of accommodation for future technical
	    improvements.
 \item{\bf 2.}  Top-down development of system-level models begins with
	    use cases, and proceeds to fragments of system
	    functionality, expressed as activity and sequence diagrams
	    (\emph{i.e.}, UML-based methods).  Use cases are high-level
	    representations of system functionality that do not reveal
	    the details of implementation.  Use case diagrams are a
	    convenient way in which a real world actor (i.e., entities
	    that are external to the system) will interact with the
	    system, the use cases with which they are involved, and the
	    boundary of the application.
 \item{\bf 3.}  Requirements are organized according to the role they
	    will play in the system-level design. For example, some
	    requirements will be directed towards the system behavior
	    because they place constraints on minimum/maximum levels of
	    acceptable functional performance. Requirements directed
	    toward system behavior and structure are developed in
	    parallel with test requirements.
 \item{\bf 4.}  Models of behavior specify {\it what the system will
	    actually do.}  Usually, behavior can be represented as
	    networks and hierarchies of tasks, functions and processes.
	    Behavior is evaluated via attributes of performance.
 \item{\bf 5.}  Models of structure specify {\it how} the system will
	    accomplish its purpose.  The system structure corresponds to
	    collections of interconnected objects and subsystems,
	    constrained by the environment within which the system must
	    exist.  The nature of each object/subsystem will be captured
	    by its attributes.
 \item{\bf 6.}  We create the system-level design by mapping fragments
	    of system behavior onto specific subsystems / objects in the
	    system structure.  Thus, the behavior-to-structure mapping
	    defines the functional responsibility of each subsystem /
	    component.  System-level designs are typically viewed as
	    collections of large, arbitrarily complex functional units,
	    forming the major components of a system.  Connections among
	    units may be arbitrarily complex, carrying unspecified data
	    and information. Still, good system architectures have the
	    ability to accommodate change (\emph{i.e.}, they provide
	    room for expansion and / or upgrades to take advantage of new
	    technologies).  Sometimes architecture representations will
	    allow for preliminary estimates of system performance and
	    cost.
 \item{\bf 7.}  In the system evaluation, performance and
	    characteristics of the system-level design are evaluated
	    against the test requirements.  Usually, several iterations
	    of development will be needed to modify the system behavior,
	    system structure, perhaps even the original operations
	    concept, and achieve a design that satisfies all of the
	    system-level requirements.
 \item{\bf 8.}  The {\it system-level specification} is a detailed
	    description of the system's capabilities (or required
	    capabilities).
\end{description}

\vspace{0.10 in}\noindent
The activities in Figure \ref{fig:system-development2} are repeated for
each level of system development (i.e., system level; sub-system level;
component level).

\section{Concept Requirements}
\subsection{Goals}

One of the key characteristics of systems which grow by evolution rather
than by design (such as cities), is a distinct lack fundamental policies
that drive their design.  In many cases, the components of a city are
created in a reactionary manner -- for example, fire protection services
are built after too many buildings burn down, airports are built to
serve cities after they have already grown too dense to accommodate one
in a central location, tap water distribution systems are gutted out and
replaced only after the old ones were too heavily loaded to be sanitary.

\subsubsection*{Goals of SimCity}  
Hindsight being 20/20, it is worthwhile to dwell on past oversights and
develop urban planning with a systems engineering process worthy of
supporting a megalopolis. The first step is to develop a set of goals
and objectives that drive the design of the city. At first glance, the
goal of a city (at least as envisioned in Maxis's
\emph{SimCity}$^{\small{TM}}$) ought to be to grow and prosper.
Unfortunately, this viewpoint overlooks the city's primary
responsibility to fulfill the needs and look after the well being of its
inhabitants.  These concerns can be captured by looking at the problem
from an individual level, on par with the scale of Maxis's \emph{The
Sims}$^{\small{TM}}$: \emph{The Sims}$^{\small{TM}}$ offers 8 needs for
each of their simulated characters: ``Hunger'', ``Energy'', ``Comfort'',
``Fun'', ``Hygiene'', ``Social'', ``Bladder'', and ``Room'', indicated
by the green bars at the bottom of the user interface screen shot shown
in Figure \ref{fig:sims-requirements}.

\begin{figure}[t]
\epsfxsize=6.0truein
\centerline{\epsfbox{figures/sims.eps}}
\caption{\emph{The Sims}$^{\small{TM}}$ Entity Requirements Model}
\label{fig:sims-requirements}
\end{figure}

\vspace{0.1truein}\noindent
The model proposed in this chapter takes an even simpler approach:

\begin{description}
 \item{\bf Shelter:} Where people live and sleep (accounts for
	    ``Energy'', ``Comfort'', and ``Room'' from \emph{The
	    Sims}$^{\small{TM}}$ model)
 \item{\bf Food/Air/Water:} The raw materials people need to consume to
	    live, or at least not starve to death (accounts for
	    ``Hunger'') and adds a ventilation requirement necessary in
	    building design.
 \item {\bf Health:} Maintenance factors, such as cleanliness, waste,
	    (accounts for Hygiene and Bladder)
 \item{\bf Work:} Most people need something productive to do when they
	    aren't attending to their other needs. This could take the
	    form of working for money, or being educated to increase
	    their knowledge bank of information.
 \item{\bf Entertainment:} If people aren't doing something productive,
	    they're probably doing something fun to while away their
	    time (accounts for ``Fun'' and ``Social'')
\end{description}

\vspace{0.1truein}\noindent
In order to fulfill these needs for all of the city's inhabitants
efficiently, what they are really looking at is developing
infrastructure to move resources around.  Accordingly, the high-level
model developed in this chapter takes an abstract view of these
resources and the transportation networks that move them around.  This
allows us to quantitatively measure the ability of the system to fulfill
these individual goals.

\subsection{Objectives}

An organization responsible for running an arcology might track multiple
composite performance variables and strive to pursue multiple goals.
These objectives might include:

\begin{itemize}
 \item Continuous improvement of the quality of life of the inhabitants
 \item Acceleration of research, development, and contributions to the
       educational body of knowledge.
 \item Optimization of resource consumption to achieve balance with
       interchanges with the outside environment.
 \item Maximization of productivity and economic performance.
 \item Achieving fairness by avoiding optimization of the whole at the
       expense of the few.  Add structure to the system by providing
       opportunities and alternatives, not imposing restrictions on who
       gets to utilize available resources and transit capacity.
\end{itemize}

\vspace{0.1truein}\noindent
To be useful, each of these objectives need to be represented as a
measurable quantity.  The simulation model should be capable of
collecting and assembling composite metrics representing these
objectives, and computing their values (or valid estimates) based on
simulation inputs.  For example, a ``quality of life'' metric might be a
composite of several measurable outputs, including the length of
required commutes, the number and duration of times they are hit with a
hunger event that can't immediately be serviced by the resource delivery
system, amount of leisure time afforded after the optimal quota of daily
work is done, and so forth.

\begin{figure}[t]
\epsfxsize=4.0truein
\centerline{\epsfbox{figures/uc_live.eps}}
\caption{{}``Live'' use case diagram.}
\label{fig:uc-live}
\end{figure}

\subsection{Use Case Diagrams}

The arcology use cases simply represent a few major activities engaged
by individual residents.  For details, see Figure \ref{fig:uc-live} and
Tables \ref{tab:actors} and \ref{tab:use-cases}.

\begin{table}[p]
\noindent
\shadowbox{\parbox[t][1\totalheight]{1\columnwidth}{%
\baselineskip=15pt
\begin{description}
 \item [Individual] : An inhabitant of the system.
 \item [Industry] : Entity by which the individual is employed.
 \item [Cargo] : Transportation Infrastructure responsible for moving
	     people around (as well as resources).
\end{description}
}}%
\caption{Actors in ``Live'' Use Case Diagram}
\label{tab:actors}
\vspace{0.3truein}
\shadowbox{\parbox[t][1\totalheight]{1\columnwidth}{%
\baselineskip=15pt
\begin{description}
 \item [Sleep] : Everyone needs a place to rest for a significant
	     portion of the daily cycle.
 \item [Feed] : Consumption of food and water resources.
 \item [Maintenance] : Miscellaneous cleaning tasks, such as bathing,
	     brushing teeth, doing laundry, dishes, \emph{etc.} would be
	     represented here.
 \item [Work] : Work is a transaction between and individual and an
	     industry to exchange money for productivity. In this case,
	     productivity fuels the reactions that the industry
	     performs.
 \item [Entertain] : Entertainment can take on several forms, from
	     merely socializing with other individuals, engaging in
	     solitary entertainment interactions (TV, games), to mass
	     entertainment (theatre, \emph{etc.})
 \item [Travel] : An individual is able to travel through the
	     transportation infrastructure to commute to work or to
	     travel to places to fulfill their other needs, such as for
	     food or social interaction with friends.
\end{description}

}}%
\caption{Individual Use Cases in ``Live'' Use Case Diagram}
\label{tab:use-cases}
\end{table}

The system boundary is provided by the living quarters, which, contrary
to its name, extend beyond an individual's residence and encompass all
of the locations where they go about their business.  The arcology
simulation model will need to be flexible enough to model these types of
activities in order to be used for design.  The one new activity
introduced by Figure \ref{fig:uc-live} is the ``Travel'' interaction.
Not all of these use cases occur in one location, so the Travel case
takes care of moving the individual from one location to another. This
interaction is performed through one of the Transportation
Infrastructure classes, which will be detailed in the System Structure.

\section{System Structure}

Models of structure specify how a system will accomplish its purpose.
Typically, the system structure corresponds to collections of
interconnected objects and subsystems, constrained by the
environment within which the system must exist.
The nature of each object and/or subsystem may be described by its attributes.

Our basic model consists of an overall package named {\tt GeneralHabitat},
which contains base classes and three more packages to organize
resources, reactions between entities, and a separate transportation
infrastructure overlay on which this project will direct its focus.

\vspace{0.1truein}\noindent
{\bf Comments on Implementation.}
The approach for this project began using I-Logix Rhapsody� in C++
Development Edition to construct UML diagrams of the Arcology
model \cite{ilogix}. Work proceeds under the expectation that the code
generation facilities of tools such as Rhapsody might someday be used to
embed source code in the framework to compile and run a working
executable as part of a future systems modeling and analysis development
environment.  As an added benefit, Rhapsody also provides automated
documentation generation of the model in rich text format. This project
documentation is interspersed throughout this chapter.
One of the side effects of using Rhapsody include some subtle
differences in naming conventions, presumably used to simplify the
merging of the standard OMG UML 1.1 specification with the practical
realities of software engineering frameworks. Notably, Rhapsody uses
``Object Model Diagrams'' in place of both ``Class Diagrams'' and
``Instance Diagrams'', and prefixes class names with ``package'' names
that get translated into programming language namespaces. Since this
project deals with abstract models, we will almost always be referring
to class diagrams rather than specific object instances.

\subsection{GeneralHabitat Package}

The GeneralHabitat package contains a generalized resource queuing and
transportation model of living support systems.  A scenario is required
to build up a model of a system by creating a hierarchy of cells that
connect to each other via transportation network infrastructures. These
cells would then begin to perform resource transactions between each
other and resource reactions within themselves to simulate the daily
operations of the system and observe it from different levels of detail,
scaling from the individual to the city to the world. The transaction
approach is well suited for implementation in a discrete event
simulation.

Much of the model is static, such as monetary costs for resources or the
structure of cells. This model is not intended to perform dynamic
economic simulations or find ecological balances such as the equilibrium
of birth and death rates of townspeople; those functions have been well
studied. That said, the nature of the event-driven simulation framework
makes it easy to patch in such functionality by manipulating variables
or cleverly reorganizing the scenario outside of the simulation.

Instead, this model is merely intended to construct a glorified
spreadsheet used to perform preliminary design and calculate rough
benefits analysis on making way-of-life changes, quantifying answers to
such questions as: ``how much energy might a city save if everyone
installed more efficient light bulbs?'' or ``how much time and energy
could we save if we staggered a city's work schedule to relieve rush
hour congestion?''


\subsection{GeneralClasses}

The {\tt GeneralClasses} object model diagram (Rhapsody's internal name
for a UML class diagram) depicts the base simulation classes and
generally provides a template for completing the design of any
simulation based on this framework.  See Figure \ref{fig:cd-general}.

\begin{figure}[htp]
\epsfxsize=6.0truein
\centerline{\epsfbox{figures/cd_general.eps}}
\caption{GeneralClasses Object Model Diagram}
\label{fig:cd-general}
\end{figure}

\vspace{0.1truein}\noindent
All object model diagrams following this pattern of classes constitute
scenario-specific use cases that highlight the use of the base
simulation classes.  The specific purposes of each class are as follows:

\begin{description}
 \item{\bf Cell:} A Cell is the fundamental unit of structure.  Each
	    cell represents an identifiable entity, which contains its
	    own collection of resources.  These resources can be traded
	    with other cells, or undergo reactions within the cell to
	    transform groups of resources into other types of resources.
	    Cells are containers for other cells, creating a hierarchy
	    that can easily be traversed with recursive functions.
	    Cells might contain any number of subcells at the next level
	    of detail down on the hierarchy, thus the Cell template is
	    also a self-referential composition of itself.  This allows
	    us to view and gather metrics from the system on several
	    levels of detail, from global down to the individual. To do
	    this, we introduce the constraint that measurement of a
	    cell's resources must always return the sum of the resources
	    of all of its child subcells, plus any quantity it owns
	    independently of its children.
 \item{\bf LeafCell:} Leaf cells are a special type of cell reserved for
	    individuals and industries. These cannot be subdivided
	    further into subcells, and thus also lack an environment or
	    a transportation infrastructure to support any child
	    subcells.
\end{description}

\vspace{0.1truein}\noindent
The handling of resources and reactions are covered by the classes {\tt
ReactionEngine}, {\tt Resource}, and {\tt ResourceEngine}, respectively.
The {\tt ReactionEngine} defines reactions that can occur within cells
to transform one set of resources into another set of resources.  The
definition of the reaction governs changes to the quantities of inputs
and outputs, and balances them the same way a chemical reaction would be
balanced.  Each resource engine keeps track of the flow of one resource
within a cell. This includes the input of resource from the environment,
trade of resources with other cells, internal reactions that transform
resources to and from other resources, and waste resource output back to
the environment.  The resource engines are initialized to fire push / pull
transaction events at regular intervals. Pull transactions would offer
to exchange monetary resources for goods and services such as food or
electricity.  Push transactions relate to the expulsion of waste, and
would end up in the immediate environment unless picked up by a
transportation system to take to, say, a waste processing plant
(represented by an industry) first.

Resources and reactions are not yet utilized in the current programming
portion of this thesis, but the hooks have been left in place for
performing studies with detailed resources accounting in the future.

\subsection{CellHierarchy}

We model the area of interest by breaking it down into a hierarchy of
cells and subcells that work at a different level of detail. There are
essentially two types of units, parent nodes and leaf nodes, with the
only distinction being that leaf nodes do not have any subcells.  Levels
of this hierarchy might correspond to jurisdictions of a society, as
presented in the example {\tt CellTypes} class diagram shown in Figure
\ref{fig:cd-celltypes}. It's important that all of the subcells add up
exactly to form the parent cell, so in some cases, it would be necessary
to define subcells that represent everything that might be left over
after allocation into existing subcells. For example, the rural areas
not part of a city would be lumped into a special residual
``City'' subcell to be included as part of a
``Nation''. Similarly, homeless people and vagrants
would be lumped together into a special ``Household'' or
``Community'' subcell to be included as part of
``City'' data. This should be an acceptable practice,
since these otherwise leftover units may tend to have similar
characteristics.

\begin{figure}[htp]
\epsfxsize=5.5truein
\centerline{\epsfbox{figures/cd_celltypes.eps}}
\caption{Example CellTypes Class Diagram}
\label{fig:cd-celltypes}
\end{figure}


\subsubsection*{CellType Classes:}

The purpose of the example class hierarchy lined up along the right-hand
side of Figure \ref{fig:cd-celltypes} might possibly be described as follows:

\begin{description}
 \item {\bf World:} This class represents the largest area of interest
	     that modelers would most likely be interested in studying.
	     At this high level of detail the branches that have any
	     significant interaction with the particular unit are most
	     important.  Generally, there is no need to model the
	     components of the cell in great detail.
 \item {\bf Region:} Geographic region tend to be composed of several
	     nations with a common situation.  Of course, large nations
	     may exist over several regions.  For our purposes, however,
	     we will assume that all nations are smaller than the
	     regions within which they are contained.
 \item {\bf Nation:} A nation sets the policy for controlling and
	     tracking international trade and commerce.  Data is often
	     available on the national level for input into the top-down
	     models.
 \item {\bf City:} A city is the highest level of organization
	     represented by an individual arcology.  Generally, an
	     arcology corresponds to a network of connected cities.  One
	     ``city'' cell unit can be put aside to account for the
	     production and consumption of all rural areas not included
	     in other cities.
 \item {\bf Community:} Families tend to cluster into communities, which
	     in turn form cities.
 \item{\bf Household:} A household consists of a family of several
	     individuals living together in one residence.  A family
	     doesn't necessarily include extended family, or preclude
	     the existence of other living arrangements such as
	     roommates.
 \item {\bf Individual:} Because individuals cannot be partitioned into
	     sub-components (we can only hope), they are modeled as a
	     leaf node in the hierarchy.  Most individuals will work for
	     an industry.  Individuals are free to move from place to
	     place as part of their daily lives.  This allows them to
	     commute to work or to visit friends in another household
	     and transfer their resource consumption to stress the
	     infrastructure at other locations.  When individuals
	     travel, it puts a strain on the transportation
	     infrastructure.
 \item {\bf Industry:} Cities have a special type of leaf node called
	     Industry, which essentially employ several Individual units
	     to perform certain specialized reactions on particular
	     resources in bulk.  Generally, they consume energy
	     resources to refine material resources.
 \item {\bf Environment:} A special passive cell that will always yield
	     any resources that it has and accept any waste that is
	     ejected into it.  Instead of interacting with other cells
	     on the same level, it only interacts with subcells. So, for
	     example, a nation's resources can be split amongst its
	     cities, and city level waste gets deposited in the nation's
	     environment.
 \item {\bf TransportationInfrastructure:} A special cell that interacts
	     with subcells. It represents the connective tissue that
	     allows resources to transit between subcells, and it takes
	     both money and fuel in the process. Several types of
	     transportation infrastructures can be defined with
	     different characteristics in terms of resource burn rates.
	     
	\begin{description}
	 \item [{\bf Attributes:}]
		\begin{description}
		 \item [{\bf Maintenance}] Monetary maintenance cost
			     incurred to keep this system up and running
			     per unit cycle.
		 \item [{\bf TransitCost}] Monetary cost required to
			     move a unit of resource through this
			     transportation infrastructure per unit
			     distance.
		 \item [{\bf Value}] Infrastructure build value, or how
			     much money needs to be invested to put this
			     transportation infrastructure in place so
			     it can be used.
		     \end{description}
	     \end{description}
\end{description}

This thesis will focus on analyzing the people-mover component of a
potential mass transit network.

\section{Transportation Infrastructure Overlay}

The transportation infrastructure overlay consists of a demand model,
a route graph, vehicle model, and environmental factors.

\subsection{Demand Model}

As an exercise, let us consider some of the data elements we would want
a schema to include that would lend themselves to a good schedule
optimizer. Each of these values of interest might need to be expressed
and measured in different forms, to indicate whether their values have
been projected from previous data, predicted based on current known
conditions, or are the actual measured values after the fact.
Additionally, projections and predictions would want uncertainties
attached to them in order to be of use for contingency planning.

First off, we will list out the information a passenger or piece of
cargo wishing to traverse the system would want to convey to us. The
simplest schema would consist of a source location, a destination, and a
desired time of arrival or departure. But much other information could
be collected that would be of use:

\begin{itemize}
 \item Unique identifier: every database needs to refer to its elements
       by some unique ID at some point. Many privacy rights activists
       cringe every time a system forces them to assume one that is
       traceable back to them. It's beyond the scope of this paper to
       address the requirements of what can or cannot be gleaned or
       pieced together by data mining this information. But suffice it to
       say that privacy and security concerns could be met by currently
       existing encryption, digital signature, and authentication
       technology. As an example, suppose that after payment, a unique
       system identifier was associated with an encrypted, one-time
       signature generated by the passenger's private key. Only that
       passenger would be able to decrypt the digital fingerprint that
       associated their personal identity information with the unique ID
       stored in the passenger roster. They would be able to prove that
       it was they who generated that unique signature ID at a later
       time, say, if they needed an alibi.  However, government or
       private entities that somehow got a hold of the passenger roster
       wouldn't be able to run searches, such as ``give me a list of all
       the people who traveled to this shopping mall'' or ``list all the
       places John has traveled to lately.'' For more restrictive
       governments or law enforcement / monitoring agencies, all or part
       of this data could be exposed through a key escrow system.  The
       point is that all of this framework exists and should be set up
       from the inception of the system, since the security and
       authentication model will likely be deeply ingrained into how the
       rest of the software systems operate. The main problem that most
       privacy advocates see is that the minimum basic anonymity and data
       privacy safeguards are simply not being deployed into the systems
       of today.
 \item Schedule constraints / flexibility : optimization thrives on
       having some slack or flexibility in its constraints. We could
       achieve more optimal schedules if only passengers had a way to
       more adequately express constraints like:
       
      \begin{itemize}
       \item What range of times could they be expected to arrive at
	     their destination?  \emph{e.g.} Not later than 9:00?
       \item How much extra would passengers be willing to pay to reduce
	     their time in transit, say be giving them preferential
	     treatment in the schedule optimization algorithm? In the
	     same vein, would any of them be interested in paying less
	     to reduce their ``pull'' on the scheduling algorithm, such
	     that their scheduling might form by economically
	     ``hitchhiking'' around on the empty seats left over in
	     schedules generated to serve passengers paying for higher
	     priority routing?
       \item What kind of safety factors or time buffers are passengers
	     comfortable with?  Would they be willing to run through an
	     airport to make a tighter connection?
      \end{itemize}
 \item Accessibility needs : handicapped passengers could make special
       requests to suit their situation. This could help budget transfer
       time and resources better. For example, instead of equipping all
       of the vehicles in a fleet with minimal accessibility features at
       great expense, a bus system could have 5\% of their fleet be fully
       equipped and serve handicapped passengers as their first priority.
\end{itemize}

Cargo would have much of the same properties as passengers, perhaps a
few more to encode other special handling instructions, hazmat
designations, and so forth. As cargo might spend significantly longer
stretches of time in the system between warehouses and transfer
stations, they might have more stringent tracking and tagging
requirements, as well as more flexibility in routing preferences,
especially between low priority bulk and high priority overnight
shipments.

Security is an important concern in a system that can be misused for
malicious purposes. While we could easily set up detection stations at
central transfer nodes to screen for explosive and hazardous materials
and other contraband, we'd want to take another step to ensure that the
sender can be traced and held accountable for the contents of a
package. The system should require some form of digital signature and
authentication from the sender in order to enter a package into the
system.

Having all this passenger and cargo data pretty much takes care of
knowing the transportation system demand inputs.

\subsection{Route Graph}

The next set of standardized data should describe how the transit
network itself is set up to handle the demands placed on it. Every
transit system could be expressed as a network, so we will liberally
apply terms from the networking field to describe some of these
concepts.  The first assumption we'll have to make is that any transit
system could be expressed and modeled as a collection of nodes and
connector links. They might vary significantly in complexity and level
of detail between transit systems, but they all need to be able to
``plug in'' to each other for inter-modal optimization to
work properly.

A simple light rail or tram network might consist of a few dozen
stations connected by a single track. On the other end of the spectrum,
a metropolitan road network modeled in detail would have thousands upon
thousands of connective paths, links to probably all of the other nodes
of transit, relatively few fixed source and destination nodes, and
likely not enough user planning data will ever be made available to
predict traffic congestion resulting from construction, weather,
accident, or just plain rush hour delays.

In any case, the minimal elements needed to represent this
transportation network would include:

\begin{itemize}
 \item A unique node identifier
 \item A geographic node location, represented in a standard reference
       frame such as the WGS-84 latitude, longitude, and altitude used
       by GPS.
 \item A connectivity matrix, minimally of transit times between node
       pairs.  A special value would indicate that certain node pairs
       (probably most of them) are not connected at all. This might even
       be digested from much more complicated routing algorithms, such
       as street navigation systems. The connectivity matrix will need
       adjustments over time, to schedule in planned closures for
       maintenance, or new routes opening up at particular times.
 \item Buffer and storage nodes, such as maintenance bays or taxiway
       queues.  These might have special properties with regards to what
       activities or states can and cannot take place.
\end{itemize}

\subsection{Vehicle Model}

In order to actually traverse this network, a transit system ultimately
needs some set of vehicles.  As an exception many parts of a transit
network might be represented as walkways on foot.  But even then we
might as well model that traffic too in order to help design capacity
for escalators, moving walkways, ticketing, and security checkpoints.

Each vehicle would have associated with it:

\begin{itemize}
 \item A physical location within the network, whether a geographic
       location in transit, or a position in a queue waiting for arrival
       at a station node, or occupying a storage or a maintenance bay.
 \item A passenger or cargo capacity
 \item A set of rules governing how fast it can navigate across its
       network, how long it takes to load and unload, \emph{etc.}
 \item Various maintenance details, such as fuel supply, crew refresh
       schedules, and at least some indicator of the probability that it
       will reach its destination without breaking down along the way or
       running late for some other reason.
\end{itemize}

The system would need a way to introduce its own arbitrarily fixed
schedule or other constraints. This could be required merely as a way to
allow legacy timetable-based systems to nominally interact with an
optimized scheduling system. While we could squeeze a more optimal
solution by imposing fewer constraints, for various reasons (suppose a
communications equipment failure prevented us from giving a last-minute
reroute to a vehicle), we need some way of communicating and enforcing
pre-existing or immutable schedule constraints.  This mechanism probably
would be similar to one we'd use for introducing planned or unscheduled
maintenance stops.

\subsection{Environmental Factors}

The last major category that would affect the performance of the system
might include ``environmental'' factors.  These factors could either be
predicted in advance with some degree of certainty, or suddenly evolving
events such as accidents or breakdowns that require a reformulation of
the optimization problem to mitigate.

Weather conditions can have a predictable effect on a system. Updates on
rain or snowstorms should be able to make their way into the system so
it can plan on having some degree of constrained capacity in advance.
Airports can plan to shut down for a few hours while
``convective weather cells'' (thunderstorms) pass by
overhead. As better forecast data has become available, air traffic
control centers have actually been able to institute ground delay
programs for aircraft all the way at their points of departure, so they
don't end up circling in holding patterns near the destination airport,
waiting for the inclement weather to abate. Such techniques for
contingency planning based on externally available data could make their
way into streamlining other forms of transportation such as road and
rail, albeit less dramatically.

These types of entries could manifest themselves as time-dependent
changes to the network connectivity matrices and node constraints. Each
cell would have a probable new value for transit time on that link,
accompanied by probable start and end times of that effect.


\section{System Behavior}

The arcology simulation model is based on a discrete event simulation
framework.  This means that state changes in the system structure are
triggered by the firing of events which occur along a global time line
event queue.  The model executes by populating the global time queue
with scheduled events and firing those events in order. Every time an
event is activated, the system global time is advanced to that new
time. Any state transitions in the model that were blocking on this
event are executed so they can perform their activities, which often
result in the scheduling of more events in the future. Thus the
simulation perpetuates events and continues in time until there are no
more events left on the simulation timeline event queue.

\subsection{Modeling the Behavior of an Individual}

The individual transitions from state to state in their daily activities
triggered by these events. A fairly simple schedule could be arranged as
follows to implement a state chart representing a typical person's
day. The state chart depends on having the right combination of events
defined and triggered to advance the individual through the full daily
cycle.

\begin{figure}[htp]
\epsfxsize=5.0truein \centerline{\epsfbox{figures/sc_individual.eps}}
\caption{State Chart Model for Behavior of an Individual} 
\label{fig:sc-individual}
\end{figure}

A massive quantity of these individuals independently going through
their daily state cycles as indicated by Figure \ref{fig:sc-individual}
would create a load on the system, either by requesting resources that
must be delivered to them, as well as moving the individuals themselves
about the transit network as required.  At the same time, we can poll
the history of each individual to collect performance metrics on how
well the system can respond to their demands.


\section{Measures of Effectiveness}
\label{sub:Measures-of-Effectiveness}
\subsection{Design Decision Variables}
\label{sub:Design-Decision-Variables}

In general, the complete city system can only improve properly if we
choose the right performance metrics to judge it by. An optimization
function that optimizes the wrong metric will certainly cut you short of
fulfilling your goals. For a city, the metrics we would want to track
include:

\begin{itemize}
 \item Resource production / consumption ratio per cell -- An effective
       system would need to be efficient at doing a lot with the
       resources it has available to consume.  We should emphasize
       efficiency over minimizing total resource use, since the latter
       would often result in some form of stagnation.
 \item Transportation overhead -- We should establish metrics to track
       the ratio of resources spent on the connective infrastructure
       compared to the nodes and activities it actually supports. Of
       course, this also needs to be balanced with the need for growth
       and interconnectivity, so allocating resources towards
       maintaining and extending transportation systems should be a
       secondary goal to increasing productivity.
 \item Sustainability -- The environment is usually the first to give up
       resources or absorb waste when they can not be serviced
       elsewhere.  However, we often do not know the environment's
       total capacity for restoring waste byproducts back into useful
       resources. The burden should be placed on the industries who
       exercise the environment the most to prove what that capacity
       might be in order to achieve a suitable equilibrium.
 \item Quality of life -- We can measure this by tracking the ability of
       the system to respond to the population units' resource requests
       to maintain their desired standard of living. It will be
       difficult to establish a calibrated baseline, however, since this
       performance measure will be relative to historical
       measurements. We can only attempt to keep the quality from
       dropping below former levels.
\end{itemize}

% LocalWords:  arcologies truein Traceability Baras UML SimCity Maxis's pt OMG
% LocalWords:  Logix namespaces GeneralHabitat GeneralClasses subcells LeafCell
% LocalWords:  ReactionEngine ResourceEngine CellHierarchy CellTypes celltypes
% LocalWords:  subcell CellType TransportationInfrastructure TransitCost hazmat
% LocalWords:  WGS GPS pre convective timeline Sustainability
