Institute for Software Integrated SystemsVanderbilt University

Generators for Synthesis of QoS Adaptation in

Distributed Real-time Embedded Systems

Sandeep Neema, Ted Bapty, Aniruddha Gokhale

Institute for Software Integrated Systems, Vanderbilt University

Jeff GrayUniversity of Alabama, Birmingham

http://www.isis.vanderbilt.edu/projects/pces

GPCE-02, Pittsburgh, PA, October 6-8, 2002

Roadmap

• Model Integrated Computing (MIC)• Motivation• Adaptive QoS Modeling Language

(AQML)• Simulation of QoS adaptation• Synthesis of QoS adaptation• Conclusions/Future Work

Model Integrated Computing (MIC)

Resulting from 15 years of research on computer-based embedded systems in aerospace, instrumentation, manufacturing and robotics.

Common challenges:• “Software” and “environment” are inseparable• Need for adaptability to changing environment

and end-user needs• Complex, heterogeneous applications• Stringent reliability and dependability requirements

Model Integrated Computing (MIC)

• Represent the information that directly orindirectly determines the structure of computationsusing domain-specific modeling paradigms

• Capture the relationship between domain models,analysis models and executable models

• Validate, analyze the domain models using generic tools

• Synthesize computations from the domain models

DSME

Model Interpreters

Models

DSDE

ModelInterpretation

ApplicationDomain

App.1

App.2

App.3

Meta-Level

Translation

Meta-modelingInterface

Formal Specifications

Application Evolution

Environment Evolution

MultiGraph Architecture

DSDE: Domain-Specific Design EnvironmentsDSME: Domain-Specific Modeling Environments

Generic Modeling Environment (GME)

http://www.isis.vanderbilt.edu/Projects/gme/default.html

Meta-modeling Environment

Domain-specific Modeling Environment

Roadmap

• Model Integrated Computing (MIC)• Motivation• Adaptive QoS Modeling Language

(AQML)• Simulation of QoS adaptation• Synthesis of QoS adaptation• Conclusions/Future Work

Motivation• RT Middleware solutions enable highly-complex

Distributed Real-time Embedded (DRE) systems• QoS adaptive frameworks (QuO*) enable abstraction

of QoS parameters and QoS adaptation• Low-level of abstraction for specification of

adaptation– Difficult to validate/verify

• System behavior not apparent in specification of adaptation– QoS adaptation software is equivalent to a discrete controller

for a highly non-linear system– Could result in instability– Need to simulate/verify

• Need: Specifications of behavior separated from software concerns

*QuO: Quality Objects (BBN Tech.)

QoS Adaptation: A Control Systems Perspective

QuOContract

ApplicationMiddleware

OS-sHardware+Network

AAAA

SSSS

SysConds

desired QoS error

observed QoS

+–

Plant

Feedback

Controller

MIC Approach

Adaptive QoS Modeling Language(AQML)

Matlab Simulink/Stateflow Simulation

Symbolic Model Verifier (SMV) Model CheckingBBN Contract Definition Language

End-users model their systems in

AQML

1

2Simulations are generated from

models

G G G

G = Generator/Model Interpreter

3Inputs for model

checkers is generated

4CDL output is

generated when simulation and model checking

results are satisfactory

5 QoS adaptive DRE system is deployed

Roadmap

• Model Integrated Computing (MIC)• Motivation• Adaptive QoS Modeling Language

(AQML)– Adaptive Behavior, Computation,

Middleware

• Simulation of QoS adaptation• Synthesis of QoS adaptation• Conclusions/Future Work

Adaptive Quality Modeling Language (AQML)

QoS Adaptation Modeling• Hierarchical, parallel, finite state machine representation• States capture system-wide QoS configurations• Transitions represent cause and effect of change in operating conditions• Data/Event variables represent the interface to the operating environment

Adaptive Quality Modeling Language (AQML) (2)

Computation Modeling• Hierarchical dataflow representation

– Compounds, primitives

• Parameters for component instrumentation and customization

Adaptive Quality Modeling Language (AQML) (3)

Middleware Modeling• Services and system condition objects• Parameters for middleware instrumentation and customization

Adaptive Quality Modeling Language (AQML) (4)

Interaction Modeling• Interaction of controller (adaptation state-machine) with

sensors/actuators (parameters in middleware/computation modeling), captured with Control connection

• References for cross-hierarchy connection

AQML Example ModelCase Study

• Dataflow model of the UAV video-streaming application

• Sender, Distributor, and Receiver, distributed application components

• ActualFrameRate, TimeInRegion, … middleware syscond (parameter) objects

• ResvWithDropping reference the adaptation behavior

AQML Example Model (2)Case Study

• NormalLoad, HighLoad, and ExcessLoad states within the QoS parameter space

• actualFrameRate, frameRate, … data variables within state machine interface with the syscond objects

• Duty, Test sub-states of HighLoad state

• Transition from duty to test enabled when time in duty exceeds 30 ticks

• frameRate variable set to 30 when transitioning from duty to test state

Roadmap

• Model Integrated Computing (MIC)• Motivation• Adaptive QoS Modeling Language

(AQML)• Simulation of QoS adaptation• Synthesis of QoS adaptation• Conclusions/Future Work

Simulation of QoS adaptation

• Matlab® Simulink®/Stateflow® used as the simulation engine• Model interpreters generate Matlab M-code to construct

Simulink/Stateflow representation• User provides a network simulation (plant) model, that can simulate

various load conditions in the network

AQML ModelMatlab M-file

G

Plant model Simulation results

Controller model

Simulation Generator

• Stateflow represents hierarchy through graphical containment on a single diagram

• bounding rectangle of a sub-state is enclosed by the bounding rectangle of a super-state

• Phase 1: traverses the AQML model-object hierarchy to compute the bounding rectangles for states

• Phase 2: traverses the AQML model-object hierarchy, and emits Matlab M-script code to construct Stateflow objects using the Matlab-Stateflow API

Generated M-script% Matlab script for creation of a Stateflow Model % generated: Friday, October 04, 2002

sfnew('UAV'); root = sfroot; mach = root.find('-isa', 'Stateflow.Machine'); chart = mach.find('-isa', 'Stateflow.Chart'); chart.Name = 'Controller'; set_param(gcbh,'Position',[120 40 300 160]);

% create states s0 = Stateflow.State(chart); s0.Name = 'ResvWithDropping'; s0.LabelString = 'ResvWithDropping'; s0.Decomposition = 'EXCLUSIVE_OR'; s0.Position = [0 0 490 440]; s1 = Stateflow.State(chart); s1.Name = 'NoReservation'; s1.LabelString = 'NoReservation'; s1.Decomposition = 'EXCLUSIVE_OR'; s1.Position = [20 40 450 280];

% create transitions t = Stateflow.Transition(chart); t.Source = s4; t.Destination = s5; l = sprintf('%s\n%s','[timeInRegion >= 30]/frameRate=30','timeInRegion_w=0'); t.LabelString = l; t.SourceOClock = 9; t.DestinationOClock = 9; t.MidPoint = [151 190];…

% create data d = Stateflow.Data(chart); d.Name = 'frameRate'; d.DataType = 'int32'; d.Scope = 'OUTPUT_DATA'; d.Name = 'actualFrameRate'; d.DataType = 'int32'; d.Scope = 'INPUT_DATA';…

Matlab-Simulink Models

Simulation Results

• Results depicts variation in the desired frame rate and the actual frame rate observed on the simulated network

• Results are obtained against a simulated sinusoidal loading profile on the network• Results can be used to fine-tune the adaptation policy against different loading

profiles (bursty, sharp transients, gradual persistent, …)• Benefit Rapid prototyping and visualization of the responsiveness and behavior

of the QoS adaptation policy

Desired frame rate Actual frame rate

Roadmap

• Model Integrated Computing (MIC)• Motivation• Adaptive QoS Modeling Language

(AQML)• Simulation of QoS adaptation• Synthesis of QoS adaptation• Conclusions/Future Work

QuO Contract Generation

• AQME models translated to QuO contracts represented in Contract Definition Language (CDL)

UAV Model

G

QuO Contract (CDL)

BBNQuoGen .CPP

.H

.CPP

.H

Target Appl./MW

Quo Contract (CDL) Generator

• CDL Contracts are expressed in flat finite-state machine like representation– Guards, and actions in transitions are method calls

over middleware objects

• Phase 1: translates the hierarchical parallel FSM representation to a flat FSM representation

• Phase 2: traverses the flattened FSM object-graph and emits CDL code– parse guards, triggers, and action expressions, – traverse Abstract Syntax Tree, and emit code– for any reference to a data or event variable in the

expression, emit the get/set method call on the middleware object

Case Study: CDLcontract UAVsplitContract ( callback UAVCallbacks::Sender_Control_Callback senderControl, syscond nowatch quo::ValueSC quo_sc::ValueSCImpl currentRegion, syscond nowatch quo::ValueSC quo_sc::ValueSCImpl

negotiatedFrameRate, syscond nowatch quo::ValueSC quo_sc::ValueSCImpl actualFrameRate, syscond quo::ValueSC quo_sc::ValueSCImpl timeInRegion ){ state state_6 ( (((long) timeInRegion ) >= 3) -> state_5, (((long) actualFrameRate ) < 27 and ((long) actualFrameRate ) >= 8) ->

state_3, (((long) actualFrameRate ) >= 27) -> state_2 ) { }…transition state_5 -> state_6 { synchronous { senderControl.setFrameRate( 10 ); negotiatedFrameRate.longValue( 10 ); timeInRegion.longValue( 0 ); } }…};

• Complex CDL contract synthesized from models

• CDL output is post-processed by the BBN QuoGen compiler to generate code for the BBN QuO adaptation framework

• Generated Adaptation code monitors the QoS state of the distributed real-time system, and execute transitions and actions to bring the system in a desired operational state

Roadmap

• Model Integrated Computing (MIC)• Motivation• Adaptive QoS Modeling Language

(AQML)• Simulation of QoS adaptation• Synthesis of QoS adaptation• Conclusions/Future Work

Conclusions

• MIC enables better design and synthesis of highly complex QoS adaptation contracts by providing a domain-specific, higher level of abstraction

• The approach shortens the design, implement, test, and iterate cycle by providing early simulation, and analysis capabilities

• The approach facilitates change maintenance and evolution as minimal changes in the models effect large changes in the low-level (textual, code-base) CDL specification

Future Work

• Investigating results from control-theory for synthesizing adaptation behaviors

• Extending the QoS adaptation modeling from a single centralized adaptation strategy, to several distributed local adaptation strategies, and their coordination and synchronization

• Enhancement of the middleware and dataflow modeling aspects of the AQME

Extra Slides

Conceptual structure

12/15/97

Components

Domain Modeling

Mapping/Synthesis

Integration Platform

Development Platform

Typical System Development

Simulation and/or analysis data

Synthesis

Domain-specific software apps

Configuration scripts

End-users Specify their systems

Applications

Specs, Drawings,Diagrams, Equations

etc.

Programmers Implement Code

Specifications

The MultiGraph Solution

Simulation and/or analysis data

Domain-specific software apps

Configuration scripts

Application Evolution

Graphical Modeling Environment

End-users model their

systems

Model Interpreter

Applications

Specifications

Synthesis

MIC Approach

• Creation of a Domain-Specific Modeling Language – QoS Adaptive Behavior– Middleware Interfaces– Application QoS parameters

• Generation of QoS adaptation code– Contract Definition Language (CDL) output

• Generation of Simulations– Verify behavior over points in the envelope of

operation, using same models

• Analysis of system– Model Checking over full operational envelope, using

same models

Adaptive QoS Modeling Environment (AQME)

• QoS Specification and Adaptation modeling– Hierarchical, parallel, finite

state machine representation– States capture system-wide

QoS configurations– Transitions represent cause

and effect of change in operating conditions

– Data/Event variables represent the interface to the operating environment

Adaptive QoS Modeling Environment (AQME)

• Software modeling– Hierarchical dataflow

representation• Compounds, primitives

– Parameters for component instrumentation and customization

• Middleware modeling– Services and system

condition objects– Parameters for

middleware instrumentation and customization