Multidimensional Qo. S Management in 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 April 30 & May 1, 2007 Colorado State U & Tech. X Corporation www. dre. vanderbilt. edu
Distributed Real-time & Embedded (DRE) Systems • Network-centric and large-scale “systems of systems” – e. g. , industrial automation, emergency response • 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 developed via robust and reliable system composition and integration of services and applications 2
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 evolution & change Mapping problem artifacts to solution artifacts is hard 3
Sources of Variability Impacting Qo. S (1/3) • Understand the sources of variability in the problem/solution space that impacts Qo. S • Find solutions to automate the mapping of the problem space to solution space • Per-component 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 end-to-end Qo. S • Communication concerns – Problem space: Choice of communication paradigms (pub-sub, RPC, MOM) and requirements on Qo. S – Solution space: Diversity in communication mechanisms e. g, CORBA IIOP, Java RMI, DDS, Event channels, and Qo. S mechanisms e. g. , Diff. Serv, Int. Serv, MPLS – P->S mapping challenges: • Decoupling application logic from provisioning communication Qo. S • Right optimizations in communication paths needed to enhance Qo. S • Redundancy and mixed mode communications needed to support Qo. S 4
Sources of Variability Impacting Qo. S (2/3) • Assembly concerns – Problem space: Discovering services and composing them together – Solution space: Interfaces and their semantics must match – P->S mapping challenges: • Must ensure functional and systemic compatibility in composition • Heterogeneity in platforms and languages in composition impacts Qo. S • Deployment concerns – Problem space: Need resources e. g. , CPU, memory, bandwidth, storage – Solution space: Diversity in resource types and their configurations – P->S mapping challenges: • • How to select and provision resources such that end-to-end Qo. S is realized? How to (re)allocate resources to maintain end-to-end Qo. S? How to place components so that near optimal Qo. S tradeoffs are made? How to allow sharing of components or assemblies? 5
Sources of Variability Impacting Qo. S (3/3) • Configuration concerns – Problem space: Multiple Qo. S requires right set of configurations • What is the unit of failover? What is the replication degree? Are entire assemblies replicated? • How to define access control rights? • Determining system task partitioning, schedulability • Defining network resource needs – Solution space: Platforms provide high degree of configuration flexibility – P->S mapping challenges: • • What configuration options control a specific dimension of Qo. S? How do different configuration options interact with each other? How to configure heterogeneous platforms? What impact deployment decisions have on configurations? 6
A Single Perspective: Tangling of Qo. S Issues • Demonstrates numerous tangled para-functional concerns • Significant sources of variability that affect end-to -end Qo. S • Qo. S concerns tangled across system lifecycle Lifecycle-wide separation of concerns (So. C) & variability management is the key Design-time Deployment-time Run-time 7
Requirements of a Solution Approach • Need expressive power to define Qo. S intent in the problem space, and perform design-time analysis • e. g. , network Qo. S needs of application flows or end-to-end latencies • Need to decouple DRE system functionality from systemic capabilities in the solution space • e. g. , decouple robot manager logic from fault tolerance configurations • Need to automate the mapping from problem to solution space • e. g. , automate the (re)deployment and (re)configuration of system functionality to maintain Qo. S • Need to provide a hosting platform with dynamic adaptation capabilities • e. g. , survivability management of robot manager 8
Qo. S Management via Multistage Architecture Multiple levels of abstraction required for resolving tangling of Qo. S issues • Model driven engineering (MDE) provides intuitive, variability management in the problem space • Resource allocation and control framework decouples problem space from solution space • Deployment and configuration tools transparently map problem space Qo. S needs to solution space artifacts • Qo. S-enabling component middleware provides hosting environment and runtime adaptation features www. dre. vanderbilt. edu 9
Our MDE Solution: Co. SMIC Toolsuite Work supported by DARPA PCES & ARMS Programs • • 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 systems Capabilities being added for Qo. S provisioning (real-time, fault tolerance, security) Co. SMIC can be downloaded at www. dre. vanderbilt. edu/cosmic 10
Expressing Multidimensional Qo. S Intent A Qo. S Modeling Language 11
Component Qo. S Modeling Language (CQML) Objectives: Challenges: • Express Qo. S design intent • Model crosscutting Qo. S concerns • Perform design-time Qo. S tradeoff analysis • Intuitive Qo. S abstractions • Separation as well as unification of Qo. S concerns • 4 types of Qo. S modeling capabilities • • Real-time Fault tolerance Security Network Qo. S • Developed as overlay on a composition modeling language • Facility to integrate behavioral modeling • Unified internal mechanism for Qo. S integration • Pluggable back end analysis tools for Qo. S tradeoff analysis • e. g. , Times tool 12
Example of Failover Unit Intent Primary Component R “Client” IO ry ma ri p A container/component server B container/component server C container/component server Primary FOU se y ar nd co R IO A’ Replica Component B’ container/component server C’ container/component server Replica FOU 13
Example of Shared Risk Group Intent Data. Center 1_SRG Rack 1_SRG Shelf 1_SRG Blade 30 Rack 2_SRG Shelf 2_SRG Blade 34 Ship_SRG Blade 29 Data. Center 2_SRG Node 1 (blade 31) Node 2 (blade 32) Shelf 1_SRG Blade 33 Blade 36 14
Example Replica Placement Intent Define N orthogonal vectors, one for each of the distance values computed for the N components (with respect to a primary) and vectorsum these to obtain a resultant. Compute the magnitude of the resultant as a representation of the composite distance captured by the placement . 1. Compute the distance from each of the replicas to the primary for a placement. 2. Record each distance as a vector, where all vectors are R 2 orthogonal. 3. Add the vectors to obtain a resultant. P 4. Compute the magnitude of the resultant. R 3 5. Use the resultant in all comparisons (either among R 1 placements or against a threshold) 6. Apply a penalty function to the composite distance (e. g. pair wise replica distance or uniformity) 15
CQML FT Modeling Abstractions Qo. S Enhancements to PICML (Platform Independent Component Modeling Language) Metamodel • Fail-over Unit (FOU): Abstracts away details of granularity of protection (e. g. Component, Assembly, App-string) • Replica Group (RPG): Abstracts away faulttolerance policy details (e. g. Active/passive replication, state-synchronization, topology of replica) • Shared Risk Group (SRG): Captures associations related to risk. (e. g. shared power supply among processors, shared LAN) Model Interpreter (component placement constraint solver): Encapsulates an algorithm for component-node assignment based on replica distance metric Protection granularity concerns State-synchronization concerns Component Placement constraints Replica Distance Metric 16
CQML RT & Net. Qo. S Modeling Abstractions • Real-time modeling provided by the RTModel element • Leverages known patterns of real-time programming usage: • e. g. , real-time CORBA • Enables modeling of: • • • Priority models Banded connections Thread pools with Lanes Resources e. g. , CPU, memory • Network Qo. S modeling allows modeling Qo. S per application flow • Classification into high priority, high reliability, multimedia and best effort classes • Enables bandwidth reservation in both directions • Client propagated or server declared models 17
Modeling & Generative Steps in CQML 1. Model components and application strings in PICML 2. e. g. , Model Fail Over Units (FOUs) and Shared Risk Groups (SRGs) using CQML 3. Generate deployment plan GME/PICML Model Information Domain, Deployment, SRG, and FOU FT Interpreter model injection Replica Placement Algorithm Augmented Deployment Plan 4. Interpreter automatically injects 5. replicas and associated CCM IOGRs 5. Distance-based constraint algorithm determines replica placement in deployment descriptors. 19
Example: FT Requirements Modeling in CQML Component FOU Replication Style = Active Deployment plan to be augmented LEGEND FOU: Fail Over Unit SRG: Shared Risk Group Replica = 3 Min Distance = 4 Shared Risk Group (SRG) hierarchy 20
Automated Sample FT Qo. S Provisioning • Automatic Injection of replicas • Augmentation of deployment plan based on number of replicas • Automatic Injection of FT infrastructure components • E. g. Collocated “heartbeat” (HB) component with every protected component. • Automatic Injection of connection meta-data • Specialized connection setup for protected components (e. g. Interoperable Group References IOGR) HB Container 21
Automated Heartbeat Component Injection Primary Component A B C container/component server OR IOGR prim HB HB HB I ary “client” intra-FOU heartbeat FPC Collocated heartbeat component Primary FOU periodic FPC heartbeat Connection Injection Replica Component R IO y ar nd co se FPC HB HB HB A’ B’ container/component server C’ container/component server Replica FOU 22
Example: Net. Qo. S Modeling in CQML • Expressing Qo. S intent for application flows • Multiple connections sharing Qo. S can use same element 23
Example: Automated Component Placement Ship_SRG Data. Center 1_SRG Rack 2_SRG Composite Distance Shelf 1_SRG Blade 30 Replica 1 Shelf 2_SRG Blade 34 Blade 29 Replica 3 Shelf 1_SRG Blade 33 Data. Center 2_SRG Node 1 (blade 31) Node 2 (blade 32) Primary Blade 36 Replica 2 24
Qo. S Analysis Requires Behavior Enhancing CQML with Behavior Modeling 25
Adding Behavioral Modeling to CQML Realized via metamodel composition i. e. , CQML with behavioral DSMLs Component Behavior Modeling Language (CBML) • a high-level domain-specific modeling language for capturing the behavior of components • e. g. , its actions & states Workload Modeling Language (WML) • a domain-specific modeling language for capturing workload, & used to parameterize the actions on CBML & WML were both developed using GME (http: //www. isis. vanderbilt. edu/projects/GME) 26
Integrating Behavioral and Structural DSMLs Context • Structural Qo. S DSML (e. g. , CQML) capture the makeup of componentbased systems and their Qo. S • There is no correlation between a component’s ports & its behavior Integration Enablers • Defined a set of connector elements that allow structural DSMLs to integrate with (or contain) CBML models • Input ports directly connect to Input Action elements • Output actions have the same name as their output port to reduce model clutter input connections output name • i. e. , prevent many to one connections 27
Unifying Qo. S Dimensions & Tradeoff Analysis The CQML Event. Bus Architecture 28
CQML Qo. S Unification & Tradeoff Analysis • • Leverages Qo. S and behavioral models Model interpretation using an Event. Bus framework Each Qo. S dimension publishes its modeled Qo. S requirements A particular Qo. S dimension is chosen as the driver e. g. , real-time • Acts as subscriber of events generated by other dimensions • Driver interpreter integrates other Qo. S dimensions making tradeoffs on the way • Pluggable back end analysis and generative tools 29
Example: Qo. S Tradeoff Analysis using TIMES tool • CQML Event. Bus architecture weaves in FT and Security concerns into RT concerns • Feeds to backend schedulability analysis tools e. g. , Times 30
Automated Problem Space to Solution Space Mapping for Configuration Options Model Transformations and Model Checking 31
Mapping Qo. S Intent to Platform Configurations Prioritized service invocations (Qo. S Policy) needs to be mapped to Banded Connection (Qo. S configuration) • Large gap between application Qo. S policies & middleware Qo. S configuration options • Necessary to realize the desired Qo. S policies • Not a straightforward mapping • Requires understanding of middleware configuration space • e. g. , multiple levels of Qo. S 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? 32 32
Solution Approach: Model-Driven Qo. S Mapping • QUality of service p. ICKER (QUICKER) • Allows modeling of application Qo. S policies • Provides automatic mapping of Qo. S policies to configuration options • Allows validating the generated Qo. S options • Automated Qo. S mapping and validation process – can be used iteratively in the design process 33 33
Research Summary Applications Middleware R&D in new, holistic approaches to end-to-end Qo. S management in distributed real-time & embedded systems Research Challenge • Managing problem space variability OS & Protocols Hardware Research Approach Benefits • Model-driven generative approach using separation of concerns • Enhance the state-of-art in MDE and AOSD technologies • Design-time “What-if” • Variety of analysis techniques analysis using including non traditional generative prog mechanisms • Generative technologies for automated analysis • Application of Engineering Mechanics • Deployment-time intelligent decisions • New applications of constraints optimization theory • Middleware specializations • Near optimal deployment • Specialized middleware stacks • Run-time Mechanisms • Multilevel, proactive Qo. S mgmt schemes • Dynamic resource management • Largely autonomic • Survivable systems www. dre. vanderbilt. edu/~gokhale 34
Acknowledgments My research achievements are made possible due to the sponsors (DARPA, NSF, industry); efforts of my students (both primary and co-advisees); working with collaborators; & advise from mentors • DOC Students & Staff • Krishnakumar Balasubramanian • Arvind Krishna • Jaiganesh Balasubramanian • Emre Turkay • Jeff Parsons • Sumant Tambe • James Hill • Akshay Dabholkar • Amogh Kavimandan • Gan Deng • Joe Hoffert • George Edwards • Dimple Kaul • Arundhati Kogekar • Gabriele Trombetti • Collaborations • Christopher Andrews • Theckla Louchios • Dr. Cemal Yilmaz • Dr. Sylvester Fernandez • Dr. Adam Porter • Thomas Damiano • Dr. Sherif Abdelwahed • Dr. Jeff Gray • Dr. Swapna Gokhale • Mentors • Dr. Doug Schmidt • Dr. Janos Sztipanovits • Dr. Gabor Karsai • Dr. Joe Loyall • Dr. Joe Cross 35
Concluding Remarks www. dre. vanderbilt. edu • Significant sources of variability in problem and solution space for managing Qo. S in DRE systems • Multidimensional Qo. S management requires a multistage architecture • • MDE for expressing Qo. S intent and backend analysis Resource allocation to decouple application logic from systemic issues Deployment & configuration tools to automate the mapping Runtime frameworks for dynamic adaptation & resource mgmt • Unresolved Issues: • Automated Qo. S tradeoff analysis • Optimizations for performance/footprint • Dealing with heterogeneity • Dealing with system scale • Unresolved Issues: • Near optimal deployment • Impact of new technologies (multicore) • Applicability to emerging/existing areas • Cyberphysical systems • High performance computing 36
EXTRA SLIDES 37
The Component Behavior Modeling Language Context • Component’s behavior can be classified as: communication & internal actions • Need to define these actions as close as possible to their real counterpart Research Contributions of CBML • Based on the semantics of Input/Output (I/O) Automata • i. e. , contains representative elements • Behavior is specified using a series of action to state transitions • Transitions have preconditions that represent guards & effects have postconditions that determine the new state after an action occurs • Variables are used to store state & can be used within pre & postconditions 38
Domain-Specific Extensions to CBML Context • Some aspects of component-based systems are not first-class entities in I/O automata • e. g. , lifecycle events & monitoring notification events • Extended CBML (without affecting formal semantics) to support domainspecific extensions Domain-Specific Extensions • Environment events – input actions to a environment component that are triggered by the hosting system rather than another component • Periodic events - input actions from the hosting environment that occur periodically 39
Ensuring Scalability of CBML Context • One of the main goals of higherlevel of abstraction is simplicity & ease of use • It is known that one of the main drawbacks of automata languages is scalability Usability Extensions • Composite Action – contains other actions & helps reduce model clutter • Repetitions - determines how many times to repeat an action to prevent duplicate sequential actions • Log Action - an attribute of an Action element that determines if the action should be logged Tool Specific – GME add-on that auto-generates required elements (e. g. , states) 40
The Workload Modeling Language generic action Context • CBML as a standalone language is sufficient enough to capture behavior of a component • For emulation purposes, it does not capture the reusable objects of a component & its workload Research Contributions of WML • Middleware, hardware, platform, & programming language independent DSML • Used to define workload generators (workers) that contains actions to represent realistic operations • Defined using a hierarchical structure that resembles common object-oriented programming packaging techniques that are consistent with conventional component technologies no payload executable actions workload generator 41
Integrating WML Models with CBML Models Context • CBML & WML are standalone DSMLs with a distinct purpose – i. e. , model behavior & workload, respectively • WML is designed to complement CBML by providing CBML with reusable operations that can map to realistic operations Integration Enablers • WML worker elements have same model semantics as variables • WML actions have same modeling semantics as CBML actions • Allows WML elements to be used in CBML models CBML WML action WML 42
Challenge 2: Choosing appropriate values for Qo. S options • Individually configuring components is tedious & error-prone • e. g. , ~140 Qo. S options for MMS mission • Choosing valid values for configuration options inherently doesn’t scale well as size of application increases 43 43
Challenge 3: Validating Qo. S options • Each Qo. S option value chosen has to be validated • Every system reconfiguration (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 Comm component 44 44
Challenge 4: Resolving Qo. S options dependencies(2/2) • Thread. Pool priorities of Comm should match priority bands defined at Gizmo Manually tracking dependencies difficult or in some cases infeasible • Dependent components may belong to more than one assembly • Dependency may span beyond immediate neighbors q • e. g. , dependency between Gizmo and Comm components Empirically validating a change in configuration slows down design process considerably • Several iterations before desired Qo. S is achieved (if at all) 45 45
Enabling Technologies • Enhanced Platform Independent Component Modeling Language (PICML), a DSML for modeling CCM applications • Qo. S Mapping using Graph Rewriting and Transformation (GRe. AT) model transformation tool • Customized Bogor model-checker to define new types and primitives to validate • Qo. S options Uses model interpreters to automate generation of system specification in Bogor 46 46
QUICKER concepts: Transformation 1. Representation of of Qo. S policies(1/2) application Qo. S policies • Platform-independent semantics closely follow application Qo. S requirements • Representation of policies at component- or assembly-level Requirement. Proxy can be per component or assembly instance 2. Representation of Qo. S options • Component Qo. S Modeling Language (CQML) captures CCMspecific Qo. S configuration options 47 47
3. QUICKER concepts: Transformations of Qo. S policies(2/2) Translation of policies into Qo. S options • • Semantic translation rules specified in terms of input (PICML) and output (CQML) type graph QUICKER Transformation engine performs mapping of Qo. S policies (in PICML) to Qo. S configuration options (in CQML) 48 48
QUICKER concepts: Validation of Qo. S options(1/2) 1. Representation of middleware Qo. S options in Bogor • • Bogor extensions allow representing domain-level concepts of system model QUICKER defines new Bogor extension for Qo. S options • Uses Bogor Input Representation (BIR) at a higher level of abstraction q • e. g. , Component, lane, band etc. data types defined in Qo. S extensions Reduces size of the system model by avoiding (redundant) auxiliary variables in specification 49 49
2. QUICKER concepts: Validation of Qo. S options(2/2) Representation of properties (that a system should satisfy) in Bogor • BIR primitives define language • • constructs to access & manipulate domain-level data types Used to define rules that validate options and check if property is satisfied Used to construct dependency structure of components which is needed for validation of connected components 3. Automatic generation of BIR specification from CQML models Rule determines if Thread. Pool priorities at Comm match with priority bands at Analysis 50 50
Скачать презентацию Multidimensional Qo S Management in Distributed Real-time
9c9c0849f9a700c71e1c1aef760eecb9.ppt