Keywords

1 Introduction

The society is now witnessing a demographic change towards an ageing population. Demographic statistics reports [1] show that the elderly population, that is, people who are older than 60 years of age constitutes about one-fourth of the total population in Europe and is expected to increase in the coming years. A similar ageing trend is also witnessed around the world. The technological boom and the need to support an increasing elderly population have prompted the research community to focus on the field of Ambient Assisted Living (AAL). There are numerous Ambient Intelligent (AI) systems that have been developed to support the elderly in their independent living. In addition, there are significant advances in the field of smart homes, wireless sensor technology, assisted robotics, e-health etc., which have created a breakthrough development in the AAL domain [2, 3]. However, a survey of the existing AAL solutions reveals a potential research gap regarding solutions that integrate all relevant technologies into a common framework.

In practice, almost all of the AAL solutions are found to be fragmented, with limited support of only few integrated functionalities. Nevertheless, it is also possible that one uses various independent systems to build up multiple functionalities. For instance, if an elderly person’s home is equipped with an AAL solution that does not have an automatic fall detection system, the user can purchase it separately, as there exist readily available, wearable separate solutions that detect a fall and raise an alarm. This functionality of a fall detection system remains the same whether it is an independent system or part of an integrated framework.

If this is the case, we need to answer an important question - if the individualized solutions can perform their functionality without integration, then do we really need to integrate all of them into a single framework bearing additional cost overheads? This paper focuses on answering such a question. The most obvious reason for a positive answer would be the difficulty encountered in using separate solutions as compared to a single integrated one; however, there might exist a more important reason - the fact that the performance of individualized solutions differ dramatically if they are integrated into a coherent framework, versus the case when they are employed in isolation. We discuss this issue in detail in Sect. 3.

The paper is organized as follows. In Sect. 2, we review some of the prominent AAL solutions with respect to their functionalities. Section 3 reasons about the necessity of developing integrated solutions rather than individualized ones. We show this by selecting representative scenarios that we simulate via sequence diagrams, and check their offline schedules against real-time deadlines. In Sect. 4, we show the functional components of an integrated AAL system by constructing a feature diagram representation. Section 5 concludes the paper and gives some directions for future work.

2 Literature Survey

In this section, we survey some of the most relevant AAL frameworks developed during the last two decades. The search is restricted to the platforms with multi-functionality support, their availability in the market (or at least at a prototype level) and documented user acceptance. Below, we first list the main functionalities required by AAL systems, and then identify AAL solutions supporting such functionalities. We summarize the results in Table 1, that is, the chosen solutions and their supported functionalities, which justify the rest of the paper.

The functionalities that we have chosen are: health monitoring, fall detection, communication and socialization, support for supervised physical exercises, personalized intelligent and dynamic program management, robotics platform support, intelligent personal assistant that takes orders, gives advice and reminders etc., support for vocal interface, mobility assistance, and home and environment management.

  1. 1.

    Health monitoring and care: Health monitoring is an important functionality of AAL systems. The parameters to monitor depend on the health status of older adults. The major health monitoring frameworks are inCASA [4], Reaction [5], UniversAAL [6], Diabetic Support Systems, Automated Memory Support for Social Interaction (AMSSI) [2] etc.

  2. 2.

    Fall detection: The risk of falling is one of the critical hazardous situations that needs to be addressed in an AAL system [7]. Examples of existing solutions include the Tunstall fall alarm, the Bay Alarm sensor etc. The inCASA architecture [4] comprises fall detection for elderly people. The GiraffPlus project [8] uses both the smart phone fall detection application and the Tunstall fall detection sensor.

  3. 3.

    Communication and social inclusion: Communication to health care professionals and social inclusion is another vital functionality of AAL systems. Among the existing frameworks, inCASA [4], Reaction [5], GiraffPlus [8], MobiServ [9] support this functionality.

  4. 4.

    Supervised physical exercises: Mobility problems are very common for elderly people. Exergames are video games that combine traditional game play with physical activity. The most common sensors available for physical activity detection are Webcamera and Kinect sensors. The Mobiserv [9] framework supports supervised physical exercises.

  5. 5.

    Personalized, intelligent and dynamic program management: An AAL system should allow the storage of the user’s personal data like medication plan, daily, weekly, monthly program planning, exercise planner, record of medical data obtained from sensors, etc. The major frameworks that support this functionality are listed in Table 1.

  6. 6.

    Robotic platforms support: The service robots like the Pearl, Care-o-Bot, Cero, PR2, Robocare etc. play a significant role in the AAL domain. Another major category is the companion robots, like the robotic baby seal Paro [2]. The major platforms with robotic support include Domeo AAL project [10], GiraffPlus [8], Mobiserv [9] etc.

  7. 7.

    Intelligent personal assistant: The cognitive abilities of elderly people decrease with age, hence the functionality provided by an intelligent informed friendly collaborator is crucial to AAL systems. Two of the frameworks that support this functionality are inCASA [4], and Reaction [5].

  8. 8.

    Vocal interface: Most of the elderly regard traditional computer interfaces as overly technical and difficult to use. Hence, support for vocal commands is necessary. There are many existing software systems for speech recognition and synthesis, out of which CMU Sphinx, Julius, Google Speech API are among the most popular. Some of the platforms that support vocal interfaces are listed in Table 1.

  9. 9.

    Mobility assistance: Many of the elderly lack the ability to move independently and require mobility support. There are many smart wheel chairs devised for this purpose, like NavChair, Wheelesley, VAHM, PerMMa etc. Apart from wheel chairs, mobility scooters and smart vehicles are prominent in this category [2].

  10. 10

    Home and environment management: The most recognized smart home systems that take care of one’s home, and perform environment management are iDorm, PERSONA (PERceptive Spaces prOmoting iNdependent Aging), CASAS Smart Home Project, MavHome, and Aware Home Research Initiative (AHRI) [2].

Table 1. Functionalities supported by various AAL frameworks
Full size table

Table 1 gives a synthetic account of various AAL frameworks in terms of supported functionalities. By inspecting the table one can notice that none of the platforms that we have reviewed supports all the functionalities that we have selected. This finding gives rise to a straightforward research question: “Are there any critical performance differences in using an integrated framework versus using individual systems side by side, for achieving the desired functionality?”. The answer to this question is elaborated in the next section.

3 Analysis of Independent vs. Integrated AAL Solutions

In the previous section we have established the fact that none of the reviewed frameworks acts as a fully integrated solution for AAL. In order to answer our original question, we proceed to analyzing a real life scenario involving a fire event and a fall event, possibly occurring simultaneously.

The motivation for choosing this scenario is based on actual data on fall and fire incidents. According to statistics, the fall incidents among elderly people over the age of 75 is at least 30 % every year, and 40 % of them fall more than once, turning this incident into one of the major risk factors for elderly people, which can sometimes lead to death [11]. Besides falls, the number of fire incidents occurring at home has also been increasing at an alarming rate. According to the report given by Nation Fire Protection, the number of fire incidents reported in 2013 is 369.500, causing 2755 civilian deaths [12]. The fire and fall incidents statistics implies that there is a high likeliness of both events happening at the same time.

We perform our behavioral analysis of solutions by modeling the sequence of message exchanges in the automatic fire and fall detection systems, and by simulating the execution traces of the resulting sequence diagrams in Visual Paradigm [13]. Fire and fall events have hard deadlines associated with their resolution, that is, if a proper timely action is not guaranteed, they will have catastrophic consequences. Therefore, we add response times to individual messages in the sequence diagrams, and thereby calculate the response times of fire detection and fall detection systems, respectively. Next, we analyze the actions schedule of each independent system by using offline scheduling, which is the most suited type of scheduling for hard real time applications [14].

3.1 Sequence Diagrams and Schedule Analysis

In this paper, we aim our analysis to understanding the behavior of automatic fire detection and fall detection systems when:

  1. 1.

    Both systems are independent, and:

    1. (a)

      Fire and fall events occur at different times.

    2. (b)

      Fire and fall events occur simultaneously.

  2. 2.

    Both systems are integrated into a common framework, and:

    1. (a)

      Fire and fall events occur at different times.

    2. (b)

      Fire and fall events occur simultaneously.

We also annotate duration constraints to the message interactions in both scenarios, in their respective sequence diagrams. A fall event is usually detected by various feature extraction techniques and fall detection algorithms running in the fall sensor [7]. Most of the fall sensors take approximately 255 ms to get activated on the occurrence of a fall event [15], and take 5 to 6 s to detect a fall [16]. Some of the fall sensors available in the market can raise a fall alarm at 30 s after the detection of a fall [17].

Let us assume that the fall alarm is communicated to a caregiver via an automatic call that takes about 1 min. The average time for the caregiver to respond to the fall alarm call is 2.96 min [18]. The caregiver can validate the fall through a telepresence system (if available), in order to reduce the risk of false alarms. This timing constraint is a variable based on the design aspects of the system. Let us assume that validation takes another 1 min. In case of a real fall, the caregiver should provide assistance immediately. The time taken for providing the required assistance varies, and depends on many factors like the distance from the hospital to the patient’s house, type of action taken, etc. For our analysis, we assume a fair time of about 15 min during which proper medical care should reach the person who has fallen.

The fire sensors do not fall under the category “wearable”, and hence the system’s performance depends on a variety of physical factors like the place of installation, height of installation, type of fire etc. There are now various categories of fire sensors such as ionization sensors, photoelectric sensors, and dual sensors. In this paper, we analyze the performance of a photoelectric sensor installed in a bedroom of a two storey house, which can detect a fire due to flaming, and raise an alarm within 54 s [19]. Let us split this into 2 actions: fire detection within 45 s, and alarm raising within 9 s from detection, in order to carry out a similar analysis like for the fall event. The fire alarm is sent to the firefighter in 30 s [20]. Due to a high number of false alarms, there is a need for confirming the alarm before taking an action. This is usually achieved via telephone call confirmations. All these actions take about 1 min [20]. For detailed analysis, we split this action into 3 subactions: 10 s response time of firefighters, 25 s for call confirmation, and another 25 s for confirmation reply. The volunteer firefighters should arrive at the spot within 9 min from fire alarm confirmation. The fire’s put out time is 60 s [20], so the total time for the whole response action is 10 min.

Fig. 1.
figure 1

Message sequence for fall event.

Full size image

Once we have assigned duration constraints to individual messages in each system, we can analyze both independent and integrated solutions, based on sequence diagram simulations, and then construct their offline schedules.

  1. 1.

    Behavior of independent, automatic fire detection system, and fall detection system, assuming fire and fall events occur at different times.

    The sequence diagrams for the individual systems, and their execution traces are described in Figs. 1 and 2, with their respective duration constraints. The duration constraints are assigned as previously discussed in this section. In case of automatic fall detection systems, the total response time is calculated by adding the individual response times of all messages in the sequence diagram of Fig. 1.

    $$\begin{aligned} R_{fall} = \sum _{i=1}^{6}{R_i}= {20.56\ } \mathrm {{min}} \end{aligned}$$
    (1)

    In case of automatic fire detection systems, the response time is calculated in a similar way:

    $$\begin{aligned} R_{fire} = \sum _{i=1}^{7}{R_i}= {12.36\ } \mathrm {{min}} \end{aligned}$$
    (2)

    The schedule graphs of the automatic fall detection, and fire detection systems are shown in Fig. 3, respectively. This gives a clear indication of the deadlines associated with each of the events in the context of our analysis: a fall event has to be addressed within 20.56 min to ensure safety, and the fire, once it occurs, has to be extinguished within 12.36 min.

  2. 2.

    Behavior of independent, automatic fire detection system, and fall detection system, assuming fire and fall events occur simultaneously.

    The sequence diagram interactions for independent fire and fall detection systems, with fire and fall events occurring simultaneously is shown in Fig. 4. In order to better illustrate the simultaneous occurrence of both events, we restrict to a single sequence diagram that shows the interaction of both systems. However, note that these systems are still independent, without any mutual interactions.

    When the fall and fire events occur simultaneously, the fall event follows the usual sequence of events, but in case of a fire event, the confirmation call of fire event is not answered as the user has fallen (shown as a lost message in the sequence diagram of Fig. 4). Consequently, it is highly possible that firefighters ignore the fire alarm. Let us imagine the worst case scenario where the fire gets notified to firefighters only when the caregiver arrives to help the fallen individual, that is, the fire event is notified after 20.56 min from start, which is far beyond the deadline of 12.36 min, associated with the fire event. A real catastrophe could occur in this scenario, as the fire is not extinguished in due time.

    The deadline miss of the fire event is clearly depicted in the schedule diagram described in Fig. 6a.

  3. 3.

    Behavior of an integrated fire detection system and fall detection system, assuming fire and fall events occur at different times.

    When the fire and fall events occur at disjoint points, the integrated system follows the same sequence of events described by the sequence diagrams in Figs. 1 and 2; the response times for both the events remain the same as in the case of independent systems, and both events are addressed within their deadlines, respectively, as shown in the diagram of Fig. 3.

  4. 4.

    Behavior of an integrated fire detection system and fall detection system, assuming fire and fall events occur simultaneously.

    We have seen earlier that if both fire and fall events occur simultaneously in independent systems, the fire event misses its deadline, which might have catastrophic consequences. Let us now check if the integrated system can address this issue. The sequence diagram in this case is shown in Fig. 5. As described by the scenario, both individual systems are integrated into a common framework, so both fall and fire events are first communicated to the integrated framework now.

Fig. 2.
figure 2

Message sequence for fire event.

Full size image
Fig. 3.
figure 3

Offline scheduling of fire and fall event messages.

Full size image

There exists a design constraint associated with the integrated system requiring that the system has to wait for an arbitrary time to check whether some other events are activated at the same time. In our case, when the fall event is sent first to the integrated system, it waits arbitrarily for 0.5 s, such that the fire event that occurred at the same point of time also gets accounted for. We can chose this waiting time, depending on the design constraints, such that the system registers multiple events and does not miss individual deadlines associated with the events. In this case, the integrated framework communicates to the firefighters and caregiver that there is fire, and a fall event has occurred also. As such, the firefighters prioritize their rescuing action without requiring a confirmation call, thus completing their action well before the associated deadline. Similarly, the caregiver does not spend time with confirmation, as there are two critical events reported at the same time, so he/she takes his/her action within the associated deadline of 20.53 s. The schedule of this scenario is shown in Fig. 6b.

Fig. 4.
figure 4

Message exchanges of fall event and fire event occurring simultaneously in an independent system.

Full size image
Fig. 5.
figure 5

Message exchanges of fall event and fire event occurring simultaneously in an integrated system.

Full size image
Fig. 6.
figure 6

Offline schedules of fire event and fall event messages.

Full size image

The scenario that we have analyzed is one among many scenarios that highlight the necessity of an integrated AAL solution. With the help of this scenario, we could clearly identify that there is a significant performance difference between independent and integrated systems, when multiple critical events occur simultaneously. Due to such evaluations, we can generalize and infer that a potential AAL framework that integrates all the functionalities ranging from health monitoring systems to assisted robotic systems is highly essential to be able to tackle multiple simultaneous events. We need a solution that is capable of making a decision by interconnecting and prioritizing the events in case more than one critical situation occurs. In short, such intelligence can be developed only if one analyzes the scenarios collaboratively, which is only possible if one uses an integrated framework of AAL functions.

4 A Feature Diagram of Integrated AAL Functions

Until now we have analyzed whether one should develop or not an integrated architectural solution for AAL. As a first step towards the design of such an integrated architecture for AAL, we capture the functionality features of such a system using a feature diagram reprsentation [21].

Fig. 7.
figure 7

Feature Diagram capturing the Functions of an Integrated AAL system.

Full size image

The feature diagram depicting the functional components and attributes of an integrated AAL system is shown in Fig. 7. In a feature diagram, a node with a solid circle represents a mandatory feature of any AAL system. A node with an empty circle represents an optional feature that can be selected by a particular system. Several nodes associated with a spanning curve represent a group of alternative features, from which a feature must be selected for a particular system.

As one can notice, the AAL system is composed of users, components, and communication protocols. The primary users of the system are elderly adults, but there are also secondary users like the caregivers, family, friends, etc., and also tertiary users like service providers, firefighters, etc. The components include the sensor unit that contains health monitoring sensors (health monitoring), ambient sensors (home monitoring), fall sensors (fall detection), and physical exercise monitoring sensors (supervised physical exercises), mobile phone of the elderly to communicate to external users via SMS, provide reminders, etc., robotic platform support that can also be used as a telepresence system for communication to external users, a private or a public cloud, mobility assistance devices, interfaces, a high end processing unit acting as the core of the AAL system, etc. The processor has the following subcomponents: context awareness module, Decision Support Systems (DSS) with associated Knowledge Bases (KB) and database. The choice of communication protocols is flexible, based on requirements. Each node is also described as local or distributed, with or without Real Time (RT) properties. The diagram in Fig. 7 should help the designer to select the appropriate features of a new AAL system, as well as figure out infeasible combinations of features.

5 Conclusions and Future Works

In this paper, we have highlighted the significance of developing an integrated framework for Ambient Assisted Living by analyzing real-life scenarios that justify such a solution. The emergent behavior that arises by integrating the various functionalities like health monitoring, smart homes, physical exercise monitoring systems, robotic platform systems, fall alarms, intelligent friendly collaborator systems, multi modal user interface systems, etc., are essential for ensuring the success of any AAL system. We have also provided a feature diagram representation of the functionalities of an integrated AAL framework, which can serve as design reference of existing or future solutions.

As part of the future work, we plan to propose a fully integrated AAL architecture, which we plan to further model and verify formally against functional and real-time requirements.