This section describes our DSPL for the self-adaptation of IoT devices. In addition, we illustrate its application in a real IoT device, a Smart Cane platform. This case study is very illustrative of e-health applications for several reasons. Firstly, it contains the architectural elements generally needed in healthcare IoT systems [
15], which includes the body area sensor network (i.e., the Smart Cane) and an Internet connected gateway (i.e., the smartphone) (see
Figure 2). Secondly, it deals with non-functional concerns that are usually in most of m-health applications, i.e., battery consumption and relative error. Finally, it has practical implications regarding issues that should be resolved in most m-health applications to make self-adaptation possible, like the ability to measure battery consumption. Although in this paper we will focus on a Smart Cane device, our approach can be integrated with any IoT device able to provide information about its current state.
4.1. Architecture of the DSPL
In a previous contribution, we introduced a goal-oriented self-adaptation approach based on DSPL for agents in the IoT [
6] that uses preference-based reasoning for plan selection. However, the focus on agent architectures hindered the applicability of the approach due to the immaturity of agent technologies, the limited support for standardization in the communication between agents, and the lack of tools to support agent development [
16]. Therefore, in this contribution, we focus on an evolution of this proposal named Tanit (goal-orienTed dynAmic software product liNes wITh preference based reasoning) for general purpose self-adaptive architectures. The main differences of Tanit with the previous proposal are related to the application model, the information contained in the DSPL, and the implementation. In [
6], software agents are used to model all the elements of the system, but agent technologies introduce an overhead derived from the reasoning engine or an agent platform, just to mention a few sources, which is not necessary for all IoT systems. Therefore, instead of self-adapting the internal components of the agent embedded in a IoT device, the Tanit approach presented here is implemented as an adaptor that adds self-adaptation capacities to an external IoT system, in this case, the Smart Cane platform.
The combination of DSPL and goals allows to select the most appropriate dynamic configuration (see
Section 3.1) taking into account different system goals during the work of the system. For example, when the battery level is high, the goal of the DSPL could be to decrease response time, but when the battery level is low, the goal could be to elongate the life of the system. Goals in DSPL approaches are usually static and do not change during the system’s lifetime [
4]. Additionally, the use of preference based reasoning allows to select how these goals are accomplished, taking into account other non-functional concerns of the system like response time or precision.
Tanit uses a closed-loop architecture (see
Figure 3) that is continuously monitoring the system and its context, to detect changes that require adaptation. When this happens, a goal that represents the system-to-be is activated. After that, the planning component selects a plan to achieve the activated goal. Self-adaptation plans are the means to achieve a goal, but they do not include specific actions, just features that should be enabled or disabled to achieve a new configuration. They do not specify what happens with the rest of the features of the system to adapt. This issue is decided at runtime, so we use a hybrid approach to compute the dynamic configurations.
The plan selection, which is the key issue in Tanit, is addressed using a preference-based reasoning approach [
17]. This kind of reasoning guides the selection of plans taking into account contextual information. In our case, we use two factors of the system named
wellness and
usefulness. System wellness is concerned with the quality or state of being in a good condition, and it is defined in terms of its internal state features such as available resources (e.g., battery level). The system usefulness is measured in terms of the goals that the system potentially can bring about and the goals that are being currently maintained. In general (but not in all cases), plans that increase or emphasize system usefulness tend to deteriorate system wellness. Both metrics are inferred from the current configuration of the system architecture, and they are used to drive the selection of plans. Reconfiguration plans are tagged with their contribution to system wellness and usefulness. The reasoning mechanism of Tanit chooses the plans taking into account these factors by using Equation (
1), where
is the usefulness of the plan
P, to achieve the goal
G for the adaptive system
A, and
is the effect of plan
P in the wellness of the adaptive system
A. By using this equation, when the wellness factor is good, our DSPL tends to choose those plans that increase its usefulness, exploiting the welfare state of the system. When the wellness of the system gets worse, the DSPL behaves conservatively to maintain its current state although its usefulness decreases. A simulation of the behavior of this equation is presented in [
6].
4.2. Integration with the Smart Cane Platform
In order to integrate the Smart Cane platform and Tanit, we have embedded Tanit inside the mobile app of the Smart Cane platform (see
Figure 2). Tanit receives from the Smart Cane information about the battery level of the system, and sends configuration commands back to the cane. Internally, Tanit analyses the battery state of the Smart Cane (in the analyze component) and determines the reconfiguration to do. This behavior is supported by the Android Activity Recognition API too, so it can make self-adaptation decisions taking into account that the user is stopped or moving. Tanit self-adaptation policies are goal-oriented. Roughly, the policies consider four goals: (a) high accuracy (the measurements are close to the real value) when the battery is high; (b) save energy when the battery is low; (c) set the Smart Cane into sleep-mode when the user is stopped; and (d) wake up the system when the user starts moving. Tanit has different plans to fulfill these goals that deal with changing the sampling rates of the force sensor and the battery sensor and enabling or disabling the neural network.
The current configuration of the system is represented by a feature model configuration. The feature model that drives the behavior of the self-adaptation is depicted in
Figure 4. This feature model contains all the goals and plans that the DSPL requires to adapt the system and the services of the Smart Cane and their configuration options. Additionally, it has some cross-tree constraints to model dependencies between goals, plans, and services. A goal cannot be active in the feature model if there is not a plan to accomplish it (e.g., in C1 the goal
Save_Energy is active if
Disable_nn or
Decrease_battery_frequency or
Decrease_force_frequency are active), and a plan cannot be active if its pre-conditions do not hold (e.g., in C2 pre-condition of
Increase_Force_frequency is
!5). Additionally, we consider quality levels of services that are related to their configuration parameters (e.g., in C3
Battery_quality.Q1 is linked to the parameter
1).
As we have explained, plan selection is made using preference-based reasoning based on wellness and usefulness. Our wellness factors are the battery level of the microcontroller and the relative error of the system, which are related to the use of the neural network and the sampling frequencies. When a goal is activated, the planner component selects the plans whose execution entails the fulfillment of the goal and applies the Equation (
1) to each plan to compute its preference. Then, the plan with the highest preference is executed.
The computation of the preference is based on the estimation of the effect of the execution of a plan and its quality to accomplish a specific goal. The effect of a plan is measured in terms of the system’s wellness and the usefulness of the
dynamic configuration (see
Section 3.1) of the system (i.e., the state of the system after a possible execution of the plan). The future wellness (i.e.
in Equation (
1)) is computed subtracting the effect of the plan from the current wellness of the system. For example, the plan
Enable NN decreases the relative error by 75% and the battery level by 20%, if the current relative error is 20% and the current battery level is 70%, then the effect of the plan in wellness will be 95% and 50%. In order to compute the usefulness of the dynamic configuration of the system (i.e.,
in Equation (
1)), the first task of the Preference-Based planner (see
Figure 3) is to compute this future dynamic configuration. Then, the usefulness is measured in terms of goals that the DSPL can accomplish (i.e., children of the feature
Goals that are active in the dynamic configuration) and the quality of the supported services (i.e.,
QX features under specific services in the feature model). The future dynamic configuration is computed taking into account the current configuration of the system and the features that will be enabled and disabled after the execution of the plan (this information about the plan is stored in the plan library, for example, the plan
Increase Battery Frequency is labelled with the activation of the feature
5, see
Figure 4). The activation/deactivation of features can cause the activation/deactivation of other features to meet tree and cross-tree constraints (e.g., the deactivation of the feature
Battery Service causes the deactivation of the sub-tree under this feature). Then, the value of usefulness is computed using the
QX features and the features under
Goals, and adding to this value the quality of the plan to accomplish the goal (this value is stored in the plan library). Finally, the equation
1 is applied to compute the preference of the plan.
Taking into account the self-adaptation goals of our DSPL, it must be possible to change on the fly the sensor sampling rate and the approach to estimate the support and non-support period (i.e., finite state machine or neural network). Additionally, the battery level should be available on-demand. We have implemented this functionality using the BLE connection between the mobile phone and the BLE microcontroller (see
Section 3.2) and Android Services. The mobile phone sends small messages of 3 Bytes to the microcontroller to adapt its behavior. Messages use 1 byte for the force sensor sampling rate (from 0 Hz to 255 Hz), 1 byte for the battery reading period (0 to 127 min), and 1 byte to enable or disable the neural network. On the other hand, the mobile phone receives information about the state of the Smart Cane platform in messages of 20 bytes.
In order for the Smart Cane platform to self-adapt, it is fundamental for it to have on-demand information on the battery level of the microcontroller. This information is not provided by any built-in sensor, so some modifications in the Smart Cane were performed. Firstly, we need to measure the battery voltage level. The battery has a support voltage from 3 V to 4.2 V, but the analog digital converter (ADC) of the microcontroller works in a range from 0 to 3.6 (with a 1/3 prescaler). Therefore, we have located the voltage divider between the battery and the ADC; this reduces the voltage in a factor of 0.866 (see
Figure 5). Hence, the ADC can read these voltages from the battery and transform them into values in the range 0 to 1023, representing 1023 the 100% of the voltage level, i.e., maximum voltage (4.2 V) and 0 the 0% of the voltage level, i.e., the minimum voltage (3 V). This information is sent to the mobile phone using the BLE battery service. This voltage level is related to the battery level, but there is not a linear relationship between them. This relationship mainly depends on the battery used, its capacity, and its discharge current. To calculate this relationship, we need the profile of the battery. The battery profile shows how a voltage decreases over time for a discharge current established (
Figure 6a). Since the discharge current is constant during this profile, the area below the discharge current line provides the capacity of the battery (mAh). This can be used to calculate the battery capacity that the system will use for a voltage level before change to a lower voltage level. For example,
Figure 6a shows how the system will consume 22.79 mAh during the 82% voltage level (4.22 h at 5.4 mAh). Furthermore, the same approach can be used to estimate the battery level given a voltage percentage by adding all the capacities of voltage percentages lower than the current one. This addition divided by the overall capacity of the battery provides the battery level (see
Figure 6b). This estimation of the battery level always underestimates the real one because it only adds the capacities of the lower voltage levels (i.e., the actual one is not considered), and the discharge current used to create the battery profile is higher than the Smart Cane real consumption. Taking into account Peukert’s law [
18], the overall capacity of the Smart Cane’s battery is always higher.