% $Id: intro.tex 3601 2006-07-24 19:35:41Z jai $

%\sqzlarge
\section{Introduction}
\label{sec:intro}
%\sqzlarge

% \subsection{Characteristics and Challenges of Enterprise DRE Systems}
\label{sec:trends}
% \sqzlarge

Enterprise distributed real-time and embedded (DRE) systems, such as
shipboard computing environments~\cite{Schmidt:01m}, airborne command
and control systems~\cite{Gill:01a}, and intelligence, surveillance
and reconnaissance systems~\cite{Schantz:04}, are growing in
complexity and importance as more computing devices are networked
together to help automate tasks previously done by human operators.
These types of systems are characterized by stringent
quality-of-service (QoS) requirements, such as low latency and jitter,
expected in real-time and embedded systems, as well as high
throughput, scalability, and reliability expected in enterprise
distributed systems.

\iffalse 
In particular, these types of systems share the following
characteristics:

\begin{itemize}\cramplist
\item {\bf Heterogeneity.} Enterprise DRE systems are often composed of
multiple networked embedded subsystems and run on a
variety of computing platforms that are interconnected by different
types of networking technologies with varying quality of service (QoS)
properties. The efficiency and predictability of enterprise DRE
systems built using different infrastructure components varies
according to the type of computing platform and interconnection
technology.

\item {\bf Simultaneous support for multiple QoS properties.}
Software controllers are increasingly replacing
mechanical and human control of enterprise DRE systems.  These
controllers must simultaneously support many challenging QoS
constraints, including (1) {\em real-time requirements}, such as low
latency and bounded jitter, (2) {\em availability requirements}, such
as fault propagation/recovery across distribution boundaries, (3) {\em
security requirements}, such as appropriate authentication and
authorization, and (4) {\em physical requirements}, such as limited
weight, power consumption, and memory footprint.  For example, a
distributed patient monitoring system requires predictable, reliable,
and secure monitoring of personal health data that can be distributed
in a timely manner to healthcare providers.

\item {\bf Dynamic operating conditions.}  Operating conditions for
enterprise DRE systems can change dynamically, resulting in the need
for appropriate adaptation and resource management strategies for
continued successful system operation.  For instance, 
in power management systems, power outages underscore the need to detect failures in a
timely manner and adapt in real-time to maintain mission-critical
power grid operations.  
\iffalse
In military contexts, likewise, a mission mode
change or loss of functionality due to an attack in combat operations
requires adaptation and possible resource reallocation to continue
with mission-critical capabilities.
\fi
\end{itemize}

As evidenced from the discussion above, 
\fi
Enterprise DRE systems have a range of QoS requirements that may vary
at runtime due to planned~\cite{Li:99} and unplanned~\cite{Tarek:03}
events.  Examples of planned events include mission goal changes due
to refined intelligence and planned task-completion exceeding mission
parameters.  Likewise, examples of unplanned events might include
system runtime performance changes due to loss of resources, transient
overload, and/\-or changes in algorithmic parameters (such as
modifying an air threat tracking subsystem to have better coverage).

\iffalse
Due to the challenges of applying theoretically-grounded techniques
for generating and adapting resource allocations to enterprise DRE
systems, conventional development and quality assurance processes
employ {\em ad hoc} techniques comprising heuristics and/\-or simple
planning algorithms to solve specific resource management problems
identified at design-time.  Unfortunately, these techniques are poorly
suited to handle dynamic events (such as equipment failure, mission
changes, damage, or significant overload) that enterprise DRE systems
encounter at runtime.
\fi

% \sqzlarge
% \subsection{Addressing DRE System Challenges with Dynamic Resource Management}
\label{sec:motiv-chal}
% \sqzlarge

\iffalse
Approaches to resolving the challenges outlined in
Section~\ref{sec:trends} have traditionally focused on conducting
offline static resource-management analysis to determine how the
system should respond to planned events and a limited set of unplanned
events~\cite{Sha:94}.  Such analysis is performed by complex
analytical and simulation models of the systems, subjecting these
models to workloads that represent various planned and unplanned
events and determining how well the systems perform in the face of the
emulated mission-level and environmental changes.  As the size of the
enterprise DRE systems and the environments in which they execute
increases, however, offline static analysis of the system becomes
intractable due to the explosion of possible state permutations and
the limitations of analytical methods to scale seamlessly to cover
large state-spaces~\cite{Schechter:98}.
\fi

{\em Dynamic resource management} (DRM)~\cite{desidirata:98,Hansen:01}
is a promising paradigm for
% alleviating the limitations of static analysis and 
supporting different types of applications running in enterprise DRE
system environments - as well as to optimize and reconfigure the
resources available in the system to meet the changing needs of
applications at runtime.  The primary goal of DRM is to ensure that
enterprise DRE systems can adapt dependably in response to dynamically
changing conditions ({\em e.g., evolving mutli-mission priorities}) to
ensure that computing and networking resources are best aligned to
meet critical mission requirements.  A key assumption in DRM
technologies is that the levels of service in one dimension can be
coordinated with and/or traded off against the levels of service in
other dimensions to meet mission needs, {\em e.g.}, the security and
dependability of message transmission may need to be traded off
against latency and predictability.

\iffalse 
% 
Capturing explicit descriptions system behavioral and performance
characteristics (e.g. each software component's resource usage and
performance profile) in a computable representation

- how components consume resources in response different stimulation
  (e.g., method invocations or event reception).

- how to designate and quantify critical system flows (i.e., the
  problem CUTS addresses)

- how to capture the tasking and concurrency architecture (a.k.a., the
  system execution model) to enable validation.

- how to manage the evolution of all this data over the design
  lifecycle: starting with speculation, going to benchmarking, actual
  components etc.

Validating the dynamically generated resource allocations do not
violate critical system properties (e.g., meeting real-time deadlines)

- how to move work traditionally done by human designers into run time
  services

- how to develop computationally efficient mathematical models that
  can accurately predict run-time system properties of a given
  resource allocation

- how to recover when validation fails

Identifying the abstract base capabilities that enable dynamic
resource management services to be tailored to different system
requirements via configuration (as opposed to redevelopment).

- what are the right points of variability and what abstractions best
  capture that variability.

- devising information models that suit the human specification and
  the run time services

- defining a development work-flow that orchestrates the activities of
  the system designer, the DRM service software developer, and
  operation of the run-time DRM services

Mapping abstract allocations into various application middleware,
operating systems and networking environments.
\fi

\iffalse
Prior work~\cite{desidirata:98,Hansen:01} on DRM has focused
on general techniques for QoS-enabled enterprise DRE systems or
specialized techniques for niche real-time systems.
Our work in this paper augments this prior work by focusing on (1)
providing a standards-based {\em multi-layer resource management}
(MLRM) infrastructure for configurable DRM services and (2) developing
and empirically validating theoretically-grounded technologies for
applying these DRM services to mission-critical enterprise DRE
systems.  In particular, our approach to DRM described in this paper
innovates across the following interrelated technology areas:
\begin{itemize}\cramplist
\item {\bf Task allocation and analysis techniques} that generate and
   validate a coordinated set of resource allocations to satisfy
   evolving mission functional and performance requirements.

\item {\bf QoS-enabled component middleware} that provides a
   configurable computing infrastructure capable of enforcing resource
   allocations, even in the presence of overload and failures, thereby
   enabling and sustaining effective enterprise DRE software
   operation.

\iffalse
\item {\bf Model-based computing tools} to provide an environment for
   tailoring application designs toward patterns and workflows that
   enable fine-grained dynamic resource management; and to enable the
   specification of application metadata to describe operational modes
   and performance requirements for both applications and systems.
\fi
\end{itemize}
\fi

This paper describes a {\em multi-layer resource management} (MLRM)
architecture we developed to demonstrate DRM capabilities in a
shipboard computing environment.  This environment consists of a grid
of computers that manage many aspects of a ship's power, navigation,
command and control, and tactical operations~\cite{Schmidt:01m} using
standards-based DRM services that support multiple QoS requirements,
such as survivability, predictability, security, and efficient
resource utilization.  Our MLRM was developed for the DARPA's {\em
Adaptive and Reflective Middleware Systems} (ARMS) program
(\url{dtsn.darpa.mil/ixodarpatech/ixo_FeatureDetail.asp?id=6}), which
is applying DRM technologies to coordinate a computing grid that
manage and automate many aspects of shipboard computing.  We describe
and empirically evaluate how the ARMS MLRM manages computing resources
dynamically and ensures proper execution of missions in response to
mission mode changes and/\-or resource load changes and failures, as
well as capability upgrades.

\iffalse
% Guys, I've commented this out to save space.
\subsection{Paper Organization}
\label{sec:org}

The remainder of the paper is organized as follows:
Section~\ref{sec:mlrm} describes the design goals and components of
the ARMS MLRM architecture in more detail and shows how it has been
applied to a total ship computing environment; Section~\ref{sec:eval}
empirically evaluates the ARMS MLRM architecture in a set of
representative experiments; Section~\ref{sec:relwork} compares our
work with related research; and Section~\ref{sec:conclu} presents
concluding remarks.
\fi

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "JSS-2006"
%%% End: 
