1. Coordinated Management of Hardware and
Software Self-adaptivity
What do we need from Reconfigurable Computing?
Onur Derin, Alberto Ferrante, Antonio V. Taddeo
Advanced Learning and Research Institute
Faculty of Informatics
University of Lugano
Lugano, 6900, Switzerland
name.surname@alari.ch
December 19, 2008

2. Outline
Introduction
Adaptation Management
Layered Model
Simulations
Component-based Approach
Component-based Model at Application Level
Component-based Model at Hardware Level
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 2/29

3. Introduction
What is the aim of this presentation?
provide requirements for a reconfigurable platform
to implement our vision of Self-Adaptive Run-time
Environment (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.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 3/29

4. Introduction: Self-Adaptivity
Definition
Self-adaptivity is the capability of a system to adapt itself
dynamically to achieve its goals.
Why self-adaptation?
Changing internal and/or external conditions
e.g. moving with a portable device between wired and wireless
networks, switching to battery power
Increasing complexity of systems and difficulties in integration
(self-organization - specification tradeoff principle Buchli and
Santini [2005])
Some information is available only at run-time (application
specific vs. general purpose)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 4/29

5. Monitor-Controller-Adaptor Paradigm
A goal is a boolean expression
Goals with terms from monitorable
space.
Self-adaptive system
Controller
Adaptation Monitorable
Space Space
e.g. different implementations-
e.g. frame size, resource utilization,
parameters, available cores, available
cache miss rate, power consumption
HW functional units, clock frequency
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 5/29

6. Quality measures for a self-adaptive system
Adaptation coverage
How big is the adaptation space?
Separation of concerns
Is the application programmer concerned with self-adaptivity
aspects?
Adaptation management
How good is the controller?
Adaptation requirements (goal) specification
How big is the monitorable space? How are goals specified?
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 6/29

7. Layered Model
A goal is a boolean expression
Goals with terms from monitorable
Self-adaptive system
space.
Controller
ASApplication MSApplication
ASRun−timeEnvironment MSRun−timeEnvironment
ASHardware MSHardware
e.g. different implementations-
e.g. frame size, resource utilization,
parameters, available cores, available
cache miss rate, power consumption
HW functional units, clock frequency
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 7/29

8. Layered Model
A goal is a boolean expression
Goals with terms from monitorable
Self-adaptive system
space.
CApplication
CRun−timeEnvironment
CHardware
ASApplication MSApplication
ASRun−timeEnvironment MSRun−timeEnvironment
ASHardware MSHardware
e.g. different implementations-
e.g. frame size, resource utilization,
parameters, available cores, available
cache miss rate, power consumption
HW functional units, clock frequency
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 7/29

9. Layered Model
Application level
Component-based Application Goals
Component Repository Component Framework Self-*
SW-RTE Interface
application level self-adaptivity
Results
Goal achievement+tasks
will be mentioned in the next
RTE level
section.
RTE-SW Interface
RTE adapts concurrency
Resource Manager
(resource allocator) and
Self-*
Resource Allocator
mapping (HAL).
Hardware Abstraction Layer
Recommender
Goals as lower/upper bounds or
Min/Max.
RTE-HW Interface
Goals+tasks + Results +
recommendations monitored parameters
Hardware level
Self-*
HW-RTE Interface
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 8/29

10. Evaluation of the model
covers self-adaptation at application, RTE and HW level
separates functionality from adaptation concern
simple decentralized controllers coordinated with a
recommendation mechanism
goals are externalized, made explicit and have to be specified
by the application programmer
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 9/29

11. Simulation: A self-adaptation example
Given a system with
adaptation space
AS = ASApplication × ASRTE × ASHardware such that
ASApplication = {Impl1 , Impl2 } and that Impl2 yields higher
throughput on a reference architecture
ASRTE = {} (no concurrency adaptation or dynamic mapping!)
ASHardware = {flow , fhigh }
monitorable space
goals
MSApplication = {throughput} T
mTh > mTh
MSRTE = {} T
mP < mP
MSHardware = {power }
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 10/29

12. Simulation Model
Application-level Controller
algorithm implementation throughput
Hardware Controller
power
clock frequency
Adaptable/Monitorable System
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 11/29

13. Simulation Model
Application-level Controller
goal achievement
rec. activation
RTE Controller (Recommender)
algorithm implementation throughput
recommendation
Hardware Controller
power
clock frequency
Adaptable/Monitorable System
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 11/29

14. Controller 1
start T
mTh > mTh
App. Controller
T T
Impl1 Impl2
mTh > mTh mTh < mTh
T
mTh < mTh
start
T
mP > mP
HW Controller
T T
fhigh
flow
mP > mP mP < mP
T
mP < mP
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 12/29

15. Simulation Results (Controller 1)
System Power (mP)
HW controller
HW adaptation
fhigh
frequency
power
mPT
flow
0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200
time (unit) time (unit)
System Throughput (mTh)
App. controller
App. adaptation
implementation
Impl2
throughput
mThT
Impl1
0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200
time (unit) time (unit)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 13/29

16. Controller 2
start
App. Controller
T Impl1 Impl2
mTh > mTh
T
mTh < mTh
start
T
mP > mP
HW Controller
T
fhigh
flow mP < mP
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 14/29

17. Simulation Results (Controller 2)
System Power (mP)
HW controller
w/ recommendation w/ recommendation
w/o recommendation w/o recommendation
fhigh
frequency
power
mPT
flow
0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200
time (unit) time (unit)
System Throughput (mTh)
App. controller
w/ recommendation w/ recommendation
w/o recommendation w/o recommendation
implementation
Impl2
throughput
mThT
Impl1
0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200
time (unit) time (unit)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 15/29

18. Introduction: Component-based Design
Main enabler for SW-RTE-HW adaptation is a component-based
approach.
Definition
A component is a self-contained element which encapsulates a
specification of a functionality, with well-defined interfaces to
interact with other components.
Definition
A component model specifies a formalism to design a component.
It defines inputs/outputs and component usage.
Definition
A component framework manages components by instantiating
and composing them.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 16/29

19. Enabling Self-adaptivity at Application Level
Application level
Component Framework
Component-based Application Goals
run-time system that implements the
Component Repository Component Framework Self-*
glue logic in compliance with the
SW-RTE Interface
component model
Results
Goal achievement+tasks
RTE level
Component model
RTE-SW Interface
defines the standard interfaces
Resource Manager
between components
Self-*
Resource Allocator
This model
Hardware Abstraction Layer
Recommender
allows the framework to be
aware of the run-time
RTE-HW Interface
characteristics of software
Goals+tasks + Results +
recommendations monitored parameters
components
Hardware level
Self-*
HW-RTE Interface
thus separation of concerns
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 17/29

20. New application development flow
Design time
extend component run-time system with an adaptation loop
and adaptation skills (next slide)
create adaptable (parameterized or compliant) versions of the
components in the component repository
Given a component graph and application goals
Run-time
parse goals
replace components with their adaptable versions
hook up relevant monitoring components
instatiate the controller
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 18/29

21. 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 goals
such as dependability and security
Gi {C } ⇒ Gj {C }
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 19/29

22. Case Study: A self-adaptive video streaming server
Latency Power
Hardware
Video streaming server
Monitor
Monitor
Picture size, Quality level Clock frequency, Voltage level
Adapter
Adapter
Controller
Controller
Application level Hardware level
Recommendations
for HW level
Controller
Monitor Recomm.
Goal
1 Bandwidth
FPS > FPS T ⇒ Latency < and FrameSize <
FPS T FPS T
Adaptation & Monitoring Space
ASApplication = {PictureSize, EncodingQuality }
MSApplication = {Latency }
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 20/29

23. GStreamer
a library for constructing of graphs of media-handling
components i.e. software component framework
already ported to N800
extendible
An Ogg player
gst-launch filesrc location=quot;test.oggquot; ! oggdemux name=d
d. ! queue ! theoradec ! ffmpegcolorspace ! ximagesink
d. ! queue ! vorbisdec ! audioconvert ! audioresample ! osssink
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 21/29

24. Enabling SW-RTE-HW Self-Adaptation
Provide a unified view of SW and HW components
extend the RTE with a component middleware in order to
manage software and hardware components.
enable adaptation capabilities with a mix of HW and SW
components (e.g. replacement of a SW component with a HW
component)
Case study
Create gstreamer components that use the DSP processor of
N800 (already done by TI)
Implement transparent migration of a software component
between ARM and DSP processors (of N800)
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 22/29

25. What do we need from Reconfigurable Computing?
What does the component middleware need
from the reconfigurable platform?
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 23/29

26. HW component abstraction
What is a hardware component for our Middleware point of
view?
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).
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 24/29

27. HW component: adaptation
How is the HW component adaptation by Middleware
performed?
Instantiation of components.
Component-Create(quot;FFTquot;);
Adaptation of high level component interactions.
Component-Connection(quot;FFTquot;, ...);
Requirements:
The reconfigurable platform should allow these ”services”.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 25/29

28. HW component: placement
The role of the Middleware
The Middleware is not responsible of component placement.
The Middleware considers HW components as resources to
use.
The role of the Reconfigurable Platform (?)
Efficient use of fabric.
Garbage Collector.
De-fragmentation.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 26/29

29. Conclusion
Proposed a model for self-adaptive systems that features
decentralized controllers and a recommendation mechanism to
coordinate adaptation management;
HW-SW adaptation coverage;
separation of self-adaptivity concerns from functionality;
goal specification interface.
Proposed a flow to implement self-adaptive applications based
on component technologies.
Tried to identify the requirements for a reconfigurable
platform to implement our Self-Adaptive RTE.
Self-adaptivity and component-based approach works well
together
self-adaptivity enables satisfying NFRs.
component-based approach enables self-adaptivity by providing
an adaptation space.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 27/29

30. Publications
A. Ferrante, A. V. Taddeo, O. Derin. Security in self-adaptive
systems. presented in 1st AETHER-Morpheus Workshop
(AMWAS’07), Paris, October 2007.
O. Derin, A. Ferrante, A. V. Taddeo. Coordinated management of
hardware and software self-adaptivity. Journal of System
Architecture, 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. Fridkins
Self-adaptive Security at Application Level: a Proposal.
presented in ReCoSoC 2007, Montpellier, France, Jun. 2007.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 28/29

31. References I
J. Buchli and C.C. Santini. Complexity Engineering: Harnessing
Emergent Phenomena as Opportunities for Engineering. In
Reports of the Santa Fe Institute’s Complex Systems Summer
School 2005. Santa Fe Institute, 2005.
Taddeo, ALaRI RCIM 2008— Self-adaptive Systems, 29/29