Date post: | 28-Mar-2015 |
Category: |
Documents |
Upload: | cameron-graham |
View: | 217 times |
Download: | 0 times |
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
OutlineOutline
I.I. Context and problemContext and problem1. Self-managing systems2. 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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
Kinds of adaptationKinds of adaptation
Structural adaptationStructural adaptation Logical: bindings between entities Spatial: locations of entities
Behavioral adaptationBehavioral adaptation Implementation Interfaces Parameters
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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)
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
MOCAS component modelMOCAS component modela subset of the UML metamodela subset of the UML metamodel
PhD defense, Monday, March 8th 2010 [email protected]
Example of the dual clutch Example of the dual clutch transmission systemtransmission system
speedSensor: SpeedSensor
gasSensor: GasSensor slopeSensor: SlopeSensor
gearBox: GearBoxlever: Lever
PhD defense, Monday, March 8th 2010 [email protected]
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
When f(speed,slope,gas)>30When f(speed,slope,gas)>30
When f(speed,slope,gas)<-30When f(speed,slope,gas)<-30
When f(speed,slope,gas)>20When f(speed,slope,gas)>20
When f(speed,slope,gas)<-40When f(speed,slope,gas)<-40
When f(speed,slope,gas)<-20When f(speed,slope,gas)<-20
When f(speed,slope,gas)>40When f(speed,slope,gas)>40
PhD defense, Monday, March 8th 2010 [email protected]
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)
PhD defense, Monday, March 8th 2010 [email protected]
Behavioral composition of MOCAS Behavioral composition of MOCAS componentscomponents
GearBox
:Transmission« delegate »
PhD defense, Monday, March 8th 2010 [email protected]
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()
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
PhD defense, Monday, March 8th 2010 [email protected]
Canonical behavior of a MOCAS component for Canonical behavior of a MOCAS component for managing adaptation: the containermanaging adaptation: the container
MOCASContainer
/initMOCASProperties()/initMOCASProperties()
behavior: MOCASBehavior
AdaptMOCASComponent(attributes, context, behavior)
[BehaviorIsConsistent and ContextIsConsistent and AttributesAreConsistent]
/adaptMOCASComponent(attributs, context, behavior)
DeferredAdaptMOCASComponent(attributes, context, behavior) /defer
PhD defense, Monday, March 8th 2010 [email protected]
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)
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
Ex.: Refinement of behaviorEx.: Refinement of behavior
New serviceNew service Context with Context with
new actionsnew actions New attributesNew attributes
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
PhD defense, Monday, March 8th 2010 [email protected]
MOCAS control loop profileMOCAS control loop profile
PhD defense, Monday, March 8th 2010 [email protected]
Structure of the autonomic containerStructure of the autonomic container
PhD defense, Monday, March 8th 2010 [email protected]
Canonical behavior of the MOCAS Canonical behavior of the MOCAS evaluatorevaluator
MOCASEvaluator
/initMOCASProperties()/initMOCASProperties()
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)
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
Ex. of a self-configuration policyEx. of a self-configuration policy
PhD defense, Monday, March 8th 2010 [email protected]
The dual-transmission gear boxThe dual-transmission gear boxfrom automatic…from automatic…
Five gear Five gear modemode
oror Six gear Six gear
modemode
PhD defense, Monday, March 8th 2010 [email protected]
The dual-transmission gear boxThe dual-transmission gear box…to manual…to manual
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
TrafficLight
Ex. of self-healingEx. of self-healing
After 30s
After 30s
After 10s
Red:Light
OffDo/switchOff
TurnOff
Green:LightAmber:Light Red:Light
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
PhD defense, Monday, March 8th 2010 [email protected]
TrafficLight
Ex. of self-healing: ResetEx. of self-healing: Reset
After 30s
After 30s
After 10s
Red:Light
OffDo/switchOff
TurnOff
Green:LightAmber:Light Red:Light
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
PhD defense, Monday, March 8th 2010 [email protected]
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
Green:LightAmber:Light Red:Light
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
toState(Off)
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
PhD defense, Monday, March 8th 2010 [email protected]
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/
PhD defense, Monday, March 8th 2010 [email protected]
Video: demo. of self-healing on Video: demo. of self-healing on traffic light componenttraffic light component
PhD defense, Monday, March 8th 2010 [email protected]
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
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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
PhD defense, Monday, March 8th 2010 [email protected]
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)
PhD defense, Monday, March 8th 2010 [email protected]
Thank you for your attentionThank you for your attention
Your questionsYour questions