Title: Model%20Driven%20Engineering%20for%20QoS%20Management%20in%20Distributed%20Real-time%20
1Model 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
2DOC 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
3Notion 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
4Technology 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
5New 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
6Promising 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
7Technology 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
8DRE 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)
9Our 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
10DRE 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
12Packaging 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
13Packaging 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
14CoSMIC 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
15Example 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)
16Example 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
18Challenge 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
19Challenge 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
20CoSMIC 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
21Applying OCML to CIAOTAO
- Middleware developers specify
- Configuration space
- Constraints
22Applying 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
23Applying 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
25Planning 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
26Example 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
27Modeling 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
29CoSMIC 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
30Resolving 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
31Resolving 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
32The Skoll DCQA System
Skoll Server(s)
Skoll Clients
33Example 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
35RACE 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
36RACE 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
37CUTS 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
38CoWorkEr 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
39Measuring 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
40CUTS BMW Utility
- Dynamic updates of test runs
- Enables viewing of collected data and metrics
41CUTS BMW Observable Metrics
- Test selection based on critical path
- Metrics include best, average, worst case timings
42Observing 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
44Technology 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
45Middleware 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
46Challenge 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!
47Approach 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)
49Structure 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
50Research 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
51Concluding 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
52EXTRA SLIDES