acomponent-basedqos architecturefor...

France Télécom R&D ARTIST2 – 01/24/2005

A Component-Based QoSArchitecture forEmbedded Systems

Jean-Charles TournierFrance Télé[email protected]

Jean-Philippe Babau CITI / INSA [email protected]

ARTIST 2 - Component Modelling and Composition

Paris, January 24th 2005

France Télécom R&D ARTIST2 - 01/24/2005 2

Context - 1/2

� Mobile embedded systems� Today

�Complex features�QoS constraints (real-time, safety, etc.)�Limited resources (CPU, memory, battery, etc.)�lead to dedicated, closed and monolithic systems

� Tomorrow: need for flexible systems�Dynamicity

–Add or remove applications on the fly

�Opening–Heterogeneous communication networks(GSM,GRPS, Bluetooth, etc.)


Context - 2/2

� Component Based Software Engineering (CBSE)� An easier way to build complex software by assembling, composingsoftware entities called components

� CBSE provides

� Adaptability� Reusability� Scalability

� Component frameworks (Think, OS-Kit, Coyote)� Provide composition of components from a functional point of view� But, no support for QoS management


Objectives

� Dynamically manage QoS constraints in component-basedsystems

� Define a QoS architecture� Open

�Independent of QoS management policies, Qos mechanisms and Qosspecifications

� Component-based� Supporting dynamic QoS management


Overview

�Our view of components

�Main QoS concepts

�Qinna

�Experiment

�Analysis

�Conclusions


CBSE - The Fractal Component Model

� Component� Run-time entity� Made of a content and a controller

� Content� Composed of a finite number of other components (recursive)� Under the control of the controller

� Controller� Reflexivity� E.g. Life-cycle, configuration, etc.

� Interface� Unique access points� Client or server

� Binding� Oriented connection between two components

�From a client interface to a server interface (type compatibility)

� Primitive or composite (component+binding)


CBSE - Fractal

� API� Life-Cycle, Reflexivity (BindingController and ContentController),Instanciation (Factory)

� ADL� A language for defining Fractal architectures (configuration)� A modular and an open (extensible) language to describe

�Components, interfaces and bindings�Attributes�Typing�Implementations�Deployment�Behaviour and QoS contracts�…


CBSE - The Think Framework

� Think� Framework for component-based operating systems� Conforms to the Fractal model� Everything is components

�Fine grain control over resources

� Two kinds of components� Hardware Abstraction Components

�Boot, exceptions, MMU, device drivers (screen, keyboard, serial port,…), etc.

� OS Services Components�Thread, scheduler (RR, priority, EDF,…), Network (Ethernet, IP, TCP,…), etc.

� Ported on ARM (Intel StrongARM, Intel xScale, Portal Player, Motorola Dragon Ball MX1),Intel x86, Hitachi H8 (Lego RCX)

� Provides a complete tools chain� ADL and IDL parsers, component compiler, etc.


Quality of Service architecture

GOOD

Performance

HIGH

Importance

GOODAVERAGEBAD

Adaptation

Specification

GOOD=25 f/sec{6,10} EDF80Kb Mem

Mapping

Sched_anal({6,10})

?

AdmissionTesting

set_prio({6,10})

Reservation

Initialization

25 f/sec?

Observation

improve_resssource()

Maintenance

degrade_toAVERAGE

Adaptation

Management

Concepts


Qinna

� A Component-Based QoS Architecture� Capturing the main QoS concepts� Generic� Dynamic� Reusable

� Qinna defines� A set of APIs� Component types� Data types� Inter-component relationships� Dynamic behavior


Qinna - QoSComponent

� Definition� Provides functional interfaces with QoS management needs

� Detail

QoSComponent

Local_Ct:T_CLFunc_Itf

(1..N)

Func_Itf

(0..N)

iLocalConstraint(1)

iQoSObserver(1)


Qinna - QoSComponentBroker

� Definition� Provides a QoSComponent with a fixed local constraint� Responsible for the admission testing and reservation for a class ofQoSComponents

� Detail

QoSComponentBroker

Global_Ct:T_CGiBrokerAdministration

(1)

iLocalConstraint

(0..N)

iQoSBroker(1)


Qinna - QoSComponentManager

� Definition� Initializes a QoSComponent from a QoS point of view� Implements initialization, maintenance and adaptation mechanisms for aclass of QoSComponents

� Detail

QoSComponentManager

Map_table:T_MTContracts:T_CT_MANAGER

iManagerAdministration

(1)

iQoSBroker (1)

iQoSManager(1)

iQoSManager (0..N)

iQoSAdapter(1)

iQoSMaintener(1)


Qinna - QoSComponentObserver

� Definition� Implements observation policy for a class of QoSComponents

� Detail

QoSComponentObserveriQoSObserverException (1)

iQoSObserverLifeCycle (1)iQoSObserver (1..N)


Qinna - QoSDomain

� Definition� Encapsulates all Qinna components� Implements adaptation and maintenance policies based on importancelevel

� Detail

QoSDomain

Contracts:T_CT_DOMAIN

iQoSDomain

(1..N)

iQoSAdapter (0..N)

iQoSObserverException(0..N)

iQoSManager (1..N)

iQoSMaintener (0..N)

iQoSObserverLifeCycle(0..N)


Qinna - Overview

QoSDomain

QoSComponentManager

QoSComponentBroker

QoSComponent1..N

1

1

1..N

11

QoSComponentObserver0..N

1

1..N

11

0..N

Functional services

Admission testingReservation

Management mechanisms(initialization,adaptation,maintenance)

Management policies(adaptation,maintenance)

Observationpolicy


Experiment

DOOM

Video

Threads

Memory

EDF

GUI

{4,20}

{4,10}

Thread QoS Level

40BAD

60GOOD

Memory QoSLevel (kb)

Video QoS Level

30{7,15}AVERAGE

{7,20}

{7,10}

Thread QoS Level

20BAD

50GOOD

Memory QoS Level(kb)

Doom QoS Level


Experiment - Qinna integration

QoSDoom

QoSDoomBroker

QoSDoomManager

QoSThread

QoSThreadBroker

QoSThreadManager

QoSEDF

QoSEDFBroker

QoSEDFManager

QoSVideo

QoSVideoBroker

QoSVideoManager

QoSDomain

GUI

Reserve(GOOD, LOW)

Reserve(GOOD)

Reserve(GOOD)

set(GOOD)

Map(GOOD):Thread={7,10}Mem=50KbDOOM=GOOD

Reserve( {7,10}) Reserve({7,10})Map({7,10}):Sched={7,10}Thread=given by

QoSEDF

Map({7,10}:Sched={7,10}

QoSThread


Analysis

� Dynamicity� Allows dynamic QoS management� Dynamic evaluation of QoS parameters� Allows dynamic architecture reconfiguration

� Reusability� Component-based� Separation policy/mechanism

� Genericity� Non QoS policy/mechanism/specification specific� Each component has its own QoS mechanisms� Management of heterogeneous QoS (real-time and non real-time)

� Real-time aspects� Admission testing can be omitted (hard real-time)� Performance depends on the implementation (avoid multiple admission testing)� Adaptation occurs in soft real-time


Conclusion

� Summary� Qinna: component-based QoS architecture� Some preliminary experiments including various QoS mechanisms, QoSpolicies and QoS specifications

� Benefits� Dynamicity� Reusability� Genericity

� Future work� Integrate complex QoS management policies� Quantitative evaluation (LOC, memory, delay overhead, etc.)� Supporting tools

acomponent-basedqos architecturefor...

Documents