1. 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

2. 2 Where We Fit into Trustworthy NES

3. 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. 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 of Cluster Plane Nadir Vector (Towards center of Earth) 30 o Normal Vector of Reference Orbit Reference Orbit Subsatellite Orbit 60 o Cluster plane at t=1/2P Cluster plane at 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. 5 Evolution of NES Application Development NES applications have historically tended to be: Stovepiped Proprietary Brittle & non-adaptive Expensive Vulnerable 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. 6 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 Services NES Applications RTOS & Protocols Hardware & Networks Middleware Services 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. 7 Example NES Middleware Services Middleware Services 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. 8 Middleware Services 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. 9 Middleware Services 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. 10 Middleware Services NES Applications RTOS & Protocols Hardware & Networks NES Application RTOS+ Hardware Diffusing Algorithm Spanning Tree Leader Election Adjacency DistributedDistributed ResetReset 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. 11 STEP 1 Parameters IO Au. QoS Specs Type Specs (template) Service Family (alternatives) a1a1 Middleware Service Library STEP 2 STEP 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-specific middleware assembly a2a2 x4x4 b1b1 m2m2 Composed QoS properties STEP 5STEP 6 OR Assisted composition of middleware as specified by the user GME Target-specific code synthesizers Synthesizer #nSynthesizer #2Synthesizer #1 STEP 9 Optimized QoS properties Optimized & verified middleware System-level optimization STEP 8 Application TinyOS Wireless Node Middleware Application VxWorks Wired Node Middleware Application RT Linux Simulator Middleware STEP 10 Our Approach to Middleware Service Package Composition

12. 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. Ix86 Opt. Ix86 VAX Opt. VAX 68K Opt. 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. 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. Ix86 Opt. Ix86 VAX Opt. VAX 68K Opt. 68K C Program To illustrate the benefits of reflection as an optimization technique, consider the evolution of compiler technology: C++ Compiler Internal Rep. PPC Opt. MIPS Opt. 88K Opt. PPCMIPS88K C++ Program Ada Compiler Internal Rep. 1751 Opt. 32K Opt. HPPA Opt. 175132KHPPA Ada Program Example: Applying Reflection as Compiler Optimization

14. 14 C/C++/Ada Compiler Common Internal Rep. Ix86 Opt. PPC Opt. 68K Opt. C/C++/Ada Programs 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 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. 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 Impl TinyOS Impl VxWorks Impl New Approach: Applying Reflection to Optimize NES Middleware

16. 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 Win2KSolaris Linux NES Application Win2K Impl Solaris Impl Linux Impl NES Middleware & Assorted Tools WinNTWin98 WinXP NES Application WinNT Impl Win98 Impl WinXP Impl NES Middleware & Assorted Tools NES Application WinCE Impl TinyOS Impl VxWorks Impl 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. 17 NES Middleware + Assorted Tools Common Semantic Representation Plat 1 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 Plat 2.pd Plat 2 Impl Plat 3 Impl 1. Read the target platform description & application requirements Application Requirements NES Applications Plat 3.pd Plat 1.pd New Approach: Applying Reflection to Optimize NES Middleware

18. 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. 19 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 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