The application of a self-adaptation depends on various aspects, e.g. the chang- ing needs of a user, environmental characteristics, and system properties. Under- standing the problem and selecting suitable solutions require precise models to represent environment, users, and the system [CLG+09]. This section introduces a classification scheme taken from [CLG+09,ALMW09] to describe the most im- portant facets of SAS. The classification is divided into the four groups (i) goal of an adaptation, (ii) cause of a change, (iii) adaptation mechanism, and (iv) effects of an adaptation.
Goals. Goals are objectives the system has to achieve or constraints that have to hold at runtime [LLYM06]. Such goals may be functional, e.g., “activate GPS during a navigation process”, or non-functional, e.g., “response time for a GPS signal has to be below 2 seconds”. Existing approaches, e.g., goal models [LY04], propose to use quantifiers and hierarchical decomposition into sub-goals to model complex goal structures for SAS. An example goal for mobile devices may be “always provide a connection to the Internet” and a sub-goal may be “prefer WLAN-connection to a cellular-connection”. Important aspects for goals of an SAS are
• Evolution. Depending on the context of a device the goal specification of a system may change dynamically at runtime. However, the specification of a
I ntr od uction F und
ament goal may also change in a static manner at design time if the SAS is changed, e.g., goals are exchanged during a system update.
• Flexibility. Goals do not necessarily specify a rigid system but may be also flexible. The more rigged a goal is the less system configurations are available, which satisfy the requirements of that goal. In that manner, a goal may be rigid, constrained, or unconstrained. A flexible goal is able to handle contextual situations, which are not specified explicitly at runtime.
• Dependency. If a system has to meet multiple goals, these potential goals may be related to each other. Thus, goals may be complementary or conflict- ing to each other. Alternatively, they may also be independent from other goals, i.e., they do not affect each other.
Example 2.4 (Goals of SAS).
The goal “activate flash at night when camera is active” is the static initial specifi- cation of a goal at design time. At runtime, this goal becomes active whenever the user activates the camera during a concert and, therefore, photos are taken with flash. With an update a new filter is deployed on the SAS and with the filter also the goal changes to “activate dark-filter at night when camera is active”.
A dynamic evolution of a goal occurs at runtime. For example, a goal states “use GPS during navigation”. Whenever the smartphone realizes that a GPS sig- nal is not accurate and localization is more precise with an additional cellular triangulation, the goal is updated dynamically at runtime to “use GPS and cel- lular triangulation during navigation”.
The goal “activate dark-filter at night when camera is active” is flexible because it still supports dynamic adaptations. For example, there are no restrictions regarding using flash or GPS while taking a photo. The less requirements a goal specifies the more flexibility is provided to handle additional or even unknown contexts, emerging at runtime.
The goals “use GPS during navigation” and “activate flash at night when cam- era is active” are independent of each other. However, the goal “deactivate all communication signals at night” contradicts the goal “use GPS during navigation”, which implies that a smartphone may not be used to navigate at night.
Change. An adaptation is triggered by changes in the context of a device. If the context changes the requirements for the device also change. Thus, the system has to adapt itself accordingly to re-satisfy the new requirements. To plan a suitable adaptation, information on location, type, and frequency of a change, is important to anticipate the occurrence of a change.
• Source. A change may occur external to the device, i.e., within the environ- ment, or internal within the device, i.e., within the system. Internal changes are investigateable in more detail, whereas the detection of external changes relies on the information of sensors.
&
als
• Type. The type of the requirement change is either functional, i.e., a func- tionality is required or prohibited, or non-functional, i.e., a the system has to satisfy a certain level of quality.
• Frequency. The frequency of a change determines the number of changes over a certain period. The scale may range from once a week over several times per minute to numerous times per second.
• Anticipation. Adaptations are predictable. Such predictions may be used to pro-actively prepare an adaptation. However, different adaptation strategies are necessary, depending on the degree of anticipation. If an adaptation is foreseeable, the adaptation is still uncertain, though likely to occur. There- fore, the system has to plan and reason about such an adaptation. In contrast to that, an adaptation may also be unforeseeable, i.e., unknown or sponta- neously occurring, in which case the system is not able to plan an according adaption [JL10].
Example 2.5 (Change in SAS).
An example for an external trigger to adapt the system is the movement of the user. If the user leaves the context of his home and enters the context of his car, the smartphone adapts itself by deactivating WLAN and activating GPS and the navigation system. An example for an internal trigger to adapt the system is the remaining amount of energy left in the battery. If the remaining energy is low, all media related applications are closed and are prevented to be opened.
A functional goal refers to provided services or functionality of the system. An example for a functional goal is “deactivate WLAN connection in a car”. In contrast to that refers a non-functional goal to the qualitative aspects of a system. For example, the goal “the responsiveness has to be below 1 second” is a qualitative aspect of a connection.
On a standard working day the user enters and leaves his office once, thus the frequency of these changes is once a day.
If the user has a repeating mobility-pattern, an adaptation may be anticipated. For example, if the user always follows the pattern “home → car → office → car → home” the smartphone is able to predict the according adaptations with a certain probability. In that example, the smartphone prepares the adaptation to the context car if the user is still in the context home. However, if there is an unforeseeable event and the car of the user breaks down, the mobility pattern changes, e.g., “home → car → street”, and the smartphone has to adapt whenever the unforeseen contextual change occurs.
Mechanism. The implemented mechanisms capture the reaction of a system towards a change. Therefore, the adaptation mechanism represents the core of an adaptation process. Adaptation mechanisms cover different levels of autonomy and there are several different possibilities to control an adaptation. Additionally, the impact of an adaptation mechanism has to be considered.
I ntr od uction F und
ament • Type. An adaptation is related to either changing the parameter configu- ration of the system or to changing the structure of the active system im- plementation, i.e., exchanging or rewiring its components. Therefore, an adaptation is either structural, parametric, or a combination of both.
• Autonomy. Existing terminology states that an adaptation is either executed autonomous, assisted, or autonomic. An autonomous adaptation process is executed without external influences, besides the contextual information. An assisted adaptation is executed with the support of an external user, e.g., if an adaptation is not executable automatically. Autonomic adaptations are also executable without any external influence. In addition to autonomous adaptations, an autonomic adaptation process is able to learn and to derive new adaptation strategies dynamically at runtime [SSH06].
• Organization. Adaptations are either executed centralized on a single sys- tem, or are distributed over several interacting systems, e.g. peer-to-peer systems, in a decentralized manner. A decentralized adaptation is not con- trolled by a single component or system. Instead, decisions have to be made collaboratively in a network of systems. Similarly, an adaptation is either re- stricted to local adaptations, i.e., one single system, or to global adaptations, i.e., within a network of systems.
• Duration. Depending on the domain, the duration of an adaptation may be a critical aspect to deal with. An adaptation may last from milliseconds up to several hours. However, this characteristic has to be considered relative to the application domain.
Example 2.6 (Adaptation Mechanisms of SAS).
If a smartphone is connected to a desktop PC, the smartphone becomes an ex- ternal harddisk. This is an example for a structural adaptation because a specific driver is activated on the smartphone to turn it into an external harddisk. If the smartphone has to adapt to a silent mode, the ringtone and other notification signals become silent. This is an example for a parametric adaptation because the volume parameter is adjusted to zero.
An example for an assisted adaptation is the manual selection of the user to communicate via WLAN instead of LTE. In this case, the adaptation is man- ually triggered and requirements are specified by the input of the user. The automatic activation of GPS and starting of the navigation system whenever the user enters a car is an example for an autonomous adaptation. In this case, the smartphone adapts itself automatically based on the contextual information. If the smartphone recognizes that a connection via LTE is better, e.g., more re- sponsive, than a connection via GSM and triggers an adaptation for this reason, the smartphone is capable for autonomic adaptations. In this case, the smart- phone is able to learn and optimize the overall adaptation process by changing adaptation goals or creating new adaptation goals on its own.
Until this point of this thesis, the given examples for an adaptation are in- tended for a single systems, i.e., centralized on a single smartphone. However, if
&
als
data has to be exchanged between two smartphones, the smartphones have to reason about the protocol, e.g., Secure Copy Protocol (SCP) or File Transfer Pro- tocol (FTP), and type of communication, e.g. Bluetooth or WLAN. They have to agree on one single solution within the capabilities of both devices. This is an example for a decentralized adaptation because the adaptation has to be or- ganized between the participating smartphones without a central smartphone that makes a decision.
Starting the navigation system of a smartphone after arriving in a new coun- try may trigger the download of the required street maps to perform a valid adaptation. In this case the adaptation may last for several minutes or hours, depending on the available connection and the amount of data. Although this is not safety critical, e.g., it does not lead to a traffic accident, it may lead to inconvenience if the user is impatient.
Effects. Every adaptation has an impact on the system it adapts. While the mechanism category deals with the adaptation itself, the listed effects are associ- ated to the overall SAS, for which the adaptation is performed.
• Criticality. The criticality of adaptations describes the impact of erroneous adaptations. This ranges from harmless to goal-critical or safety-critical.
• Predictability. Another important aspect are effects of an adaptation on the system and whether they are foreseeable. An adaptation may perform as expected, in which case guarantees may be specified. However, an adap- tation may further perform differently each time it is executed, e.g, if the adaptation is flexible regarding the result. In that case, only limited or none guarantees are specifiable.
• Overhead. The overhead deals with the additional negative impacts on the overall system performance during an adaptation. An adaptation constantly has to be non-intrusive to the system and, therefore, should always consume a minimal amount of memory and computational power [MRD08]. In the worst case, an intrusive adaptation leads to thrashing and, thereby, a system ceases to provide its services [BMSG+09].
Example 2.7 (Adaptation Effects on SAS).
The adaptation “activate the navigation system” fails if the smartphone has not enough battery available to support GPS and the navigation. In that case the adaptation fails to complete. The failing of this adaptation is non-critical if the user is not yet driving. However, if such an adaptation fails while the user is driving his car and depends on the navigation system, a failure becomes more critical because it distracts the user.
The adaptation for the contextual requirement “deactivate all communication signals at night” results always in the same system configuration where all com- munication related aspects of the smartphone are deactivated. The more flexi- ble requirement for the contextual requirement “activate dark-filter at night when camera is active” may not always lead to the same system configuration. The
I ntr od uction F und
ament requirement specifies no restrictions regarding the activation of additional fil- ters, such as a black-white filter. Therefore, one adaptation may activate the black-white filter and the next adaptation for that context may not activate that filter. In that case, the effects of the adaptation are not foreseeable.
Every adaptation consumes resources. For example, every context has to be identified, e.g., by using the sensors of the smartphone to identify if the user enters a car. Thereupon, the adaptation mechanism has to compute, which changes are to be made and how the requirements are to be satisfied, e.g., GPS has to be activated and the navigation system has to be loaded. Finally, the adaptation has to be executed, e.g., GPS is being activated and the navigation system is being loaded. The more resources such an adaptation consumes, the more overhead it generates. If the adaptation consumes most of the available resources, other services, e.g., receiving emails, may be suspended.
The adaptation aspects of goals, change, mechanism, and effects are used to describe and to evaluate the capabilities of an SAS. Although this classification provides a holistic overview of the concept behind SAS the matter of a technical implemen- tation is still unaddressed. Therefore, the Monitor-Analyze-Plan-Execute-Knowl- edge (MAPE-K) paradigm is introduced in the next section, as a common ap- proach to handle the inherent dynamics of mobile devices at runtime.