Abstract
The increasing average age of the population in most industrialized countries imposes a necessity for developing advanced and practical services using state-of-the-art technologies, dedicated to personal living spaces. In this paper, we introduce a hierarchical distributed approach for home care systems based on a new paradigm known as Internet of Things (IoT). The proposed generic framework is supported by a three-level data management model composed of dew computing, fog computing, and cloud computing for efficient data flow in IoT based home care systems. We examine the proposed model through a real case scenario of an early fire detection system using a distributed fuzzy logic approach. The obtained results prove that such implementation of dew and fog computing provides high accuracy in fire detection IoT systems, while achieving minimum data latency.
1. Introduction
In most industrialized countries, demographical and structural trends tend toward more and more elderly people [1]. One social trend in particular affects the old-age population, and that is the move away from the nuclear family household with elderly people becoming increasingly restricted to living alone or in assisted living facilities. This leaves many people to their own means in receiving healthcare and other services. The effects of these trends are dramatic on public and private healthcare, management and monitoring of emergency conditions, and the individuals themselves. Figure 1 shows past and future increase in the old-age dependency population group, where the old-age dependency ratio is the ratio of the population aged 65 years or more to the working population aged 15–64 (presented as number of dependants per 100 persons of working age). The increasing average age of the total population will result in a dramatic increase of emergency situations and missions within the coming years [2]. It is economically and socially beneficial to reduce the burden of urgent service providing for the elderly and disabled by enhancing prevention and early detection. This requires a long-term shift from a centralized, expert-driven, crisis care model to one that permeates home environments. Therefore, in the near future, there will be a necessity for the homecare industry to develop advanced and practical services using state-of-the-art technologies, dedicated to personal living spaces.
Systems that render their service in a sensitive and responsive way and are unobtrusively integrated into our daily environment are referred to as being ambient intelligent ones [3, 4]. Ambient Intelligence (AmI) has been recognized as a promising approach to tackle the aforementioned problems in the domain of assisted living [5]. An important aspect in AmI is the use of context-aware technologies, such as wireless sensor networks (WSNs) [6, 7] to perceive stimuli from both the users and the environment. Living assistance systems focusing on the support of people with special needs (elderly, disabled) in their own homes are called home care systems (HCS) [8]. HCS applications include services, products, and concepts to increase the quality of life, wellbeing, and safety of elderly people. The main goal of HCS is to achieve benefits for the individual (increasing safety and wellbeing), the economy (higher effectiveness of limited resources), and the society (better living standards) [9].
To enable the features of a HCS, the home has to become intelligent with the help of the smart objects [10]. Smart objects are considered to have the characteristics of ubiquitous communication/connectivity, pervasive computing, and ambient intelligence. These objects communicate among each other and build networks of things, the so-called Internet of Things (IoT) [11, 12]. The goal of the IoT is to enable things to be connected anytime, anyplace, with anything and anyone ideally using any path/network and any service. A HCS scenario is characterized by being connected, context-sensitive, personal, adaptive, and anticipative. The IoT is capable of providing all characteristics necessary for a smart assisted living environment. Monitoring, alarming, management, and service providing can be enabled through IoT, without the need for the users to recognize the technology behind it [13].
Ambient intelligence based HCS tools range from medication management tools and medication reminders that allow the older adults to take control of their health conditions [14, 15], to tools that provide more safety for the elderly, using mobile emergency response systems [16], fall detection systems [17], and video surveillance systems [18]. Other HCS technologies provide help with daily activities, based on monitoring activities of daily living (ADL) and issuing reminders [19], as well as helping with mobility and automation [20]. Finally, such technologies can allow older adults to better connect and communicate with their peers, as well as with their family and friends [21, 22]. The possibility of using IoT based solutions in the HCS is still a very new topic in the research area, with possibilities and challenges being reported [10, 23–26], but also first attempts at building such systems are being made [27, 28]. WSN is a key technology that will enable future IoT solutions.
The main contributions of this article are as follows: () we present an Internet of Things (IoT) generic framework for HCS for the elderly; () we provide a data management model for efficient data flow in IoT based HCS; and () we examine a case study for fog computing within the IoT framework using a fuzzy logic approach. The proposed framework can serve as a foundation for future development of HCS applications, since it can be easily adapted to meet the general requirements of most of the service providers.
The rest of this paper is organized as follows. Section 2 gives a description of our IoT framework for HCS, based on hierarchical distributed three-level computational model for data processing. In Section 3, to demonstrate the effectiveness and the feasibility of the system, we implemented a prototype fog-based computing paradigm of an early fire detection system using a distributed fuzzy logic approach. The results from our system, discussion, and conclusion are provided in Sections 4 and 5.
2. IoT Framework for HCS
In this section we will present some similar attempts from the literature, in order to position our contribution within the state of the art in this research field. Thereafter, we will introduce our architecture for HC IoT solutions.
The authors in [29] developed an Internet of Things solution that uses fuzzy logic to control the temperature in an indoor environment. Their approach achieves an energy saving around 40%. The systems architecture is divided into three layers: data collection, data processor, and actuators. Data collection layer is gathering local data, but also data from external IoT platforms, that can be easily interconnected to smart objects such as Arduino Uno.
Fuzzy logic based home healthcare system for the chronic heart disease patients for out-of-hospital follow-up and monitoring is proposed in [30]. The system comprises two parts: (a) local and (b) remote. The local part is Arduino-based data aggregator that collects data from the sensors attached to a patient. The remote part stores data in the cloud and sends data to the remote service providers like emergency, doctors, or insurance providers.
In [31], an intelligent home-based platform known as iHome Health-IoT is proposed and implemented. The network architecture of this platform consists of three network layers: smart medical service layer (represented by providers), medical resource management layer (represented by cloud services), and sensor data collecting layer.
All the above-mentioned solutions have some shortcomings when it comes to IoT implementation. In [29] there is only local processing; hence this solution should not be considered as an IoT solution. The data from the IoT platform are used as an input to the local processor unit, but the data from the system are not sent back to the cloud. On the other hand, in [30, 31], there is no intermediate data processing, that is, fog computing.
The novelty in our approach is the introduction of three levels for data processing: dew computing, fog computing, and cloud computing. Although fog computing and cloud computing can be found in other architectures from the literature, we have not found dew computing as part of such an architecture. These three levels are compulsory for a solution to be considered as IoT solution, although not all of them should equally participate in all applications.
The IoT architecture we propose is given in Figure 2. It consists of four parts: smart home, smart neighborhood, service providers, and the cloud; and each part is associated with particular way of data processing; that is, smart objects inside the smart home perform dew computing, smart sinks (home sink or neighborhood sink) and service providers perform fog computing, and finally the IoT cloud performs cloud computing.
The smart objects (sensors and actuators) installed inside the smart home represent the lowest level of the architecture. They are responsible for collecting raw measurements of some physical phenomena. As smart objects, they should be able to perform initial data processing. Instead of sending raw data to the smart home sink, they can send processed data or information. This paradigm of data processing by smart object is identified in the literature as dew computing [32]. The dew computing model is based on a large number of programmable and self-adaptive heterogeneous devices ranging from smart phones to intelligent sensors, capable of running applications in a distributed manner without requiring a central communication point [32]. They can be connected through different protocols for smart home, such as ZigBee and Z-Wave and can work cooperatively to perform complex tasks for large variety of applications [33]. Dew computing is still hard to be achieved in real implementation, since heterogenous smart objects are using diverse protocols for communication [33].
On the second level, there is the fog computing, responsible for decision making. At this level, the input is not the raw data but already processed information, that is, the output of dew computing. Smart home sinks, smart neighborhood sinks, or even service providers are responsible for performing more extensive computation and making decisions whenever possible with the available data. Fog computing extends cloud computing and services to the edge of the network [34]; that is, services are hosted at the network edge or even at the end devices such as network routers, sinks, or access points. The goal of the fog computing is to improve the efficiency by directly processing data on the network and thus reducing the amount of data that has to be transferred for processing [32]. Therefore, the fog paradigm is suitable for real time big data analytics; it reduces service latency and improves QoS [35, 36]. Other benefits of fog computing are its proximity to specific end-users, its dense geographical distribution, its ability to reconfigure itself, and its potential to improve security [32].
Finally, at the third level, there is the cloud computing, as a state-of-the-art paradigm for IoT solutions. Through this paradigm, businesses and service providers are able to consume Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS), in order to make their business processes and products more competitive [32]. Still, existing PaaSs do not enable the provisioning of applications with cloud and fog components. In the near future, a penetration of such PaaSs that support and automate applications in a hybrid cloud/fog environment is expected [37].
In our architecture, the cloud is not directly connected to the smart home, in contrast to most of the published research, where the cloud can send instruction directly to the smart home [38]. In our cases, the service providers are responsible for taking further actions, regardless of whether they receive the instructions from the cloud, from the local neighborhood sink, or whether they make the decisions by their own. We found similar communication flow only in [39].
Most of the solutions from the literature that include fog computing in IoT assume fog computing only at the smart home gateway. In our architecture, we extended fog computing for one more level, that is, the smart neighborhood and the service providers. The main reason for this is the application domain for which we introduce this architecture. Namely, HC systems are primarily beneficial for elderly people, where first aid can often be offered within the neighborhood. For example, in the case of fire, people can generally run out of the flat/house if they are aware of it. In the case of the elderly, they are not always capable of leaving the site without assistance. The immediate or close environment can play a crucial role; therefore, in our scheme, apart from service providers, we augment the system by including services from nonformal subjects, such as volunteers trained for emergency situations or humanitarian organizations. Similar enhancement is proposed in [40], as well as a module for positioning.
HCS are complex since they integrate products and components from multiple sectors and manufacturers. Standardization should play a major role toward construction of complex systems from simpler components and toward interchangeability and interoperability of the components [41]. There are efforts to identify standardization requirements in the field of ICT and wellbeing (including care and healthcare standards). Although many standards already exist, they have not been developed for HCS and therefore need extensions and modifications. The European standardization bodies (i.e., CEN, CENELEC, and ETSI) here play the major role [41].
3. Implementation of Prototypical Fog-Based Fire Detection System
In this section, we present a fog-based system for fuzzy logic decision making in a fire scenario, since event detection is a central component in the AmI of the HCS. Nevertheless, the area of event description has not received enough attention. The majority of current event description and detection approaches rely on using precise values to specify event thresholds, and they include using SQL-like primitives [42], Petri nets [43], and stochastic methods like Bayesian classifiers and hidden Markov models [44], Dempster-Shafer evidence theory [7], and probabilistic context free grammars [45]. We believe that crisp values cannot adequately handle the often imprecise sensor readings. We chose fuzzy logic because this approach is built to support and tolerate unreliable, imprecise sensor data. It is very intuitive as the reasoning in fuzzy logic is similar to human reasoning and is able to provide approximate solutions to problems that are difficult for other methods. Fuzzy logic is being deployed in terms of IoT and WSNs in several areas such as trust models [46], cluster-head election [47], and energy optimized routing [48]. Still, not much work has been done on using fuzzy logic for event description and detection [49, 50].
For our case study, we present a possible IoT based system that can distinguish between a real fire and regular household activities that include smoke and heat. Our distributed decision making system implements a fuzzy inference system that takes crisp input, performs fuzzification, makes a decision using rules stored in a database, and performs defuzzification of the output.
The data processing and data flow of this scenario regarding our hierarchical distributed computing approach are given in Figure 3. Dew computing is done at sensor level, that is, performed by smart objects. Fog computing can be performed by smart home sinks, as well as by the smart neighborhood sink, or by the service providers such as the fire department for our case study. Cloud computing at the top of the system stores and processes all data and uses advanced algorithms to discover new knowledge from the gathered data and improve the decision making processes. In this paper we focus on the first two levels, that is, the dew and fog computing, for which the details are given in the forthcoming paragraphs.
3.1. Dataset and Preprocessing
For the tests conducted in this project, we used the data measured in four different fire events simulated by the National Institute of Standards and Technology (NIST) [51]. They made several tests in manufactured home and two-story home, as well as nuisance alarm tests. They provide measurements of different sensors before and after the fire. There is available data for temperature, smoke, and different gases concentration.
3.2. Sensor Placement
We used four scenarios in our system, where two of them were performed in a two-story house and the other two in a one-story house. Their data provides information about temperature, smoke obscuration, carbon monoxide, carbon dioxide, and oxygen concentration. For our project we used temperature, carbon dioxide (CO2), and oxygen (O2) data, as these factors are crucial when working with fire detection. The temperature is the main factor pointing a fire situation. As for the chosen gases, analyzing the graphs of the data provided by NIST, we chose CO2 and O2. We chose CO2 over CO because we aim to provide higher reliability of the fire detection system, and CO2 sensors are less prone to false detection [52, 53].
It is important to know some facts about the houses that were used in the tests. Both houses have alarms in all the rooms. For the purpose of our project we used the “flaming mattress, bedroom (burn room door closed)” or scenario 1 and “flaming chair, living room” or scenario 2, both from the two-story house. We also used “flaming chair, living area” or scenario 3 and “cooking oil fire, kitchen” or scenario 4, both from one-story house. The referential scenario is scenario 1, because the parameters for fuzzy system were chosen according the data of this scenario. In the first two scenarios we worked with 30 sensors organized in these 6 rooms: living room, foyer, den, and kitchen (from the first floor); Bedroom 1 and Bedroom 3 (from the second floor). Each room has 5 sensors. Figures 4 and 5 represent the room organization and sensor placement for the one-story and for the two-story house, respectively.
The sensors are distributed on different locations trough the rooms. The location of the sensor with regard to the location of the potential fire (i.e., the sensor proximity to the fire) is an important factor when making a correct decision. The locations of the sensors in our case study are predetermined in the experimental settings given by NIST and are the expected locations for smart objects/sensors in a standard modern home. All of the sensors report temperature readings. Additionally, each floor has a sensor which measures the concentration of gases (O2 and CO2) and sends this information to the other sensors on the same floor. All sensors maintain an individual copy of the temperature, O2 and CO2 concentration, and additionally information about the average temperature of its neighboring sensors (all sensors in a room are considered as neighboring sensors). In the one-story house, there are seven sensors in each room. In our model we observe four rooms (Bedroom 1, Bedroom 2, living room, and kitchen), so in total 28 sensors.
3.3. Fuzzy Inference System Implementation
We used MATLAB to create fuzzy inference systems (FIS). We chose MATLAB because it is a well-known numerical computing environment. It has a unique Fuzzy Logic Toolbox that provides everything needed for the project: specialized GUIs for building FIS, membership functions, and support for “AND,” “OR,” and “NOT” logic, as well as standard Mamdani and Sugeno-type FIS [54, 55]. It is really easy to develop the FIS with MATLAB and it takes only few steps to do that. The development of the system is made in the FIS Editor which handles the high level issues in the system such as number of input and output variables and variable names. The toolbox does not limit the number of inputs or outputs allowed.
For each of the four scenarios we performed eight tests with different input attributes and different inference methods. The parameters for these eight tests are shown in Table 1. We used four input variables: temperature (temp), temperature of the neighboring nodes (tempN), and oxygen (O2) and carbon dioxide (CO2) concentration.
After defining the variables, the next step is defining the membership functions (MF) for the input and output values. A membership function determines the certainty with which a crisp value is associated with a specific linguistic value. The membership functions can have different shapes. Some of the most frequently used shapes include triangular, trapezoidal, and Gaussian shapes. All of the MFs for our system are trapezoidal-shaped (Figure 6). For the temperature and average temperature of the neighbors we use the same plots defining four MF: freezing, cold, average, and hot. They are expressed in Celsius in range . For CO2 we use two MFs: low and high. CO2 concentration is expressed in % volume fraction in range . For O2, we use two membership functions: low and high, expressed in % volume fraction in range [16, 23].
The next step is defining the rules used in the FIS. Increasing the number of defined MFs leads to more rules, which increases the complexity of the system. Programming sensors with fuzzy logic has few disadvantages, and one of them is that storing a rule base might require a significant amount of memory. The number of rules grows exponentially to the number of variables. Having variables each of which can take values, the number of rules in the base is . Sensors have limited memory; thus some techniques of reducing the rule base must be implemented.
To create our rule base we used common sense logic. However, for more complex systems, expert should be consulted. Figure 7 shows some of the rules we have in our rule base. Our system, for the four input attributes, has 33 rules, even though the initial number was 64. We reduced the number of rules in order to implement the system in a more efficient way. The rules were reduced manually.
For example, the rule 27 If (temp is hot) and (tempN is freezing) then (fireDetection is no)
is obtained by merging 4 rules: If (temp is hot) and (tempN is freezing) and (O2 is low) and (CO2 is low) then (fireDetection is no) If (temp is hot) and (tempN is freezing) and (O2 is low) and (CO2 is high) then (fireDetection is no) If (temp is hot) and (tempN is freezing) and (O2 is high) and (CO2 is low) then (fireDetection is no) If (temp is hot) and (tempN is freezing) and (O2 is high) and (CO2 is high) then (fireDetection is no)
For more complex systems, there are different techniques that can be used for rules reduction [56].
4. Results and Discussion
In this section we will evaluate the performance of our fire detection case study. The results from our systems are in the interval . Values smaller than 0.5 are considered 0 (no fire) and all other values are considered 1 (fire). We count the number of the following cases: (i) true positive, TP: there is fire and it is detected by the system; (ii) true negative, TN: there is not fire and the system did not detect one; (iii) false positive, FP: there is no fire, but the system detected fire; (iv) false negative, FN: there is fire, but the system did not detect it.
For each node in the test we analyze the output. If one node has detected a fire, then the whole system detects a fire. Using (1) and (2) we calculate precision (number of items correctly classified as being positive) and recall (number of correct positive items divided by the total number of items from the positive class), while we use (3) to calculate the -measure (harmonic mean of precision and recall).
To achieve high accuracy in detection, the technique should have high precision and recall values. The results for the four scenarios and each test are given in Table 2. We can see that this system never detects false fire. This is concluded from the precision measure, because for all tests we have a value of one. The recall measure depends on the false negative value, which is important when we want to answer how fast the system will detect the fire. Scenario 1 has the best results, but this is a referential case, because we build the fuzzy model on the data from this scenario. So, if we eliminate this case, the best results are achieved for scenario 4. The -measure is almost 90% for the best tests, and the worst value is 53%. The average -measure for scenario 2 is 68.97%, for scenario 3 is 76.33%, and for scenario 4 is 85.43%. This means that the system should perform around these values. The fuzzy system worked perfectly when there is no fire to detect; that is, it does not produce false positives.
When we analyze the different tests we performed, the best results we have are those from test 2. In this test we did not use the attribute tempN, which means that this attribute does not improve the performance of our system. The reason for this, is that when the closest node to the fire is making the decision, this attribute is always lower than the attribute temp, and because our systems detects fire when at least one node detects fire, tempN does not give any useful information to the system. Therefore, we can conclude from the results that the data acquired from only one sensor is sufficient for detecting fire.
If we observe the results between test 3 and test 4 (where CO2 and O2 are excluded, resp.), we can see that O2 is more important when we make the decision, because when we use O2 the system detects the fire faster.
Figure 8 shows comparison between the -values calculated in a node in an immediate proximity to the fire (green) and a node that is further away from the fire (blue). This is quite expected as the fire from Bedroom 3 does not spread immediately to Bedroom 1. In some of the scenarios the fire is extinguished immediately; the system takes these cases into consideration and does not detect fire after it has been extinguished. Figure 9 shows the -value in one such case from scenario 2. This implies that the number of smart sensors can be reduced with a good solution for their placement within the smart home.
In order to compare fuzzy logic approach with other methods for classification, we selected Naïve Bayes classifier, since it has very similar computational complexity with fuzzy logic approach. The accuracy rate of our fuzzy logic approach is 81.4%, while for Naïve Bayes classifier it is 71.78%. Both accuracy rates represent the best result among all scenarios.
5. Conclusion
In this paper we present an Internet of Things (IoT) generic framework for home care systems for the elderly, which can serve as a foundation for future development of HCS applications. We identified a hierarchical distributed computing approach that consists of three computing levels: dew computing, fog computing, and cloud computing, emphasizing its benefits with respect to system latency.
Moreover, this paper discussed IoT challenges when using fuzzy logic and decision making algorithms to create a sophisticated home fire alarm system as a reliable method for preventing accidents. We showed how a system of sensors put at various locations in one’s home can be of a great benefit for the safety and security of it. More importantly with the data processing and data flow model for the fire detection case study we demonstrate the effectiveness and the feasibility of the proposed IoT framework for HCS.
Competing Interests
The authors declare that they have no competing interests.