Composable Middleware Services for High
Confidence Networked Embedded Systems
NSF ITR Kickoff Meeting, 12/04/03
Dr. Douglas Schmidt, Dr. Andy Gokhale, & Dr. Akos Ledeczy
{d.schmidt, a.gokhale, a.ledeczy}@vanderbilt.edu
Institute for Software
Integrated Systems
Vanderbilt University
Nashville, Tennessee
Where We Fit into Trustworthy NES
Security
Codesign
Control Theory
&
Hybrid Modeling
Middleware
Infrastructure
2
ISIS Technology Focus Areas & Background
• Model-Integrated Computing
• Embedded & hybrid systems modeling &
analysis, meta-programmable modeling tools,
model-synthesis tools, generators, open tool
integration platform for model-based design
• Component Middleware for Distributed
Real-time & Embedded (DRE) Systems
• Adaptive & reflective middleware, Model
Driven Middleware integration technology
above component middleware, Real-time
CORBA (ACE+TAO)
• Model- & Middleware-based Systems
Applications
• Diagnosis, embedded & hybrid systems
modeling & analysis, fault adaptive systems,
autonomous air vehicles, mission-computing,
shooter localization, total ship computing
3
http://www.isis.vanderbilt.edu/
New Challenges for Embedded Applications
Past Challenges
Future Challenges
Normal Vector of
Normal Vector ofReference Orbit
Cluster Plane
60o
Subsatellite Orbit
Earth
30o
Cluster plane
Cluster planeReference
at t=0
at t=1/2P
Nadir Vector
Orbit
(Towards center of Earth)
• Stand-alone and/or tightlycoupled embedded systems
with stringent quality of
service (QoS) demands
• e.g., latency, jitter,
footprint
• Resource constrained
Information processing replaces
mechanical structure
Dynamic Sensor Networks
• Larger-scale networked embedded systems
• Stringent simultaneous quality of service (QoS)
demands
• e.g., availability, security, latency, scalability
• Part of larger systems-of-systems
• Dynamic context & computation
• Extremely resource constrained
4
Evolution of NES Application Development
F2
F1
F1
F2
F5
F5
F3
F6
F3
F6
F4
F7
F4
F7
NES applications have also
historically been built directly
atop hardware
• Tedious
• Error-prone
• Costly over lifecycles
5
NES applications have
historically tended to be:
Stovepiped
Proprietary
Brittle & non-adaptive
Expensive
Vulnerable
Evolution of NES Application Development
NES
Applications
NES
Applications
Middleware
Services
Middleware
Services
Middleware
Middleware
RTOS
& Protocols
RTOS
& Protocols
Hardware &
Networks
Hardware &
Networks
NES applications have also
been built directly atop
hardware
• Tedious
• Error-prone
• Costly over lifecycles
NES applications have
historically tended to be:
Stovepiped
Proprietary
Brittle & non-adaptive
Expensive
Vulnerable
• Middleware factors out many reusable
mechanisms & services from what was
traditionally NES application responsibility
• This refactoring helps improve NES
application confidence & trustworthiness
6
Example NES Middleware Services
Location
Power Control
NES
Applications
Alarm
Routing
Middleware
Services
Spanning tree
Group Management
Leader Election
Middleware
Consensus
Clock Synchronization
RTOS
& Protocols
Configuration
Data Streaming
Data Aggregation
Hardware &
Networks
Sentry
Network Monitor
Scheduling
Reconfiguration
State Synchronization
7
Key R&D Challenges for NES Middleware
• There is a limit to how much
application functionality can be
factored into reusable middleware
• Standard middleware
technologies are too resource
consumptive & don’t provide
sufficient confidence for missioncritical NES applications
• Middleware is becoming
complicated to use & provision
statically & dynamically
NES Applications
Middleware
Services
Middleware
Workload &
Replicas
Operating Sys
& Protocols
Connections &
priority bands
CPU & memory
Network latency
& bandwidth
Hardware &
Networks
• NES applications are complicated
to deploy & configure correctly
8
Method of Attack for NSF ITR Project
• Develop a suite of models
NES
Applications
Middleware
Services
Middleware
RTOS
& Protocols
Hardware &
Networks
• Models enable the representation, verification, analysis,
composition, & synthesis of common middleware services
(such as time synchronization, localization, distributed
synchronization, consensus, & security) required by NES
applications
• Design & validate a new approach to NES
application development
• Where model-based techniques are used to synthesize,
customize, & compose middleware that can be tailored
reflectively at design-time & run-time for the needs of
particular NES applications
• Prototype & demonstrate composable
middleware at ISIS & in IVY testbed at UCB
• Systematically integrate adaptation mechanisms into a
coherent set of strategies that complement their effects &
limitations & enables NES applications to evaluate &
understand the effectiveness of these mechanisms
working together
9
Composable Middleware Service Packages
NES
Applications
Middleware
Services
Middleware
RTOS
& Protocols
Hardware &
Networks
NES Application
D
i
s
t
r
i
b
u
t
e
d
Diffusing Algorithm
R
e
s
e
t
Spanning Tree
Leader Election
Adjacency
RTOS+
Hardware
• Applications determine the type of
middleware services required
• Physical characteristics of the
system determine dynamics,
accuracy, security, & required fault
behavior of services
• Services are built in layers with
rich interdependence
• Algorithms used in services
depend on the distributed
computation model
• Complexity & computational cost
of the algorithms depend on the
distributed computation model
Goal: Automated synthesis & deployment of middleware service
package from verified coordination service components
10
Our Approach to Middleware Service Package Composition
QoS
Specs
STEP 1
Parameters
Type Specs
(template)
GME
Middleware Service
Library
Application requirements:
 Services needed
 QoS requirements
 Target platform specs
STEP 3
STEP 2
Service Family
(alternatives)
STEP 4
IO Au.
a1
Assisted composition of middleware as specified by the user
OR
STEP 6
a2
Application-specific
middleware assembly
m2
x4
Tools for model analysis & verification:
safety, liveness, deadlock, etc
STEP 10
STEP 9
STEP 7
Synthesizer #1
Composed
QoS properties
b1
STEP 8
System-level optimization
Optimized
QoS properties
Optimized & verified
middleware
Target-specific code synthesizers
Automatic composition & synthesis
of middleware from requirements
STEP 5
Synthesizer #2
Synthesizer #n
Application
Application
Application
Middleware
Middleware
Middleware
TinyOS
RT Linux
VxWorks
Simulator
Wired Node
Wireless Node
11
STEP 10
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
•Early compilers required
•Separate internal representations handwritten for each programming language &
•Separate hand-written optimizers for each
target backend
Internal Rep.
Ix86
Opt.
VAX
Opt.
68K
Opt.
Ix86
VAX
68K
•Developing, verifying, validating, & evolving all
these components separately is costly, timeconsuming, tedious, & error-prone
•The problem only gets worse as more
languages & target backends emerge
12
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++
Compilerand
Ada Compiler
language
•Separate hand-written optimizers for
each target backend
Internal Rep.
Internal Rep.
•Developing, verifying, validating, &
evolving all these components
separately is costly, time-consuming,
PPC
MIPS& error-prone
88K
1751 32K HPPA
tedious,
Opt.
Opt.
Opt.
Opt.
Opt.
Opt.
PPC
MIPS
88K
1751
32K
HPPA
•The problem only gets worse as more
languages & target backends emerge
13
Example:
Applying Reflection as Compiler Optimization
C/C++/Ada Programs
C/C++/Ada Compiler
Common Internal Rep.
Ix86
Opt.
PPC
Opt.
68K
Opt.
Ix86
PPC
68K
Ix86
.md
PPC
.md
68K
.md
• Modern compilers, such as GNU GCC, support
• A common internal representation (still hand-written) for
each programming language
• Based on generalizing the language semantics
• A synthesized compiler optimizer that is customized
automatically for each target backend
• Based on reflective assessment of algebraic target
machine description
3. Generate an optimizer that is customized for the
particular platform/language
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
14
New Approach:
Applying Reflection to Optimize NES Middleware
Conventional middleware for embedded systems is developed & optimized
in a manner similar to early compiler technologies:
NES Application
NES Middleware
& Assorted Tools
TinyOS
WinCE
Impl
Impl
VxWorks
Impl
WinCE
TinyOS
VxWorks
• Conventional middleware require
• Separate tools and interfaces hand-written for each
ORB middleware specification
• e.g., CORBA, Java RMI, COM+, nORB, etc.
• 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, time-consuming,
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
15
New Approach:
Applying Reflection to Optimize NES Middleware
Conventional middleware for embedded systems is developed & optimized
in a manner similar to early compiler technologies:
•Conventional middleware require
NES Application
NES Application
NES Application
•Separate tools and interfaces hand-written for
each ORB middleware specification
•e.g., CORBA, Java RMI, COM+
NES Middleware
NES Middleware
NES Middleware
•Separate
hand-written & hand-optimized
& Assorted Toolsfor each embedded
& Assorted target
Tools
& Assorted Tools
implementations
platform
•e.g., various OS/network/HW configurations
Solaris validating,
Win98
TinyOS
Win2K
WinNT& evolving
WinCE
•Developing,
verifying,
all
Implseparately
Impl
Impl
Implcomponents
Impl
Impl
these
is costly, timeLinux
VxWorks
consuming,
tedious, & error-proneWinXP
Impl
Impl
Impl
•Moreover,
it is even harder to hand-configure
support for dynamic platform variations & complex
application use-cases
Win2K
Solaris
WinNT
Win98
WinCE
TinyOS
•The problem only gets worse as more middleware,
Linux
WinXP
VxWorks
16
target platforms,
& complex applications
emerge
New Approach:
Applying Reflection to Optimize NES Middleware
NES
Applications
• The functional & QoS-related properties of embedded
systems middleware can be improved greatly as follows:
• A common internal representation (ideally autogenerated) for each middleware specification
Application Requirements
NES Middleware
+ Assorted Tools
Common Semantic
Representation
Plat1
Impl
Plat2
Impl
• 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
Plat3
Impl
3. Generate middleware that is customized for a
Middleware 2. Use discrimination network to analyze the
Generator
optimization rules & opportunities
Plat1
Plat2
Plat3
Plat1
.pd
Plat2
.pd
Plat3
.pd
particular platform & application use-case
1. Read the target platform description &
17 requirements
application
Overview of CoSMIC Modeling Toolsuite
• CoSMIC toolsuite
consists of an integrated
collection of modeling,
analysis, & synthesis
tools that address key
lifecycle challenges of
middleware &
applications
• The CoSMIC tools are
based on the Generic
Modeling Environment
(GME)
Open-source CoSMIC tools available at www.dre.vanderbilt.edu/cosmic/
18
Concluding Remarks
RECAP OF ITR PROJECT GOALS
Model, analyze, synthesize, & provision middleware services for
networked embedded systems (NES) applications that require coordination
& control of multiple quality of service properties end-to-end
Next steps for ITR project are to apply Model Driven Middleware (MDM) to:
1.Configure & deploy NES applications end-to-end
2.Configure component containers & run-time environments
3.Synthesize NES application & middleware-specific configurations
4.Synthesize dynamic QoS adaptation & resource management services
5.Benchmark & optimize provisioned NES applications
We will work closely with UC Berkeley & SRI collaborators in the OEP testbed
to integrate our MDM tools & middleware services with other NES aspects
Our NSF ITR project is leveraging MDM technologies funded by
other efforts (e.g., DARPA MoBIES, NEST, PCES, & ARMS)
19