1. Vanderbilt University
GaMMA: Generative and Model-driven Metaprogrammable Architectures for Deployment and Configuration of Distributed Real-time & Embedded Systems
Aniruddha Gokhale
Assistant Professor
ISIS, Dept. of EECS
Vanderbilt University
Nashville, Tennessee

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
Jai, here are my comments on this slide:
Please redraw the example application to focus on something from the context of ARMS than a general-purpose enterprise system. The reasons for this are that (1) Ken Birman works in the space of general-purpose enterprise systems & he’s got a LOT more experience/clout in the area of survivability than we do at this point so it’s pointless to try & go up against him head-to-head since he’s got ~5-10 big successes in this area over the past two decades & (2) we should focus on things that we really understand better than focus like Ken, i.e., namely enterprise DRE systems, such as ARMS. Please see
Please try to emphasize multi-dimensional QoS properties explicitly in the middle set of bullets in these slides. It’s implicit in what you say here, but please make it explicit since it ought to be a key focus to differentiate from the kinds of work that Ken does.
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. D&C Challenges for DRE Systems
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
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
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
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. 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
Design-time
Deployment-time
Run-time

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

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. Model Transformations and Model Checking
Automated Problem Space to Solution Space Mapping for Configuration Options
Model Transformations and Model Checking

17. Mapping QoS Intent to Platform Configurations
9/20/2018
Mapping QoS Intent to Platform Configurations
Prioritized service invocations (QoS Policy) needs to be mapped to Banded Connection (QoS configuration)
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? 17 17

18. Solution Approach: Model-Driven QoS Mapping
9/20/2018
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 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)