\iffalse
% Maybe too much - ASG
DRE systems software often must deal
with significant variability caused by the need to address multiple
simultaneous challenges, including: (1) integrating several individual
subsystems using different technologies and platforms, (2) supporting
a diverse set of {\em software attributes} including functional
properties, such as the algorithms used to achieve the goals, and
quality of service (QoS) properties, such as predictable
latency/jitter, throughput guarantees, scalability, 24x7 availability,
dependability, and security that must be satisfied simultaneously in
real-time, (3) adaptation and constant fine tuning of the system
required due to changing customer needs and operating conditions, and
(4) ensuring DRE systems have long lifetimes ($\sim$15-30 years),
which requires safeguarding them against technology obsolescence.
\fi

\iffalse
% commenting this out but if any text is worth including for stronger
% motivation, we could reinclude parts of this - ASG
Many of the most challenging next-generation DRE systems will operate
in large-scale configurations that take input from large numbers of
remote sensors and provide geographically dispersed operators with the
ability to interact with the collected information and to control
remote effectors.  In circumstances where the presence of humans in
the loop is too expensive or their responses are too slow, these
systems must respond autonomously and flexibly to unanticipated
combinations of events at run-time.  Moreover, these systems are
increasingly being networked to form long-lived {\em systems of
systems} that must run unobtrusively and largely autonomously,
shielding operators from unnecessary details, while simultaneously
communicating and responding to mission-critical information at
heretofore infeasible rates.  Examples of the large-scale DRE systems
outlined above include metropolitan area traffic control systems that
process sensor data from 1,000s of vehicles, coordinated swarms of
unmanned air vehicles, command and control systems for theater-level
battle management, home power management, and terrorist tracking and
identification systems.  In such systems, it is hard to enumerate, or
often even approximate, all possible physical system configurations or
workload mixes {\em a priori}.
\fi

% showcase salient features of DRE systems
These DRE systems include many interdependent levels, such as
network/bus interconnects, many coordinated local and remote
endsystems, and multiple layers of software, that together derive the
following challenges: (1) as {\em distributed systems}, DRE systems
require capabilities to manage connections and message exchange
between (often heterogeneous) networked computing devices, (2) as {\em
real-time systems}, DRE systems require predictable and efficient
control over end-to-end system resources, such as memory, CPU, and
network bandwidth, and (3) as {\em embedded systems}, DRE systems have
weight, cost, and power constraints that limit their computing and
memory resources.

% validation requirements and traditional ways of doing this.
Stringent validation and testing of the design and implementation of
DRE systems is therefore imperative to determine if the QoS and
functional requirements are met. Unfortunately, DRE systems
development and validation historically has used relatively static
development and analysis techniques (such as function-oriented design
and rate monotonic analysis~\cite{LSD:89}) to implement, allocate,
schedule, and manage their resources. These static approaches have
proven to be acceptable for {\em closed} DRE systems, such as
avionics, automotive or industrial process control. In closed systems
the set of application tasks that will run in the system and the loads
they will place on system resources change infrequently and are known
in advance.   

These approaches are not well-suited, however, for the next-generation
of {\em open} DRE systems, such as sensor network applications, total
shipboard computing and emergency response systems~\cite{Schmidt:04h}.
Open systems evolve more rapidly and must collaborate with multiple
remote sensors, provide on-demand browsing and actuation capabilities
for human operators, and respond flexibly to unanticipated situational
factors that arise at run-time. 
\iffalse %% Commented out
Conventional approaches that work well for closed DRE system
development yield the following shortcomings~\cite{Sharp:98,Sharp:03}
for open DRE systems: (1) poor global resource utilization with low
platform adaptability and high upgrade costs, (2) numerous complex
system configurations that increase validation and maintenance costs,
(3) excessive acceptance testing and certification cycles, and (4)
incompatible technology infrastructures that cannot be retargeted and
reused to rapidly meet emerging DRE system needs.
\fi      %% Commented out
