Simulation of a Self-adaptive Run-time Environment with Hardware and Software Components Onur Derin, Alberto Ferrante Advanced Learning and Research Institute Faculty of Informatics Universit` a della Svizzera italiana Lugano, 6900, Switzerland name.surname@alari.ch SINTER’09 August 25, 2009
Outline A model of self-adaptive systems SACRE Framework Extending SACRE on heterogeneous platforms Conclusion Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 2/20
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 Some information is available only at run-time (application specific vs. general purpose, design space exploration vs. run-time adaptation) Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 3/20
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 Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 4/20
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? Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 5/20
Layered Model A goal is a boolean expression Goals with terms from monitorable Self-adaptive system space. Controller AS Application MS Application AS Run − timeEnvironment MS Run − timeEnvironment AS Hardware MS Hardware e.g. different implementations- e.g. frame size, resource utilization, parameters, available cores, available cache miss rate, power consumption HW functional units, clock frequency Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 6/20
Layered Model A goal is a boolean expression Goals with terms from monitorable Self-adaptive system space. C Application C Run − timeEnvironment C Hardware AS Application MS Application AS Run − timeEnvironment MS Run − timeEnvironment AS Hardware MS Hardware e.g. different implementations- e.g. frame size, resource utilization, parameters, available cores, available cache miss rate, power consumption HW functional units, clock frequency Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 6/20
Component-based approach Main enabler for application-level and RTE-level adaptation is a component-based approach. allows the framework to be aware of the run-time characteristics of components thus separation of concerns Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 7/20
Model of a self-adaptive heterogeneous system Self-adaptive Component Framework the component run-time environment is extended with an MCA loop does application level adaptations does RTE-level adaptations Resource manager adapts concurrency, redundancy and mapping. Goals as lower/upper bounds or Min/Max. Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 8/20
SACRE Framework Component model based on the KPN model of computation suited for streaming applications A SACRE component extends the SACREComponent abstract class implements the task() method has a thread of its own specifies its input and output ports exchanges typed messages through its named input and output ports is adaptable has a command interface for adaptations input and output ports are hookable ports can be connected to a different connector at run-time declares its adaptable parameters Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 9/20
SACRE Framework Connectors unbounded buffers that hold typed messages blocking read, non-blocking write connects one output port to one input port Pipelines created by means of a simple language ; -separated list of statements & for parallel, ! for serial composition & has precedence over ! no cycles = ⇒ deadlock-freedom input port A E output port C D connector B F Figure: A & B ! C ! D ! E & F Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 10/20
Possible adaptations at Application Level Parameter adaptation of a component C i ( p i ) ⇒ C i ( p j ) Structural adaptation Replacement of a component C i ⇒ C j Parallelization of a component C i ⇒ { C i j } Transformation with adaptation patterns for high level goals such as dependability and security G i { C } ⇒ G j { C ′ } Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 11/20
Case Study: A self-adaptive MJPEG streaming server Source R2B DCT Quantize ZZE RLE Sink Latency, Picture size, Network bandwidth Quality level Adapter Monitor Controller Goal FPS > FPS T ⇒ Latency < FPS T and FrameSize < Bandwidth 1 FPS T maximize PictureSize and Quality Adaptation & Monitoring Space AS Application = { PictureSize , EncodingQuality } MS Application = { Latency , Bandwidth } Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 12/20
Enabling RTE-level adaptations with HW and SW components Need for a component run-time environment with a unified view of SW and HW components a distributed component middleware on the heterogeneous platform a software layer on processor cores a hardware wrapper/proxy on reconfigurable units its extension to enable adaptation capabilities with a mix of HW and SW components (e.g. replacement of a SW component with a HW component) Initial solution: Extending SACRE functional simulation an abstract solution to be refined on real platforms Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 13/20
Extending SACRE for RTE-level adaptations Assembly composition of components into a single SACRE component Composite Resource Mapping a total function from components to resources to show that a component runs on a resource Resource pipeline the pipeline that emerges from the composition of resource components Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 14/20
An extended SACRE example CPU1 FPGA1 B A D E F CPU2 input port C G output port connector resource CPU1: A, B, D resource CPU2: C, G resource FPGA1: E, F pipeline App1: A ! B & C ! D ! E ! F ! G Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 15/20
How to connect the internal ports to resource ports? Problem: Cyclic resource pipeline is prone to deadlocks! Sol. 1 merge the two ports as one ⇒ resource thread becomes useless Sol. 2 resource thread transfers tokens between internal and external connectors ⇒ connector concept has to be modified, reading order is important Sol. 3 introduce middleware components ⇒ reading order is important. MW components can also be used to implement adaptation capabilities. Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 16/20
Inserting middleware components CPU1 FPGA1 1 2 B 3 4 A D E F 1 2 CPU2 5 C G task() of a middleware component is simply implemented by calling read and write operations on its ports labeling function label the edges of the application pipeline with an integer value that represent the maximum number of application components that a token may go through until arriving to that edge. tokens are forwarded from the input channels with a smaller-labeled-channel-first fashion Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 17/20
Adaptation capabilities to be implemented in extended SACRE parametric adaptation of the resource structural adaptation of the resource pipeline structural adaptation of the application pipeline over the resource pipeline migration of a component from one resource to another create the same type component instance in the destination resource remove/add ports from/to middleware components relabel edges paralellization onto multiple cores dependability pattern makes sense as well Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 18/20
Conclusion extended our model for self-adaptive systems for RTE-level adaptations on heterogeneous platforms identified the requirements for a self-adaptive heterogeneous component run-time environment proposed to extend SACRE as an initial solution provides an abstract solution for future refinements allows experimenting with adaptation algorithms associate costs to application components (e.g. execution time, power) centralized vs. decentralized control mapping policies adaptation patterns for high-level goals Derin, ALaRI SINTER’09— Self-adaptive Run-time Environment 19/20
Recommend
More recommend
