composable middleware services for high confidence networked embedded systems nsf itr kickoff...
TRANSCRIPT
Composable Middleware Services for High Composable Middleware Services for High
Confidence Networked Embedded SystemsConfidence Networked Embedded Systems
NSF ITR Kickoff Meeting, 12/04/03NSF ITR Kickoff Meeting, 12/04/03
Dr. Douglas Schmidt, Dr. Andy Gokhale, & Dr. Akos Ledeczy
{d.schmidt, a.gokhale, a.ledeczy}@vanderbilt.eduInstitute for
Software Integrated Systems
Vanderbilt University Nashville, Tennessee
2
Where We Fit into Trustworthy NESSecurity Codesign
Middleware Infrastructure
Control Theory &
Hybrid Modeling
3
ISIS Technology Focus Areas & Background
http://www.isis.vanderbilt.edu/
• 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
4
New Challenges for Embedded Applications
• 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
• 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
Future Challenges
Information processing replaces mechanical structure
Earth
Normal Vector ofCluster Plane
Nadir Vector(Towards center of Earth)
30o
Normal Vector ofReference Orbit
ReferenceOrbit
Subsatellite Orbit60o
Cluster plane at t=1/2P
Cluster planeat t=0
Dynamic Sensor Networks• Stand-alone and/or tightly-coupled embedded systems with stringent quality of service (QoS) demands
• e.g., latency, jitter, footprint
• Resource constrained
• Stand-alone and/or tightly-coupled embedded systems with stringent quality of service (QoS) demands
• e.g., latency, jitter, footprint
• Resource constrained
Past Challenges
5
Evolution of NES Application Development
NES applications have historically tended to be:
StovepipedProprietary
Brittle & non-adaptiveExpensiveVulnerable
NES applications have also historically been built directly atop hardware
• Tedious• Error-prone• Costly over lifecycles
F1
F3
F2 F5
F4 F7
F6
F1
F3
F2 F5
F4 F7
F6
6
Evolution of NES Application Development
NES applications have historically tended to be:
StovepipedProprietary
Brittle & non-adaptiveExpensiveVulnerable
NES applications have also been built directly atop hardware
• Tedious• Error-prone• Costly over lifecycles
Middleware
MiddlewareServices
NES Applications
RTOS& Protocols
Hardware & Networks
Middleware
MiddlewareServices
NES Applications
RTOS& Protocols
Hardware & Networks
•Middleware factors out many reusable mechanisms & services from what was traditionally NES application responsibility
•This refactoring helps improve NES application confidence & trustworthiness
7
Example NES Middleware Services
Middleware
MiddlewareServices
NES Applications
RTOS& Protocols
Hardware & Networks
Data Aggregation
Sentry
Configuration
Data Streaming
Clock Synchronization
Leader Election
Consensus
Spanning tree
Group Management
Reconfiguration
State Synchronization
Network Monitor
Scheduling
Alarm
Routing
Location
Power Control
8
Middleware
MiddlewareServices
NES Applications
Operating Sys& Protocols
Hardware & Networks
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 mission-critical NES applications
•Middleware is becoming complicated to use & provision statically & dynamically
•NES applications are complicated to deploy & configure correctly
Network latency & bandwidth
Workload & Replicas
CPU & memory
Connections & priority bands
9
Middleware
MiddlewareServices
NES Applications
RTOS& Protocols
Hardware & Networks
Method of Attack for NSF ITR Project• Develop a suite of models
• 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
10
Middleware
MiddlewareServices
NES Applications
RTOS& Protocols
Hardware & Networks
NES Application
RTOS+Hardware
Diffusing Algorithm
Spanning Tree
Leader Election
Adjacency
Di
st r ibuted
R e s e t
• 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
Composable Middleware Service Packages
Goal: Automated synthesis & deployment of middleware service package from verified coordination service components
11
STEP 1Parameters
IO Au.
QoS Specs Type Specs
(template)
Service Family (alternatives) a1
Middleware ServiceLibrary
STEP 2STEP 3 Application requirements:
Services needed QoS requirements Target platform specs
STEP 4
Tools for model analysis & verification: safety, liveness, deadlock, etc STEP 7
Automatic composition & synthesis of middleware from requirements
Application-specificmiddleware assembly
a2
x4 b1
m2
ComposedQoS properties
STEP 5STEP 6 ORAssisted composition of middleware as specified by the user
GME
Target-specific code synthesizers Synthesizer #nSynthesizer #2Synthesizer #1STEP 9
OptimizedQoS properties
Optimized & verifiedmiddleware
System-level optimizationSTEP 8
Application
TinyOS
Wireless Node
Middleware
Application
VxWorks
Wired Node
Middleware
Application
RT Linux
Simulator
Middleware
STEP 10 STEP 10
Our Approach to Middleware Service Package Composition
12
•Early compilers required •Separate internal representations hand-written for each programming language &
•Separate hand-written optimizers for each target backend
•Developing, verifying, validating, & evolving all these components separately is costly, time-consuming, tedious, & error-prone
•The problem only gets worse as more languages & target backends emerge
C Compiler
Internal Rep.
Ix86Opt.
Ix86
VAXOpt.
VAX
68KOpt.
68K
C Program
To illustrate the benefits of reflection as an optimization technique, consider the evolution of compiler technology:
Example:
Applying Reflection as Compiler Optimization
13
•Early compilers required •Separate internal representations hand-written for each programming language and
•Separate hand-written optimizers for each target backend
•Developing, verifying, validating, & evolving all these components separately is costly, time-consuming, tedious, & error-prone
•The problem only gets worse as more languages & target backends emerge
C Compiler
Internal Rep.
Ix86Opt.
Ix86
VAXOpt.
VAX
68KOpt.
68K
C Program
To illustrate the benefits of reflection as an optimization technique, consider the evolution of compiler technology:
C++ Compiler
Internal Rep.
PPCOpt.
MIPSOpt.
88KOpt.
PPC MIPS 88K
C++ Program
Ada Compiler
Internal Rep.
1751Opt.
32KOpt.
HPPAOpt.
1751 32K HPPA
Ada Program
Example:
Applying Reflection as Compiler Optimization
14
C/C++/Ada Compiler
Common Internal Rep.
Ix86Opt.
PPCOpt.
68KOpt.
C/C++/Ada Programs
Ix86
Ix86.md
PPC
PPC.md
68K
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
1. Read the target machine description
Optimizer Generator
2. Use discrimination network to analyze the optimization rules & opportunities
3. Generate an optimizer that is customized for the particular platform/language
• A synthesized compiler optimizer that is customized automatically for each target backend• Based on reflective assessment of algebraic 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
Example:
Applying Reflection as Compiler Optimization
15
• 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
• Separate hand-written & hand-optimized implementations for each embedded target platform• e.g., various OS/network/HW configurations
• Conventional middleware require• Separate tools and interfaces hand-written for each ORB middleware specification • e.g., CORBA, Java RMI, COM+, nORB, etc.
NES Middleware & Assorted Tools
NES Application
Conventional middleware for embedded systems is developed & optimized in a manner similar to early compiler technologies:
WinCE
WinCEImpl
TinyOS
TinyOSImpl
VxWorks
VxWorksImpl
New Approach:
Applying Reflection to Optimize NES Middleware
16
•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
•Separate hand-written & hand-optimized implementations for each embedded target platform•e.g., various OS/network/HW configurations
•Conventional middleware require•Separate tools and interfaces hand-written for each ORB middleware specification •e.g., CORBA, Java RMI, COM+NES Middleware & Assorted Tools
Win2K Solaris
Linux
NES Application
Win2KImpl
SolarisImpl
LinuxImpl
NES Middleware & Assorted Tools
WinNT Win98
WinXP
NES Application
WinNTImpl
Win98Impl
WinXPImpl
NES Middleware & Assorted Tools
NES Application
WinCE
WinCEImpl
TinyOS
TinyOSImpl
VxWorks
VxWorksImpl
New Approach:
Applying Reflection to Optimize NES Middleware Conventional middleware for embedded systems is developed & optimized in a manner similar to early compiler technologies:
17
NES Middleware + Assorted Tools
Common Semantic Representation
Plat1
Impl
• The functional & QoS-related properties of embedded systems middleware can be improved greatly as follows:
• A common internal representation (ideally auto-generated) for each middleware specification
• Based on generalizing the middleware semantics
Middleware Generator
2. Use discrimination network to analyze the optimization rules & opportunities
3. Generate middleware that is customized for a particular platform & application use-case
• 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
Plat2
Plat2
.pd
Plat2
ImplPlat3
Impl
1. Read the target platform description & application requirements
Ap
pli
cati
on
Req
uir
em
ents
NES Applications
Plat3
Plat3
.pd
Plat1
Plat1
.pd
New Approach:
Applying Reflection to Optimize NES Middleware
18
Overview of CoSMIC Modeling Toolsuite
Open-source CoSMIC tools available at www.dre.vanderbilt.edu/cosmic/
•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)
19
Concluding RemarksRECAP 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
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
Next steps for ITR project are to apply Model Driven Middleware (MDM) to:
Our NSF ITR project is leveraging MDM technologies funded by other efforts (e.g., DARPA MoBIES, NEST, PCES, & ARMS)
We will work closely with UC Berkeley & SRI collaborators in the OEP testbed to integrate our MDM tools & middleware services with other NES aspects