The MAPE-K Feedback Loop

The decisions when, what, and how to adapt a mobile device have to be made by the SAS at runtime to cope with dynamic behavior of a user. To facilitate system- atic control of the adaptation process, the system continuously reasons about its contextual situation. For example, a mobile device collects contextual information, e.g., its geographical location and available connection types, to reason about how to establish a connection to the Internet in this contextual situation.

Feedback loops are a common paradigm to facilitate an adaptation process at runtime in a coordinated, reliable manner [BMSG+_{09, CLG}+_{09]. The feedback}

enables a static or dynamic evolution of the system and is used to optimize the adaptation behavior. Positive feedback occurs when an initial change in a system is reinforced. In contrast, negative feedback triggers a response that counteracts an executed decision.

Example 2.8 (Positive and Negative Feedback).

According to some non-functional requirement, the connection with the best throughput is to be preferred. Initially starting with a HSDPA connection, the smartphone continuously checks for other connection types. If GSM becomes available, the smartphone tests this connection type as an alternative. Since GSM has a lower throughput than HSDPA, the adaptation process emits a neg- ative feedback for that decision. The same happens if LTE becomes available. In contrast to GSM, the adaptation process emits a positive feedback because the throughput via LTE is higher than via HSDPA. Therefore, the system is going to prefer LTE over HSDPA automatically in upcoming adaptation decisions.

&

als

The basic principle of such feedback loops is a refinement of the sense-plan-act approach used in the AI community [Nil80]. With a feedback loop the adaptation process may become completely autonomous.

The first concrete architecture of a feedback loop for autonomous SAS was introduced in a blueprint of IBM [IBM06]. This feedback loop is depicted in Figure2.4. The loop facilitates a controlled autonomous adaptation by executing the four tasks (i) monitor, (ii) analyze, (iii) plan, and (iv) execute. These tasks share a common knowledge basis. This approach is commonly known as the MAPE-K loop.

Infor- mation Change Request Feedback Know- ledge Change Plan

Figure 2.4:MAPE-K Feedback Loop [IBM06]

Monitoring. The monitoring task is responsible for capturing basic informa- tion of the contextual situation, e.g., via sensor data. This information is corre- lated to specific aspects, e.g., the current location and available connection types. Such information includes network topology information, property settings, sta- tus of resources, offered capacities, and throughput. The information is either static or the information is highly dynamic and continuously changes over run- time. A monitor aggregates this information, e.g., for a better information scal- ability [SGS13] in a large decentralized network of smartphones. Thereafter the information is filtered to the most relevant aspects for an adaptation before pass- ing them to the analyze task. For example, assume that in a contextual situation only the location and throughput are of relevance. In that case, the information about responsiveness and lighting conditions are discarded.

Analyze. The analysis of the monitoring information provides the means to recognize contextual situations and to derive higher order information. Based on the analysis of that data a decision is met whether an adaptation is necessary or not. The gathered monitoring information about the current contextual situation is correlated to the requirements a context imposes on the system. For example, if the context office becomes active, the analysis task checks if the requirement “able to send and receive email” is already satisfied with the current system configura-

I ntr od uction F und

ament tion or if an adaptation is necessary. Additionally, the adaptation behavior may be analyzed to employ prediction techniques to plan and prepare for upcoming adaptations. Therefore, the device has to be able to learn about contextual situ- ations and the adaptation behavior executed on the device. If the requirements change due to a change in the contextual situation, the analyze task passes an according change request to the plan task.

Plan. The plan task derives a procedure to execute a desired adaptation of the system to satisfy the imposed requirements. An adaptation procedure may range from a single command, e.g., “activate WLAN”, to a complex adaptation sequence, e.g., “activate WLAN”, “deactivate GPS”, and “set ringtone volume to 0”. Further- more, the planning is driven by specific goals, i.e., functional or non-functional requirements, when an adaptation plan is derived. This ranges from a problem solution, i.e., satisfying all requirements and goals, to a complex optimization pro- cess to derive the best system configuration for a contextual situation. The derived change plan is passed to the execute task to apply all changes and reconfigure the system at runtime transparently.

Execute. In the execution task, suitable methods and mechanisms are sched- uled to perform the changes in the current system configuration. These changes may range from parameter changes, e.g., ringtone volume, to the exchange of components or code fragments, e.g., discarding email notification component or changing the keyboard component from English to the German. The execute task is responsible for carrying out these changes within a running system in an ordered sequence of non-conflicting tasks.

Knowledge Basis. The four tasks monitor, analyze, plan, and execute share a common knowledge model. This knowledge includes specifications or profiled in- formation required by the adaptation process. For example, the knowledge model includes contextual information, adaptation behavior profiles, monitoring metrics, adaptation policies, as well as system capabilities. The specified knowledge is ei- ther explicitly specified, i.e., everything that may happen is covered within the model, or implicitly specified, i.e., uncertain or unknown behavior may occur at runtime, which is not covered within the model. The knowledge model is imple- mented as a registry, dictionary, database, or any other repository that provides access to knowledge according to the interfaces prescribed by the architecture.

The knowledge is obtainable in three ways [IBM06].

1. Knowledge is a-priori specified at design time and deployed on the system locally before runtime,

2. the knowledge is continuously retrieved from an external knowledge source, e.g., an external database in the Internet, or

3. the adaptation process itself generates knowledge, e.g., leveraging moni- toring information, planning decisions, and profiles of contextual changes. This information is either used to continuously update or extend existing knowledge at runtime.

&

als

The knowledge is representable via three different types [IBM06].

• Solution Topology Knowledge. Captured knowledge about components and their architecture, e.g., dependencies between components such as nav- igation system requires GPS.

• Policy Knowledge. A policy is knowledge that is used to decide whether an adaptation is necessary and which changes have to be applied. Thus, a policy corresponds to a set of constraints or preferences that influence the analyze task and planning task.

• Problem Determination Knowledge. Problem determination knowledge includes monitored data, symptoms and decision trees. This knowledge is used to further derive or update existing knowledge at runtime, i.e., via learning algorithms or profiling.

The main part of this thesis is focused on the plan task based on a knowledge model. Relation to the other tasks of monitoring, analyze, and execute are pointed out, but it is assumed that these tasks are provided as a black-box. The next section points out research challenges that are addressed in this thesis.