RCIM 2008 - - ALaRI

Coordinated Management of Hardware andSoftware Self-adaptivity

What do we need from Reconfigurable Computing?

Onur Derin, Alberto Ferrante, Antonio V. Taddeo

Advanced Learning and Research InstituteFaculty of InformaticsUniversity of Lugano

Lugano, 6900, Switzerland

[email protected]

December 19, 2008

Outline

Introduction

Adaptation ManagementLayered ModelSimulations

Component-based ApproachComponent-based Model at Application LevelComponent-based Model at Hardware Level

Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 2/29

Introduction

What is the aim of this presentation?

provide requirements for a reconfigurable platformto implement our vision of Self-Adaptive Run-timeEnvironment (RTE).

What have we done?

modelling of Self-Adaptive Systems;

management of adaptation at SW and HW level;

enabling self-adaptation at Application level;

enabling self-adaptation at RTE & HW level.

This work was supported by EU-FET AETHER project.


Introduction: Self-Adaptivity

DefinitionSelf-adaptivity is the capability of a system to adapt itselfdynamically to achieve its goals.

Why self-adaptation?

Changing internal and/or external conditionse.g. moving with a portable device between wired and wirelessnetworks, switching to battery power

Increasing complexity of systems and difficulties in integration(self-organization - specification tradeoff principle Buchli andSantini [2005])

Some information is available only at run-time (applicationspecific vs. general purpose)


Monitor-Controller-Adaptor Paradigm

AdaptationSpace

Controller

Self-adaptive system

MonitorableSpace

Goals

A goal is a boolean expression

with terms from monitorable

space.

e.g. different implementations-

parameters, available cores, available

HW functional units, clock frequency

e.g. frame size, resource utilization,

cache miss rate, power consumption


Quality measures for a self-adaptive system

Adaptation coverageHow big is the adaptation space?

Separation of concernsIs the application programmer concerned with self-adaptivityaspects?

Adaptation managementHow good is the controller?

Adaptation requirements (goal) specificationHow big is the monitorable space? How are goals specified?


Layered Model

ASApplication

ASRun−timeEnvironment

ASHardware

Controller


MSApplication

MSRun−timeEnvironment

MSHardware

Goals



space.







Layered Model

ASApplication

ASRun−timeEnvironment

ASHardware

CApplication

CRun−timeEnvironment

CHardware


MSApplication

MSRun−timeEnvironment

MSHardware

Goals



space.







Layered Model

Resource Manager

Hardware Abstraction Layer

Resource Allocator

RTE level

RTE-SW Interface

RTE-HW Interface

Application level

SW-RTE Interface

Hardware level

HW-RTE Interface Self-*

Self-*

Goal achievement+tasks Results

Goals+tasks + recommendations

Results + monitored parameters

Component Repository Component Framework

Component-based Application

Self-*

Recommender

Goals

application level self-adaptivitywill be mentioned in the nextsection.

RTE adapts concurrency(resource allocator) andmapping (HAL).

Goals as lower/upper bounds orMin/Max.


Evaluation of the model

covers self-adaptation at application, RTE and HW level

separates functionality from adaptation concern

simple decentralized controllers coordinated with arecommendation mechanism

goals are externalized, made explicit and have to be specifiedby the application programmer


Simulation: A self-adaptation example

Given a system with

adaptation space

AS = ASApplication × ASRTE × ASHardware such thatASApplication = {Impl1, Impl2} and that Impl2 yields higherthroughput on a reference architectureASRTE = {} (no concurrency adaptation or dynamic mapping!)ASHardware = {flow , fhigh}

monitorable space

MSApplication = {throughput}MSRTE = {}MSHardware = {power}

goals

mTh > mTTh

mP < mTP


Simulation Model

Application-level Controller

Hardware Controller

Adaptable/Monitorable System

clock frequency

algorithm implementation

power

throughput


Simulation Model

Application-level Controller

RTE Controller (Recommender)

Hardware Controller

Adaptable/Monitorable System

rec. activation goal achievement

recommendation

clock frequency

algorithm implementation

power

throughput


Controller 1

Impl1

start

Impl2

mTh < mTTh

mTh > mTTh

mTh > mTTh

mTh < mTTh

App. Controller

flow fhigh

start

mP < mTP

mP > mTP

mP > mTP

mP < mTP

HW Controller


Simulation Results (Controller 1)

flow

fhigh

0 20 40 60 80 100 120 140 160 180 200

freq

uenc

y

time (unit)

HW controller

HW adaptation

Impl1

Impl2

0 20 40 60 80 100 120 140 160 180 200

impl

emen

tatio

n

time (unit)

App. controller

App. adaptation

mPT

0 20 40 60 80 100 120 140 160 180 200

pow

er

time (unit)

System Power (mP)

mThT

0 20 40 60 80 100 120 140 160 180 200

thro

ughp

ut

time (unit)

System Throughput (mTh)


Controller 2

Impl1

start

Impl2

mTh < mTTh

mTh > mTTh

App. Controller

flow fhigh

startmP > mT

P

mP < mTP

HW Controller


Simulation Results (Controller 2)

flow

fhigh

0 20 40 60 80 100 120 140 160 180 200

freq

uenc

y

time (unit)

HW controller

w/ recommendationw/o recommendation

Impl1

Impl2

0 20 40 60 80 100 120 140 160 180 200

impl

emen

tatio

n

time (unit)

App. controller


mPT

0 20 40 60 80 100 120 140 160 180 200

pow

er

time (unit)

System Power (mP)


mThT

0 20 40 60 80 100 120 140 160 180 200

thro

ughp

ut

time (unit)

System Throughput (mTh)



Introduction: Component-based Design

Main enabler for SW-RTE-HW adaptation is a component-basedapproach.

DefinitionA component is a self-contained element which encapsulates aspecification of a functionality, with well-defined interfaces tointeract with other components.

DefinitionA component model specifies a formalism to design a component.It defines inputs/outputs and component usage.

DefinitionA component framework manages components by instantiatingand composing them.


Enabling Self-adaptivity at Application Level

Resource Manager

Hardware Abstraction Layer

Resource Allocator

RTE level

RTE-SW Interface

RTE-HW Interface

Application level

SW-RTE Interface

Hardware level

HW-RTE Interface Self-*

Self-*

Goal achievement+tasks Results

Goals+tasks + recommendations

Results + monitored parameters

Component Repository Component Framework

Component-based Application

Self-*

Recommender

GoalsComponent Framework

run-time system that implements theglue logic in compliance with thecomponent model

Component model

defines the standard interfacesbetween components

This model

allows the framework to beaware of the run-timecharacteristics of softwarecomponents

thus separation of concernsTaddeo, ALaRI RCIM 2008— Self-adaptive Systems, 17/29

New application development flow

Design time

extend component run-time system with an adaptation loopand adaptation skills (next slide)create adaptable (parameterized or compliant) versions of thecomponents in the component repository

Given a component graph and application goals

Run-time

parse goalsreplace components with their adaptable versionshook up relevant monitoring componentsinstatiate the controller


Possible adaptations at Application Level

Parameter adaptation of a component Ci (pi )⇒ Ci (pj)

Structural adaptation

Replacement of a component Ci ⇒ Cj

Parallelization of a component Ci ⇒ {Cij}Transformation with adaptation patterns for high level goalssuch as dependability and securityGi{C} ⇒ Gj{C ′}


Case Study: A self-adaptive video streaming server

Adapter

Monitor

Controller

Monitor Controller Recomm.

Recommendationsfor HW level

Adapter

Monitor

Controller

Video streaming server Hardware

Hardware levelApplication level

Clock frequency, Voltage level

Power

Picture size, Quality level

Latency

GoalFPS > FPST ⇒ Latency < 1

FPST and FrameSize < BandwidthFPST

Adaptation & Monitoring Space

ASApplication = {PictureSize, EncodingQuality}MSApplication = {Latency}


GStreamer

a library for constructing of graphs of media-handlingcomponents i.e. software component framework

already ported to N800

extendible

An Ogg player

gst-launch filesrc location="test.ogg" ! oggdemux name=d

d. ! queue ! theoradec ! ffmpegcolorspace ! ximagesink

d. ! queue ! vorbisdec ! audioconvert ! audioresample ! osssink


Enabling SW-RTE-HW Self-Adaptation

Provide a unified view of SW and HW components

extend the RTE with a component middleware in order tomanage software and hardware components.enable adaptation capabilities with a mix of HW and SWcomponents (e.g. replacement of a SW component with a HWcomponent)

Case study

Create gstreamer components that use the DSP processor ofN800 (already done by TI)

Implement transparent migration of a software componentbetween ARM and DSP processors (of N800)


What do we need from Reconfigurable Computing?

What does the component middleware needfrom the reconfigurable platform?


HW component abstraction

What is a hardware component for our Middleware point ofview?

it can have different size;

it should implement a specific functionality(e.g. FFT);

it should be compliant to the component model;

it should be manageable by the component framework.

What is reconfigurable? (i.e. adaptation skills)

The component itself!

The component interactions (e.g. topology).


HW component: adaptation

How is the HW component adaptation by Middlewareperformed?

Instantiation of components.Component-Create("FFT");

Adaptation of high level component interactions.Component-Connection("FFT", ...);

Requirements:

The reconfigurable platform should allow these ”services”.


HW component: placement

The role of the Middleware

The Middleware is not responsible of component placement.

The Middleware considers HW components as resources touse.

The role of the Reconfigurable Platform (?)

Efficient use of fabric.

Garbage Collector.

De-fragmentation.


Conclusion

Proposed a model for self-adaptive systems that features

decentralized controllers and a recommendation mechanism tocoordinate adaptation management;HW-SW adaptation coverage;separation of self-adaptivity concerns from functionality;goal specification interface.

Proposed a flow to implement self-adaptive applications basedon component technologies.

Tried to identify the requirements for a reconfigurableplatform to implement our Self-Adaptive RTE.

Self-adaptivity and component-based approach works welltogether

self-adaptivity enables satisfying NFRs.component-based approach enables self-adaptivity by providingan adaptation space.


Publications

A. Ferrante, A. V. Taddeo, O. Derin. Security in self-adaptivesystems. presented in 1st AETHER-Morpheus Workshop(AMWAS’07), Paris, October 2007.

O. Derin, A. Ferrante, A. V. Taddeo. Coordinated management ofhardware and software self-adaptivity. Journal of SystemArchitecture, doi:10.1016/j.sysarc.2008.07.002, July 2008.

O. Derin, A. Ferrante. Enabling self-adaptivity at application level.presented in 2nd AETHER-Morpheus Workshop (AMWAS’08),Lugano, October 2008.

A. Ferrante, A. V. Taddeo, M. Sami, F. Mantovani, J. FridkinsSelf-adaptive Security at Application Level: a Proposal.presented in ReCoSoC 2007, Montpellier, France, Jun. 2007.


References I

J. Buchli and C.C. Santini. Complexity Engineering: HarnessingEmergent Phenomena as Opportunities for Engineering. InReports of the Santa Fe Institute’s Complex Systems SummerSchool 2005. Santa Fe Institute, 2005.


Technology

RCIM 2008 - - ALaRI