self-adaptation: mape-k and control theorystephane.mocanu/slides_staars/weyns.pdfmape-k behaviors...
Post on 27-Jan-2021
10 Views
Preview:
TRANSCRIPT
-
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
top related