FESAS Adaptation Logic Template

For building the adaptation logic, there are different approaches present in literature. The managed resources and the adaptation logic can be integrated following the internal approach or separated according to the external approach.

6.1. System Model for the FESAS Framework

As we aim at a reusable adaptation logic, the adaptation logic should be sep- arated from the managed resources as this improves reusability (cf. require-

ment RDev1). All approaches have in common that the adaptation logic is com-

posed of [229, 403]: (i) control structure components including components for the connection to the managed resources and, optionally, (ii) supporting compo-

nents (cf. requirements RDev2.i and RDev2.ii), such as the context manager spec-

ified by requirement RDev4. Figure 6.1 shows the elements of the FESAS Adap-

tation Logic Template. Integrating this reference architecture presented in [228]

into the FESAS Framework satisfies requirement RDev2. In the following, this

section introduces the FESAS Adaptation Logic Template. Parts of this section are taken from [228]1_.

Request Data Instruction

Managed Resource Probe Actuator Actuator Analyzer Monitor Executor Sensor Adaptation Logic Knowledge Context Actuator Physical Sensor Context Manager Planner Probe Probe Effector

Figure 6.1.: The FESAS Adaptation Logic Template extends the MAPE cy- cle with a context manager for abstraction from specific informa- tion (cf. [228]). Left: concept, right: component model.

Within the SASs research community, the MAPE-K model [198] is the common approach for an adaptation logic control structure [76,229,320,384]. Accordingly, the FESAS Adaptation Logic Template integrates this model for adaptation con- trol. The knowledge component acts as a central repository for all kinds of data used in the adaptation logic and supports the MAPE functionality. Often, a SAS is a system-of-systems and the adaptation logic is distributed in these cases. Therefore, the adaptation logic template offers flexibility for decentralization and

distribution of its components (cf. requirement RDev3.i). This requirement is

addressed in the FESAS Adaptation Logic Template as the components for the

6.1. System Model for the FESAS Framework

MAPE functionality are optional for a specific subsystem, but must be present in the global view of the SAS. Furthermore, one subsystem can have multiple MAPE loops, e.g., for supporting different self-CHOP properties [198]. Follow- ing the MAPE-K model [198], the template provides sensors and effectors for interaction with the managed resources. Sensors read information from so called probes. These probes store information about (i) the resources themselves (self- awareness), (ii) the environment (context-awareness) – collected by the managed resources using physical sensors (e.g., GPS, infra-red sensor, or camera) –, and (iii) information about the users. An effector uses specified interfaces, so called actuators, to enact the adaptation actions. These actuators trigger changes of the managed resources or adapt the environment using context actuators of the managed resources.

Additionally to the MAPE functionality, the FESAS Framework integrates the context manager [228] to improve the context-awareness and support context

adaptation (cf. requirement RDev4). The context manager (i) receives context in-

formation which is gathered through physical sensors of the managed resources, (ii) aggregates the data of sensors, and (iii) maintains a context model. Fur- thermore, the context manager integrates an architectural model of the managed resources. This way, the MAPE functionality can be decoupled from the specific data retrieved from the managed resources. Therefore, the MAPE components can operate on a higher level of abstraction. This improves the reusability of the MAPE components and algorithms within these components as there is no need to customize them for each use case.

The FESAS Adaptation Logic Template is a rather high level concept. Driven by the idea of further improving reusability, in [228], we presented the FESAS Component Template for a MAPE component. In the following, the section presents this template. Based on the Template Method pattern [137], the MAPE components are composed of an exchangeable logic – e.g., for an analyzer, this would be an algorithm for analyzing the monitored data – and logics for communi- cation and data handling, i.e., serialization and access to a knowledge repository. The communication logic offers methods for receiving and sending data to other components as well as requesting data from other components. Figure 6.2 shows the template for a MAPE component.

6.1. System Model for the FESAS Framework receiveData() extRequest() sendData() requestData() In Out Functional Logic Logic1 … LogicN callLogic() prepareDataForSending() AL component Logic Request Data MAPE Component

Figure 6.2.: The FESAS Component Template (cf. [228]) separates generic func- tionality, such as communication between MAPE components, and specific code for the algorithms of the MAPE functionality. This improves the reusability of code. Most of the methods are imple- mented by components of the FESAS Framework. Developers can focus on implementing the functional logic (bold marked box). Ap- pendices B.1 and B.2 provide the descriptions of the interfaces.

The separation of the functionalities in reusable communication sub-components and customizable functional logics supports reusability. Further, encapsulating a specific algorithm within a functional logic element enables a separation from reusable methods for using the communication module or controlling the work- flow. In object-oriented programming languages, inheritance supports this struc- ture. Functional logic elements inherit most methods from an abstract logic. Only the callLogic() method for its function has to be implemented or the developer has to specify which logic should be loaded from a repository. Addi- tionally, one MAPE component can integrate various functional logics, e.g., a monitoring component with different algorithms for different sensor types. The component template enables reusability w.r.t. different aspects. First, the com- ponent itself is reusable. It offers a skeleton of methods for calling the functional logic, communication, and knowledge handling. Furthermore, exchanging the functionality is simplified as the interfaces stay stable. Additionally, it is possible to use the same component skeleton for all adaptation logic components. Only the functional logic must be customized to its purpose, which satisfies require-

ment RDev5.ii. Second, reusability is offered as the interfaces provide generic

6.1. System Model for the FESAS Framework