The SA-BSN is an exemplar of a healthcare application implemented in ROS [1]. The goal of the SA-BSN is to detect emergencies by continuously monitoring the patient’s health status. Furthermore, the SA-BSN is equipped to adapt itself in order to maintain the desired QoS levels with minimal human intervention, while accounting for classes of uncertainty.

A range of vital signs is periodically collected from the patient through a set of distributed sensors: electrocardiograph sensor (ECG) for heart rate and electrocardiogram curve; a pulse oximeter (SaO2) for measuring blood oxygen saturation; a thermometer (TEMP), that collects the body temperature in Celsius; a sphygmomanometer for measuring and systolic arterial blood pressure (ABP); there is also a Glucose sensor for measuring blood glucose levels. The collected data is then forwarded to the Central Hub: a component in the Managed System to fuse the vital signs and classify the overall health situation of the patient into low, moderate, or high risk status. As a self-adaptive system, the BSN has the Managing System module, which is responsible for continuously assuring the fulfillment of the desired QoS attributes related to the values of reliability and battery consumption (i.e. cost).

For the evaluation of the quality of the adaptation the BSN uses control theory metrics following the terminology proposed by Camara et al. [2]. The chosen QoS constraint is attributed to a setpoint, which is set by the user before the system execution. For example, if the concerned QoS attribute is the reliability, one could set it to 95%, within an acceptable error range. This is called setpoint tracking, which can be measured by the steady-state error (SSE) metric.

Moreover, while trying to meet its requirements, the system is prone to a range of uncertainties. Thus, the controller is activated to mitigate the effects of unexpected events in quality attributes. Such uncertainties can be depicted in three distinctive scenarios. The first scenario, S1, focuses on uncertainties related to the overflow of sensed data into the Central Hub queue and also to the possible data uncertainties in sensors, which are related to the reliability of the system. The second scenario, S2, focuses on the uncertainty related to the operational frequencies of the components, which can lead to a battery consumption that exceeds what is needed to satisfy the requirements. In the third scenario, S3, depending on the patient profile, the operator may not want to use certain sensors; with fewer components to manage, less uncertainty in the system is expected and, consequently, a more stable adaptation process.

[1] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng, “ROS: an open-source robot operating system,” in ICRA workshop on open source software, vol. 3, no. 3.2. Kobe, Japan, 2009, p. 5.

J. Camara, A. V. Papadopoulos, T. Vogel, D. Weyns, D. Garlan, S. Huang, and K. Tei, “Towards bridging the gap between control and self-adaptive system properties,” ser. SEAMS ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 78–84.