MHARS : A mobile system for human activity recognition and inference of health situations in ambient assisted living

This paper presents MHARS (Mobile Human Activity Recognition System), a mobile system designed to monitor patients in the context of Ambient Assisted Living (AAL), which allows the recognition of the activities performed by the user as well as the detection of the activities intensity in real time. MHARS was designed to be able to gather data from different sensors, to recognize the activities and measure their intensity in different user mobility scenarios. The system allows the inference of situations regarding the health status of the patient and provides support for executing actions, reacting to events that deserve attention from the patient’s caregivers and family members. Experiments demonstrate that MHARS presents good accuracy and has an affordable consumption of mobile resources.


Introduction
One of the goals of pervasive computing is to create Ambient Intelligence, in other words, to make environments sensitive to the presence of human beings (Cook et al., 2009).The basic idea behind smart environments is to rely on sensors and other pervasive devices, interconnected through a wireless network, to detect characteristics of users and the environment non-obtrusively.From the data collected, intelligent systems can make some kind of inference (reasoning) and then select and execute actions that will benefit the present users (Cook et al., 2009).In addition, systems for smart environments need to be agile in response time and adaptable to changes in the context of the environment and the users.
In the healthcare field, the term Ambient Assisted Living (AAL) has been used to designate a multidisciplinary research area focused on the development of intelligent systems for remote monitoring of the daily activities of patients (ADL -Activities of Daily Living) transiting through intelligent environments, such as Smart Homes (Memon et al., 2014).There is a broad spectrum of practical ap-plications for AAL systems, such as rescue systems and emergency response, detection of falls, video surveillance systems, etc. Patient monitoring by means of AAL systems differs from the traditional healthcare model.In the latter, it is necessary that patients periodically visit hospitals for medical evaluation.In AAL, patient follow-up can be held at distance, in the comfort of the home, or even when they move around (Deborah and Ida, 2010).With the aid of AAL systems, healthcare professionals can follow the situation of the patient in real-time and quickly make decisions and perform actions to improve or stabilize the clinical situation.
AAL systems require an infrastructure composed of a network of wireless sensors and actuators (WSAN) for healthcare, computer equipment, software applications and databases, which are interconnected to exchange data and to provide intelligent patient care services.Sensors and actuators forming WSANs are connected to local servers to send medical data to health monitoring systems.The local servers, also known as intelligent residential gateways, often use a wireless router to allow multiple real-time patient monitoring applica-tions to send and receive data over home networks (Memon et al., 2014).
Among the various sensors that can be applied in AAL systems there are wearable medical sensors able to monitor physiological signals (e.g.electrocardiogram, electromyography, cardiac frequency, volume of oxygen consumed) or to collect data that reflect the body movement (e.g.accelerometer and gyroscope).Usually, personal mobile devices (cell phones, tablets and smartphones) are also equipped with sensors of movement or location (e.g.accelerometer, GPS).Environmental sensors can also be used, as they collect information that helps to determine whether the environmental conditions (temperature, luminosity, air humidity, carbon dioxide levels) favor the patient's health.
Monitoring the patient's activities is important to develop a therapeutic strategy aiming to optimize individual treatment outcomes.The improvement in individual physical performance is an important asset in the treatment of chronic diseases.In many cases, the use of drugs is not sufficient to ensure improved quality of life for patients with chronic diseases.Studies show that the regular practice of physical exercise, when appropriate to the patient's physical condition, helps to obtain the best results in most treatments of chronic diseases, especially cardiovascular (e.g.hypertension, heart failure, atrial fibrillation) and respiratory ones (e.g.chronic bronchitis, emphysema, asthma) (Sui et al., 2007).In this manner, it is common that the health professionals recommend that the patient performs certain physical exercises, or even to suspend some activities inadequate for his/her treatment.
AAL systems with the ability to recognize patterns of human activity (e.g. to walk, run, sit) from various types of sensor data are referred to as HARS (Human Activity Recognition Systems).For example, this type of system allows to infer whether the patient walks or runs frequently, or adopts a more sedentary posture.The recognition process is a complex task, requiring the analysis of several parameters, which may vary depending on the kind of activities, the available sensors, among others.Furthermore, a profound understanding of how to perform the analysis of data related to the movement of individuals is needed, as well as knowledge about preprocessing techniques and efficient inference algorithms to be used.
Besides detecting the user's performed activity, in some situations it is important to assess how the patient is reacting to certain physical activities, and even to check whether the effort level is compatible with his/her physical limits.These limits are imposed by the patient's health condition, age, weight and other factors.In the event of non-conformance to the patterns of activity and intensity recommended, the AAL system can take the decision to issue an alert to the health professional responsible for the patient.Another possibility is to directly request the patient to increase or decrease the activity intensity to match his/her limits.For example, if during a run the heart rate rises above what is considered normal for that activity, the AAL system may recommend the patient to run at a slower pace or even to suspend the activity.Alternatively, the system could suggest a different activity, such as a walk, if better suited to the patient's state.
In the context of HARS, accuracy in recognizing both the activity and its intensity indicates the efficiency of the system and varies according to several factors, including the quality of the data collected by the sensors and the classification algorithm applied.The quality of the collected data depends on the type and characteristics of the sensor employed.The combination of data provided by different types of sensors helps to infer the patient's situation, enabling a quick decision-making and action execution, especially in emergency situations.Therefore, it is necessary to overcome problems associated with sensor failures or the low precision of the data collected, in order to guarantee a high degree of accuracy in the recognition of activities.
Due to the mobility inherent in physical activities, some AAL systems place their activity and intensity detection module in personal mobile devices to provide greater flexibility.However, given the constraints in relation to processing power and battery consumption of these devices, a major challenge is how to perform the activity inference and intensity measurement in a timely manner and still consume computer resources in a sustainable manner.This balance is fundamental to reach a cost/ benefit ratio that makes the system viable.
In this context, the aim of this article is to present the architecture, functionalities and evaluation results of MHARS (Mobile Human Activity Recognition System), an AAL system aimed at the recognition of user activities and measurement of their respective intensi-ties, which runs on mobile personal devices.This system was developed at the Distributed Systems Lab of the Federal University of Maranhão (UFMA), Brazil, in collaboration with the UFMA University Hospital.The main goal of this research is to support the monitoring of patients with chronic diseases.MHARS's main requirements are: the ability to interact with different types of sensors; to recognize physical activities and to measure the intensity with which they are being executed; the ability to infer situations related to the user's health condition and to perform actions in response to them; and to provide storage and support for remote querying of patient data.
As MHARS main contributions we highlight its capacity of providing the recognition of the user's activities combined with their intensity; the fact that it runs solely on the mobile device, without the need for a server infrastructure for the inference of the user's activities; the support for various patient's mobility scenarios; a good accuracy of the activity recognition algorithm; and the provision of a rich set of features, that include the detection of user-defined situations and the provision of a decision-making engine for defining an action plan (set of actions) that must be executed whenever relevant health situations are detected.
The remainder of the article is structured as follows.MHARS (Mobile Human Activity Recognition System) describes the components and the main features of MHARS.Evaluation presents the results concerning the evaluation of the system, i.e. the verification of the achieved accuracy in activity detection and the evaluation of performance and resource consumption of the system.Related work discusses related work.Finally, Conclusion contains the conclusions of this work and prospects of applying MHARS in healthcare.

MHARS (Mobile Human Activity Recognition System)
MHARS is a mobile system aimed at tracking patients in the context of Ambient Assisted Living.It allows the recognition of the activities carried out by the user as well as the detection of the intensity of this activity in real time.
The development of MHARS has had the institutional support of UFMA University Hospital (HU-UFMA) and, in particular, of the Center for Research in Nephrology within HU-UFMA.During the execution of this work, several meetings with health professionals from HU-UFMA were held.The purpose of these meetings was to specify the requirements of a system capable of performing remote monitoring of patients with chronic diseases.In particular, the main physical activities to be monitored were identified, as well as the models for measuring the activity intensity.
The following functional requirements were then established: (i) multiple interaction with sensors: to be able to interact with different types of sensors (wearable, mobile, or embedded in smart environments), to obtain different types of information about the patient (e.g., physiological body movement and location) and the environments in which he/she lives (e.g.brightness, temperature, air quality); (ii) activity recognition: to be able to collect, process and classify the data obtained, so as to enable the automatic recognition of the activities performed by the patient in real time; (iii) measurement of intensity: being able to gauge the intensity with which the patient performs the activities proposed by healthcare professionals; (iv) situation inference: to be able to infer situations related to the patient's health (e.g.running with moderate intensity at an altitude of 1,800 meters at 15:00 having atrial fibrillation), based on data from sensors, the activity performed and its intensity, and taking into account the treatment specificity of each patient; (v) decision-making: being able to make decisions and to take actions appropriate to each defined situation in which the patient may be during the execution of activities; (vi) storage and availability of data: the data from activity recognition and intensity measurement should be stored permanently and made available to healthcare professionals; (vii) mobility: the system must run in personal mobile devices, so that it can be used by the patients in their daily normal routines.
Non-functional requirements were listed as follows: (i) the inference process of activities must have an acceptable accuracy; (ii) the system must consume a minimum of computer resources; (iii) the system must run on modern mobile devices.
For the development of some components of MHARS, the SDDL (Scalable Data Distribution Layer) (David et al., 2013) and M-Hub (Mobile Hub) (Talavera et al., 2015) middleware were used, both of them developed at the Laboratory of Advanced Collaboration (LAC) of the Pontifical Catholic University of Rio de Janeiro (PUC-Rio), in collaboration with the Distributed Systems Laboratory of the Federal University of Maranhão (UFMA).
SDDL is a scalable and high-performance communication middleware which allows the communication between stationary nodes (remote servers) and mobile nodes (mobile devices) connected via wireless networks (David et al., 2013).M-Hub is a middleware service designed to run on mobile devices, whose purpose is to discover, record and transmit data sent by smart objects (sensors and actuators) through the SDDL middleware (Talavera et al., 2015).
Figure 1 displays the components of MHARS.S2PA (Short-Range Sensor, Presence and Actuation) is the component that performs the collection of context data from low-level sensors and distributes this data to HURS (Human Activity Recognition Service), IMS (Intensity Measurement Service), SAS (Situation-Aware Service) and the Connection Service.This can be acceleration data ( 5), heart rate data (6) or any other raw data collected from nearby sensors (1).HURS performs activity recognition based on the acceleration data; IMS recognizes the intensity of the activity using the heart rate data; SAS detects the user's situation.They send the inferred activity (2), intensity (3) and situation (4) to the Connection Service that performs their distribution through the MR-UDP protocol to a cloud infrastructure where SDDL services are executed.Data sent through the Connection Service are stored locally on the mobile device until a network connection is available, when they will be forwarded to the SDDL cloud.The context data passed to the SDDL cloud is persisted into a relational database and made available to health professionals through a WEB application.Finally, DMS is a component responsible for executing actions based on the inferred user's situation (4).The next subsections detail the operation of each of these components.

S2PA Service (Short-Range Sensor, Presence and Actuation)
To perform the recognition of activities, the measurement of their intensities, and the detection of the corresponding user's situation, in this work we used the following sensors: accelerometer and heart rate sensor.Specifically, the accelerometer was used in the detection of activities, while the detection of intensity was done with a sensor capable of measuring the user's heart rate.
A Zephyr Bioharness 31 sensor was used to collect the physiological data (heart rate) of the patients.This is a wearable sensor that is connected to the mobile devices via Bluetooth technology2 .The Zephyr Bioharness 3 allows the monitoring of heart rate and breathing.It also has an acceleration sensor.In addition to this, we also used the sensors available on a Moto G II3 smartphone during the development and evaluation of MHARS.
The accelerometer is a sensor capable of measuring the acceleration of the body.The sensor measures acceleration only through the phenomenon of weight experienced by the user's body.Modern devices are capable of measuring the acceleration in three dimensions (X, Y, Z), which allows the construction of a wide range of applications that need to know the position and movement of the device.
The heart rate monitor (or heart rate sensor) allows the measurement of the number of heart beats of a person per time unit during the execution of a specific activity.This is done through the analysis of electrocardiographic waves coming from the heart.The sensor analyzes these signals to measure how often the heart is beating per minute.
Figure 2 presents the position of the sensors in the body of patients assumed in this research.It can be observed that the heart rate sensor is positioned in the patient's chest to collect vital signs.
To implement the component responsible for data collection, we used the S2PA service (Short-Range Sensor, Presence and Actuation) present in the M-Hub middleware.This service is responsible for the acquisition of data from the sensors.S2PA can get data in two ways: (i) when the sensor to be used is built into the smartphone (internal sensor), the S2PA [sensor), S2PA?] carries out the data acquisition through the Android sensors API4 ; (ii) when using external sensors, such as the Zephyr Bioharness 3. In the latter case, the service is also responsible for the preliminary phase of discovery and connection with external sensors, to subsequently receive data from them.
During development, it was necessary to incorporate into S2PA a selective sensor activation feature according to the needs of the appli-cation, since the default S2PA version performs automatic activation of all available sensors, which can lead to a high consumption of computational resources.So, in order to improve the performance of S2PA, this component has been modified to allow every application running on the mobile device to activate only those sensors necessary for its functioning.

HURS (Human Activity Recognition Service)
The HURS component is responsible for the recognition of the activity performed by the patient.HURS is able to recognize the following activities: walking, running, jumping, standing, lying down, and walking up or down stairs.
To recognize the activities, HURS receives the acceleration data and performs a preprocessing on them.The pre-processing consists of the conversion and refinement of the sign from the acceleration sensor to a more adequate format for the data classifier.During pre-processing, the accelerometer signal characteristics are extracted, resulting in a reduced set of numeric values that represent certain characteristics related to acceleration (e.g.mean, standard deviation, the peak acceleration, and entropy of the signal).
In HURS we used pre-processing techniques with low computational cost, which are explained in Evaluation.The pre-processed data are then used as input to a machine learning algorithm, a previously trained classifier, which is responsible for categorizing the activity that the user is performing.The specific machine learning algorithm used in HURS was IBk, available from the WEKA library (Mark et al., 2009).This library contains various machine learning algorithms capable of recognizing patterns in data sets.

IMS (Intensity Measurement Service)
IMS is the MHARS component responsible for the activity intensity measurement.The activity intensity is related to the physiological effects (e.g.stress, muscle fatigue, lactic acid) of the activity being performed, considering the health condition and the physical limits of each patient.The intensity is usually mapped to a scale comprising a set of ranges called intensity zones (ACSM's, 2006).In general, the intensity calculation can consider different parameters, including heart rate, ECG (electrocardiogram) or volume of consumed oxygen.Choosing the best parameter varies according to the monitoring requirements, such as the environment in which the patient is located, the degree of intrusiveness, and the portability of the sensors to be used.
In the development of IMS, it was necessary to map the medical knowledge related to the intensity levels of physical activities to a computational model.Therefore, interviews with health professionals were made and a bibliographic study was carried out to identify the possible approaches to be used to detect the intensity of physical activities.As a result of this study, it was identified that the dominant model for detecting the intensity of physical activities consists in the analysis of the heart rate (Tanaka et al., 2001;Sui et al., 2007).
Heart rate data represent the number of heartbeats during a given time interval, usually measured in minutes.There are several features of a person's heart rate; the main ones are: • Basal heart rate (FCBasal): this is the heart rate when the individual is at rest, that is, the lowest frequency in which the heart hits.It must be measured when the person wakes up because this is when the body is in the highest degree of relaxation.IMS uses the maximum heart rate as the main parameter to determine the intensity level of the activities.The closer the current heart rate is to FCMax, the highest the intensity of the activities.The health professional can inform the maximum heart rate of the patient to IMS or this can be calculated by using the formula FCMax = 220-age.This formula was developed by Fox et al. (1971) and is one of the most commonly used formulas to determine the FCMax of a person.There is no precise formula for the FCMax (Robert and Robergs, 2002).Although the formulas are a means to find a value approaching the FCMax, it is recommended that the health professionals request the patient to undergo a stress test to accurately determine the FCMax.
Table 1 shows the five intensity levels (heart rate zones) recognized by IMS.Each level consists of a range of heart rates.More intense activities require the heart to operate at a higher frequency.In lower intensity activities, the heart rate tends to be lower.For example, a person who performs a low-level race will feature a heart rate between 60% and 70% of his/her FCMax.In another example, an ordinary person who is presenting a heart rate above 90% of his/her FCMax, while conducting a physical activity, can be characterized as being in a dangerous situation, because only athletes with a good physical conditioning can make activities with this intensity.To perform physical activity, it is recommended that the patient in treatment stay within the ideal heart rate, i.e. respect the intensity compatible with his/her physical conditioning.

SAS (Situation-Aware Service)
SAS is responsible for inferring the different situations experienced by the patient.Generally, each situation is characterized by the correlation of a set of data related to the ongoing activity, its intensity, and even data on the chronic condition and the physical limits of each patient.SAS has an intrinsic relationship with DMS (Decision-Making), which is the component responsible for decision-making and the execution of actions in response to the occurrence of certain situations.Situations, decisions and actions to be performed are represented through rules of the Event-Condition-Action (ECA rules) type.These rules are specified by means of a language based on an XML document.Therefore, health professionals may describe situations to be monitored through this language, duly assisted by a computer specialist.
Figure 3 provides an example of a document that describes a dangerous situation to patients with heart disease (Pinheiro et al., 2013).This example helps to explain how SAS works.
The first step to specify a situation consists in informing the data to be used in the situation recognition.In the example of Figure 3, lines 6 to 9 define the heart rate and altitude data.Soon after that, the rules that characterize a particular situation must be defined.
The rules contain the logical operators (and) and (or), and comparison operators.Comparison operators check the difference between two values; one of them is the collected or inferred data, and the other a constant one.They return a Boolean value (true or false).The comparison operators supported by SAS are: equal, different, bigger, smaller, equal or greater and less than or equal.In the same example, lines 10 to 21 set the expression to be validated.In this case, it is checked whether the user's heart rate is above 100 beats per minute and whether the altitude of the place where the user is is greater than 2,000 meters.If the expression is true, SAS sends the inferred situation to the DMS and Connection Service.
Upon receiving the situation, DMS checks what are the actions to be carried out in accordance with the identified situation.Some examples of actions that DMS enables are: sending SMS, displaying a visual notification, and issuing a sound notification.In the example of Figure 3, lines 22 to 26 define the action to perform if the expression is true.In that case, the action corresponds to sending a SMS message to a health professional.
MHARS users can define new situations by editing the XML document describing the ECA rules that is loaded during the initialization of SAS.That will usually be done by an IT professional who must translate desired situations and actions described by health professionals into the above described XML syntax.

CS (Connection Service)
CS is the component responsible for the opportunistic connection to a cellular network or WI-FI, allowing the sending of data to a remote server, as soon as there is an available network connection.
The remote server contains a database related to patient monitoring.On the one hand, this database can store low level data, in order to build a measurement history of the data collected from the sensors placed on the patient's body over time.On the other hand, it stores high level information, such as information that represents the history of situations experienced by the patient during treatment, or records of decisions and actions that were taken in emergency situations.The database can be queried remotely by health professionals through a Web platform.
During the boot process, CS establishes a connection with the SDDL gateway through the MR-UDP communication protocol, as well as with the database available on the device.Whenever the Connection Service receives data from S2PA, HURS, IMS or SAS, it checks whether the device is connected to a wireless network in order to forward it to the gateway.If the device is not connected to a network, the data is stored in a local database on the device.CS periodically checks whether the mobile device is connected to a wireless network and, as soon as a connection is available, propagates the data in the local database through the gateway.

Evaluation
This section describes the evaluation of MHARS.It first describes the experiments that were carried out to assess the accuracy of the classification process used to infer the activities performed by the user, detailing the tools and methods used in the evaluation process.Next, it presents the experiments carried out to analyze the use of computational resources required by MHARS during its operation.Since MHARS was developed to be executed in mobile devices, it must make a parsimonious use of computing resources in order to be used in practice.

Methodology for evaluating the activity recognition accuracy
The methodology for the evaluation of MHARS was based on case studies, which consisted of experiments involving the monitoring of 10 people performing the following activities: walking up and down stairs, walking, running, sitting, standing and lying.To this end, the following metrics adopted was accuracy, which expresses the percentage of success in the recognition of the activities performed in a set of samples collected in a given space of time.
In the experiments, we used a Motorola Moto G II Smartphone with Android OS 4.4.2KitKat and a Zephyr BioHarness 3 wearable device.Two accelerometers were used for the recognition of activities: the one built into the smartphone (internal sensor), and the other available in the wearable device (external sensor).Every patient used the smartphone in two different positions: at the waist and in the user's front right pocket, which we will refer to from now on just as "leg".The wearable device was designed to be used only on the chest.The objective was to analyze the accuracy variation considering different positions of the accelerometer.Both sensors have been configured to operate on a frequency of 50 Hz, since this value is frequently used in the literature (Hoseini-Tabatabaei et al., 2013;Anguita et al., 2013) and is considered quite adequate to detect both stationary activities (e.g.standing) as well as dynamic ones (e.g.running).In addition, this frequency is regarded as acceptable with respect to the battery consumption of mobile devices.For the measurement of the activity intensity, we only used a heart rate sensor embedded in the wearable device, operating at a frequency of 1 Hz.This frequency is the device's standard and cannot be configured.The preprocessing method used in the experiments consisted in obtaining the following representative values: the average values of each axis (X, Y, Z), as well as the square root of the average obtained from the medium for each axis.These values are passed to the classifier to run the activity recognition process.It is important to note that other methods of preprocessing could also be adopted.However, other possibilities require greater consumption of computer resources, so they were not considered suitable for activity recognition in real time executed solely on personal mobile devices, due to processing power and memory limitations.
The activity recognition process and the computation of its intensity were executed in intervals of 2.54 seconds.This means that, at a frequency of 50 Hz, the preprocessing, clas-sification, and intensity measurement are executed based on 128 samples of acceleration data in each cycle.This time window and the amount of samples are considered sufficient for the recognition of activities that are executed repeatedly.For example, a person walking normally performs 90 to 130 steps per minute, which corresponds to 1.5 and 2.7 steps per second.Therefore, a time window of 2.54 seconds is more than enough to recognize this type of repetitive activity (Anguita et al., 2013).
The data classifier needs to be trained on the basis of representative data of labeled activities so it can subsequently correctly recognize the activities performed by the user.It is worth mentioning that the training procedure is an intensive computational process and, for that reason, is not performed on the mobile device, but rather on a server.To build the training dataset we adopted the following strategy: considering the total number of samples collected, 70% was devoted to the classifier's training, while the remaining 30% were intended for its validation, that is, for evaluating the classifier's accuracy in correctly recognizing activities after it had gone through the training process.This split of the dataset was needed to verify the presence of overfitting (Russell and Norvig, 2003), a problem that occurs when the classifier cannot recognize a given activity for which it was trained based on the analysis of unknown samples.This indicates that the classifier, even trained, cannot generalize the activity recognition, that is, it reflects an accidental pattern found in the training data and not the general pattern of the problem.
Various machine-learning techniques are employed for the recognition of human activities, including instance-based methods, also known as lazy classifiers.This work investigates the use of IBk, an instance-based algorithm, for the recognition of human activities.IBk was chosen after a bibliographic study and several comparison experiments were conducted to evaluate the relative effectiveness of machine learning algorithms frequently used in the problem of activity recognition (Hoseini-Tabatabaei et al., 2013).Specifically, the following algorithms have been tested: decision tree algorithms, e.g.Random Forest, RepTree and Random Tree; lazy classifiers, e.g.IBk; neural networks learning, e.g.MLP with backpropagation; and rule-based classifiers, e.g.JRIP.Among these, IBk achieved the highest accuracy values.
IBk is a machine-learning algorithm based on instances that works calculating the distance between pairs of instances of a problem and using this information to classify new instances.A specific function should be used to measure the distance between the instances (Witten and Frank, 2005).When testing an unseen instance, the algorithm picks up the knearest neighbors and measures the distance of the unseen instance to these.The unseen instance will be put in the more frequent class among the k-nearest neighbors.For this reason IBk is also known as K-Nearest Neighbors (KNN) algorithm.

Accuracy evaluation results
Table 2 presents the accuracy results obtained for the different types of activities performed and the varied accelerometer positions.Regarding the type of activity performed, stationary activities (that generate low variation of the acceleration) presented higher accuracy, when compared with dynamic activities (that generate higher acceleration variations).These results are attributed to the fact that the recognition of dynamic activities requires precise sensors that would allow the detection of variations in the acceleration in short time periods.Depending on the sensor precision, the data provided to train the classifier algorithm may not be the most representative for a given activity, which could mistakenly lead to the inference of an activity different to the one that the user is performing.The calibration of the sensors also tends to interfere with the degree of precision of the collected data, affecting the training of the classification algorithm and, consequently, resulting in lower activity recognition accuracy.
With respect to the accelerometer position, it can be seen that the accuracy is higher when the accelerometer is located at the waist and the leg, when compared to the results obtained by fixing it to the chest.These results are attributed to the fact that, when positioned at the waist or the leg, the accelerometers can detect the user movement with greater precision, given that these parts of the body are moved more sharply during the execution of activities.
By analyzing the results, we can also conclude that HURS has a satisfactory activity recognition accuracy (83%), which proves that it can be reliably used in the monitoring of patients.This is reinforced by data found in the literature, which states that a system is satis-factory if it is capable of detecting human activities with an accuracy higher than 70% (Hoseini- Tabatabaei et al., 2013).We also believe that HURS can achieve even higher accuracy by using approaches such as the use of more accurate sensors, the use of a larger volume of samples to train the classifier algorithm, and the use of classifiers built through a combination of ML algorithms.It is important to highlight that the main focus of the described experiments was to evaluate the ability to recognize different activities considering different positions of the acceleration sensors on the user's body.

Methodology for evaluating the computing resource usage
For the evaluation of the computing resource usage demanded by MHARS for its execution we considered a scenario in which a health professional accompanies the daily activities carried out by patients.During this evaluation, we analyzed MHARS resource consumption running on a middle range smartphone, the Motorola Moto G II with Android OS 4.4.2KitKat.The objective of the performed tests was to evaluate the MHARS CPU and memory usage stratified by the following components: S2PA, which is responsible for gathering sensor data; preprocessing; and activity inference.We also measured battery consumption while running MHARS.
For the evaluation of CPU and RAM usage, MHARS was executed for one hour.Measurements were taken at intervals of 30 seconds, totaling 120 measurements for each resource (CPU and Memory) and MHARS component (data gathering, preprocessing, and infer-ence).For the evaluation of the device's battery consumption the following strategy was adopted: initially the device's battery was fully charged, then the device was disconnected from the charger and we started the execution of MHARs.The system was also executed for one hour, collecting the battery level at intervals of 30 seconds.Besides the mean value of the data samples collected during the experiments, we also calculated the following statistical data for each metrics: median, standard deviation, and maximum/minimum values.

Results of the evaluation of computing resource usage
Table 3 presents the average, median, and standard deviation and the maximum value for the CPU consumption of the three evaluated MHARS components.The pre-processing and inference components accounted for most of the CPU usage, due to the fact that they are responsible for processing the acceleration data, while the data gathering component only forwards the data received from sensors.It can be seen that all components consumed less than 6% of the CPU usage during the tests, having an average value of less than 4.5% of CPU utilization.Therefore, we can conclude that MHARS can run on current mobile devices without consuming too much processing power.
Table 4 shows the results of MHARS's memory usage.During this evaluation, the preprocessing component used more memory than the other ones, due to the fact that this component is responsible for buffering the acceleration data collected for a time period of 2.54 seconds.One can observe that individually all three components occupied less than 10 MB of RAM during the tests, presenting an average value of 7 MB of memory usage.The results show that MHARS can run on current mobile devices requiring less than 30 MB of RAM, which represents only 3% of the RAM available on the device used in the experiments.This is a satisfactory result, since current mobile devices are usually equipped with 1 or more GB of RAM.
Figure 4 shows the battery charge level decay of the mobile device during the one-hour period in which MHARS was executed.During the test the mobile device battery level dropped from 100% to 92% during the period of one hour, that is, the battery of the mobile device declined by 8% during the period considered.Therefore, we can estimate that the system can be used for a period of more than 12 hours without the need to recharge the device's battery.
Therefore, we can conclude that the system can monitor the patient for a long period of time in a high-mobility scenario.This means that the patient can perform routine activities like working, shopping, or studying without worrying about recharging the device's battery.
Considering the results of MHARS's performance, we can conclude that its consumption of CPU and RAM can be considered satisfactory and the system can run on smart-  phones without compromising the device performance for a period of more than 12 hours.

Related work
This section shows a comparative study between MHARS and other works related to the recognition of physical activities and the measurement of their intensity based on the use of data from mobile device sensors.Miluzzo et al. (2008) introduce the architecture and evaluation of the application called CenceMe.It detects activities using just a mobile device, and the activities recognized are: sitting, standing, walking and running.The purpose of the CenceMe application is to publicize the activities that the user does during the day in a social network.CenceMe is able to detect whether the user is talking, and this requires the classification of the sound signal of the mobile device's microphone.The application also has a co-location feature, that is, it is able to detect the proximity of people surrounding the user.To do this, it sends the device's geo-location data to a remote server that is responsible for identifying which friends are geographically close to each other.The CenceMe activity classification process is performed by the Activity Classifier component.To classify the activities it is necessary to obtain the mobile device's accelerometer data and submit them to a preprocessing stage.This work calculates the average and standard deviation on the three axes of the acceleration signals.The preprocessed data are then sent to the classifying algorithm, which in this case employs the J48 algorithm (Witten and Frank, 2005).The evaluation results present an accuracy of 78% of the activity detection model.
The work of Carvalho et al. (2011) introduces a system for the monitoring of patients in home environments, which performs the recognition of activities based on the use of the mobile device's accelerometer sensor data.To perform the activity intensity measurement, physiological data is also collected.This information is then stored on a server located at the user's home, which is also responsible for the distribution of data to health professionals who are remotely assisting the patient.This research has focused on the detection of situations through the use of fuzzy rules (Russell and Norvig, 2003), which are built on the basis of medical guidelines to determine the patient's clinical condition.The system also sends notifications to the professional assist-ing the patient, so they can take the necessary actions in accordance with the inferred patient situation.The developed system is able to determine three levels of intensity: resting, moderate, and intense.These predefined values were based on the calorie waste necessary to perform the activities.For example, the activity of running can be considered intense, while walking is moderate, and lying and sitting can be classified as resting.To recognize the level of activity intensity it is necessary to collect data from a wearable device positioned at the user's waist.Note that this system is not designed to support scenarios where the patient may move through various environments, due to the fact that it needs a local server at the user's home, where the activity and situation recognition is performed.This server also provides the communication features required to reach the health professionals.Tapia et al. (2007) use acceleration and heart rate data for both the activity recognition and the measurement of its intensity.Fourteen different activities are recognized.For the evaluation of the inference model, they collected acceleration data from 21 people.They used several preprocessing algorithms, such as signal entropy, energy, and variance.The pre-processed data was sent to the classification algorithm C 4.5, which creates a decision tree.The evaluation results of the activity recognition model indicate an accuracy of 94.9%.To achieve this result it was necessary to fix to the user's body five acceleration sensors in different positions and a heart rate sensor.A downside of this approach is that the use of several sensors is considered uncomfortable by many users.This is also an issue that must be taken into consideration in scenarios of high patient mobility.
The system proposed by Eid et al. (2013) is designed to be used in the monitoring of athletes during sports activities, but without aiming to classify them.The goal of the system is only to measure the intensity of the performed activities.In this work, the intensity measurement is achieved based on the use of a heart rate sensor, using for this purpose an Arduino microprocessor.There is support for mobility scenarios considering different sporting environments.The system also provides features for inferring situations and making decisions.Besides the use of sensors, the system also applies actuators that inform the athlete whether the activity is being performed in the correct intensity.As can be noticed, most of the related works presented in this section are able to detect user activities, but some, like Carvalho et al. (2011), focus only on the measurement of the activity intensity.For the recognition of activities performed by the user, the acceleration data is widely used.Each work can detect a different set of activities, so we cannot say with precision what work is able to recognize activities with greater accuracy than the others.Most of the works did not have the concern of creating an inference model that runs on the mobile device.This feature allows the monitoring of the patient in high-mobility scenarios that are not restricted to the patient's home or hospital.Most of the works do not provide mechanisms that allow the execution of actions in response to user's situations.Also, only few works, such as Miluzzo et al. (2008), provide resources for data distribution and persistence.

Comparative analysis of related work
One of MHARS's characteristics is that the whole inference process is held solely on the mobile device, which provides a great degree of mobility to the user.Another positive consequence is that it is able to operate efficiently even in case of network disconnections -which is common in wireless environments -since it does not depend on a server.MHARS was designed to preserve the computer resources of the mobile device.To achieve this, we chose to use preprocessing techniques and a classification algorithm that requires little computational resources during the activity recognition process.Nevertheless, MHARS achieved an accuracy of more than 80%, which is considered very satisfactory.In addition, MHARS also measures the activity intensity level and provides a rich set of features that includes the detection of user-defined situations and the provision of a decision-making engine to define an action plan (set of actions) that must be executed whenever relevant health situations are detected.

Conclusions
The main contribution of this work was the development of an AAL system named MHARS with a focus on monitoring patients with chronic diseases.The system performs the recognition of activities and the detection of the intensity in which they are being carried out by the device user.The paper presented MHARS's architecture and its main components, describing their features.
MHARS was evaluated in respect to its capacity to recognize different activities using accelerator sensors fixed on different positions in the user's body.The results of the evaluation indicate that the system has achieved a satisfactory accuracy.The amount of computational resources required for running the system was also measured.The results indicated that the system can be executed on mobile devices like mid-range smartphones for a long period of time (more than 12 hours).
The comparison of the proposed system with related work highlights MHARS' capacities of providing both the recognition of the user's activities combined with their intensity; the fact that it runs solely on the mobile device, without needing a server infrastructure for the inference of the user's activities; the support for several types of patient's mobility scenarios; a good accuracy of the activity recognition algorithm; and the provision of a rich set of features, that include the detection of user-defined situations and the provision of a decision making-engine to define an action plan (set of actions) that must be executed whenever relevant health situations are detected.
MHARS's architecture was conceived in such a way that it easily allows the extensibility of the types of activities that can be recognized.In order to extend the set of recognized activities, one must provide a file containing a new classification model that is loaded by the HURS component during its initialization.However, to build a new classification model it is necessary to perform the steps described in Methodology for evaluating the activity recognition accuracy, that include the construction of a training dataset that is used as input for the IBk algorithm in order to build the new classification model.
As future work we can highlight: (i) the investigation of new preprocessing techniques, such as acceleration energy and entropy, that may result in a better activity recognition accuracy; (i) the evaluation of other techniques for activity inference, such as SVN (Support Vector Machines); (iii) the evaluation of MHARS with patients and healthcare professionals in order to validate the system user experience; (iv) the development a graphical authoring tool to define situations, which would allow healthcare professionals to describe situations without requiring the support of computer professionals; (v) the investigation of other techniques for situation specification and inference besides the use of ECA rules, such as the use of logic programming, spatial and temporal logic, ontologies, fuzzy logic and evidence theory (Ye et al., 2012).

Figure 2 .
Figure 2. Position of the sensors used in the experiments.

Figure 3 .
Figure 3. XML document used to represent situations and actions.

Table 2 .
Accuracies obtained for different accelerometer positions.

Table 3 .
Evaluation of CPU utilization (in percentage of CPU usage).

Table 4 .
Evaluation of memory usage (in MB).

Table 5 .
Comparison with related work.