Automated Middleware Qo S Configuration Techniques using Model

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

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) Qo. S 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

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

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

Our Solution: Co. SMIC MDE Tool Chain • • Co. SMIC tools e. g. , PICML used to model application components, CQML for Qo. S Captures the data model of the OMG D&C specification Synthesis of static deployment plans for DRE applications Capabilities being added for Qo. S provisioning (real-time, fault tolerance, security) Co. SMIC can be downloaded at www. dre. vanderbilt. edu/cosmic

Middleware Configuration (1/2) COMPONENT EXECUTORS Callback Interfaces POA Protocol Properties ORB Portable Priorities COMPONENT SERVER 1 COMPONENT SERVER 2 7 Even t Rec eptacles Sources Component Home Com po nent Context E vent Rec eptacles Source s Com po ne n t C ontex t Internal Interfaces Thread Pools Event Sinks Callback Interfaces End-to-End Priority Propagation F acets Eve nt S inks • Support many quality of service (Qo. S) configuration knobs Component Home COMPONENT EXECUTORS Container Priority Band Container Facets • Raise the level of abstraction Component Reference In ternal I nterfaces • Benefits of Qo. Senabled middleware technologies

Middleware Configuration (2/2) • Benefits of Qo. Senabled middleware technologies Callback Interfaces POA ORB COMPONENT SERVER • Drawbacks of Qo. S-enabled middleware technologies • Achieving desired Qo. S increasingly a system Qo. S configuration problem, not just an initial system functional design problem Lack of effective Qo. S configuration tools result in Qo. S policy mis-configurartions that are hard to analyze & debug 8 Even t Rec eptacles Sources In ternal I nterfaces COMPONENT EXECUTORS Com po nent Context Component Home Event Sinks • Support many quality of service (Qo. S) configuration knobs Container F acets • Raise the level of abstraction Component Reference

Motivating Application: NASA MMS Mission • NASA’s Magnetospheric Multi. Scale (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

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

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

Component-based MMS Mission Prototype Spacecraft 1 Bus Processor (Vx. Works Node) Payload Processor (Linux Node) Sensor Suite (Linux node) Sensor 1 Sensor 2 Gizmo Agent Science Agent Algorithm Comm Agent Algorithm GNC Agent Sensor 3 Exec Agent Comm Agent Sensor 4 Ethernet (802. 3) Exec Agent • MMS application components are bundled together into hierarchical assemblies • Assembly package metadata conveys component interconnections & implementation alternatives • Several different assemblies tailored to deliver different end-to-end Qo. S 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 prototype developed using Component-Integrated ACE ORB (CIAO)

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

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

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

Challenge 3: Validating Qo. S Options • Each Qo. S 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 17

Challenge 4: Resolving Qo. S Option Dependencies Thread. Pool priorities of Comm should match priority bands defined at Gizmo • “Qo. S option dependency” is defined as: • Dependency between Qo. S 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, errorprone, & slows down development & QA process considerably • Several iterations before desired Qo. S is achieved (if at all) 18

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

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

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

Resolving Challenge 1: Translating Policies to Options (1/2) • Expressing Qo. S policies • PICML modes application-level Qo. S 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 Qo. S policy elements for MMS mission vs. ~140 Qo. S options 27

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

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

Resolving Challenge 4: Resolving Qo. S Option Dependencies • Dependency structure maintained in Bogor used to track dependencies between Qo. S 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 • Change(s) in Qo. S options of dependent component(s) triggers detection of potential mismatches • e. g. , dependency between Gizmo invocation priority & Comm lane priority 30

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

Questions? 1 -5 10 -20 21 -100 33