\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.  The ``system model'' can also
be viewed as a series of general-purpose templates, each represented as
(conceptual) classes and relationships among classes.

\section{Model of Systems Engineering Development}

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 frontend systems development
which will be employed by this project.  Points to note are as follows:

\begin{figure}[p]
\epsfxsize=4.8truein
\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.8truein
\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}

\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
	    develpment.  At the frontend 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 of 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
	    (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 (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, such as cities, which grow by
evolution rather than by design, 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.

\vspace{0.1truein}\noindent
{\bf 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''.

\begin{figure}[t]
\epsfxsize=5.0truein
\centerline{\epsfbox{figures/sims.eps}}
\caption{\emph{The Sims}$^{\small{TM}}$ Entity Requirements Model}
\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)
 \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 views of these resources and the transportation
networks that move them around. 

\subsection{Objectives}

A formal representation of the arcology optimization problem 
has multiple variables and multiple goals. The latter include:

\begin{itemize}
 \item Continually improve the quality of life for inhabitants
 \item Accelerate development of improvements to the body of knowledge
 \item Maximize productivity, performance.
 \item Optimize resource consumption to achieve balance with interchanges
      with the outside environment.
 \item Avoid optimizing the whole at the expense of the few by trampling
       individual freedoms.  Add structure to the system by providing
       opportunities and alternatives, not imposing restrictions on who
       gets to travel and who doesn't.
\end{itemize}

\vspace{0.1truein}\noindent
To be useful, each of these objectives need to represented as a
measurable entity.  The simulation model should be capable of assigning
metrics to 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 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 all of
the {}``required'' work is done, \emph{etc.}

\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 different modes of
operation.  For details, see Figure \ref{fig:uc-live} and Tables
\ref{tab:actors} and \ref{tab:use-cases}.

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 Cargo Transportation
Infrastructure classes, which will be detailed in the System Structure.

\begin{table}[htp]
\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}

\section{System Structure}

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 could be used to embed
C++ 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 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.

Our basic model consists of an overall package named GeneralHabitat,
which contains base classes and three more packages to organize
resources, reactions, and a separate transportation infrastructure
overlay on which we will direct our focus.


\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 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 between the deaths and
birth rates of people or towns; 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 an glorified
spreadsheet used to perform preliminary design and calculate rough
benefits analysis on changes to ways of life, quantifying answers to
such questions as: \char`\"{}how much energy might a city save if
everyone installed more efficient light bulbs?\char`\"{} or
\char`\"{}how much time can we save if we staggered a city's work
schedule to relieve rush hour congestion?\char`\"{}

\subsection{GeneralClasses}

The GeneralClasses object model diagram (i.e., 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.
	    Generally, there are five basic types of cells that work
	    together: The entity itself, the entity's environment, the
	    entity's transportation infrastructure, and leaf cells to
	    represent individuals and industries. To further complicate
	    matters, entities are arranged into hierarchies of
	    subcells. This allows us to view the system on several
	    levels of detail, from global down to the individual. To do
	    this, we introduce the constraint that a cell's resources
	    always equals the sum of the resources of all of its child
	    subcells.
 \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 lack an environment or a
	    transportation infrastructure to support those subcells.
\end{description}

\vspace{0.1truein}\noindent
The handling of resources and reactions are covered by the classes {\tt
ReactionEngine}, {\it Resourse}, 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.

\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 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
\char`\"{}City\char`\"{} subcell to be included as part of a
\char`\"{}Nation\char`\"{}. Similarly, homeless people and vagrants
would be lumped together into a special \char`\"{}Household\char`\"{} or
\char`\"{}Community\char`\"{} subcell to be included as part of
\char`\"{}City\char`\"{} 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*{Classes:}

\vspace{0.1truein}\noindent
The purpose of classes along the right-hand side of
Figure \ref{fig:cd-celltypes} is 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 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
	     \char`\"{}city\char`\"{} cell unit can be put aside to
	     account for 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 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 [{Attributes:}]~
			  
	      \begin{description}
	       \item [{Maintenance}] Monetary maintenance cost incurred
			   to keep this system up and running per unit
			   cycle.
	       \item [{TransitCost}] Monetary cost required to move a
			   unit of resource through this transportation
			   infrastructure per unit distance.
	       \item [{Value}] Infrastructure build value, 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 them 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 runs searches, such as {}``give me a list of
      all the people who traveled to this shopping mall\char`\"{} or
      \char`\"{}list all the places John has traveled to
      lately.\char`\"{} 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 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 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 could more
      adequately express things 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 they 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 \char`\"{}pull\char`\"{} on the scheduling algorithm,
	     so their scheduling might flow around
	     \char`\"{}hitchhiking\char`\"{} economically around the
	     empty seats left over in schedules generated to server
	     passengers paying for higher priority routing?
       \item What kind of safety factor or time buffer are they
	     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
\char`\"{}plug in\char`\"{} to each other for intermodal 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 the GPS system.
 \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
       can and cannot take place.
\end{itemize}

\subsubsection{Vehicle Model}

In order to finally traverse this network, though, a transit system
ultimately needs some set of vehicles (though many parts of a transit
network might be represented as walkways on foot, which we might as well
model too in order to help design capacity for escalators, moving
walkways, ticketing and security checkpoints? perhaps even to make sure
hallways and doorways are wide enough to meet capacity and fire
codes). Each vehicle would have associated with it:

\begin{itemize}
 \item A geographic location within the network, whether it was a
       geographic location in transit, at or waiting for arrival at a
       station node, or even occupying a storage or a maintenance bay.
 \item A passenger or cargo capacity
 \item A set of rules governing how fast it can navigate 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 the
optimized system. While we could squeeze a more optimal solution by
imposing fewer constraints, for various reasons (such as lack of
equipage to perform last-minute reroutes), we need some way of
communicating and enforcing pre-existing schedule constraints. In the
end, this probably isn't any different than the mechanism we'd use for
introducing scheduled maintenance stops.

\subsubsection{Environmental Factors}

The last major category might include \char`\"{}environmental\char`\"{}
factors that would affect the performance of the system. 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 predicable 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
\char`\"{}convective weather cells\char`\"{} (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 contingency planning
based on externally available data could make their way into
streamlining other forms of transportation, albeit less dramatically.

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

\newpage
\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 the global time line
queue.  The model executes by populating the global time queue with
scheduled events and firing those events in order. Every time an event
is activiated, the system global time is advanced to that 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 queue.


\subsection{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 statechart representing a typical person's
day. The statechart depends on having the right combination of events
defined and triggered to advance the individual through the full daily
cycle.

\begin{figure}[htp]
\epsfxsize=4.5truein \centerline{\epsfbox{figures/sc_individual.eps}}
\caption{Individual Statechart} 
\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 resource use, since the latter could
       cause 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 what 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. This performance
       measure will be relative to historical measures, however, so it
       will be difficult to establish a calibrated baseline. The only
       qualification for this model is to attempt to keep the quality
       from dropping below former levels.
\end{itemize}
