Model%20Driven%20Engineering%20for%20QoS%20Management%20in%20Distributed%20Real-time%20 - PowerPoint PPT Presentation

About This Presentation
Title:

Model%20Driven%20Engineering%20for%20QoS%20Management%20in%20Distributed%20Real-time%20

Description:

Model Driven Engineering for QoS Management in Distributed Realtime – PowerPoint PPT presentation

Number of Views:87
Avg rating:3.0/5.0
Slides: 50
Provided by: Aniruddh7
Category:

less

Transcript and Presenter's Notes

Title: Model%20Driven%20Engineering%20for%20QoS%20Management%20in%20Distributed%20Real-time%20


1
Model Driven Engineering for QoS Management in
Distributed Real-time Embedded Systems
Dr. Aniruddha S. Gokhale a.gokhale_at_vanderbilt.ed
u Assistant Professor, EECS
Presented at Avaya Labs April 14th, 2006
2
DOC Group Research
  • CoSMIC - Modeling Deployment Configuration
    (DC) crosscutting concerns
  • RACE Resource and Control Engine
  • DAnCE Deployment And Configuration Engine
  • CIAO QoS-enabled component middleware

www.dre.vanderbilt.edu
3
Notion of Enterprise Distributed Real-time
Embedded (DRE) Systems
The Past
  • Real-time embedded systems
  • Deeply embedded
  • Resource constrained
  • Fixed and often static operational modes and
    environments

4
Technology Enablers Component Middleware
Write Code That Reuses Code
  • 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


5
New Demands on DRE Systems
  • Key challenges in the problem space
  • Network-centric, dynamic, very large-scale
    systems of systems
  • Stringent simultaneous quality of service (QoS)
    demands
  • Highly diverse complex problem domains

6
Promising Solution Model Driven Engineering
(MDE)
  • Develop, validate, standardize generative
    software technologies that
  • Model
  • Analyze
  • Synthesize
  • 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

ltCONFIGURATION_PASSgt ltHOMEgt ltgt
ltCOMPONENTgt ltIDgt ltgtlt/IDgt
ltEVENT_SUPPLIERgt ltevents this
component suppliesgt lt/EVENT_SUPPLIERgt
lt/COMPONENTgt lt/HOMEgt lt/CONFIGURATION_PAS
Sgt
Goal is not to replace programmers per se it is
to provide higher-level domain-specific languages
for middleware/application developers users
7
Technology Enabler Generic Modeling Environment
(GME)
Write Code That Writes Code That Writes Code!
GME Architecture
COM
COM
GME Editor
ConstraintManager
Browser
Translator(s)
COM
Add-On(s)
Metamodel
GModel
GMeta
XML
UML / OCL
CORE
Paradigm Definition
XML
ODBC
Goal Correct-by-construction DRE systems
www.isis.vanderbilt.edu/Projects/gme/default.htm
8
DRE Lifecycle Stages Affecting QoS
  • Specification Implementation
  • Defining, partitioning, implementing appln
    functionality as standalone components
  • Assembly Packaging
  • Bundling a suite of software binary modules
    metadata representing app components
  • Installation
  • Populating a repository with packages required by
    app
  • Configuration
  • Configuring packages with appropriate parameters
    to satisfy functional systemic requirements of
    an application without constraining to physical
    resources
  • Planning
  • Making deployment decisions to identify nodes in
    target environment where packages will be
    deployed
  • Preparation
  • Moving binaries to identified entities of target
    environment
  • Launching
  • Triggering installed binaries bringing appln to
    ready state
  • QoS Assurance Adaptation
  • Runtime (re)configuration resource management
    to maintain end-to-end QoS

OMG Deployment Configuration (DC)
specification (ptc/05-01-07)
9
Our MDE Solution CoSMIC
  • CoSMIC tools e.g., PICML used to model
    application components
  • Captures the data model of the OMG DC
    specification
  • Synthesis of static deployment plans for DRE
    applications
  • New capabilities being added for QoS provisioning
    (real-time, fault tolerance)

CoSMIC can be downloaded at www.dre.vanderbilt.edu
/cosmic
10
DRE System Example Boeing Bold Stroke
Data Links
Mission Computer
Vehicle Mgmt
Nav Sensors
Radar
Expendable Management
Expendables
11
(I) The Packaging Aspect
  • Application components are bundled together into
    assemblies
  • Several different assemblies tailored towards
    delivering different end-to-end QoS and/or using
    different algorithms can be part of the package
  • e.g., large-scale DRE systems require 100s-1,000s
    of components
  • Packages describing the components assemblies
    can be scripted via XML descriptors

12
Packaging Aspect Problems (1/2)
Ad hoc techniques for ensuring component
syntactic semantic compatibility
Distribution deployment done in ad hoc manner
Ad hoc means to determine event notification
support
13
Packaging Aspect Problems (2/2)
Existing practices involve handcrafting XML
descriptors
lt! Associate components with impls
--gtltcomponentfilesgt ltcomponentfile
idRateGenerator"gt ltfileinarchive
nameHouseRateGen.csd"/gt lt/componentfilegt
ltcomponentfile idHiResGPS"gt
ltfileinarchive nameaGPS.csd"/gt
lt/componentfilegt ltcomponentfile
idcockpitDisplay"gt ltfileinarchive
namenavDisplay-if.csd"/gt lt/componentfilegt
lt/componentfilesgt
XML file in excess of 3,000 lines, even for
medium sized scenarios
Modifications to the assemblies requires
modifying XML file
14
CoSMIC MDE Solution for Packaging Aspect
  • Platform-Independent Component Modeling Language
    (PICML)
  • Developed in Generic Modeling Environment (GME)
  • Core of Component Synthesis using
    Model-Integrated Computing (CoSMIC) toolchain
  • Capture elements dependencies visually
  • Define static semantics using Object Constraint
    Language (OCL)
  • Define dynamic semantics via model interpreters
  • Also used for generating domain specific
    meta-data
  • Correct-by-construction

15
Example Metadata Generated by PICML
  • Component Interface Descriptor (.ccd)
  • Describes the interface, ports, properties of a
    single component
  • Implementation Artifact Descriptor (.iad)
  • Describes the implementation artifacts (e.g.,
    DLLs, OS, etc.) of one component
  • Component Package Descriptor (.cpd)
  • Describes multiple alternative implementations of
    a single component
  • Package Configuration Descriptor (.pcd)
  • Describes a configuration of a component package
  • Top-level Package Descriptor (package.tpd)
  • Describes the top-level component package in a
    package (.cpk)
  • Component Implementation Descriptor (.cid)
  • Describes a specific implementation of a
    component interface
  • Implementation can be either monolithic- or
    assembly-based
  • Contains sub-component instantiations in case of
    assembly based implementations
  • Contains inter-connection information between
    components
  • Component Packages (.cpk)
  • A component package can contain a single
    component
  • A component package can also contain an assembly

Based on OMG (DC) specification (ptc/03-06-03)
16
Example Output from PICML
A Component Implementation Descriptor (.cid) file
ltComponentAssemblyDescription id"a_HUDDisplay"gt .
.. ltconnectiongt ltnamegtGPS-RateGenlt/namegt
ltinternalEndPointgt ltportNamegtRefreshlt/portNa
megt ltinstancegta_GPSlt/instancegt
lt/internalEndPointgt ltinternalEndPointgt
ltportNamegtPulselt/portNamegt
ltinstancegta_RateGenlt/instancegt
lt/internalEndPointgt lt/connectiongt
ltconnectiongt ltnamegtNavDisplay-GPSlt/namegt
ltinternalEndPointgt ltportNamegtRefreshlt/portN
amegt ltinstancegta_NavDisplaylt/instancegt
lt/internalEndPointgt ltinternalEndPointgt
ltportNamegtReadylt/portNamegt
ltinstancegta_GPSlt/instancegt lt/internalEndPointgt
lt/connectiongt ... lt/ComponentAssemblyDescriptio
ngt
  • Describes a specific implementation of a
    component interface
  • Contains inter-connection information between
    components

lt!-Component Implementation Descriptor(.cid)
associates components with impl. artifacts--gt
ltDeploymentComponentImplementationDescriptiongt
ltlabelgtGPS Implementationlt/labelgt
ltUUIDgt154cf3cd-1770-4e92-b19b-8c2c921fea38lt/UUIDgt
ltimplements href"GPS.ccd"/gt
ltmonolithicImplgt ltprimaryArtifactgt
ltnamegtGPS Implementation artifactslt/namegt
ltreferencedArtifact href"GPS.iad"/gt
lt/primaryArtifactgt lt/monolithicImplgt lt/Deploymen
tComponentImplementationDescriptiongt
17
(II) The Multilayer Configuration Aspect
Configuration of components assemblies
  • Component-based software must be configurable at
    many levels
  • e.g., application components containers,
    component servers, middleware services
    infrastructure

Configuration of component server
Configuration of event notifiers
Configuration of component containers
Configuration of the middleware bus
18
Challenge The M/W Bus Configuration
Component middleware is characterized by a large
configuration space that maps known variations in
the application requirements space to known
variations in the middleware solution space
19
Challenge Configuring Container Policies
Determine thread pool sizes how are they shared
number of lanes and their priorities if
borrowing is enabled
Determine various middleware policies for server
objects e.g., security, lifetime, replication
Determine right buffer sizes
Determine end-to-end priority propagation model
to use
Determine the server object management policies
Ensure semantic compatibility among chosen
configurations
  • Existing techniques for metadata configurations
    rely on ad hoc manual configurations e.g., CORBA
    server-side programming
  • This glue code is traditionally handcrafted

20
CoSMIC MDE Solutions for Configuration Aspect
  • Approach
  • Develop an Options Configuration Modeling
    Language (OCML) using GME
  • OCML is used by
  • Middleware developer to design the configuration
    model
  • Application developer to configure the middleware
    for a specific application
  • OCML metamodel is platform-independent
  • OCML models are platform-specific

21
Applying OCML to CIAOTAO
  • Middleware developers specify
  • Configuration space
  • Constraints

22
Applying OCML to CIAOTAO
  • Middleware developers specify
  • Configuration space
  • Constraints
  • Application developers provide a model of desired
    options their values, e.g.,
  • Middleware network resources
  • Concurrency connection management strategies
  • Constraint checker flags incompatible options

23
Applying OCML to CIAOTAO
  • Middleware developers specify
  • Configuration space
  • Constraints
  • Application developers provide a model of desired
    options their values, e.g.,
  • Middleware network resources
  • Concurrency connection management strategies
  • Constraint checker flags incompatible options
  • Synthesizes XML descriptors for middleware
    configuration
  • Generates documentation for the middleware
    configuration
  • Validates the configurations

24
(III) Deployment Planning Aspect
Component integrators must make appropriate
deployment decisions, including identifying the
entities (e.g., CPUs) of the target environment
where the packages will be deployed
Select the appropriate package to deploy on
selected target
Determine current resource allocations on target
platforms
Select appropriate target platform to deploy
packages
25
Planning Aspect Problems
How to ensure a particular deployment
configuration maximizes QoS
How do you correlate QoS requirements of packages
to resource needs
How do you determine current resource allocations?
How do you ensure that the selected targets will
deliver required QoS
26
Example Fault Tolerance Planning
FOU and requirements
  • CoSMIC (PICML) enhancements to represent failover
    units and replication groups
  • capture requirements, such as replication
    degrees, heartbeat intervals, importance,
    replication style, state synchronization
    mechanisms

27
Modeling Shared Risk for FT Planning
system wide risk hierarchy
  • Model shared risk group elements in a system
    e.g., ship comprising regions, data centers,
    shelves, racks and blades
  • Generative programming to synthesize deployment
    plans for FOUs that minimize shared risk (e.g.,
    co-failure probability)

28
(IV) Quality Assurance QoS Validation Aspect
  • Existing Quality Assurance Processes
  • Auto-build scoreboard systems
  • e.g. Mozillas Tinderbox
  • Error reporting based on prepackaged installation
    tests
  • e.g. GNU GCC and ACE TAO
  • Online crash reporting
  • e.g. Netscapes QFA and Microsofts Watson
  • Shortcomings inadequate, opaque, inefficient and
    inflexible QA processes
  • Scope Generally restricted to functional testing
    and often incomplete
  • Documentation No knowledge of what has or hasnt
    undergone QA
  • Control Developers have no control over the QA
    processes
  • Adaptation Cant learning from the earlier test
    results
  • Persistent Challenges
  • Scale
  • Massive configuration optimization space
  • Time to market pressure
  • Rapid updates, frequent releases
  • Heterogeneity
  • Scattered resources distributed developers
  • Incomplete information
  • Unobservable usage context
  • Emerging Opportunities
  • Leverage remote computing resources and network
    ubiquity for distributed, continuous QA

29
CoSMIC MDE Solution for QA Aspect
  • Approach
  • Develop an Benchmark Generation Modeling Language
    (BGML) w/GME
  • BGML provides a model-based toolsuite to
    empirically evaluate refine deployment
    configurations to maximize application QoS
  • Use in conjunction with OCML
  • BGML Workflow
  • End-user composes the scenario in the BGML
    modeling paradigm
  • Associate QoS properties with this scenario, such
    as latency, jitter, or thruput
  • Synthesize the appropriate test code to run the
    experiment measure the QoS
  • Feedback metrics into models to verify if system
    meets appropriate QoS at design time

30
Resolving Planning Challenges with BGML (1/2)
  • Example Scenario
  • Navigation Display displays GPS position
    updates
  • GPS Component generates periodic position
    updates
  • Airframe Component processes input from the GPS
    component and feeds to Navigation display
  • Trigger Component generates periodic refresh
    rates
  • Goal
  • Determine the configuration settings for the
    individual components to achieve the QoS required
    for this scenario

Step1 Model component Interaction using BGML
Step2 Configure each component, associating the
appropriate IDL interfaces
31
Resolving Planning Challenges with BGML (2/2)
Step4 Associate QoS metrics to measure in the
scenario
Step3 Associate operations with the component
ports
void start_time_probe () if (!timer_count)
test_start ACE_OSgethrtime ()
start_timer_probe ACE_OSgethrtime () void
stop_time_probe () finish_timer_probe
ACE_OSgethrtime () history.sample
(finish_timer_probe - start_timer_probe) if
( timer_count niterations)
test_end ACE_OSgethrtime () ACE_DEBUG
((LM_DEBUG, "test finished\n"))
ACE_Throughput_Statsdump_throughput ("Total",
gsf,
test_end - test_start,
stats.samples_count ())
  • BGML tool allows actual composition of the target
    interaction scenario, auto-generates benchmarking
    code
  • Each configuration option can then be tested to
    identify the configuration that maximizes the QoS
    for the scenario
  • These empirically refined configurations can be
    reused across applications that have similar/same
    application domains
  • These configurations can be viewed as
    Configuration Customization (CC) patterns

32
The Skoll DCQA System
Skoll Server(s)
Skoll Clients
33
Example ACETAOCIAO Build Scoreboard
  • Nerve center of quality control
  • www.dre.vanderbilt.edu/ scoreboard
  • Updated by automatic builds
  • 40 builds on 8 OS platforms
  • Many configurations tested
  • Participating machines located at
  • Washington University
  • UC Irvine
  • BBN Technologies
  • Remedy, Netherlands
  • Object Sciences Corps
  • Hunleth.com
  • Riverace Corp
  • ISIS/Vanderbilt
  • PrismTechnologies
  • Object Computing Inc
  • Monitored by the build-czar by all core
    developers

34
(V) Adaptation Resource Management Aspect
CONTEXT
Made feasible using adaptive reflective
middleware
Need to provide runtime QoS adaptation along
functional path
Global, dynamic resource management
35
RACE Control Architecture
  • Static Inputs
  • Resource (CPU) utilization set-point
  • ltarmsCPUset-pointgt 0.8
  • lt/armsCPUset-pointgt
  • End-to-end deadlines
  • ltarmsdeadline units"ms"gt800
  • lt/armsdeadlinegt
  • Dynamic Inputs
  • Current CPU utilization
  • End-to-end execution time

36
RACE Control Architecture
  • Processing
  • RACE Controller
  • Reallocates resources to meet control objectives
  • RACE Control Agent
  • Maps resource reallocation to OS/string specific
    parameters
  • Uses OS string control agents to modify
    OS/string parameters

37
CUTS Environment for Emulating DRE Systems
  • Component Workload Emulator (CoWorkEr)
    Utilization Test Suite (CUTS) consists of a test
    network of CoWorkEr nodes
  • Outside the test network is a Benchmark Data
    Collector (BDC) for collecting test metrics
  • Makeup functionality of a CoWorkEr
  • CCM assembly constructed from CCM monolithic
    components
  • Can perform CPU operations, database operations
    memory allocations deallocations
  • Can perform background workloads
  • Can send/receive events to/from other CoWorkErs
    to form application strings

38
CoWorkEr Behavioral Modeling in CUTS
  • I/O Automata used to model behavior using state
    transitions and actions
  • WML integrates into I/O automata at the action
    level
  • Extends semantics of binding between worker and
    its actions

39
Measuring the Performance of Components
Critical paths can be selected evaluated to
determine if end-to-end QoS deadlines are meet
All data is collected by the Benchmark Data
Collector (BDC) stored in a database for
offline evaluation
Time to transmit an event is measured
Time to process an event is measured
40
CUTS BMW Utility
  • Dynamic updates of test runs
  • Enables viewing of collected data and metrics

41
CUTS BMW Observable Metrics
  • Test selection based on critical path
  • Metrics include best, average, worst case timings

42
Observing RACE Control Behavior
  • Demonstrates increased load due to hog string
  • Web enabled application of RACE to control QoS

43
(VI) Optimizations for Product-line Architectures
Air Frame
FLIR
AP
HUD
GPS
Nav
IFF
  • PLAs define a framework of components that adhere
    to a common architectural style with a clean
    separation of commonalities and appropriate
    provisions for incorporating variations
  • Middleware factors out many reusable
    general-purpose domain-specific services from
    traditional DRE application responsibility

Standards middleware is a key technology
candidate for supporting and sustaining vision of
software product-lines
44
Technology Gaps in Middleware for PLAs
  • PLAs have very focused but crosscutting
    requirements of underlying middleware
    infrastructure
  • Optimized for the platform
  • Lean footprint
  • Efficient configuration deployment
  • Support run-time adaptations reconfigurations
  • Standards middleware development optimizations
    philosophy catered to maintaining generality,
    wide applicability, portability reusability
  • OS, compiler and hardware independent
  • e.g., CORBA, J2EE. .NET
  • These technology gaps are hindering PLA progress
    gt adverse economic and societal consequences
  • e.g. shortcomings of pre-postulated middleware
    Jacobsen 04

Need to tailor and optimize standards middleware
for PLAs while continuing to provide standards
compliance, portability and flexibility
45
Middleware Specialization Catalog
  • Specification-imposed specializations
  • Layer-folding
  • Constant propagation
  • Memoization
  • Framework specializations
  • Aspect Weaving techniques
  • Bridge ?Reactor
  • Template method ? Protocol
  • Strategy ?Messaging, Wait, Demultiplexing
  • Development of reusable specialization patterns
  • Deployment platform specializations
  • Unroll copy loops
  • Use emulated exceptions
  • Leverage zero-copy data transfer buffers
  • Identifying specialization points in middleware
    where patterns are applicable
  • Domain-specific language (DSL) tools process
    for automating the specializations

46
Challenge Lack of Application Context
  • Missed middleware optimization opportunities
  • Without application context
  • Every invocation performs check for locality
  • Middleware glue code for both code paths present
    in all use cases
  • Impossible for middleware (alone) to predict
    application usage

Cannot be solved by operating solely at
middleware level!
47
Approach Supply Application Context w/Models
  • Build a global assembly optimizer framework
  • Use models to capture derive application
    context
  • Explicit, e.g., radar sensor are collocated
    (user-specified)
  • Implicit, e.g., radar sensor are deployed onto
    the same node
  • Example
  • Detect components internal to an assembly
  • Eliminate overhead of
  • Multiple Homes

48
(No Transcript)
49
Structure Spectrum of DSLs
Routine configuration
Creative construction
Wizards
Feature-based configuration
Graph-like language (with user-defined elements)
Subgraph of an (infinite) graph
Path through a decision tree
Subtree of a feature tree
50
Research Impact Future Work
Advanced MDE
Current progress stems from years of iteration,
refinement, successful use
CoSMIC
Model driven middleware
Shape the standards e.g., OMGs Model Driven
Architecture (MDA) for DRE systems
RT/CCM
ACETAO
CORBA Component Model (CCM)
Component Models (EJB)
  • Long-term Research Directions
  • High confidence, geographically distributed DRE
    systems
  • Grid applications
  • Large enterprise systems
  • Greater focus on platform-independent models
  • Heterogeneous systems

Real-time (RT) CORBA
CORBA DCOM
DCE
Micro-kernels
RPC
Internet
1970
2010
2000
2005
Year
51
Concluding Remarks
  • Model-Driven Engineering (MDE) is an important
    emerging generative technology paradigm that
    addresses key lifecycle challenges of DRE
    middleware applications
  • OMG PSIG on Model Integrated Computing

www.omg.org/news/meetings/tc/ agendas/mic.htm
Many hard RD problems with model-driven
engineering remain unresolved!!
  • CoSMIC MDE tools are based on the Generic
    Modeling Environment (GME)
  • CoSMIC is available from www.dre.vanderbilt.edu/co
    smic
  • GME is available from www.isis.vanderbilt.edu/Proj
    ects/gme/default.htm

52
EXTRA SLIDES
Write a Comment
User Comments (0)
About PowerShow.com