190 likes | 293 Vues
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
E N D
Composable Middleware Services for High Confidence Networked Embedded SystemsNSF 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
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 http://www.isis.vanderbilt.edu/
Future Challenges Normal Vector of Reference Orbit Normal Vector of Cluster Plane 60o Subsatellite Orbit Earth 30o Cluster plane at t=0 Cluster plane at t=1/2P Reference Orbit Nadir Vector (Towards center of Earth) Information processing replaces mechanical structure • 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 Dynamic Sensor Networks New Challenges for Embedded Applications Past Challenges • Stand-alone and/or tightly-coupled embedded systems with stringent quality of service (QoS) demands • e.g., latency, jitter, footprint • Resourceconstrained
F1 F2 F5 F3 F6 F4 F7 Evolution of NES Application Development NES applications have historically tended to be: Stovepiped Proprietary Brittle & non-adaptive Expensive Vulnerable F1 F2 F5 F3 F6 F4 F7 • NES applications have also historically been built directly atop hardware • Tedious • Error-prone • Costly over lifecycles
NES Applications NES Applications Middleware Services Middleware Services Middleware Middleware RTOS & Protocols RTOS & Protocols Hardware & Networks Hardware & Networks Evolution of NES Application Development NES applications have historically tended to be: Stovepiped Proprietary Brittle & non-adaptive Expensive Vulnerable • NES applications have also been built directly atop hardware • Tedious • Error-prone • Costly over lifecycles • Middleware factors out many reusable mechanisms & services from what was traditionally NES application responsibility • This refactoring helps improve NES application confidence & trustworthiness
Spanning tree Location NES Applications Middleware Services Middleware RTOS & Protocols Hardware & Networks Example NES Middleware Services Power Control Alarm Routing Group Management Leader Election Consensus Clock Synchronization Configuration Data Streaming Data Aggregation Sentry Network Monitor Scheduling Reconfiguration State Synchronization
Workload & Replicas Connections & priority bands CPU & memory Network latency & bandwidth 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 NES Applications Middleware Services Middleware Operating Sys & Protocols Hardware & Networks
NES Applications Middleware Services Middleware 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
Composable Middleware Service Packages • 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 NES Application NES Applications Diffusing Algorithm Middleware Services Di st r ibuted Spanning Tree R e s e t Middleware Leader Election RTOS & Protocols Adjacency RTOS+ Hardware Hardware & Networks Goal: Automated synthesis & deployment of middleware service package from verified coordination service components
Middleware Service Library STEP 1 Parameters GME QoS Specs Type Specs (template) Application requirements: • Services needed • QoS requirements • Target platform specs STEP 3 STEP 2 STEP 4 Service Family (alternatives) IO Au. a1 a2 m2 Automatic composition & synthesis of middleware from requirements Assisted composition of middleware as specified by the user OR x4 b1 STEP 6 STEP 5 Composed QoS properties Application-specific middleware assembly Tools for model analysis & verification: safety, liveness, deadlock, etc System-level optimization STEP 7 STEP 8 Optimized QoS properties Optimized & verified middleware Target-specific code synthesizers STEP 9 Synthesizer #1 Synthesizer #2 Synthesizer #n Application Application Application Middleware Middleware Middleware VxWorks TinyOS RT Linux Simulator Wireless Node Wired Node STEP 10 STEP 10 Our Approach to Middleware Service Package Composition
Ix86 Opt. VAX Opt. 68K Opt. Ix86 VAX 68K Example:Applying Reflection as Compiler Optimization To illustrate the benefits of reflection as an optimization technique, consider the evolution of compiler technology: C Program • Early compilers required • Separate internal representations hand-written for each programming language & C Compiler • Separate hand-written optimizers for each target backend Internal Rep. • 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
Ix86 Opt. VAX Opt. 68K Opt. Ix86 VAX 68K Example:Applying Reflection as Compiler Optimization To illustrate the benefits of reflection as an optimization technique, consider the evolution of compiler technology: C++ Program Ada Program C Program • Early compilers required • Separate internal representations hand-written for each programming language and C++ Compiler Ada Compiler C Compiler • Separate hand-written optimizers for each target backend Internal Rep. Internal Rep. Internal Rep. • 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 PPC Opt. MIPS Opt. 88K Opt. 1751 Opt. 32K Opt. HPPA Opt. PPC MIPS 88K 1751 32K HPPA
3. Generate an optimizer that is customized for the particular platform/language 2. Use discrimination network to analyze the optimization rules & opportunities Optimizer Generator Ix86 PPC 68K 1. Read the target machine description Ix86 .md PPC .md 68K .md Example:Applying Reflection as Compiler Optimization • Modern compilers, such as GNU GCC, support • A common internal representation (still hand-written) for each programming language • Based on generalizing the language semantics C/C++/Ada Programs C/C++/Ada Compiler • A synthesized compiler optimizer that is customized automatically for each target backend • Based on reflective assessment of algebraic target machine description Common Internal Rep. Ix86 Opt. PPC Opt. 68K Opt. • Key Benefit of Reflective Optimization • New targets can be supported by writing a new machine description, rather than writing a new code generator/optimizer
TinyOS Impl WinCE Impl VxWorks Impl WinCE TinyOS VxWorks 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 • Separate tools and interfaces hand-written for each ORB middleware specification • e.g., CORBA, Java RMI, COM+, nORB, etc. NES Application NES Middleware & Assorted Tools • 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
NES Application NES Application NES Middleware & Assorted Tools NES Middleware & Assorted Tools Solaris Impl Win98 Impl TinyOS Impl Win2K Impl WinNT Impl WinCE Impl Linux Impl WinXP Impl VxWorks Impl Win2K Solaris WinNT Win98 WinCE TinyOS Linux WinXP VxWorks 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 • Separate tools and interfaces hand-written for each ORB middleware specification • e.g., CORBA, Java RMI, COM+ NES Application NES Middleware & Assorted Tools • 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
Application Requirements 3. Generate middleware that is customized for a particular platform & application use-case 2. Use discrimination network to analyze the optimization rules & opportunities Middleware Generator Plat1 Plat2 Plat3 Plat1 .pd Plat2 .pd Plat3 .pd 1. Read the target platform description & application requirements New Approach:Applying Reflection to Optimize NES Middleware • 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 NES Applications NES Middleware + Assorted Tools • 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 Common Semantic Representation Plat1 Impl Plat2 Impl Plat3 Impl
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/
Next steps for ITR project are to apply Model Driven Middleware (MDM) to: • Configure & deploy NES applications end-to-end • Configure component containers & run-time environments • Synthesize NES application & middleware-specific configurations • Synthesize dynamic QoS adaptation & resource management services • Benchmark & optimize provisioned NES applications Concluding Remarks RECAP OF ITR PROJECT GOALS Model, analyze, synthesize, & provisionmiddleware services for networked embedded systems (NES) applications that require coordination & control of multiple quality of service properties end-to-end 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)