Self-Adaptation: MAPE-K and Control Theory

Danny Weyns & Stepan Shevtsov www.lnu.se/adaptwise

Grenoble, France November 4, 2014

Linnaeus University Sweden Växjö Campus

2

AdaptWise research team focusing on engineering self-adaptive systems

Växjö, Sweden - Google Maps https://maps.google.com/maps?f=d&source=s_d&saddr=Växjö...

1 of 1 10/2/13 12:30 PM

Research setting

•  Software engineers have to deal with uncertainties

resulting from incomplete knowledge at design time, e.g. •  - Dynamic operating conditions that are difficult to predict •  - Parts enter and leave the system at will •  - Changing goals

•  How to engineer such systems and guarantee the required system goals?

Self-adaptation

•  System maintains a model of itself at runtime •  System reasons about itself and adapts to realize system goals

•  Architecture-based self-adaptation •  - Separation between domain concerns & adaptation concerns •  - Adaptation concerns are handled by a feedback loop •  - Feedback loop ≈ set of components that share knowledge

Software system

Environment

input effect

Non-controllable software, hardware, network, physical context

Model architecture-based self-adaptation

Managed system

Managing system

Self-adaptive software system

monitor adapt

Controllable software

monitor

Environment

input effect

Non-controllable software, hardware, network, physical context

Model architecture-based self-adaptation

Managing system

Self-adaptive software system

monitor adapt

monitor

M K

MAPE-K - M: Monitor - A: Analyze - P: Plan - E: Execute - K: Knowledge

A

E

P

Environment

input effect

Non-controllable software, hardware, network, physical context

Managed system Controllable software

Model architecture-based self-adaptation

Research focus

•  Principles of architecture-based self-adaptation •  - FORMS: Unifying reference model for self-adaptation •  - Do External Feedback Loops Improve the Design of Self-

Adaptive Systems?

•  Rigorous modeling and verification •  - ActivFORMS: Active formal models for self-adaptation •  - Unifying approach for self-adaptation that integrates

architecture-based approach with control-theoretic approach

Research focus

•  Principles of architecture-based self-adaptation •  - FORMS: Unifying reference model for self-adaptation •  - Do External Feedback Loops Improve the Design of Self-

Adaptive Systems?

•  Assurances to handle uncertainty •  - ActivFORMS: Active formal models for self-adaptation •  - Unifying approach for self-adaptation that integrates

architecture-based approach with control-theoretic approach

Today

ActivFORMS: Starting points

Assurances for self-adaption - One prominent approach is using formal models - Main focus on K of MAPE-K - Main focus on uncertainty wrt model parameters

Assurance of adaptation capabilities by MAPE functions?

- E.g., does analysis detect errors correctly? - Are adaptations performed in order of selected plan?

How to provide assurances with changing/new goals?

- Requires support for adaptations of adaptation functions

ActivFORMS: Active formal models for self-adaptation

Formal model of complete MAPE-K loop Model is directly executed to adapt the managed system Model directly supports online verification of goal satisfaction/violation Goals and MAPE-K models can be changed at runtime to support changing/new goals

Approach

Active Model MAPE-K behaviors modeled as network of timed automata Adaptation requirements formulated in timed computation tree logic Model can be verified offline (e.g., using Uppaal tool)

PlanReadyPlanDisable

PlanPlanWait

PlanDisableLane

!dependOnLane()

addPlanStepDisable()

planned()

execute[RiD]!

planningDisableLane[RiD]?initiatePlan()

addPlanStepWait()

dependOnLane()

PlanReadyPlanDisable

PlanPlanWait

PlanDisableLane

!dependOnLane()

addPlanStepDisable()

planned()

execute[RiD]!

planningDisableLane[RiD]?initiatePlan()

addPlanStepWait()

dependOnLane()

Figure 4: Plan automaton of a robot

from verification only hold to the extent that the implementation ofthe managed system conforms to the model of the system that isused for verification. Such conformance can be tested, for examplewith model-based testing techniques [21]. We illustrate verificationwith an example for the robotic system.

Monitoring(1).RequestToDisableLane&& knowledge[1].disabledLane == Lane_cd--> Execution(1).DisableLane&& knowledge[1].disabledLane == Lane_cd

The goal allows verifying that when the monitor behavior ofrobot with ID 1 receives a request for disabling a particular lane,the execution behavior will eventually adapt the managed systemaccordingly.

4.1.2 Virtual MachineIn ActivFORMS, the formally verified model can directly be ex-

ecuted to realize self-adaptation using a virtual machine. The vir-tual machine can perform the following functions: initiate model,execute model, interact with the managed system and the environ-ment, verify goals at runtime, and update running models whenrequested. We discuss these functions in detail.

Initiate Model. When the virtual machine starts1, it first trans-lates the active model (network of automata) to an internal graphrepresentation. Concretely, each node of an automaton becomes anode of a graph for that automaton; links between the nodes be-come edges between the corresponding nodes. Operations such aschecking guards, updating state, etc. are translated into task graphsthat are associated with the corresponding nodes and edges. Com-munication between automata (signals) are integrated in the taskgraphs of the edges or nodes that send and receive signals.

Fig. 5 shows an excerpt of the internal representation of theformal model of a robot. Fig. 5(a) shows the analysis automa-ton of a robot, (b) shows an excerpt of abstract syntax tree of thetransition between the nodes Analyzing and DisableLaneRequest,and (c) shows the task graph generated for the guard DiableLane== matchRequest(request). The task graph shows the subsequentatomic tasks that need to be executed to check the guard.

When the active model is translated to the internal representa-tion, the state of each graph and the global state is initiated and themodel is then ready for execution.

Execute the Model. Model execution conforms to the semanticsof networked timed automata. The execution of the active model is1The virtual machine is implemented in Java and can be startedwith the ActivFORMSEngine class.

Figure 6: Input triggered execution

Figure 7: Time triggered execution

triggered either by input from the managed system or the environ-ment,2 or by time.

Fig. 6 shows the execution steps of an input triggered execution.When the virtual machine receives input, it first identifies the en-abled nodes that are interested for the given input, which will be oneor more nodes of the monitor behavior of the feedback loop. Nextthe virtual machine selects a node for execution.3 If the transitionis valid, the task graph of the selected node is executed, otherwiseanother enabled node is selected for execution. The execution ofthe task graph may trigger a subsequent behavior, e.g., a monitormay trigger an analysis and so forth. If there exists no valid node,no transition will be taken. This may point to an inconsistency be-tween the model of the managed system that was used during thedesign of the managing system and the implementation of the man-aged system. An example of an input triggered execution in therobotic system is a monitor behavior that receives a signal from aprobe to disable a lane and starts processing this request.

Fig. 7 shows the execution steps of a time triggered execution.The virtual machine maintains an internal clock that incrementswith time steps. The real time that corresponds with each time stepcan be configured in the virtual machine engine. In the followingexample, each step of the clock corresponds with 100 ms.

engine.setRealTimeUnit(100);

In line with the semantics of timed automata, for each time step,the virtual machine identifies the enabled node for each automatonand checks whether the time step would invalidate the time invari-ants of the enabled nodes. The virtual machine will then execute

2The active model interacts with the managed system and the en-vironment via signals that communicate with probes and effectors.We explain the details of interaction via probes and effectors below.3We limit the explanation to input triggered execution for binarychannel semantics, that is, a signal that is sent from a probe syn-chronizes non-deterministic with one enabled location of a monitorautomaton. The virtual machine also supports broadcast channels,where a signal can trigger multiple enabled locations.

Virtual Machine

Can load and execute active model Interaction with managed system and environment through probes and effectors Allows verification of goal satisfaction/violation Goals and MAPE-K models can be changed at runtime to support changing/new goals

Goal management

Goal model with associated adaptation models Goal monitor monitors goal satisfaction Goal adaptor satisfies current goals and adapt active model when needed Goal manager supports inspection active model and updating models

Case study

Goal Management Interface

Goal Management Interface Show executing model

Goal Management Interface Updating goals and models

Goal Management Interface Update model

Discussion

Active formal model paves the way for “handling continuous change” Goal model and associated adaptation models - Support changing goals and adding new goals - Results in small models allowing efficient verification We have applied the approach successfully to different case studies Various opportunities for future research remain, including:

- Support for probabilistic models - Runtime support for model checking - Coordination between active models

Research focus

•  Principles of architecture-based self-adaptation •  - FORMS: Unifying reference model for self-adaptation •  - Do External Feedback Loops Improve the Design of Self-

Adaptive Systems?

•  Rigorous modeling and verification •  - ActivFORMS: Active formal models for self-adaptation •  - Unifying approach for self-adaptation that integrates

architecture-based approach with control-theoretic approach

Unifying approach for self-adaptation that integrates architecture-based approach with control-theoretic approach

Control theory provides a mature mathematical framework to design and analyze feedback loops Has been used to control computing systems Focus primarily on controlling resources of computing systems (CPU, memory, bandwidth, etc.) Our aim is to control software

Motivation for controlling software

How do control-based solutions relate to MAPE-K based solutions? Are they complementary? Or does control theory provide a foundational theoretical framework to software adaptation?

Unifying approach for self-adaptation that integrates architecture-based approach with control-theoretic approach

Control in service-based system: e.g., - Dynamically replace service that goes down with alternative - Change service with better quality properties - Change the workflow at runtime to improve QoS, etc.

How  does  the  (mathema-cal)  model  of  so2ware  look  like?    

For  which  types  of  adapta-ons  can  we  control  so2ware  and  for  which  not?  How  is  a  setpoint/input  defined?    

What  are  the  “knobs”  to  adapt  so2ware?      What  guarantees  can  be  provided?  How  do  typical  so2ware  adapta-on  proper-es  relate  to  typical  proper-es  of  controllers?      

What  are  the  benefits  and  limita-ons  of  applying  control  theory  to  so2ware  systems?    

Variety of challenges

Systema-c  literature  review  of  using  control  theory  to  adapt  so2ware    

Focus  on  applica-on  layer  and  suppor-ng  service  layer  (not  1  to  1  mapping  to  resources  (e.g.  a  driver  or  virtual  machine)          

Research  ques-ons  we  plan  to  address    -‐    RQ1:  What  is  the  focus  of  research  on  control-‐based  adapta-on  in  so2ware  systems?  -‐  RQ2:  What  quali-es  are  affected  by  adap-ng  so2ware  using  principles  from  control  theory?  -‐  RQ3:  How  are  the  so2ware  systems  with  feedback  controllers  modeled  and  constructed?  

     

In  parallel,  we  are  studying  how  to  apply  a  control-‐based  approach  to  adapt  the  architecture  of  a  service  based  system      

Current work

Bibliography    •  D.  Weyns,  S.  Malek,  J.  Andersson,  FORMS:  Unifying  Reference  Model  for  

Formal  Specifica-on  of  Distributed  Self-‐Adap-ve  Systems,  ACM  Transac-ons  on  Autonomous  and  Adap-ve  Systems,  TAAS,  7(1),  2012  

•  D.  Weyns,  U.  I2ikhar  and  J.  Söderlund,  Do  External  Feedback  Loops  Improve  the  Design  of  Self-‐Adap-ve  Systems?  A  Controlled  Experiment,  So2ware  Engineering  for  Adap-ve  and  Self-‐Managing  Systems,  SEAMS  2013  

•  M.  Usman  I2ikhar,  Danny  Weyns:  Ac-vFORMS:  ac-ve  formal  models  for  self-‐adapta-on,  Interna-onal  Symposium  in  So2ware  Engineering  of  Adap-ve  and  Self-‐Managing  Systems,  SEAMS  2014  

•  D.  Weyns,  S.  Shevtsov,  S.  Pllana:  Providing  Assurances  for  Self-‐Adapta-on  in  a  Mobile  Digital  Storytelling  Applica-on  Using  Ac-vFORMS,  Interna-onal  Conference  on  Self-‐Adap-ve  and  Self-‐Organizing  Systems,  SASO  2014    

•  Papers  available  via:                hcp://homepage.lnu.se/staff/daweaa/publica-ons/publica-ons.htm