1. Automated Middleware QoS Configuration Techniques using Model Transformations Vanderbilt University Nashville, Tennessee Institute for Software Integrated Systems Amogh Kavimandan & Aniruddha Gokhale {amoghk,gokhale}@dre.vanderbilt.edu www.dre.vanderbilt.edu Research supported by Lockheed Martin STI Project

2. Distributed Real-time & Embedded (DRE) Systems Network-centric and large-scale “systems of systems” e.g., industrial automation, emergency response Different communication semantics e.g., pub-sub Satisfying tradeoffs between multiple (often conflicting) QoS demands e.g., secure, real-time, reliable, etc. Regulating & adapting to (dis)continuous changes in runtime environments e.g., online prognostics, dependable upgrades, keep mission critical tasks operational, dynamic resource mgmt DRE systems increasingly adopting component-based architectures

3. Variability in the solution space (systems integrator role) Diversity in platforms, languages, protocols & tool environments Enormous accidental & inherent complexities Continuous evolution & change Challenges in Realizing DRE Systems Variability in the problem space (domain expert role) Functional diversity Composition, deployment and configuration diversity QoS requirements diversity Mapping problem artifacts to solution artifacts is hard

4. Components encapsulate application “business” logic Components interact via ports Provided interfaces, e.g., facets Required connection points, e.g., receptacles Event sinks & sources Attributes Containers provide execution environment for components with common operating requirements Components/containers can also Communicate via a middleware bus and Reuse common middleware services SecurityReplicationNotificationPersistence SchedulingA/V StreamingLoad Balancing … Container … … Middleware Bus Container … Technology Enablers for DRE systems: Component Middleware “Write Code That Reuses Code”

5. Challenges in Component-based DRE Systems … specification … … composition & packaging analysis, validation & verification, testing configuration & optimization deployment planning & QoS provisioning

6. Our Solution: CoSMIC MDE Tool Chain 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 applications Capabilities being added for QoS provisioning (real-time, fault tolerance, security) CoSMIC can be downloaded at www.dre.vanderbilt.edu/cosmic

7. Middleware Configuration (1/2) 7 Container COMPONENT EXECUTORS Component Home POA Callback Interfaces I n t e r n a l I n t e r f a c e s E v e n t S i n k s F a c e t s R e c e p t a c l e s E v e n t S o u r c e s Component Reference C o m p o n e n t C o n t e x t COMPONENT SERVER 1 Container COMPONENT EXECUTORS Component Home POA Callback Interfaces I n t e r n a l I n t e r f a c e s E v e n t S i n k s F a c e t s R e c e p t a c l e s E v e n t S o u r c e s Component Reference C o m p o n e n t C o n t e x t COMPONENT SERVER 2 ORB End-to-End Priority Propagation Thread Pools Portable Priorities Protocol Properties Priority Band Benefits of QoS- enabled middleware technologies Raise the level of abstraction Support many quality of service (QoS) configuration knobs

8. Middleware Configuration (2/2) 8 Container COMPONENT EXECUTORS Component Home POA Callback Interfaces I n t e r n a l I n t e r f a c e s E v e n t S i n k s F a c e t s R e c e p t a c l e s E v e n t S o u r c e s Component Reference C o m p o n e n t C o n t e x t COMPONENT SERVER Drawbacks of QoS-enabled middleware technologies Achieving desired QoS increasingly a system QoS configuration problem, not just an initial system functional design problem Benefits of QoS- enabled middleware technologies Raise the level of abstraction Support many quality of service (QoS) configuration knobs Lack of effective QoS configuration tools result in QoS policy mis-configurartions that are hard to analyze & debug ORB

9. Solution Approach: Model Driven Engineering (MDE) Develop, validate, & standardize generative software technologies that: 1. Model 2. Analyze 3. Synthesize & 4. Provision multiple layers of middleware & application components that require simultaneous control of multiple quality of service properties end-to-end Specialization is essential for inter-/intra-layer optimization & advanced product-line architectures Middleware Services DRE Applications Operating Sys & Protocols Hardware & Networks <…events this component supplies…> <…events this component supplies…> Goal is not to replace programmers per se – it is to provide higher-level domain-specific languages for middleware/application developers & users

10. Motivating Application: NASA MMS Mission NASA’s Magnetospheric MultiScale (MMS) space mission consists of four identically instrumented spacecraft & a ground control system Collect mission data Send it to ground control at appropriate time instances 10

11. Motivating Application: NASA MMS Mission MMS mission QoS requirements span two dimensions Multiple modes of operation Varying importance of data collection activity of satellite sensors based on mission phase 11 Slow Survey Fast Survey Burst

12. Motivating Application: NASA MMS Mission MMS mission QoS requirements span two dimensions Multiple modes of operation Varying importance of data collection activity of satellite sensors based on mission phase Need to translate QoS policies into QoS configuration options & resolve QoS dependencies 12 Slow Survey Fast Survey Burst

13. MMS prototype developed using Component-Integrated ACE ORB (CIAO) Several different assemblies tailored to deliver different end-to-end QoS behaviors and/or algorithms can be part of the package e.g., full-scale MMS has 100’s of components & 10’s of assemblies Packages describing the components & assemblies can be scripted via XML descriptors generated by automated model-driven tools MMS application components are bundled together into hierarchical assemblies Assembly package metadata conveys component interconnections & implementation alternatives Spacecraft 1 Sensor Suite (Linux node) Bus Processor (VxWorks Node) Ethernet (802.3) Sensor 1 Sensor 2 Sensor 3 Sensor 4 Payload Processor (Linux Node) Gizmo Agent Gizmo Agent Gizmo Agent Gizmo Agent Algorithm Exec Agent Comm Agent Science Agent Exec Agent Comm Agent GNC Agent Component-based MMS Mission Prototype

14. Challenge 1: Translating QoS Policies to QoS Options 14 Prioritized service invocations (QoS Policy) must be mapped to Real-time CORBA Banded Connection (QoS configuration) Large gap between application QoS policies & middleware QoS configuration options Bridging this gap is necessary to realize the desired QoS policies The mapping between application-specific QoS policies & middleware- specific QoS configuration options is non-trivial, particularly for large systems

15. Challenge 1: Translating QoS Policies to QoS Options 15 Conventional mapping approach requires deep understanding of the middleware configuration space e.g., multiple types/levels of QoS policies require configuring appropriate number of thread pools, threadpool lanes (server) & banded connections (client) Protocol Properties Explicit Binding Client Propagation & Server Declared Priority Models Portable Priorities Thread Pools Static Scheduling Service Standard Synchonizers Request Buffering

16. Challenge 2: Choosing Appropriate QoS Option Values 16 Individually configuring component QoS options is tedious & error-prone e.g., ~10 distinct QoS options per component & ~140 total QoS options for entire NASA MMS mission prototype Manually choosing valid values for QoS options does not scale as size & complexity of applications increase

17. Challenge 3: Validating QoS Options 17 Each QoS option value chosen should be validated e.g., Filter priority model is CLIENT_PROPAGATED, whereas Comm priority model is SERVER_DECLARED Each system reconfiguration (at design time) should be validated e.g., reconfiguration of bands of Analysis should be validated such that the modified value corresponds to (some) lane priority of the Comm

18. Challenge 4: Resolving QoS Option Dependencies “QoS option dependency” is defined as: Dependency between QoS options of different components Manually tracking dependencies is hard – or in some cases infeasible Dependent components may belong to more than one assembly Dependency may span beyond immediate neighbors –e.g., dependency between Gizmo & Comm components Empirically validating configuration changes by hand is tedious, error- prone, & slows down development & QA process considerably Several iterations before desired QoS is achieved (if at all) 18 ThreadPool priorities of Comm should match priority bands defined at Gizmo

19. 19 Solution Approach: Model-Driven QoS Mapping QUality of service pICKER (QUICKER) Model-driven engineering (MDE) tools model application QoS policies Provides automatic mapping of QoS policies to QoS configuration options Validates the generated QoS options Automated QoS mapping & validation tools can be used iteratively throughout the development process

20. Enhanced Platform Independent Component Modeling Language (PICML), a DSML for modeling component- based applications QoS mapping uses Graph Rewriting & Transformation (GReAT) model transformation tool Customized Bogor model-checker used to define new types & primitives to validate QoS options 20 QUICKER Enabling MDE Technologies

21. Enhanced Platform Independent Component Modeling Language (PICML), a DSML for modeling component- based applications QoS mapping uses Graph Rewriting & Transformation (GReAT) model transformation tool Customized Bogor model-checker used to define new types & primitives to validate QoS options 21 QUICKER Enabling MDE Technologies CQML Model interpreter generates Bogor Input Representation (BIR) of DRE system from its CQML model CQML Model Interpreter Bogor Input Representation

22. 22 QUICKER Concepts: Transformation of QoS policies(1/2) RequirementProxy can be per component or assembly instance 1.Platform-Independent Modeling Language (PICML) represents application QoS policies PICML captures policies in a platform- independent manner Representation at multiple levels e.g., component- or assembly-level

23. 23 QUICKER Concepts: Transformation of QoS policies(1/2) 1.Platform-Independent Modeling Language (PICML) represents application QoS policies PICML captures policies in a platform- independent manner Representation at multiple levels e.g., component- or assembly-level 2.Component QoS Modeling Language (CQML) represents QoS options CQML captures QoS configuration options in a platform-specific manner

24. 24 3.Translation of application QoS policies into middleware QoS options Semantic translation rules specified in terms of input (PICML) & output (CQML) type graph e.g., rules that translate multiple application service requests & service level policies to corresponding middle- ware QoS options QUICKER transformation engine maps QoS policies (in PICML) to QoS configuration options (in CQML) QUICKER Concepts: Transformations of QoS policies(2/2) Provider Service Request Provider Service Levels Level 1 Level 2 Level 3 Multiple Service RequestsService Levels Priority Model Policy Thread Pool Lanes

25. 25 QUICKER Concepts: Validation of QoS Options (1/2) 1.Representation of middleware QoS options in Bogor model-checker BIR extensions allow representing domain-level concepts in a system model QUICKER defines new BIR extensions for QoS options Allows representing QoS options & domain entities directly in a Bogor input model –e.g., CCM components, Real- time CORBA lanes/bands are first-class Bogor data types Reduces size of system model by avoiding multiple low-level variables to represent domain concepts & QoS options

26. 26 2.Representation of properties (that a system should satisfy) in Bogor BIR primitives define language constructs to access & manipulate domain-level data types, e.g.: Used to define rules that validate QoS options & check if property is satisfied 3.Automatic generation of BIR of DRE system from CQML models QUICKER Concepts: Validation of QoS Options (2/2) Rule determines if ThreadPool priorities at Comm match priority bands at Analysis Model interpreters auto-generate Bogor Input Representation of a system from its CQML model

27. Resolving Challenge 1: Translating Policies to Options (1/2) 27 Expressing QoS policies PICML modes application-level QoS policies at high-level of abstraction e.g., multiple service levels support for Comm component, service execution at varying priority for Analysis component Reduces modeling effort e.g., ~25 QoS policy elements for MMS mission vs. ~140 QoS options

28. Resolving Challenge 1: Translating Policies to Options (2/2) Mapping QoS policies to QoS options GReAT model transformations automate the tedious & error-prone translation process Transformations generate QoS configuration options as CQML models Allow further transformation by other tools e.g., code optimizers & generators Simplifies application development & enhances traceability 28

29. Resolving Challenges 2 & 3: Ensuring QoS Option Validity CQML model interpreter generates BIR specification from CQML models BIR primitives used to check whether a given set of QoS options satisfies a system property e.g., fixed priority service execution, a property of Comm component Supports iterative validation of QoS options during QoS configuration process 29 QUICKER

30. Resolving Challenge 4: Resolving QoS Option Dependencies Change(s) in QoS options of dependent component(s) triggers detection of potential mismatches e.g., dependency between Gizmo invocation priority & Comm lane priority 30 Dependency structure maintained in Bogor used to track dependencies between QoS options of components, e.g.: Analysis & Comm are connected Gizmo & Comm are dependent Detect mismatch if either values change Dependency Structure of MMS Mission Components

31. Functional Specification & Analysis Tools Hatcliff, J. et. al. (2003). Cadena QoS Adaptation Modeling Tools Ye, J. et. al. (2004). DQME Zinky, J., (1997). QuO QoS Specification Tools Ritter, T. et. al. (2003). CCM QoS MetaModel Ahluwalia, J. et. al. (2005). Model-based Run-time Monitoring Frolund, S. et. al. (1998). QML Schedulability Analysis Tools Madl, G. et. al. (2004). Automatic Component-based system verification Kodase, S. et. al. (2003). AIRES Academic Related Work 31

32. Concluding Remarks QUICKER provides Model-Driven Engineering (MDE) for QoS-enabled component middleware Maps application-level QoS policies to middleware-specific QoS configuration options Model transformations automatically generate QoS options Model-checking extensions ensure validity of QoS options at component- & application- level 32 QUICKER MDE tools & CIAO QoS-enabled component middleware available as open- source at www.dre.vanderbilt.edu/CoSMIC

33. Questions? 33 1-510-2021-100