## 2 System Design
The input and output ranges for both function are normalized between \(-1\) and 1. The functions were designed based on engineering expertise and criterion, and after observation of the system behavior in a simulated environment. Figure 2: Fuzzy transfer functions. (**a**) FDM1; (**b**) FDM2. _FDM1_ determines the increment on the transmission power to be applied depending on the difference between the desired number of neighbors and the present one. If the present number of neighbors is greater than the desired one, the transmission power will be increased, and decreased otherwise. For a negative input the function has larger slope than for positive values. The idea is to get large changes for negative values (the present number of neighbors is greater than the desired one \(ND_{R}\)) in order to save energy consumption due to lower transmission power required. By other side, _FDM2_ adjusts the desired number of neighbors for each WSN node and is linear in the range between \(-1\) and 1. The desired number of neighbors for a node will be decreased if the battery level drops below a critical value. In addition, the Figure 1 also provides a different view of the system as consisting of three blocks: _Monitoring_ (comprises the tasks _TM1_ and _TM2_), _Reasoner_ (comprises the tasks _TR1_ and _TR2_) and _Actuator_ (comprises the task _TA1_), which complies with the architectural model MAPE-K (Monitor, AnalyZe, Plan, Execute, Knowledge) [13] and has driven the software design of the system. The Figure 3 proposes a general software design for accomplishing self-adaptive systems based on MAPE-K. It is based on the one fully described in [14], customized for the SunSPOT platform. The components _PowerScalingMonitor_, _BatteryLevelObservation_ and _NodeDegreeObservation_ in Figure 3 shape the _Monitoring_ block in Figure 1. The component _PowerScalingMonitor_ monitors, at a specific rate, the number of neighbors (also called _node degree_) and the battery level of a node, and also decides if the change in any of those values is significant enough to run the reasoner, the component based on fuzzy control that establishes the desired transmission power. The components _BatteryLevelObservation_ and _NodeDegreeObservation_ measure respectively the battery level and the number of neighbors of a node. The component _PowerScalingController_ accomplishes the _Reasoner_ block in Figure 1. This component's parameters must be tuned whenever a change in the dynamics of the control system is needed. The component _PowerTransmissionActuator_ carries out the _Actuator_ block in Figure 1, is able to modify the transmission power of a node based on the desired value specified by the invoking component. Finally, the component _ORAMediatorForSunSpot_ enables interaction among the rest of components. It behaves as a broker decoupling observers, reasoners and actuators. Figure 3: Software components accomplishing the self-adaptive system improving the energy consumption while keeping the communication connectivity. Whenever a component is registered in the _ORAMediatorForSunSpot_, the rest of registered components are aware of that, thus they can access the new one if needed. The new components are registered by means of the interface _ORAMediator_. The regular interactions among components is depicted in the UML sequence diagram in Figure 4. The _ORAMediatorForSunSpot_ will start the _PowerScalingMonitor_ component by means of the _TriggerPolicy_ interface. That component will measure periodically the number of neighbors and the battery level of a node and will decide, based on such values, if it is worth triggering the reasoner to make new decisions, by means of the _Reasoner_ interface. The _PowerScalingController_ component will request the latest measures by means of the _ObservationProvider_ interface whenever triggered. The _ORAMediatorForSunSpot_ component captures the request, gets the data from the observer by means of the _Observer_ interface and finally fulfils the _PowerScalingController_ request.