\documentclass{article}
\include{6033-preamble}
\usepackage{graphicx}

\begin{document}
\dpp{1}{Dan Ports}{2004/02/26}{R9: Karger TR1}
\begin{center}
\LARGE{\bf A Concurrently-Staged Approach \\For Surveillance Monitoring}
\end{center}
\vspace{1em}

\section{Architecture}
This proposal describes the design for the central computer of a video
surveillance system that monitors multiple video streams over the
network and identifies and serves suspicious frames via the HTTP
protocol. The principal design objectives for the system are fault
isolation (particularly for subroutines known to be buggy) and
scalability.

This implementation is based on the Staged Event-Driven Architecture
(SEDA) model proposed by Welsh.\footnote{An Architecture for Highly
  Concurrent, Well-Conditioned Internet Services, Matt Welsh. Ph.D.
  Thesis, University of California, Berkeley, August 2002} This
architecture divides the processing of requests into stages. Each
stage has a controller that maintains a queue of requests (``events'')
to be processed. The controller invokes an event handler process to
handle each event; multiple handler processes for the same stage can
operate concurrently. Individual stages only communicate with each
other by inserting events into each other's event queue.

The SEDA architecture is well-suited for this problem, because
processing camera data is naturally divided into stages. It allows all
the major design objectives to be met. Fault isolation is ensured by
having stages implemented as separate processes with their own address
spaces, and tightly restricting inter-process communication. Moreover,
if a handler process crashes, the stage controller can restart it. The
design scales well, as the number of handler threads for each stage
can be dynamically adjusted as needed. In particular, since queues are
used at each stage, graceful degradation is possible: when the system
is overloaded, the controller manages the queue, ensuring that events
are processed in a ``fair'' order such that every camera receives
attention.

Stages in this architecture communicate by enqueuing events. Since
stages never share address spaces, inter-process communication is
necessary. This is achieved by having each stage controller process
listen on an internal port; processes from other stages can connect to
this port and submit a properly formatted event to be placed into the
queue. Thus, the basic model for a controller process is an event loop
that listens for new requests to be inserted into the queue, and
removes events from the queue in an appropriate order and spawns the
event handler processes.

The SEDA design can achieve extremely high levels of performance
through its use of concurrency. The number of event handler threads
executing at each stage of the pipeline is dynamically adjusted
based on the number of requests in the queue. If the length of the
queue is beyond some threshold, a new thread is added at that stage,
up to a maximum limit. If threads remain idle, they will be shut
down.

\begin{figure}[htbp]
  \centering
  \includegraphics[width=5in]{dp1-stagediagram}
  \caption{Stage flow diagram}
  \label{fig:stageflow}
\end{figure}

\section{Stages}
The flow of data through the stages is shown in Figure
~\ref{fig:stageflow}. Video stream data is obtained from the cameras
via a HTTP client. It is then decoded using the transcoder, and passed
to the AI subroutine, which identifies suspicious images. These images
are assigned to human spotters and distributed via a web server.

\paragraph{Camera HTTP Client}
Video streams are obtained from each camera via HTTP. The input events to
this stage are the asynchronously-received packets from the
cameras. The event handler threads parse these sequences of packets
into chunks of an appropriate length (in seconds), then place this
data in the queue of the Transcoder stage, along with metadata about
which camera it was received from and when. This stage also handles
opening the connections to the clients and sending the GET request
during initialization or if a connection is dropped.

\paragraph{Transcoder}
The Transcoder stage wraps the \texttt{transcode} function. The inputs
to this stage are raw stream chunks received from the cameras, and the
transcoded JPEG output is passed to the Anomaly Detection stage.

\paragraph{Anomaly Detection}
This stage wraps the \texttt{detect\_anomaly} function. The output is a
single frame, a threat score, and information about which camera the
image came from. This output is placed in the queue to the Assigment
stage. Because each event handler process for this stage operates in
its own memory segment and handles only one \texttt{detect\_anomaly}
call, a bug in this function will merely crash this process, without
affecting the rest of the system.

\paragraph{HTTP Server Parser}
When HTTP requests from spotters' web browsers are received, their
data is passed asynchronously to this stage, which implements the HTTP
protocol. If a GET request is received for the next image, the request
is passed to the Assignment stage. The HTTP Server Parser stage also
triggers the appropriate alarm if a spotter indicates that an image is
suspicious.

\paragraph{Assignment}
This stage handles the assignment of video frames to spotters. It has
two input queues: one receiving scored frames from the Anomaly
Detection stage, and one receiving HTTP requests from the HTTP Server
Parser. When a request is received, an appropriate frame is selected.
The selection algorithm may be fairly complex, and ought to take into
account both the threat score and the camera number: the most
suspicious frames should be processed first, but there should also be
some balancing to ensure that frames from all cameras are serviced.
Frames with a very low (near-zero) threat index may be discarded under
high-load conditions. The pairing of the HTTP request and selected
frame is enqueued for the HTTP Reply stage.

\paragraph{HTTP Server Reply}
This stage simply responds to a HTTP request in its queue by sending
the image that has been assigned to it.

\section{Acknowledgements}
The architecture for this implementation was based on the SEDA
architecture developed by Matt Welsh as part of his Ph.D. thesis research;
more information is available at\\
\texttt{http://www.eecs.harvard.edu/~mdw/proj/seda/}.

Austin Clements provided many helpful insights during the design
process.
\end{document}