5.1 Introduction

High‐impact applications enabled by BSN‐based systems are required to be secure, safe, and reliable, especially when dealing with the monitoring and controlling of the physical and biochemical parameters of the human body. Achieving correctness, accuracy, and efficiency at execution time by meeting the strict requirements in terms of fault tolerance, adaptability, and reliability is of crucial importance and a very challenging issue. In this regard, the autonomic computing paradigm can perfectly fulfill such critical requirements of BSN applications in which proper techniques can be incorporated to enable specific self‐managing capabilities and successfully cope with unforeseen changing conditions that may lead to unpredictable behaviors.

This chapter first introduces background concepts on the autonomic paradigm and its application on the BSN context. Then, the needs for BSN‐specific autonomic‐enabling development tools are discussed. Finally, a framework conceived to support rapid design and implementation of applications having autonomic properties, SPINE‐*, is presented. Implemented as an extension of SPINE2, the autonomic elements are incorporated into the same high‐level abstractions adopted for developing the BSN applications. Specifically, it aims at easily integrating the autonomic behavior without affecting the applications, thanks to the adopted task‐oriented paradigm, which allows for the required separation of concerns between the user‐defined application business logic and the autonomic‐related operations.

5.2 Background

The term Autonomic Computing (AC) was coined by researchers in IBM [1], who advised the need for a management component acting in a similar fashion to the autonomic nervous system of the human body, in response to the increasingly complexity of managing computing systems. The AC paradigm was then conceived for dealing with the complexity of distributed software systems and enabling mission‐critical applications to meet high reliability and adaptability requirements. It faces the problem by introducing a series of self‐* properties, thanks to systems that are able to perform several self‐management actions with no direct human intervention. The main self‐* properties (usually known as self‐CHOP properties) are the following:

• Self‐configuration: depending on high‐level policies and objectives, a system is able to effectively configure and adapt itself on the basis of the user’s needs and environmental conditions by dynamically adding, replacing, or removing its components with no system outages.
• Self‐healing: to guarantee an adequate level of reliability, the system should autonomously prevent, detect, and possibly remedy malfunctions and errors. The nature of possible problems that can be detected spans from low‐level hardware failures to high‐level erroneous software configuration. However, it is important that the operations related to the self‐healing process do not affect other vital components in the system.
• Self‐optimization: the system should perform its activities by proactively and effectively targeting the maximum performance given the restricted available resources. This optimization process should constantly seek performance improvement without interfering with the system in achieving the user‐defined goals.
• Self‐protection: systems with such a property are able to guarantee an adequate level of security in terms of detecting, and possibly preventing, malicious attacks aimed at disrupting the normal planned system operations. Moreover, the system should also protect itself from user inputs that may be inconsistent, implausible, and dangerous.

5.3 Motivations and Challenges

As discussed in the previous chapters, BSN developers can benefit from the use of programming frameworks (e.g. SPINE, SPINE2, and MAPS), which target ease of development, fast prototyping, code reusability, efficiency, and application interoperability. However, the global quality of the applications not only derives from the use of a well‐defined programming approach and related tools, but also on how good they are designed and implemented to deal with the changing conditions and possible problems due to the interaction with the environment and other interconnected systems. In fact, since unpredictable conditions (e.g. sensing faults) may lead to unwanted behaviors at execution time, it is not reasonable for a BSN system to be constantly supervised and maintained by human operators once deployed. Therefore, despite usual development issues are proven to be successfully addressed by the most common programming frameworks, the way in which the correctness of applications, during the post‐deployment stage, has to be defined is usually completely up to the developers. And this is becoming a particularly challenging task in view of the fact that evermore complex BSN applications will need a better runtime support as a result of the immersion of people into more pervasive, smarter, but also risky environments.

Providing an effective approach to allow developers providing self‐managing capabilities and easily integrating them into applications, in order to improve reliability and maintainability, is a major challenge. Unfortunately, most of the currently available BSN programming frameworks represent trustworthy tools for defining the high‐level application logic, but they do not provide an explicit and clear way for designing an underlying autonomic structure capable of addressing the application management requirements.

5.4 State‐of‐the‐Art

The integration of the autonomic principles into networking systems has been studied and proposed in many research works [2, 3]. Also, real prototypes have been developed, deployed, and tested as releases of several international projects: BISON [4], ANA [5], Haggle [6], CASCADAS [7], EFIPSANS [8], and Autonomic Internet [9].

However, differently from traditional networks, the peculiar characteristics of sensor networks make the design and implementation of the autonomic management approaches even more challenging, and to date, this branch of research has not been satisfactorily investigated yet. Examples of autonomic‐oriented system architectures explicitly designed to support sensor networks management are MANNA [10], BOSS [11], WinMS [12], and Starfish [13].

MANNA [10] is a generic architecture providing three different abstraction planes, one for each management function: functional areas, management levels, and WSN functionalities. The latter includes basic low‐level operations like sensing, processing, and communication, whereas the management levels represent the typical system’s layers, i.e. the business logic, the middleware services, and the networking layer. Finally, the functional areas represent, for each aforementioned system’s layer, the different perspective to which autonomic actions can be applied, specifically configuration, maintenance, performance, security, accounting, and fault management perspective.

Based on the standard UPnP protocol, the BOOS architecture [11] is designed to support automatic discovery, configuration, and controlling of devices over traditional networks, by avoiding any manual setup. Due to the limited resources of sensor devices, to fully support UPnP functionality, a mediator component running on the coordinator serves as a provider of the required services for network management. The BOSS architecture is constituted of several functional components: control manager, service manager, event handlers, and sensor network‐level management functions.

WinMS [12] is a network management system able to support dynamic adaptation of nodes as a response to changing network conditions. Depending on high‐level policies, WinMS is based on a local management scheme, which works according to the neighborhood network state, and a decentralized scheme, which depends on global network‐level knowledge. The low‐level communication is provided by a lightweight TDMA protocol, FlexiMAC, supporting a tree‐based gathering scheme, which is in charge of collecting and disseminating network state data and management information.

Starfish [13] is a framework conceived to support the definition of self‐adaptive behaviors in sensor networks. Specifically, a node‐side policy management system, called Finger2, is in charge of executing the adaptive strategies dealing with the management of reconfigurations and failures. Such strategies are specified by the developers through a desktop client tool, which includes a set of libraries to facilitate the programming of nodes by providing a high‐level language for defining both autonomic policies and user’s application logic.

Although the previously described frameworks and architectures are examples of generic self‐management systems, most of the current research efforts are mainly focused on self‐healing and fault management [14–24]. Moreover, these studies are usually carried out by considering the WSN context, whereas few efforts are devoted to BSNs. This is why we aim at addressing such a shortcoming by specifically exploring the viability and convenience of autonomic computing in the BSN context.

5.5 SPINE‐*: Task‐Based Autonomic Architecture

Due to the intrinsic complexity of distributed computing systems, like BSNs, there exist different approaches for integrating the autonomic properties, which can be applied at different system’s perspectives: network‐level, communication stack‐level, software layer‐level, service‐level, function‐level, or component‐level.

However, we advise the practice of clearly and explicitly separating the application business logic from the implemented autonomic management operations. If well‐designed, the main benefit from using such separation of concerns is that the application developer’s efforts can be focused on the characteristics of the application and its primary goals, without being forced to take care of any of the autonomic management components. In fact, the autonomic behavior can be easily added afterwards, with no risk of affecting the previously defined application logic.

In the following, an autonomic architecture fulfilling the aforementioned requirements is presented. It has been designed and implemented around the SPINE2 framework, whose task‐based abstractions provide the necessary mechanisms for assuring the application isolation and composition properties. The autonomic features have been added to SPINE2 without affecting the original runtime engine but instead only involving its task library, which has been enhanced with the introduction of a new set of autonomic‐specific tasks. The way a SPINE‐* application can be defined is depicted in Figure 5.1. Such an application is constituted by a multiplane architecture which, in its basic configuration, is composed of two distinct planes, one representing the user application logic and the other providing the autonomic operations. Since a task is only aware of its input data, it is clearly possible to employ a generic nonautonomic task in the autonomic plane on the basis of specific needs. Also, it is worth noting that, differently from the application example provided in Chapter 4 (see Figure 4.2), all tasks have been depicted with no assumption on their specific types.

Different kinds of interactions can be established between the planes for performing direct manipulation on the application data streams or reconfiguring the application tasks. Despite such interactions, the degree of isolation in the execution of tasks guarantees that the separation of concerns’ property still holds, with the application plane having no awareness of the presence of the autonomic plane.

The generic architecture of Figure 5.1 shows two specific autonomic approaches. In the first case, the parameters of task T7 are tuned at runtime so as to optimize its function and thus adapting its behavior depending on the data originating from task T1. Specifically, the adaptation action is performed by the autonomic task AT2 after a preprocessing made by AT1 on the source data coming from T1. Since no data stream is injected to the application plane, but rather a reconfiguration action is performed, such an interaction (configuration connection) is represented with a dashed arrow from AT2. In the second case, supposing that the aim of the autonomic tasks AT3 and AT4 is to improve the quality of data, the output data stream from T5 is redirected to the autonomic plane, specifically to T9. In turn, T9 provides AT3 and AT4 with the data stream to be analyzed and manipulated prior to feed the aggregator task T10, which is in charge of fusing the two data streams and sending the resulting stream to T6. In such a configuration, the direct connection T5–T6 has been removed and replaced with the subgraph of tasks in the autonomic plane.

The proposed task‐based multiplane autonomic architecture can be employed in many common situations in which self‐* properties need to be satisfied. In the following, some examples of task‐based application enhanced with the SPINE‐* autonomic mechanisms are presented. In particular, we show the four self‐CHOP properties: self‐configuration, self‐healing, self‐optimization, and self‐protection.

As represented in the reference architecture of Figure 5.1, a useful property of BSN applications is the ability of autonomously reconfiguring the parameters of a task at runtime depending on the changing system and/or environmental conditions. As shown in Figure 5.2, two different ways for triggering a reconfiguration task can be adopted. In Figure 5.2a, the SensReconfig task of the autonomic plane is driven by the output results of the Processing task (which performs some kinds of analyses on raw sensed data). Specifically, the SensReconfig task is able to modify the application behavior by acting on the Sensing task parameters, e.g. the sampling rate, or even disabling/enabling its execution. In a similar way, the example depicted in Figure 5.2b shows a ReconfigTask acting on both the Sensing task and the Processing task. However, the autonomic task execution is not triggered from inside the task application but instead the desktop application running on the BSN coordinator (as well as on a remote computer) is in charge of driving the autonomic action, for instance when a different sensor data acquisition or processing is needed on the basis of new requirements or some changing conditions recognized on the coordinator side.

Another important and critical issue for applications in the health‐care domain is the ability of recovering from possible faults and errors occurring in data, algorithms, or networking functionalities. Thus, the self‐healing property becomes a crucial requirement to be fulfilled not least because reliability and correctness of the provided services have to be autonomously and continuously guaranteed at runtime by the system itself without requiring the intervention of the operators. As an example, Figure 5.3 shows the autonomic tasks interposed between the sensing layer and the processing layer so as to determine the quality of the raw data from the sensors and thus to avoid that corrupted samples (when detectable) could affect the computing functions and thus the whole application accuracy and erroneous behavior. Specifically, the FaultsDetection task may be conceived as an online detection process for specific faults in the data stream coming from the Sensing task, which is also in charge of possibly redirecting the corrupted stream to the FaultsFiltering task for the actual recovering process. As discussed in Ref. [25], different kinds of data faults can heavily impact the application correctness. Moreover, it is also shown that not all of them can easily be treated with proper recovery techniques in order to improve system’s tolerance to data faults and then achieve better efficiency and reliability.

As for the optimization of BSN applications, one of the most critical issue is to determine the proper conditions that allow to extend the operating life of the wearable devices. Since the radio data transmission and the sensing process (depending on the type of the physical sensor in use) are the most energy‐demanding operations, it is reasonable to extend the typical Sensing–Processing–Transmission application pattern with proper autonomic tasks for optimizing such operations depending on some specific conditions and requirements. For instance, as shown in Figure 5.4, the sampling rate can be adapted, at runtime, on the basis of the variability of the resulting output of the processing task. In fact, such that it can be reduced when the data samples do not change so much for a certain period of time, i.e. when the sensor data variability remains below a certain threshold. For the same reason, the radio transmission of such data can be avoided when the application on the coordinator‐side does not need to be continuously fed with slightly changing data streams and thus saving energy on the battery‐operated sensor nodes by optimizing the most power‐hungry operation.

Due to the distinct features of BSNs, like the sensitive nature of data managed (biomedical and personal information), wireless communication, and mobility of sensors, privacy and security represent major concerns for wearable systems to play a significant role in the e‐health‐care domain. Thus, enhancing the monitoring of physical environment with proper security mechanisms is of prominent importance. The task‐based autonomic architecture of SPINE‐* does not aim at addressing such issues with specific self‐protection mechanisms to contrast external attacks but is intended to provide a proper way to encapsulate such security solutions in reusable components to be directly plugged into the task application when required. As a very simple example, the DataEncryption task of Figure 5.5, which usually demands a lot of computation, can be activated during outdoor activities or when in public untrusted environments but disabled when running at home and secure locations, so as to adapt the application to the execution context.

5.6 Autonomic Physical Activity Recognition

In the following, the benefits of SPINE‐* in a real BSN application are presented. Specifically, the existing physical activity recognition described in Refs. [26, 27] is considered as testbed application, which has been turned into an equivalent autonomic version. The whole system consists of a desktop application running on the coordinator and responsible for classifying postures and movements through a k‐NN‐based classifier to be applied on pre‐elaborated data gathered from waist‐worn and thigh‐worn sensors, both equipped with a 3‐axis accelerometer. In particular, the node‐side applications consist of (i) sensing the accelerometer sensors, (ii) computing the mean, max, and min features over specific accelerometer axes (also called channels), and (iii) merging and transmitting the results to the coordinator. In Figure 5.6, the two node‐side applications, designed through the task‐based programming abstraction approach and with no autonomic tasks, are depicted.

Even though such an implementation provides a core functionality for the system to work, it does not include some important features that could be fundamental in case of unexpected conditions. In particular, it is completely unaware of the quality of the data streams coming from the accelerometers and, as a consequence, the activity recognition could provide incorrect detection results. Hereafter, we show how the addition of an autonomic plane, and specifically the integration of self‐healing tasks, is beneficial in case of corrupted data. In this regard, the impact of sensed data faults on the activity recognition accuracy is first reported. Then, the improved system fault tolerance and reliability is shown by adopting a proper self‐healing layer able to detect and possibly recover such data faults at runtime.

The evaluation approach that we consider consists in carrying out a testbed on the specific predefined sequence of activities shown in Figure 5.7, starting from the “Standing Still” state, and with each state roughly lasting 30 s.

The accelerometer sampling time has been set to 25 ms, whereas the features of the processing tasks (see Figure 5.6) are computed over 40 sampled raw data, every new 20 acquired samples (shift). The k‐NN‐based classifier has the parameter K set to 1, whereas the Manhattan distance has been adopted due to its excellent performance on well‐separated classes (i.e. the states of Figure 5.7). According to such setting and assuming lack of faults in the raw data streams, the classification over the whole activities’ transition pattern of Figure 5.7 has obtained an accuracy of 99.75%.

In order to evaluate the impact of erroneous sensor readings on the classification accuracy, we have carried out several tests by considering the original raw data streams and altering them with artificial injected faults before feeding the processing layers of the applications of Figure 5.6. As data faults injection, we consider the models identified in Ref. [22], and in the following, we focus on short faults. Such faults consist in irregularities disseminated over a data stream and are modeled as random spikes with parameters P and C, where P is the percentage of raw data affected by spikes and C is the intensity factor, which means that the value of a spike is determined by multiplying the original value of a sensor sample by the C factor.

The results of how the classification accuracy significantly degrades due to short faults are reported in Table 5.1. As a first example, by considering faults affecting all the axes of both accelerometers (on waist and thigh) involved in the preprocessing, the accuracy conspicuously drops to slightly more than 50% with just 5% of the raw data samples affected by spikes.

Also, when considering only one single channel per time affected by faults, the results of Table 5.2 clearly show that the recognition accuracy is more influenced by the quality of the data stream coming from the sensor worn on the thigh, rather than the ones from the waist node.

Hereafter, we show how the introduction of a self‐healing plane to the node‐side applications of the activity recognition system is capable of improving the system accuracy by detecting and recovering short faults. The enhanced autonomic version of the application in Figure 5.6a is shown in Figure 5.8. In a similar way, a self‐healing plane has also been applied on the accelerometer raw data streams of the application running on the thigh node.

With specific reference to the short faults, the underlying approach of the detection and recovery functionalities of the two autonomic tasks is analyzing the variability in the accelerometer data streams. In particular, such streams are split into consecutive data windows, each containing W sensor samples, over which the mean and the standard deviation sd are computed. Then, every single sample in the data window is compared to the standard deviation and, in case its value is much greater than sd, the sample is marked as fault. Specifically, a task parameter T is adopted to determine the threshold value , against which the comparison is performed. If no corrupted data is detected, samples are directly forwarded to the Split task, otherwise the FaultsFiltering will be considered for the subsequent recovering phase. With regards to short faults, the adopted recovering method consists in replacing a corrupted sensor reading with the previous sampled data. Although it appears as a very simple approach, it actually shows its effectiveness in canceling the negative effects of such outliers in the accelerometer streams and thus preventing inaccurate processing leading to low recognition accuracy. A comparison of classification accuracies without and with the self‐healing autonomic plane is reported in Table 5.3. In particular, window W = 40 and threshold parameter T = 3 have been adopted in our experiments.

With a frequency of short faults within 10%, the recovery operation demonstrates to guarantee very highly accurate outcomes. Conversely, increasingly lower improvements are obtained in the other cases. This is because when a data stream has very recurrent faults, it would be impossible to establish if a specific value is part of a correct data sequence or is a result of a failed sensing operation.

5.7 Summary

Incorporating fault tolerance, adaptability, and reliability into BSNs is a challenging task. In this regard, the autonomic computing is an effective paradigm whose self‐* properties are able to fulfill such complex requirements. After having introduced background concepts on the autonomic paradigm, this chapter has presented an architecture for rapid prototyping of BSN applications with autonomic characteristics, SPINE‐*. It extends the SPINE2 programming framework by means of an autonomic plane, a way for separating out the provision of self‐* properties from the BSN application logic. Then, we have considered a human activity recognition application as a test case by first analyzing how its effectiveness can be heavily affected by data faults in the sensor readings. Finally, we have shown how a self‐healing layer (capable of detecting and possibly recovering such faults at runtime) can improve the recognition accuracy, thus improving the quality of the application.

References

1. 1 Horn, P. (2001). Autonomic Computing: IBM’s Perspective on the State of Information Technology. Tech. Rep., IBM T.J. Watson Labs, New York.
2. 2 Samaan, N. and Karmouch, A. (2009). Towards autonomic network management: an analysis of current and future research directions. IEEE Communications Surveys Tutorials 11 (3): 22–36.
3. 3 Agoulmine, N. (2010). Autonomic Network Management Principles: From Concepts to Applications. Ed. Academic Press.
4. 4 The BISON Project Website. http://www.cs.unibo.it/bison (accessed 11 June 2017).
5. 5 The ANA Project Website. www.ana‐project.org (accessed 5 June 2017).
6. 6 The Haggle Project Website. http://ica1www.epfl.ch/haggle (accessed 10 June 2017).
7. 7 The CASCADAS Project Website. http://acetoolkit.sourceforge.net/cascadas (accessed 12 June 2017).
8. 8 The EFIPSANS Project Website. http://secan‐lab.uni.lu/efipsans‐web (accessed 7 June 2017).
9. 9 The Autonomic Internet Project Website. http://www.autoi.ics.ece.upatras.gr/autoi (accessed 8 June 2017).
10. 10 Ruiz, L.B., Nogueira, J.M., and Loureiro, A.A.F. (2003). MANNA: amanagement architecture for wireless sensor networks. IEEE Communications Magazine 41 (2): 116–125.
11. 11 Song, H., Kim, D., Lee, K., and Sung, J. (2005). UPnP‐based sensor network management architecture. Second International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2005), Osaka, Japan (13–15 April 2005).
12. 12 Lee, W.L., Datta, A., and Cardell‐Oliver, R. (2006). WinMS: wireless sensor network‐management system, an adaptive policy‐based management for wireless sensor networks, Tech. Rep.
13. 13 Bourdenas, T. and Sloman, M. (2010). Starfish: policy driven self‐management in wireless sensor networks. Proceedings of the 2010 ICSE Workshop on Software Engineering for Adaptive and Self‐Managing Systems, ser. SEAMS’10, Cape Town, South Africa (3–4 May 2010), pp. 75–83. New York: ACM.
14. 14 Paradis, L. and Han, Q. (2007). A survey of fault management in wireless sensor networks. Journal of Network and Systems Management 15: 171–190.
15. 15 Boonma, P. and Suzuki, J. (2007). Bisnet: a biologically‐inspired middleware architecture for self‐managing wireless sensor networks. Computer Networks 51 (16): 4599–4616, (1) Innovations in Web Communications Infrastructure; (2) Middleware Challenges for Next Generation Networks and Services.
16. 16 Yu, M., Mokhtar, H., and Merabti, M. (2008). Self‐managed fault management in wireless sensor networks. Proceedings of the 2008 the Second International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies, ser. UBICOMM’08, Valencia, Spain (29 September–4 October), pp. 13–18. Washington, DC: IEEE Computer Society.
17. 17 Lee, M.‐H. and Choi, Y.‐H. (2008). Fault detection of wireless sensor networks. Computer Communications 31: 3469–3475.
18. 18 Turau, V. and Weyer, C. (2009). Fault tolerance in wireless sensor networks through self‐stabilisation. International Journal of Communication Networks and Distributed Systems 2: 78–98.
19. 19 Choi, J.‐Y., Yim, S.‐J., Huh, Y.J., and Choi, Y.‐H. (2009). An adaptive fault detection scheme for wireless sensor networks. Proceedings of the 8th WSEAS International Conference on Software Engineering, Parallel and Distributed Systems, Cambridge, UK (21–23 February 2009), pp. 106–110. Stevens Point, WI: World Scientific and Engineering Academy and Society (WSEAS).
20. 20 Jiang, P. (2009). A new method for node fault detection in wireless sensor networks. Sensors 9 (2): 1282–1294.
21. 21 Oh, H., Doh, I., and Chae, K. (2009). A fault management and monitoring mechanism for secure medical sensor network. International Journal of Computer Science and Applications 6: 43–56.
22. 22 Bourdenas, T. and Sloman, M. (2009). Towards self‐healing in wireless sensor networks. Proceedings of the 2009 Sixth International Workshop on Wearable and Implantable Body Sensor Networks, ser. BSN’09, Berkeley, CA (3–5 June 2009), pp. 15–20. Washington, DC: IEEE Computer Society.
23. 23 Asim, M., Mokhtar, H., and Merabti, M. (2010). A self‐managing fault management mechanism for wireless sensor networks. International Journal of Wireless Mobile Networks 2 (4): 14.
24. 24 Ji, S., Yuan, S.‐F., Ma, T.‐H., and Tan, C. (2010). Distributed fault detection for wireless sensor based on weighted average. Proceedings of the 2010 Second International Conference on Networks Security, Wireless Communications and Trusted Computing – Volume 01, ser. NSWCTC’10, Wuhan, Hubei, China (24–25 April 2010), pp. 57–60. Washington, DC: IEEE Computer Society.
25. 25 Galzarano, S., Fortino, G., and Liotta, A. (2012). Embedded self‐healing layer for detecting and recovering sensor faults in body sensor networks. Proceedings of the 2012 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Seoul, Korea (14–17 October 2012), pp. 2377–2382.
26. 26 Bellifemine, F., Fortino, G., Giannantonio, R. et al. (2011). SPINE: a domain‐specific framework for rapid prototyping of WBSN applications. Software: Practice and Experience 41: 237–265.
27. 27 Gravina, R., Guerrieri, A., Fortino, G. et al. (2008). Development of body sensor network applications using SPINE. IEEE International Conference on Systems, Man and Cybernetics, 2008. SMC 2008, Singapore (12–15 October 2008), pp. 2810–2815.