Thesis defense presented by Cyril Ballagny Monday, March 8th 2010 Advisor: Franck Barbier Co-Advisor: Nabil Hameurlain MOCAS: a state-based component model

Thesis defense presented byCyril Ballagny

Monday, March 8th 2010

Advisor: Franck BarbierCo-Advisor: Nabil Hameurlain

MOCAS: a state-based component model for self-adaptation

PhD defense, Monday, March 8th 2010 [email protected]

OutlineOutline

I.I. Context and problemContext and problem1. Self-managing systems2. Self-adaptive systems3. Management of adaptation

II.II. MOCASMOCAS1. The component model2. Adaptation of MOCAS components3. Self-adaptation of MOCAS components

III.III. Tools and demo.Tools and demo.IV.IV. Conclusion and perspectivesConclusion and perspectives


Management of systemsManagement of systems

The current complexity impedes the sole The current complexity impedes the sole management by administratorsmanagement by administrators

Managed system

Sensors Effectors

Requires a control loopRequires a control loop Sensors for monitoring Administrator for taking

decision Effectors for controlling

Administrator

Monitors Controls


Management system

Autonomic systemsAutonomic systems

Systems manage Systems manage themselves [Horn, themselves [Horn, 2001]2001] In a closed control loop In an open control loop

Managed system

Sensors Effectors

Administrator

Monitors Controls

Supervises

Policy


Autonomic systemsAutonomic systems Minimize administrator’s intervention byMinimize administrator’s intervention by

Self-Configuring to be ready to provide their services, whatever environment they are deployed in

Self-Healing to prevent deficiencies and correct them if they occur

Self-Optimizing to guarantee high performance Self-Protecting to defeat attacks

Self-CHOP capabilities


OutlineOutline

I.I. Context and problemContext and problem1. Self-managing systems2. Adaptive systems3. Management of adaptation




Self-adaptive systemsSelf-adaptive systems Self-adaptation is the basis for enabling self-CHOP Self-adaptation is the basis for enabling self-CHOP

capabilitiescapabilities “Self-adaptive software evaluates its own behavior and

changes behavior when the evaluation indicates that it is not accomplishing what the software is intended to do, or when better functionality or performance is possible.” [Laddaga, 2000]

“Self-adaptive software modifies its own behavior in response to changes in its operating environment.” [Oreizy et al., 1999]

Self-adaptive systems modify their functioning in Self-adaptive systems modify their functioning in response to internal and external stimuliresponse to internal and external stimuli


Kinds of adaptationKinds of adaptation

Structural adaptationStructural adaptation Logical: bindings between entities Spatial: locations of entities

Behavioral adaptationBehavioral adaptation Implementation Interfaces Parameters


OutlineOutline





System coherenceSystem coherence [Moazami,1999] [Leger, 2009] [Moazami,1999] [Leger, 2009]

Structural constraints must be respected Structural constraints must be respected (e.g. cardinality, matching of services)(e.g. cardinality, matching of services)

Entities are in locally coherent statesEntities are in locally coherent states Invariants of the system must hold trueInvariants of the system must hold true


Moment for adapting a systemMoment for adapting a system Ad-hoc approach: particular execution points are Ad-hoc approach: particular execution points are

tagged [Hofmeister , 1994]tagged [Hofmeister , 1994] General approach: condition of quiescence [Kramer & General approach: condition of quiescence [Kramer &

Magee,1990]Magee,1990] Transactional approach Replacement of an entity

depends on the state of other

entities

:A :B :C

Adaptation is feasible

Adaptation is feasible


State transfertState transfert

Transfert of attributes values (writing of Transfert of attributes values (writing of exportation/importation operations)exportation/importation operations)

Transfert of execution point (e.g. saving call Transfert of execution point (e.g. saving call stack)stack)

:A :B

:C

$i$j


Problems of current self-adaptive Problems of current self-adaptive component-based systemscomponent-based systems

Manage behavioral adaptation like structural Manage behavioral adaptation like structural adaptationadaptation Require passivation of several components

Have control loopsHave control loops Designed in an ad-hoc way

With respect to the system to manage With respect to the desired self-* capabilities

Centralized in a management infrastructure Closed (no support for unanticipated adaptation)


OutlineOutline





Thesis: Thesis: “Reifying the structure and the behavior of “Reifying the structure and the behavior of software components as models improves software components as models improves adaptability of these components”adaptability of these components”

Implication: Implication: Specification of the MOCAS Specification of the MOCAS component model relying on the UML component component model relying on the UML component model and on UML state machinesmodel and on UML state machines

Technologies & Tools:Technologies & Tools: MOCASEngine: an engine based on the Eclipse

Modeling Framework for executing UML specification A complete toolkit for designing, developing and testing

MOCAS components

Overview of our contribution to the Overview of our contribution to the design of self-adaptive systemsdesign of self-adaptive systems


Our vision of a software componentOur vision of a software component

Respects a component modelRespects a component model Communicates through interfacesCommunicates through interfaces Is configurableIs configurable Has an observable stateHas an observable state Is composableIs composable A

Provided interface

Requiredinterface

Configurationinterface


MOCAS component modelMOCAS component modela subset of the UML metamodela subset of the UML metamodel


Example of the dual clutch Example of the dual clutch transmission systemtransmission system

speedSensor: SpeedSensor

gasSensor: GasSensor slopeSensor: SlopeSensor

gearBox: GearBoxlever: Lever


The GearBox component behaviorThe GearBox component behavior

GearBox

/initMOCASProperties()/initMOCASProperties()

Park

Rear

Neutral

Drive

UpUp DownDown

UpUp DownDown

UpUp

DownDown

First Second

ThirdFourth

Fifth

do/toFirst()do/toFirst() do/toSecond()do/toSecond()

do/toFourth()do/toFourth() do/toThird()do/toThird()

do/toFifth()do/toFifth()

When f(speed,slope,gas)<-10When f(speed,slope,gas)<-10

When f(speed,slope,gas)>10When f(speed,slope,gas)>10








Structural composition of MOCAS Structural composition of MOCAS componentscomponents

:GearBox :SpeedSensor

:GasSensor

:Lever

:GearBox

:Transmission

« assembly »

« assembly »

« delegate »

HorizontalHorizontal

Vertical Vertical (a.k.a hierarchic)(a.k.a hierarchic)


Behavioral composition of MOCAS Behavioral composition of MOCAS componentscomponents

GearBox

:Transmission« delegate »


First SecondEvent[guard]/effectsentry/f1()do/toFirst()exit/f3() [speed>10]

UML state machines:UML state machines:run-to-completion run-to-completion cyclecycle

Between two cycles, a MOCAS Between two cycles, a MOCAS component is “quiescent”component is “quiescent”

do/toSecond()


OutlineOutline





Canonical behavior of a MOCAS component for Canonical behavior of a MOCAS component for managing adaptation: the containermanaging adaptation: the container

MOCASContainer


behavior: MOCASBehavior

AdaptMOCASComponent(attributes, context, behavior)

[BehaviorIsConsistent and ContextIsConsistent and AttributesAreConsistent]

/adaptMOCASComponent(attributs, context, behavior)

DeferredAdaptMOCASComponent(attributes, context, behavior) /defer


Management of adaptationManagement of adaptation

Adaptation is requested by sending a signal, Adaptation is requested by sending a signal, in the same way as a functional servicein the same way as a functional service

The component is The component is quiescent quiescent between two between two run-to-completion run-to-completion cyclescycles

Adaptation is done without interrupting state Adaptation is done without interrupting state activities (i.e. “do/” notation)activities (i.e. “do/” notation)


Consistency of adaptationConsistency of adaptation

1)1) The new state machine must own the last active The new state machine must own the last active state configurationstate configuration

Three variants of the behavior of a component

V1 V2 V3

A

B

CD

A

CE

A

C

E F G


Consistency of adaptationConsistency of adaptation

2)2) All the actions invoked by the state machine must exist in All the actions invoked by the state machine must exist in the functional contextthe functional context

3)3) All the attributes required by constraints are owned by the All the attributes required by constraints are owned by the component or the triggering signalcomponent or the triggering signal

Drive

First Seconddo/toFirst()do/toFirst() do/toSecond()do/toSecond()

public class FunctionalContext{ public void toFirst(){…} public void toSecond(){…}}

Drive

First SecondS[gas>10]S[gas>10]

[speed>0][speed>0]

OKOKOKOK

GearBox

speed : Integergas : Integer

OKOKOKOK


Ex.: Refinement of behaviorEx.: Refinement of behavior

New serviceNew service Context with Context with

new actionsnew actions New attributesNew attributes


OutlineOutline





MOCAS control loop profileMOCAS control loop profile


Structure of the autonomic containerStructure of the autonomic container


Canonical behavior of the MOCAS Canonical behavior of the MOCAS evaluatorevaluator

MOCASEvaluator


AdaptationPolicy

policy: MOCASPolicy

H*

MOCASSignal/dispatcher^MOCASSignalMOCASSignal/dispatcher^MOCASSignal

effector: MOCASEffector

MOCASSignal /deferMOCASSignal /defer

/compose(/compose(“effector”, MOCASEffector)“effector”, MOCASEffector)

DeliverPolicy(mocasPolicy) /composeDeliverPolicy(mocasPolicy) /compose(“policy”,mocasPolicy)(“policy”,mocasPolicy)


Self-configurationSelf-configuration

Deployment of sensorsDeployment of sensors Configuration of a well-fitting operating Configuration of a well-fitting operating

mode (attributes + functional context + mode (attributes + functional context + behavior)behavior)

Switching between operating modesSwitching between operating modes


Ex. of a self-configuration policyEx. of a self-configuration policy


The dual-transmission gear boxThe dual-transmission gear boxfrom automatic…from automatic…

Five gear Five gear modemode

oror Six gear Six gear

modemode


The dual-transmission gear boxThe dual-transmission gear box…to manual…to manual


TrafficLight

Ex. of self-healingEx. of self-healing

After 30s

After 30s

After 10s

Red:Light

Green:LightAmber:Light Red:Light

Red

Green

Amber

Green:Light

Amber:Light


TrafficLight

Ex. of self-healingEx. of self-healing

After 30s

After 30s

After 10s

Red:Light

OffDo/switchOff

TurnOff


RedEntry/red^TurnOnExit/red^TurnOff[red.inState(On) & orange.inState(Off) & green.inState(Off)]

GreenEntry/green^TurnOnExit/green^TurnOff[red.inState(Off) & orange.inState(Off) & green.inState(On)]

AmberEntry/orange^TurnOnExit/orange^TurnOff[red.inState(Off) & orange.inState(On) & green.inState(Off)]

OnDo/switchOn

TurnOn

Green:Light

OffDo/switchOff

TurnOff

OnDo/switchOn

TurnOn

Amber:Light

OffDo/switchOff

TurnOff

OnDo/switchOn

TurnOn

e.g. Deficiency


TrafficLight

Ex. of self-healing: ResetEx. of self-healing: Reset

After 30s

After 30s

After 10s

Red:Light

OffDo/switchOff

TurnOff





OnDo/switchOn

TurnOn

Green:Light

OffDo/switchOff

TurnOff

OnDo/switchOn

TurnOn

Amber:Light

OffDo/switchOff

TurnOff

OnDo/switchOn

TurnOn


TrafficLight

Ex. of self-healing: Activating a coherent stateEx. of self-healing: Activating a coherent state

After 30s

After 30s

After 10s

Red:Light

OffDo/switchOff

TurnOff





OnDo/switchOn

TurnOn

Green:Light

OffDo/switchOff

TurnOff

OnDo/switchOn

TurnOn

Amber:Light

OffDo/switchOff

TurnOff

OnDo/switchOn

TurnOn

toState(Off)


OutlineOutline





Tools for MOCAS componentsTools for MOCAS components TopCased platform for designTopCased platform for design

Plugin to generate Java classes for constraints and functional context and packaging MOCAS components

MOCAS Engine for execution of modelsMOCAS Engine for execution of models Relies on Eclipse Modeling Framework

MOCASA for test and managementMOCASA for test and management Deployment of a MOCAS architecture Observation and control of components’ behavior Delivering of updates through adaptation

Open source tools available atOpen source tools available athttp://mocasengine.sourceforge.net/


Video: demo. of self-healing on Video: demo. of self-healing on traffic light componenttraffic light component


Quantitative evaluationQuantitative evaluationImplementation Component Instanciation State change Memory

Java SE+

EMF

Simple 1083ms 2498µs 4.4Mo

Adaptive 2341ms (x2.16) 2954µs (x1.18) 8.8Mo (x2)

Autonomic 3555ms (x3.28) 5320µs (x2.13) 13.3Mo (x3)

Java ME+

UML2ForJavahttp://

uml2forjava.sourceforge.net/

Simple 0.220ms 26µs 0.040Mo

Using a container costs one more component mitigated by behavioral composition

Making a component autonomic costs two more components

Most of the cost is due to EMF


OutlineOutline





MOCAS is aMOCAS is a UML-basedUML-based component model component model for designing open self-adaptive systemsfor designing open self-adaptive systems

MOCAS isMOCAS is Generic: every kind of systems are concerned Uniform: all the “non-functional” components respect the

MOCAS component model Reflexive: structure and behavior are discovered and

modified at runtime Decentralized: each component embeds its control loop

ConclusionConclusion


ConclusionConclusion

MOCAS fostersMOCAS fosters Transparency of adaptation mechanisms by

incorporating a component into a container which manages adaptation

Flexibility of the control mechanism by dividing it into several MOCAS components

Usability by relying on one formalism from design to administration

MOCAS provides a set of tools which cover MOCAS provides a set of tools which cover the software life cycle of a MOCAS systemthe software life cycle of a MOCAS system


Limits and perspectivesLimits and perspectives

Focus on self-healing and self-configuration Focus on self-healing and self-configuration onlyonly

Performance of the MOCAS engine has to Performance of the MOCAS engine has to be improved (alternative to EMF)be improved (alternative to EMF)

Coordination protocol to be enhancedCoordination protocol to be enhanced Validation to be enhanced (more case Validation to be enhanced (more case

studies)studies)


Thank you for your attentionThank you for your attention

Your questionsYour questions

Documents

Thesis defense presented by Cyril Ballagny Monday, March 8th 2010 Advisor: Franck Barbier Co-Advisor: Nabil Hameurlain MOCAS: a state-based component model