Adaptive & Reflective Middleware
for Large-scale Distributed Real-time
& Embedded Systems
Dr. Douglas C. Schmidt
[email protected]
www.ece.uci.edu/~schmidt/
Accomplishments & New Directions
• Productivity & quality gains from
higher-level abstraction mechanisms
• Partially automated
solutions for
limited domains
Analysis
Generation
Distributed real-time & embedded
(DRE) systems are increasingly
pervasive & essential
Characteristics of DRE Systems
• Mission-critical control
• Resource constrained
• Stringent simultaneous QoS
demands
• Network-centric & large-scale
• Dynamic operating conditions
2
Current Challenges & Limitations
Emerging Trends
• Large-scale DRE
system requirements
are increasingly
more
• Dynamic
• Diverse
• Demanding
Distributed Network of embedded sensor
motes for environment monitoring,
tracking, & surveillance (10,000 nodes)
Total Ship Computing Environments:
Global dynamic resource
management (1,000 nodes)
1000 – 1,000,000
node fusion of physical
& information
systems
Gossamer
Space
Antenna
(1,000,000
nodes)
Distributed Active Control:
Vibration Damping on Delta-4
Rocket Payload Fairing (1,000
nodes)
Noiseless sonar on
submarines to provide
camouflage (3,000 nodes)
3
Current Challenges & Limitations
Emerging Trends
• Large-scale DRE
system requirements
are increasingly more
• Dynamic
• Diverse
• Demanding
Technology Problems
Today’s DRE systems are:
• Stovepiped
• Proprietary
• Brittle & non-adaptive
• Expensive
• Vulnerable
Applications
Applications
Sensors
Controllers
Actuators
Utility
Applications
Cultural Problems
• Existing research
approaches do not
scale to address key
technology problems
• Non-appreciation of
the importance of
DRE software
Utility “Curve”
“Broken” “Works”
Resources
Operating
System
Endsystem
Operating
System
Networks
Endsystem
Operating
System
Networks
Endsystem
4
Lessons from IT History
2,400 bits/sec to
1 Gigabits/sec
CPUs & networks have
increased by 3-7 orders of
magnitude in the past decade
Extrapolating this trend to
2010 yields
• ~100 Gigahertz desktops
• ~100 Gigabits/sec LANs
• ~100 Megabits/sec wireless
• ~10 Terabits/sec Internet
backbone
10 Megahertz to
1 Gigahertz
DRE software has not improved as rapidly
or as effectively as hardware & networks
These advances stem
largely from standardizing
hardware & software APIs
and protocols, e.g.:
• Intel x86 & Power PC chipsets
• TCP/IP, ATM
• POSIX & JVMs
• Middleware & components
• Quality of service aspects
5
The Road Ahead for DRE Systems
INTERNETWORKING ARCH
RTP
TFTP
FTP
HTTP
TELNET
DNS
UDP
IP
Middleware
Solaris
Fibre Channel
Ethernet
ATM
20th Century
Applications
Sensors
Controllers
Actuators
Domain-Specific
Services
Domain-Specific
Services
Domain-Specific
Services
Common
Services
Common
Services
Common
Services
Distribution
Middleware
Distribution
Middleware
Distribution
Middleware
Infrastructure
Middleware
Infrastructure
Middleware
Infrastructure
Middleware
Operating
System
Networks
Endsystem
Win2K
FDDI
Applications
Endsystem
Middleware
Services
TCP
Applications
Operating
System
MIDDLEWARE ARCH
Middleware
Applications
Operating
System
Networks
Endsystem
VxWorks
Linux
LynxOS
21st Century
Benefits of Middleware
• Highly scalable QoS
• Enable new resource
management capabilities
• Support common & open
technology bases
• Leverage & enhance
advances in assurance &
security
Utility
We need to create the new
generation of open DRE system
middleware technologies to
1. Simultaneously control
multiple QoS properties &
2. Improve software
development quality,
productivity, & assurability
Desired
Utility
Curve
“Working
Range”
Resources
6
Technical Challenge:
Real-time Control of Distributed Resources
Goal: Create new generation of middleware to simultaneously control multiple QoS properties
Distributed
security
Distributed fault tolerance
Applications
Distributed
resource
management
Middleware
• Allocation/reservations, caching,
scheduling, monitoring, & load
balancing
OS & Protocols
Hardware
TBMD Application
AAW Application
QoS
QoS
Requested QoS
Measured QoS
}
Local
middleware
Global
Middleware
Control
Control
Algorithm
Algorithm
Workload &
Replicas
Control
Control
Algorithm
Algorithm
Control
Vars.
Control
Control
Algorithm
Algorithm
Workload &
Replicas
Workload &
Replicas
Connections &
priority bands
Connections &
priority bands
Connections &
priority bands
CPU & memory
CPU & memory
CPU & memory
Network latency
& bandwidth
Network latency
& bandwidth
Network latency
& bandwidth
Ship-wide QoS Doctrine
& Readiness Display
7
Hard Problem 1:
Secure Multi-level Distributed Resource Management
Problem
• Multiple technology
bases make it hard to
analyze & control the
QoS of distributed
resources at multiple
system levels
dynamically, dependably,
& securely
TBMD Application
Requested
QoS
AAW Application
QoS
QoS
Control
Control
Algorithm
Algorithm
Measured QoS
Research Challenge
• Devise middleware to formally specify QoSconstrained global resource management plans;
model, reason about and refine them; &
monitor/enforce these plans automatically at runtime
Control
Control
Algorithm
Algorithm
Load Balancer
FT CORBA
Control
Control
Algorithm
Algorithm
Workload &
Replicas
RT/DP CORBA + DRTSJ
Connections &
priority bands
RTOS + RT Java
CPU & memory
IntServ + Diffserv
Network latency
& bandwidth
Solution Approach
• Doctrine-driven middleware to support multi-level management of DRE
resources
• i.e., dynamic, dependable, & scalable resource analysis, scheduling,
allocation, monitoring & balancing
• Guided by online reflective QoS models & empirical evaluation
8
Example: Data Parallel CORBA
Parallel Object
Client on
parallel ORB
Part 1
Part 2
Data
reorganization
strategies
Computing Grid
• Airborne HPEC
• Distributed
shipboard clusters
• CONUS
supercomputers
•…
Part 3
Data Parallel CORBA bridges the gap between traditional CORBA applications &
high-performance embedded parallel processing applications as follows:
•Enable CORBA applications over clusters of computers
•No change required in software technologies, methodologies, or tools
•Enable massively parallel applications to integrate easily with distributed
systems
•Allow parallel applications to benefit from distributed object methodologies,
technologies, & tools
•Add parallelism & data distribution to the transparencies offered by CORBA
•Enable a new class of applications e.g., financial, industrial, medical, aerospace,
multimedia, and military domains
9
Hard Problem 2:
Meta-programmable DRE Middleware Frameworks
Problem
• Existing DRE systems are rigidly designed with fixed
QoS parameters that limit their utility for new operations
Research Challenges
• Assuring dynamic flexibility and
QoS simultaneously
Solution Approach
• Meta-programming techniques that
• Decouple functional & QoS paths to allow more degrees of freedom
• Specify QoS doctrine declaratively
• Support dynamic QoS adaptation & optimizations
Applications
Applications
Interceptor
Sys Cond
Sys Cond
Sys Cond
Sys Cond
Middleware
Local
Resource
Managers
Workload &
Replicas
Connections &
priority bands
}
Mechanism & Property
Managers
QoS Contract
QoS Contract
Interceptor
Middleware
{
Workload &
Replicas
Connections &
priority bands
CPU & memory
CPU & memory
Network latency
& bandwidth
Network latency
& bandwidth
Endsystem
Local
Resource
Managers
Endsystem
10
Example: Meta-programmed Distributed QoS Aspects
Mission
Requirements
Timeliness
Importance
Fidelity
• Maintain an out-of-the-window
view of imagery
• Frames must be dropped in
reverse order of importance
• Highest fidelity frames
must be delivered
www.dist-systems.bbn.com/tech
www.cs.wustl.edu/~schmidt
NETWORK RESERVATION
• Condition: Excessive Network load
• Action: Use IntServ &
DiffServ to reserve bandwidth
D istrib u to r
BBBBIBBBBBBBBBBBBBBBBB
I BPBIBBB BP IP
PPIBBPB
B PB
IBBB
PBB
BB
BBPP
BBIP
P
BB
B
P
B
B
P
P
P
P
PBBBBBBBP
B
BB
B
BB
BB
BP
BB
BB
IBBP
PBIBBBPBBBBBPB
BBB
B
B
IBBBBBBBBBBBBBBP
IBP
B
...PBBPBBPBBI
D istrib u to r
I I I
DATA FILTERING
• Condition: Excessive Network or CPU load
• Action: Drop selective frames
QoS Contracts
X
IMAGE MANIPULATION
• Condition: Excessive
Network load
• Action: Scale image to
smaller size
X
LOAD BALANCING
• Condition: Excessive CPU load
• Action: Migrate distributor to a
lightly loaded host
11
Hard Problem 3:
DRE Middleware Generation & Optimization Tools
Problems
• However, conventional
• COTS middleware is often
unsuited for DRE systems due DRE development
techniques are
to insufficient
• Tedious
• QoS specification &
• Proprietary
enforcement
• Manual & ad hoc
• Time/space optimizations
• Flexibility & customizability
Workload &
Replicas
Workload &
Replicas
Connections &
priority bands
Connections &
priority bands
CPU & memory
CPU & memory
Network latency
& bandwidth
Network latency
& bandwidth
t2
t3
t4
t5
t6
t7 t8
t9
Solution Approach
• Develop Model Driven Architecture (MDA)
tools to reflectively auto-generate,
optimize, & verify custom implementations
of standard DRE middleware from higherlevel specifications
t12 t13
t11
t14
t15
t16 t17
t18 t19 tREQ’D
DRE Applications
Common Middleware Tools
Common Semantic Rep.
Impl1
Impl2
Impl1
Plat1
Plat2
Plat3
Plat1.pd
Plat2.pd
Plat3.pd
Optimized & verified
DRE middleware
Research Challenge
• Minimizing footprint & customizing
standard DRE middleware capabilities
without sacrificing key QoS properties
t10
Application Requirements
tSTART
Middleware
Generator
12
Example:
Applying Reflection as Compiler Optimization
To illustrate the benefits of reflection as an optimization
technique, consider the evolution of compiler technology:
•Early compilers required
C Program
•Separate internal representations
hand-written for each programming
C Compiler
language &
•Separate hand-written optimizers
Internal Rep.
for each target backend
Ix86
Opt.
Ix86
VAX
Opt.
VAX
68K
Opt.
•Developing, verifying, validating, & evolving
all these components separately is costly,
time-consuming, tedious, & error-prone
68K
•The problem only gets worse as more
languages & target backends emerge
13
Example:
Applying Reflection as Compiler Optimization
To illustrate the benefits of reflection as an optimization
technique, consider the evolution of compiler technology:
C Program
C Compiler
Internal Rep.
Ix86
Opt.
VAX
Opt.
68K
Opt.
Ix86
VAX
68K
C++
Program
•Early
compilers required Ada Program
•Separate internal representations
hand-written for each programming
C++language
Compiler and
Ada Compiler
•Separate hand-written optimizers for
each target backend
Internal Rep.
Internal Rep.
•Developing, verifying, validating, &
evolving all these components
separately is costly, time-consuming,
PPCtedious,
MIPS & 88K
error-prone 1751 32K HPPA
Opt.
Opt.
Opt.
Opt.
Opt.
Opt.
PPC
MIPS
88K
1751
32K
HPPA
•The problem only gets worse as more
languages & target backends emerge
14
Example:
Applying Reflection as Compiler Optimization
•Modern compilers, such as GNU GCC, support
•A common internal representation (still hand-written)
for each programming language
C/C++/Ada Compiler
•Based on generalizing the language semantics
•A synthesized compiler optimizer that is customized
automatically for each target backend
Common Internal Rep.
•Based on reflective assessment of algebraic
target machine description
Ix86 PPC 68K
3. Generate an optimizer that is customized
Opt. Opt. Opt.
for the particular platform/language
C/C++/Ada Programs
Ix86
PPC
68K
Ix86
.md
PPC
.md
68K
.md
Optimizer
Generator
2. Use discrimination network to analyze
the optimization rules & opportunities
1. Read the target machine description
Key Benefit of Reflective Optimization
•New targets can be supported by writing a new machine description,
rather than writing a new code generator/optimizer
15
New Approach:
Applying Reflection to Optimize DRE Middleware
Conventional middleware for embedded systems is developed
& optimized in a manner similar to early compiler technologies:
CORBA Application
CORBA ORB
& Assorted Tools
LynxOS
WinNT
Impl
Impl
VxWorks
Impl
WinNT
LynxOS
VxWorks
•Conventional middleware require
•Separate tools and interfaces hand-written for
each ORB middleware specification
•e.g., CORBA, Java RMI, COM+
•Separate hand-written & hand-optimized
implementations for each embedded target
platform
•e.g., various OS/network/HW configurations
•Developing, verifying, validating, & evolving all
these components separately is costly, timeconsuming, tedious, & error-prone
•Moreover, it is even harder to hand-configure
support for dynamic platform variations & complex
application use-cases
•The problem only gets worse as more middleware,
target platforms, & complex applications emerge 16
New Approach:
Applying Reflection to Optimize DRE Middleware
Conventional middleware for embedded systems is developed
& optimized in a manner similar to early compiler technologies:
CORBA Application
CORBA ORB
& Assorted Tools
LynxOS
WinNT
Impl
Impl
VxWorks
Impl
WinNT
LynxOS
VxWorks
•Conventional middleware require
Java Application
COM+ Application
•Separate tools and interfaces hand-written for
each ORB middleware specification
•e.g., CORBA, Java RMI, COM+
Java RMI
COM+ ORB
•Separate
hand-written & hand-optimized
& Assorted Toolsfor each embedded
& Assorted target
Tools
implementations
platform
•e.g., various OS/network/HW configurations
Solaris validating,
Win98
Win2K
WinNT& evolving
•Developing,
verifying,
all
Implseparately
Impl
Implcomponents
Impl
these
is costly, timeLinux
consuming,
tedious, & error-proneWinCE
Impl
Impl
•Moreover,
it is even harder to hand-configure
support for dynamic platform variations & complex
application use-cases
Win2K
Solaris
WinNT
Win98
•The problem only gets worse as more middleware,
Linux
WinCE
target platforms,
& complex applications
emerge 17
New Approach:
Applying Reflection to Optimize DRE Middleware
Application Requirements
CORBA/Java/COM+ •The functional and QoS-related properties of
embedded systems middleware can be improved
Applications
Common ORB
+ Assorted Tools
Common Semantic
Representation
Plat1
Impl
Plat2
Impl
Plat3
Impl
Plat1
Plat2
Plat3
Plat1
.pd
Plat2
.pd
Plat3
.pd
greatly by advanced R&D on the following topics:
•A common internal representation (ideally autogenerated) for each middleware specification
•Based on generalizing the middleware semantics
•A synthesized middleware implementation that is
optimized automatically for each target platform &
application use-case
•Based on reflective assessment of platform
descriptions & application use-case
3. Generate middleware that is customized for
a particular platform & application use-case
Middleware 2. Use discrimination network to analyze
Generator
the optimization rules & opportunities
1. Read the target platform description
& application requirements
18
DARPA DRE Software R&D Focus
Air
Frame
AP
Nav
Event
Channel
WTS
Replication
Service
Multi-faceted
Software
Development
Comparable &
Customizable
Frameworks &
Intelligent
Middleware
Object Request Broker
GPS
IFF
FLIR
Cross-cutting Concerns
Synchronization
Persistence
Memory Management
Fault Tolerance
Model-based
Software Development
& Domain-specific
Languages
Applications to
Embedded Systems
Collaborative
Software
Development
Environments
Patterns &
Pattern
Languages
19
Descargar

Coordinating Group for High Confidence Software and …