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

PhD defense, Monday, March 8th Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th Management of systems The current complexity impedes the sole management by administrators Managed system SensorsEffectors Requires a control loop Requires a control loop Sensors for monitoring Administrator for taking decision Effectors for controlling Administrator Monitors Controls

PhD defense, Monday, March 8th Management system Autonomic systems Systems manage themselves [Horn, 2001] Systems manage themselves [Horn, 2001] In a closed control loop In an open control loop Managed system SensorsEffectors Administrator Monitors Controls Supervises Policy

PhD defense, Monday, March 8th Autonomic systems Minimize administrators intervention by Minimize administrators 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 Outline I.Context and problem 1.Self-managing systems 2.Adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th Self-adaptive systems Self-adaptation is the basis for enabling self-CHOP capabilities Self-adaptation is the basis for enabling self-CHOP capabilities 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 response to internal and external stimuli

PhD defense, Monday, March 8th Kinds of adaptation Structural adaptation Structural adaptation Logical: bindings between entities Spatial: locations of entities Behavioral adaptation Behavioral adaptation Implementation Interfaces Parameters

PhD defense, Monday, March 8th Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th System coherence [Moazami,1999] [Leger, 2009] Structural constraints must be respected (e.g. cardinality, matching of services) Structural constraints must be respected (e.g. cardinality, matching of services) Entities are in locally coherent states Entities are in locally coherent states Invariants of the system must hold true Invariants of the system must hold true

PhD defense, Monday, March 8th Moment for adapting a system Ad-hoc approach: particular execution points are tagged [Hofmeister, 1994] Ad-hoc approach: particular execution points are tagged [Hofmeister, 1994] General approach: condition of quiescence [Kramer & Magee,1990] General approach: condition of quiescence [Kramer & Magee,1990] Transactional approach Replacement of an entity depends on the state of other entities :A:B:C Adaptation is feasible

PhD defense, Monday, March 8th State transfert Transfert of attributes values (writing of exportation/importation operations) Transfert of attributes values (writing of exportation/importation operations) Transfert of execution point (e.g. saving call stack) Transfert of execution point (e.g. saving call stack) :A:B :C $i $j

PhD defense, Monday, March 8th Problems of current self-adaptive component-based systems Manage behavioral adaptation like structural adaptation Manage behavioral adaptation like structural adaptation Require passivation of several components Have control loops Have 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 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th Thesis: Reifying the structure and the behavior of software components as models improves adaptability of these components Thesis: Reifying the structure and the behavior of software components as models improves adaptability of these components Implication: Specification of the MOCAS component model relying on the UML component model and on UML state machines Implication: Specification of the MOCAS component model relying on the UML component model 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 design of self-adaptive systems

PhD defense, Monday, March 8th Our vision of a software component Respects a component model Respects a component model Communicates through interfaces Communicates through interfaces Is configurable Is configurable Has an observable state Has an observable state Is composable Is composable A Provided interface Required interface Configuration interface

PhD defense, Monday, March 8th MOCAS component model a subset of the UML metamodel

PhD defense, Monday, March 8th Example of the dual clutch transmission system speedSensor: SpeedSensor gasSensor: GasSensor slopeSensor: SlopeSensor gearBox: GearBox lever: Lever

PhD defense, Monday, March 8th The GearBox component behavior GearBox /initMOCASProperties() Park Rear Neutral Drive Up Down Up Down Up Down First Second Third Fourth Fifth do/toFirst() do/toSecond() do/toFourth() do/toThird() do/toFifth() When f(speed,slope,gas)<-10 When f(speed,slope,gas)>10 When f(speed,slope,gas)>30 When f(speed,slope,gas)<-30 When f(speed,slope,gas)>20 When f(speed,slope,gas)<-40 When f(speed,slope,gas)<-20 When f(speed,slope,gas)>40

PhD defense, Monday, March 8th Structural composition of MOCAS components :GearBox:SpeedSensor :GasSensor :Lever :GearBox :Transmission « assembly » « delegate » Horizontal Horizontal Vertical (a.k.a hierarchic) Vertical (a.k.a hierarchic)

PhD defense, Monday, March 8th Behavioral composition of MOCAS components GearBox :Transmission « delegate »

PhD defense, Monday, March 8th First Second Event[guard]/effects entry/f1() do/toFirst() exit/f3() [speed>10] UML state machines: run-to-completion cycle Between two cycles, a MOCAS component is quiescent do/toSecond()

PhD defense, Monday, March 8th Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th Canonical behavior of a MOCAS component for managing adaptation: the container MOCASContainer /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 Management of adaptation Adaptation is requested by sending a signal, in the same way as a functional service Adaptation is requested by sending a signal, in the same way as a functional service The component is quiescent between two run-to-completion cycles The component is quiescent between two run-to-completion cycles Adaptation is done without interrupting state activities (i.e. do/ notation) Adaptation is done without interrupting state activities (i.e. do/ notation)

PhD defense, Monday, March 8th Consistency of adaptation 1)The new state machine must own the last active state configuration Three variants of the behavior of a component V1 V2V3 A B C D A C E A C E F G

PhD defense, Monday, March 8th Consistency of adaptation 2)All the actions invoked by the state machine must exist in the functional context 3)All the attributes required by constraints are owned by the component or the triggering signal Drive First Second do/toFirst() do/toSecond() public class FunctionalContext{ public void toFirst(){…} public void toSecond(){…} } Drive First Second S[gas>10] [speed>0] OK OK GearBox speed : Integer gas : Integer OK OK

PhD defense, Monday, March 8th Ex.: Refinement of behavior New service New service Context with new actions Context with new actions New attributes New attributes

PhD defense, Monday, March 8th Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th MOCAS control loop profile

PhD defense, Monday, March 8th Structure of the autonomic container

PhD defense, Monday, March 8th Canonical behavior of the MOCAS evaluator MOCASEvaluator /initMOCASProperties() AdaptationPolicy policy: MOCASPolicy H* MOCASSignal/dispatcher^MOCASSignal effector: MOCASEffector MOCASSignal /defer /compose(effector, MOCASEffector) DeliverPolicy(mocasPolicy) /compose(policy,mocasPolicy)

PhD defense, Monday, March 8th Self-configuration Deployment of sensors Deployment of sensors Configuration of a well-fitting operating mode (attributes + functional context + behavior) Configuration of a well-fitting operating mode (attributes + functional context + behavior) Switching between operating modes Switching between operating modes

PhD defense, Monday, March 8th Ex. of a self-configuration policy

PhD defense, Monday, March 8th The dual-transmission gear box from automatic… Five gear mode Five gear modeor Six gear mode Six gear mode

PhD defense, Monday, March 8th The dual-transmission gear box …to manual

PhD defense, Monday, March 8th TrafficLight Ex. of self-healing After 30s After 10s Red:Light Green:Light Amber:LightRed:Light Red Green Amber Green:Light Amber:Light

PhD defense, Monday, March 8th TrafficLight Ex. of self-healing After 30s After 10s Red:Light Off Do/switchOff TurnOff Green:Light Amber:LightRed:Light Red Entry/red^TurnOn Exit/red^TurnOff [red.inState(On) & orange.inState(Off) & green.inState(Off)] Green Entry/green^TurnOn Exit/green^TurnOff [red.inState(Off) & orange.inState(Off) & green.inState(On)] Amber Entry/orange^TurnOn Exit/orange^TurnOff [red.inState(Off) & orange.inState(On) & green.inState(Off)] On Do/switchOn TurnOn Green:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn Amber:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn e.g. Deficiency

PhD defense, Monday, March 8th TrafficLight Ex. of self-healing: Reset After 30s After 10s Red:Light Off Do/switchOff TurnOff Green:Light Amber:LightRed:Light Red Entry/red^TurnOn Exit/red^TurnOff [red.inState(On) & orange.inState(Off) & green.inState(Off)] Green Entry/green^TurnOn Exit/green^TurnOff [red.inState(Off) & orange.inState(Off) & green.inState(On)] Amber Entry/orange^TurnOn Exit/orange^TurnOff [red.inState(Off) & orange.inState(On) & green.inState(Off)] On Do/switchOn TurnOn Green:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn Amber:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn

PhD defense, Monday, March 8th TrafficLight Ex. of self-healing: Activating a coherent state After 30s After 10s Red:Light Off Do/switchOff TurnOff Green:Light Amber:LightRed:Light Red Entry/red^TurnOn Exit/red^TurnOff [red.inState(On) & orange.inState(Off) & green.inState(Off)] Green Entry/green^TurnOn Exit/green^TurnOff [red.inState(Off) & orange.inState(Off) & green.inState(On)] Amber Entry/orange^TurnOn Exit/orange^TurnOff [red.inState(Off) & orange.inState(On) & green.inState(Off)] On Do/switchOn TurnOn Green:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn Amber:Light Off Do/switchOff TurnOff On Do/switchOn TurnOn toState(Off)

PhD defense, Monday, March 8th Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th Tools for MOCAS components TopCased platform for design TopCased platform for design Plugin to generate Java classes for constraints and functional context and packaging MOCAS components MOCAS Engine for execution of models MOCAS Engine for execution of models Relies on Eclipse Modeling Framework MOCASA for test and management MOCASA for test and management Deployment of a MOCAS architecture Observation and control of components behavior Delivering of updates through adaptation Open source tools available at

PhD defense, Monday, March 8th Video: demo. of self-healing on traffic light component

PhD defense, Monday, March 8th Quantitative evaluation ImplementationComponentInstanciationState changeMemory Java SE + EMF Simple1083ms2498µs 4.4Mo Adaptive2341ms (x2.16)2954µs (x1.18) 8.8Mo (x2) Autonomic3555ms (x3.28)5320µs (x2.13) 13.3Mo (x3) Java ME + UML2ForJava Simple0.220ms 26µs0.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 Outline I.Context and problem 1.Self-managing systems 2.Self-adaptive systems 3.Management of adaptation II.MOCAS 1.The component model 2.Adaptation of MOCAS components 3.Self-adaptation of MOCAS components III.Tools and demo. IV.Conclusion and perspectives

PhD defense, Monday, March 8th MOCAS is a UML-based component model for designing open self-adaptive systems MOCAS is a UML-based component model for designing open self-adaptive systems MOCAS is MOCAS 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 Conclusion

PhD defense, Monday, March 8th Conclusion MOCAS fosters MOCAS 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 the software life cycle of a MOCAS system MOCAS provides a set of tools which cover the software life cycle of a MOCAS system

PhD defense, Monday, March 8th Limits and perspectives Focus on self-healing and self-configuration only Focus on self-healing and self-configuration only Performance of the MOCAS engine has to be improved (alternative to EMF) Performance of the MOCAS engine has to be improved (alternative to EMF) Coordination protocol to be enhanced Coordination protocol to be enhanced Validation to be enhanced (more case studies) Validation to be enhanced (more case studies)

PhD defense, Monday, March 8th Thank you for your attention Your questions