\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 mistakes
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}$^{\textrm{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}$^{\textrm{TM}}$:
\emph{The Sims}$^{\textrm{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}$^{\textrm{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}$^{\textrm{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}

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
encompasses the entire design of the simulation.
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 can correspond to jurisdictions of a society, as
presented in the 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{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}
