Aniruddha Gokhale a.gokhale@vanderbilt dre.vanderbilt/~gokhale Assistant Professor

1. GaMMA: Generative and Model-driven Metaprogrammable Architectures for Deployment and Configuration of Distributed Real-time & Embedded Systems Aniruddha Gokhale a.gokhale@vanderbilt.edu www.dre.vanderbilt.edu/~gokhale Assistant Professor ISIS, Dept. of EECS Vanderbilt University Nashville, Tennessee www.dre.vanderbilt.edu

2. Intro Section Start with some sample case such as the intelligent transportation example

3. Distributed Real-time & Embedded (DRE) Systems • Network-centric and large-scale “systems of systems” • e.g., industrial automation, emergency response, intelligent transportation • Service orchestration via composition, deployment and configuration • Diversity along multiple dimensions • simultaneous different QoS requirements e.g., secure, real-time, reliable, etc. • different middleware infrastructures • different programming and communication abstractions DRE systems must be robust and reliable

4. D&C: Scope of Proposed R&D • Deployment • Bootstrapping middleware functionality that is customized and optimized for the use case across the computing resources of the system • Configuration • Fine tuning the installed middleware artifacts by activating the right set of configuration options and choosing the right set of values across the computing resources of the system • Assumptions • Resource allocation, schedulability analysis and task partitioning done a priori • Deployment planning i.e., choice of resources, selection of technology base and implementation choices of services done a priori

5. Challenges in the problem space (domain expert role) • Functionality diversity => orchestrating multiple diff services end-to-end • QoS requirements diversity =>defining QoS goals for different parts of the overall system • Challenges in the solution space (systems integrator role) • Diversity in middleware platforms, programming models, communication abstractions & tool environments • Diversity in configuration and bootstrapping mechanisms • Enormous accidental & inherent complexities D&C Challenges for DRE Systems Problem space to Solution space mapping is hard => Need tool automation for DRE D&C activities

6. Technical Description

7. Sources of Variability Impacting D&C (1/3) • Understand the sources of variability in the problem/solution space that impacts D&C • Find solutions to automate the mapping of the problem space to solution space • Per-component/service concerns • Problem space: Functionality often supplied as third party COTS • Solution space: Implementations for different platforms and languages • P->S mapping challenges: • Implementations must match platform and language choice • Choice of implementation impacts middleware customization and configuration • Communication concerns • Problem space: Choice of communication paradigms (pub-sub, RPC, MOM) can differ between services • Solution space: Diversity in communication mechanisms e.g, CORBA IIOP, Java RMI, DDS, Event channels • P->S mapping challenges: • Decoupling application logic from provisioning communication mechanisms • Right optimizations in communication paths needed to enhance QoS • Must deal with communication between heterogeneous middleware technologies

8. Sources of Variability Impacting D&C (2/3) • Bootstrapping concerns • Problem space: defining the expected capabilities of the platform • Solution space: identifying the necessary features of the middleware • P->S mapping challenges: • Customizing the right set of middleware features • Optimizing the installed middleware base • Assembly concerns • Problem space: Discovering services and composing them together • Solution space: Making interconnections between bootstrapped middleware artifacts • P->S mapping challenges: • Must ensure functional and systemic compatibility in composition • Account for heterogeneity in platforms and languages in composition

9. Sources of Variability Impacting D&C (3/3) • Configuration concerns • Problem space: Multiple QoS requires right set of configurations • Defining the unit of failover, the replication degree. • Defining timeliness requirements • What are • Solution space: Individual middleware platforms provide high degree of configuration flexibility • P->S mapping challenges: • What configuration options and their values control a specific dimension of QoS? • How do different configuration options interact with each other? • How to configure the overall system made up of heterogeneous platforms?

10. Design-time Deployment-time Run-time A Single Perspective of D&C Challenges • D&C issues demonstrate numerous tangled concerns • Significant sources of variability must be accounted by D&C tools • D&C concerns tangled across system lifecycle This research focuses on design- and deployment-time D&C issues Focus of this Research

11. Technical Approach (1/2) • Leveraging the Commonalities • Identify commonalities to build a common D&C tool chain called GaMMA • OMG D&C spec is a good start e.g., our DAnCE tool chain • Identify backend tools GaMMA will need to interact with e.g., FOCUS or Aspect tools for optimizations • Addressing the Variabilities • Make GaMMA “Metaprogrammable” to handle the different sources of variabilities identified earlier • Use Model-driven and Generative tools to instantiate a concrete GaMMA tool for a specific use case GaMMA is akin to a product line architecture for D&C

12. Technical Approach (2/2) • Emphasis on model-based design • Capture recurring D&C solutions as patterns within DSMLs • Meta-model composition of middleware feature models, composition models, and QoS models • Stepwise Model transformations moving from problem space (platform independent) to solution space (platform dependent) • Generative techniques to instantiate D&C “product variant” • Single tool with capabilities for deployment and configuration • Works in the heterogeneous setup

13. Discuss Prior Work & discuss solution approaches combining these into GaMMA(a) using metamodel composition(b) encoding recurring patterns(c) generative mechanisms PICML, CQML for expressing composition and QoS intent POSAML for middleware stack models Specializations using FOCUS, AspectC++ QUICKER model transforms and validation

14. Services Composition via CoSMIC Toolsuite Work supported by DARPA PCES & ARMS Programs • CoSMIC tools e.g., PICML used to model application components, CQML for QoS • Captures the data model of the OMG D&C specification • Synthesis of static deployment plans for DRE systems • Capabilities being added for QoS provisioning (real-time, fault tolerance, security) CoSMIC can be downloaded at www.dre.vanderbilt.edu/cosmic

15. Component QoS Modeling Language (CQML) Objectives: • Express QoS design intent • Model crosscutting QoS concerns • Perform design-time QoS tradeoff analysis Challenges: • Intuitive QoS abstractions • Separation as well as unification of QoS concerns • 4 types of QoS modeling capabilities • Real-time • Fault tolerance • Security • Network QoS • Developed as overlay on a composition modeling language • Facility to integrate behavioral modeling • Unified internal mechanism for QoS integration • Pluggable back end analysis tools for QoS tradeoff analysis • e.g., Times tool

16. Automated Problem Space to Solution Space Mapping for Configuration Options Model Transformations and Model Checking

17. Mapping QoS Intent to Platform Configurations Large gap between application QoS policies & middleware QoS configuration options Necessary to realize the desired QoS policies Not a straightforward mapping Requires understanding of middleware configuration space e.g., multiple levels of QoS requires configuring appropriate number of thread pools, threadpool lanes (server) and banded connections(client) How do you validate the options? How do you maintain compatibility across components? Prioritized service invocations (QoS Policy) needs to be mapped to Banded Connection (QoS configuration) 17

18. Solution Approach: Model-Driven QoS Mapping QUality of service pICKER (QUICKER) Allows modeling of application QoS policies Provides automatic mapping of QoS policies to configuration options Allows validating the generated QoS options Automated QoS mapping and validation process – can be used iteratively in the design process 18

19. Generative Framework within MDE tools The CQML EventBus Architecture provides an example of how multiple QoS dimensions are handled inside a framework

20. CQML QoS Unification & Tradeoff Analysis • Leverages QoS and behavioral models • Model interpretation using an EventBus framework • Each QoS dimension publishes its modeled QoS requirements • A particular QoS dimension is chosen as the driver e.g., real-time • Acts as subscriber of events generated by other dimensions • Driver interpreter integrates other QoS dimensions making tradeoffs on the way • Pluggable back end analysis and generative tools

21. Example: QoS Tradeoff Analysis using TIMES tool • CQML EventBus architecture weaves in FT and Security concerns into RT concerns • Feeds to backend schedulability analysis tools e.g., Times

22. R&D Evaluation(a) representative applns(b) ISISlab resources Based on 2 stage approach: Model checking for correctness of D&C instantiated variant Emulation-based (CUTS)