% $Id: overview.tex,v 1.19 2006/01/04 19:55:38 gokhale Exp $

\section{Overview of the ITS Case Study}
\label{sec:overview}

This section provides an overview of the ITS case study, focusing on
its component architecture, as well as the scale and variability of
its requirements.

\subsection{ITS Component Architecture}
\label{sec:its-arch}

\iffalse
\begin{floatingfigure}[r]{0.55\columnwidth}
%\begin{wrapfigure}{r}{2.8in}
  \centering
  \vspace{-0.5in}
  \includegraphics[width=0.53\columnwidth]{uc_diagram}
  \vspace{-0.7in}
  \caption{Use Case Diagram for the ITS Case Study}
  \label{fig:its-usecase}
%\end{wrapfigure}
\end{floatingfigure}

Figure~\ref{fig:its-usecase} shows the primary actors and use cases in
our ITS case study.  {\em ITS Configurator actors} use ITS
capabilities to configure the set of available facilities in certain
warehouses, such as the structure of transportation belts, routes used
to deliver items, and characteristics of storage facilities ({\em
e.g.}, whether hazardous items are allowed to be stored, maximum
allowed total weight of stored items, etc).  {\em ITS Operator actors}
use ITS capabilities to reorganize warehouses to fit future changes,
as well as receiving items, storing items into the warehouse, fetching
items from the warehouse to certain locations, querying inventory,
specifying delivery time deadline, and updating operator console
views.  {\em Operating Environment actors} use ITS capabilities to
tolerate partial failures due to transportation hardware facility
problems, such as broken belts.  To handle such failures, the software
entities associated with hardware devices must alert the ITS work flow
manager in real-time, {\em i.e.}, with low latency delay, and higher
processing priority.  The ITS must then recalculate the delivery
possibilities dynamically based on available transportation resources
and delivery time requirements and then reschedule the delivery.  \fi

\iffalse
\begin{figure}[!htb]
  \centering
  \vspace{-0.5in}
  \includegraphics[width=0.7\columnwidth]{uc_diagram}
  \vspace{-0.5in}
  \caption{Use Case Diagram for the ITS Case Study}
  \label{fig:its-usecase}
\end{figure}
\fi

Figure~\ref{fig:its-comp} illustrates the components that form the
core implementation and integration units of our ITS case study.
Some ITS components (such as the OperatorConsole) expose interfaces
to end users, {\em i.e.}, ITS operators.  Other components (such as
TransportationUnit) represent hardware entities, such as cranes,
forklifts, and belts. Yet other database management components (such
as ItemRepository and StorageFacility) expose interfaces to manage
external backend databases (such as those tracking items inventory
and storage facilities).  Finally, the sequences of events within
the ITS is coordinated by control flow components (such as the
WorkflowManager and StorageManager).

An ITS needs capabilities to tolerate partial failures due to
transportation hardware facility problems, such as broken belts.  To
handle such failures, the software entities associated with hardware
devices must alert the ITS work flow manager in real-time, {\em i.e.},
with low latency delay, and higher processing priority.  The ITS must
then recalculate the delivery possibilities dynamically based on
available transportation resources and delivery time requirements and
then reschedule the delivery.

\begin{floatingfigure}[r]{0.55\columnwidth}
%\begin{wrapfigure}{r}{0.55\columnwidth}
  \centering
  \vspace{-0.3in}
  \includegraphics[width=0.53\columnwidth]{ITS_Architecture_Modified}
  \vspace{-0.5in}
  \caption{ITS Subsystems and Key Components}
  \label{fig:its-comp}
%\end{wrapfigure}
\end{floatingfigure}

The capabilities shown in Figure~\ref{fig:its-comp} are used in the
context of their associated ITS subsystems as follows: (1) the {\em
Warehouse Management subsystem} consists of a set of high-level
functionality and decision making components that calculate the
destination location and delegates other details other subsystems,
(2) The {\em Material Flow Control subsystem} executes high-level
decisions calculated by the Warehouse Management subsystem to
deliver items to the destination location, {\em e.g.}, it
(re)calculates routes, schedules transportation facilities, and
reserves storage facilities, (3) the {\em Warehouse Hardware
subsystem} handles physical devices, such as sensors and
transportation units ({\em e.g.}, belts, forklifts, cranes, and
pallet jacks) that correspond to various component types, such as
ItemLocationSensor and TransportUnit.

The functionality of the ITS subsystems shown in
Figure~\ref{fig:its-comp} can be monitored and controlled by one or
more OperatorConsole components, and all persistence concerns are
handled via databases.  The Material Flow Control subsystem requires
high throughput of continuously refreshed data, soft real-time
processing of regular tasks.  Components in the Warehouse Hardware
subsystem require hard real-time deadlines associated with periodic
processing.

Our ITS component architecture is implemented using the CIAO
QoS-enabled component middleware, which combines Lightweight CCM
features (such as standard mechanisms for specifying, implementing,
packaging, assembling, and deploying components) with Real-time
CORBA features (such as thread pools, portable priorities,
synchronizers, priority preservation policies, and explicit binding
mechanisms).  ITS also use CIAO's {\em Deployment And Configuration
Engine} (DAnCE)~\cite{Schmidt:05y}, which implements the OMG
Deployment and Configuration (D\&C) specification~\cite{DandC:03} to
help developers deploy and configure pre-built components and
component assemblies. Finally, ITS uses the CoSMIC MDD tools work in
conjunction with CIAO and DAnCE to separate the application business
logic from system deployment and configuration concerns to make ITS
development more rapid and flexible.

\subsection{Scale and Variability in the ITS Case Study}
\label{sec:its-var}

Although the ITS component archihtecture described in
Section~\ref{sec:its-arch} are present in most warehouses, there may
be significant differences in customer needs, warehouse specific
requirements, task specific QoS requirements, and integration with
other subsystems. Implementing an ITS properly therefore requires a
thorough understanding of the scalability and variability manifested
in the system.  For example, the warehouse automation hardware and
software infrastructure is often supplied by multiple vendors who
select different hardware and software platforms and tools.  The
resulting heterogeneity yields integration and deployment challenges
over an ITS lifetime since various components may be removed or
replaced by components from other vendors, which often requires
system-wide reconfiguration of system resources to ITS components to
improve overall system QoS.

In general, variabilities resulting from different warehouse
configurations, hardware/\-software platforms, and QoS requirements
yield much diversity in ITS implementations, particularly for
large-scale warehouses that consists of thousands of
software/\-hardware components.  An ITS could have a diverse set of
characteristics and QoS requirements including -- but not limited to
-- high throughput of continuously refreshed data, hard real-time
deadlines associated with periodic processing, well defined
computational paths traversing multiple components, soft real-time
processing of regular tasks, and operator display and control
requirements.

\iffalse
\begin{table}[!htb]
  \centering
  \begin{tabular}{||c|c|c||}
  \end{tabular}
  \caption{Characteristics of an Example ITS System}
  \label{tab:its-example}
\end{table}
\fi

Figure~\ref{fig:its-example} shows the ITS product instance we
developed for this case study.  Based on requirements mined from
Siemens warehouse management business units our case study consists of
$\sim$120,000 lines of C++ source code and contains 8 component types
and 193 component instances deployed into a warehouse, including 2
OperatorConsoles, 1 TransportationFacility, 1 ItemRepository, 1
StorageManager, 1 WorkflowManager, 1 StorageFacility, 18
ItemLocationSensors and 168 TransportUnits.

%\begin{floatingfigure}[r]{0.55\columnwidth}
\begin{wrapfigure}{r}{0.55\columnwidth}
  \vspace{-0.3in}
  \includegraphics[width=0.5\columnwidth]{characteristics}
  \caption{Characteristics of an Example ITS System}
  \label{fig:its-example}
\end{wrapfigure}
%\end{floatingfigure}
These 193 components are deployed into 191 processes, which in turn
are hosted in 26 physical nodes, with 2 single-CPU PCs running on
Windows XP and 24 nodes running on various versions of Linux OS with
some of which having Timesys Linux real-time scheduling class.  All
the nodes are connected through 100 MB Fast Ethernet and all nodes
are installed with the ACE 5.4.7, TAO 1.4.7, and CIAO 0.4.7
middleware. The database management system for ITS case study is
MySQL 5.0.

All components run in separate processes except in two collocated
cases: ItemRep\-ository/\-Storage\-Manager and
Trans\-portation\-Facility/\-Storage\-Facility.  One should note
that even for the same set of components, however, the composition
and configuration of an ITS deployment may vary significantly across
different warehouses, depending on the availability of actual
transportation facilities, computing hardware and software
resources.

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "isorc06-its"
%%% End:
