% $Id: intro.tex,v 1.27 2005/11/23 19:54:35 gokhale Exp $

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

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

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.  In particular, these types of systems share the
following characteristics:

% changed to cramplist everywhere since it was causing things to be
% too near to each other
\begin{itemize}\cramplist
\item {\bf Heterogeneity.} Enterprise DRE systems often 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 Networked embedded properties.}  Enterprise DRE systems are
often composed of multiple networked embedded subsystems.  For
example, a shipboard computing environment may have multiple {\em
threat tracking subsystems} that colloborate with multiple {\em
mission planner subsystems} (which make decisions on what actions to
take depending on the threats being tracked) and multiple {\em effector
subsystems} (which enact the decisions).  There should be strong
communication and colloboration between these networked embedded
subsystems to achieve the critical functionalities of an enterprise
DRE system.

\item {\bf Simultaneous support for multiple QoS properties.}
Software controllers~\cite{ogata97} 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 Large-scale system-of-systems operation.}  The scale and
complexity of enterprise DRE systems often makes it infeasible to
deploy them in separate disconnected islands.  The functionality of
these systems must therefore be partitioned and distributed over a
range of networks.  For example, an urban bio-terrorist evacuation
capability requires highly distributed functionality involving
networks connecting command and control centers with bio-sensors that
collect data from police, hospitals, and urban traffic management
systems.

\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.  In civilian contexts, for
instance, power outages underscore the need to detect failures in a
timely manner and adapt in real-time to maintain mission-critical
power grid operations.  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.
\end{itemize}

As evidenced from the discussion above, 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).

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.

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

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}.

{\em Dynamic resource management}
(DRM)~\cite{desidirata:98,Nutt:00,Hansen:01} is a promising paradigm
for alleviating the limitations of static analysis and support
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.  A key 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

Prior work~\cite{desidirata:98,Nutt:00,Hansen:01} on DRM has focused
on general techniques for QoS-enabled enterprise DRE systems or
specialized techniques for niche real-time systems~\cite{Ghosh:04}.
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}

The remainder of this paper describes how our MLRM architecture has
demonstrated DRM capabilities in a {\em total ship computing
environment} (TSCE), which is a grid of computers that manage many
aspects of a ship's power, navigation, command and control, and
tactical operations~\cite{Schmidt:01m}.  To make a TSCE an effective
platform requires coordinated and standards-based DRM services that
can support multiple QoS requirements, such as survivability,
predictability, security, and efficient resource utilization.  The
MLRM described in this paper 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 grid of computers that
manage and automate many aspects of Naval TSCEs.  We describe and
empirically evaluate how the ARMS MLRM manages the computing resources
in TSCE dynamically and ensures proper execution of TSCE 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: 
