Keywords

1 Introduction

As defined by Marsal-Llacuna et al. [1], Smart Cities aim to improve urban performance by using data, information and information technology (IT) to deliver more efficient services to citizens. IT must satisfy interconnected and smart characteristics. On one hand, city services may be interconnected through a distributed computing platform allowing integration, collection and dissemination of data; on the other hand, to become smart they must integrate information from various sources, analyze model, optimize and help visualization of these complex information to make better operational decisions.

The Centre of Regional Science at the Vienna University of Technology has identified six main components of a smart city: smart economy, smart mobility, smart environment, smart people, smart living, and smart governance [2]. The city of Côte Saint-Luc, Canada, faces an increased number of seniors that forces them to find solutions for promoting aging well at home, within the city. These circumstances leads the city to adopt a smart city approach mainly characterized by smart living for the aging population. Efficient and economical solutions may provide peace of mind, safety and support to limit isolation and promote social participation. Indeed, the administrative team of the city of Côte Saint-Luc believes that its intelligence relies on investments in human and social capital, as well as in technology infrastructure, sustainable growth and the quality of senior’s life. These refer to the key components “smart living” of a smart city. The smart cities services must be able to interact with most of the aging population, offering non-complex interfaces that are well adapted to the abilities and preferences of each elder while maintaining functional efficiency in the delivery of services.

The needs of seniors and their state of health change over time as they age and loss of autonomy sets in [3, 4]. Thus, as activities of daily living become more and more difficult to perform by the senior, increasing the number of situations of handicaps, institutionalization sometimes becomes the only solution [5]. Moreover, social interactions, community living and communication are factors that have an important influence on quality of life [6, 7]. For seniors, interacting with citizens and participating in social activities and entertainment are essential for a good life [6, 7]. Generally, seniors can communicate with family and friends by phone, email, and mail. However, seniors with cognitive or physical impairments have difficulty accessing social media and participating in social activities. This leads to social isolation and aggravation of the state of health [8].

To delay institutionalization and limit isolation, Ambient Assisted Living (AAL) systems build smart environment that provides assistance as well as healthcare and especially rehabilitation to seniors with physical or cognitive deficits. AAL systems include technology networks, heterogeneous information, smart devices, products and services. It is an ecosystem of connected objects, medical technologies, sensor networks and software applications for the monitoring and home support of frail people. To make everyday life easier, they propose to automate complex tasks and to monitor activities of daily living for facilitating independence. Above all, they offer continuous assessment of activities carried out, and a reduction in caregiver burden [3, 6].

To design AAL system that fulfills the user requirements, the City needs action-oriented approach where research questions emerge through consultation and interaction among several disciplines and sectors to develop socially useful, feasible, practical, effective and sustainable solutions [9]. Stakeholders must work together in a transdisciplinary research approach and methodology. As defined by Harvard transdisciplinary research “Transdisciplinary Research is defined as research efforts conducted by investigators from different disciplines working jointly to create new conceptual, theoretical, methodological, and translational innovations that integrate and move beyond discipline-specific approaches to address a common problem”. Indeed, transdisciplinary research provides an opportunity to bring out AAL relevant and appropriate solutions [9]. However, these solutions must be based on a reliable architecture to guarantee efficient services. As the domain of IoT is emerging, lack of standardization leads to a variety of products that provokes communication issues. It is then difficult to propose a coherent AAL system for the users. The goal of this work is twofold: (1) to identify the technical and technological requirements to be met to enable the city to promote aging in place for older residents; and (2) to design a software infrastructure that provides efficient and useful AAL applications that fulfill these requirements.

The rest of the document is structured as follows; Sect. 2 describes background and related works. Section 3 discusses the requirements and challenges an AAL system must satisfy in a smart city context. Section 4 describes the design and the implementation of the AAL architecture. Section 5 shows how the architecture was deployed in five participants home to fulfill their needs. A discussion of the deployment results follows. Finally, Sect. 6 concludes the paper and highlights the future work.

2 Background and Related Works

AAL is a multidisciplinary approach that leverages a wide range of technologies from different fields to deliver personalized services. Deployed AAL systems deal with many contextual information, based on a sensor/actuator information, user actions, user profiles, and ambient information [3]. The different AAL technologies that accompany aging in place are applied in various domains [3, 5, 6]:

  • Facilitate communication between the senior and caregivers;

  • Monitor the health parameters of the senior;

  • Monitor the environment and the activities of the senior’s daily life using sensors to ensure greater comfort and safety;

  • Facilitate the mobility of people out of their homes.

To offer adequate services to the seniors, the scope of the AAL systems covers not only the measure, control and connection of the network of sensors and actuators, it also requires understanding the habits and the behavior of the inhabitants in order to react according to their needs, their state of mind and their desires [4]. A user-centered approach is therefore required, involving the elders themselves, as well as a transdisciplinary approach that includes the City’s administrators, computer engineers, geriatric specialists, caregivers and clinicians [9].

Most AAL systems are moving towards the IoT platform paradigm with programs to control devices, display monitoring recordings, adjust ambient settings, lock doors and windows, and so on [10]. The Internet of Things (IoT) is a technological paradigm derived from innovative concepts and developments in information and communication technologies associated with ubiquitous computing, and ambient intelligence [11, 12]. Such an approach brings significant improvements to the interaction of users, but is often based on the presence of a monolithic architecture. Monolithic architecture is complex and costly in deployment time, with many limitations in terms of scalability and component reuse [13]. Yet, while connected to a wide range of independent devices and systems, the architecture of today’s AAL systems tends to focus on service resiliency and software component integration.

The choice of a general structure has an impact on the reliability, performance, maintainability and therefore lifetime of the AAL systems. It needs a structure that is customizable, that could adapt to various features and react to dynamic changes to devices. Therefore, among the various infrastructure proposed, AAL middleware is mainly preferred to facilitate the homogenization of different technologies and to satisfy the prerequisite characteristics [14]. Also a microservices platform is favored because it makes possible to design an easy-to-scale IoT system that quickly integrates new technological components and allows each instance to be adapted to the profile of the user [13].

3 AAL Systems Requirements and Challenges

Designing AAL systems requires respecting several characteristics and norms. The general architecture of AAL systems must fulfill the following requirements: heterogeneity; interoperability; usability; security; accuracy; reliability; maintainability; efficiency and technological scalability [15]. In a smart city context, the vast number of users reached necessitates to assure effective services delivery. The scalability is then twofold. Its scope covers the increase of the number of users reached and the number of devices to integrate because of the personalization of the services offered to each senior.

The AAL system designed and presented in this paper is part of a transdisciplinary methodological approach, which ensures that the issues emerging from seniors and the city are satisfied. We will show in the following that designing AAL on a middleware architecture that integrates microservices will realize the pre-cited requirements and respond to transdisciplinary approach. These requirements are grouped into four categories:

  • Modularity: heterogeneity – interoperability – maintainability;

  • Availability of services: scalability of technology – reliability – efficiency;

  • Services delivery: scalability for seniors – security;

  • Adaptability: adaptation to the senior profile – usability – accuracy.

Indeed, scalability is required for the city to offer services to a large number of citizens. However, modularity is a key requirement for the city to offer multiples services that should evolve according to new services the city desires to offer and new devices the IoT improvements will make available. Citizens expect also that the city will comply with security, reliability and accuracy of the city services.

3.1 Modularity

Modularity is a concept that includes heterogeneity, interoperability and maintainability. Indeed, it expresses the fact that the technological components fit together despite their differences. Due to the rapid evolution of the IoT domain, no standard has yet emerged. Rather, a wide variety of IoT components appears on the market including network connectivity options, proprietary or standards-based protocols, and unknown communication methods. It is expected that for years, new devices, new services and new protocols force IoT systems to accommodate various components and let them interact despite the diversity. Users also ask to get access to IoT services irrespective to the medium used.

This heterogeneity requires interoperability without concession regarding maintainability. Interoperability refers to the ability for the AAL system to propose interfaces that are understood by all the IoT components and to allow access between them. Maintainability guarantees the ability of the AAL system to continue to be interoperable in the future despite the evolution of the technology, the update of each component and the apparition of new components.

To respect heterogeneity, ensure interoperability and maintain it over time, communication protocols as well as data format must be independent. Middleware and software components address this heterogeneity issue. Middleware is a feature that allows several devices to be managed by the platform. In general, middleware can be considered as a software construct mediating between two or more disparate software components [16]. The software components are part of a system or application. It is a web service, a software package, a web resource, or a module that encapsulates a set of functions or data. Components are a way to break down the complexity of the software into manageable parts [14]. Each component hides the complexity of its implementation behind an interface. This mechanism reduces the complexity of software development, maintenance, operations, and support, and allows to reuse the same code in many systems. To preserve this mechanism, the software components and the middleware for AAL must be kept simple and offer broad compatibility and interoperability with most of the IoT components. Excessive duplication of proprietary software must be prevented. Overall, it is better to opt for solutions and initiatives that are open source, easily to install, and quickly maintainable. Moreover, if the middleware is built on microservices, it guarantees flexibility and ease of work in large systems, reducing the amount of communication and coordination between entities [13].

3.2 Availability of Services

AAL systems are intended to change according to the needs of seniors and the configuration of the smart home that must integrate new IoT components. The user profile and his preferences are unique, necessitating the use of personalized sensors and actuators. Sometimes, it also requires to implement new services or modify existing ones. Despite the scalability of the technology induced by the changes, the AAL system must provide reliable and efficient services. This is all the more important given that the final users are not comfortable with technology. The software architecture must then be able to evolve with the senior needs and inspire confidence among the seniors and the city.

Each microservice can be: deployed independently; independently designed, developed and tested. As a result, this architecture style has a greatly increased responsiveness to change. It makes it possible to respond better to the objectives of responsiveness and adaptability of Agile approaches [13]. The individual components can be run across a variety of platforms. A layered and non-monolithic architectural organization makes it possible to promote the scaling up of components and technical requirements in a transparent manner. Indeed, each layer is responsible for the local management of a subset of information, while the overall management lies with all components. To ensure the availability of services, the system must be able to detect, to reason and act on the actions performed in the environment. The ability to communicate and interact with the surroundings is part of the AAL approach.

3.3 Services Delivery

The proposed architecture is intended for an entire city. It must then be able to be deployed to multiple participants. This scalability according to the number of seniors must not affect the quality of services offered. The AAL system must also guarantee security as it covers private issues.

The microservice architecture structures an application as a collection of services that are highly maintainable and testable, loosely coupled, independently deployable and organized around business capabilities. The microservice architecture enables the continuous delivery and deployment of large and complex applications. AAL system can be spread across multiple servers or even multiple databases. The architecture has better fault isolation; if one microservice fails, the others will continue to work. To evolve quickly, the system offers at least one local cache. This is necessary to ensure the resilience of the system. For example, if the microservice of the local user fails or is slow, other microservices will not be affected, they should be able to work independently. In the worst case, the remote information will be empty or classified with a default value. In this case, the microservices will also be faster, because they will not need to join data from a remote source to meet the demands of users.

3.4 Adaptability

To ensure that the smart home fulfills the senior needs, the design of AAL system must be participatory, transdisciplinary and user centered [9]. Interactions with the smart home remain simple and integrated into everyday life to facilitate its use by seniors. AAL systems should be able to anticipate the user’s needs as much as possible and provide the necessary assistance in a non-intrusive and subtle manner. The profiles, the health status of seniors and the habitats are mostly different. The system must be organized to effectively manage these differences and offers equal, adapted and accurate services despite the underlying differences and the response of the users.

To ensure adaptability and ease of use, intuitive interfaces through voice control and tangible interfaces must be offered to provide for the seniors, easy ways to control the AAL system. At the reverse, the AAL system must put in place mechanisms to notify caregivers using IoT components that are dispatched into the home. Thus, the AAL architecture must share information between the IoT components to monitor the senior anywhere, at any time, regardless of the kind of action performed and assistance needed. Therefore, the information shared between the IoT components is described at a high level of abstraction in order for the IoT components to avoid specific implementation details and rather exchange semantic information.

Fig. 1.
figure 1

AAL system logic architecture based on microservices.

Full size image

4 AAL Systems Design and Implementation

Deriving from the previous requirements, the AAL architecture proposed in the City is based on a middleware that offers microservices described on a high level of abstraction. The microservice architecture ensures interoperability between distinct technologies over time. A microservice architecture is a specific software system design process that structures an application as a collection of loosely coupled services. The services work in cooperation to provide the features defined in the system. With microservices, each application runs independently from the others. Therefore, adding or changing features will affect only the service involved without affecting the others.

4.1 Architecture Design

Figure 1 illustrates the logical architecture of microservices that defines the distribution and relationship between AAL systems, subsystems, and components. This architecture, built as a set of independent microservice modular components, is easy to test, maintain and understand. It enables organizations to increase their agility while improving workflows and the time needed to enhance production.

The access protocol management module provides an interface for the handling of the different communication protocols based on the standard IEEE 802.15.x and 802.11. It usually acts as a driver for connected objects. Typically, this module provides wireless mesh technology designed to carry small amounts of data over short or medium distances.

The connectivity protocol module is designed as an extremely lightweight published/subscribed messaging transport. It is useful for connections to remote sites where a small code footprint is required or a reduced network bandwidth. It implements a channel subscription mechanism. Whenever an event occurs, it notifies all entities registered in the channel. Thus, when a new event occurs all registered components are notified, avoiding an active standby.

The microservice of persistence and data management deals with data backup in the appropriate databases. As part of this architecture, we deployed two database management systems. One deals with raw data and the other with processed data to increase efficiency in some monitoring operations.

The protocol bridge is a microservice that bundles devices and other technologies into a single solution. It provides a uniform user interface and a common approach to automating actions and rules across the system. It communicates electronically with smart and not-so-smart devices, performs user-defined actions, and provides high-level access to connected objects.

The asynchronous event driven is responsible for the web application server, for presenting information and notifications in a client’s application. It communicates with the rest API by the PUT, GET, POST and DELETE commands. It spreads the data to the upper layers. The Gateway API manages access, certificates, and security protocols.

Physically, the proposed system is organized in six layers (Fig. 2). The lowest layer is composed of connected objects, including all the sensors, equipment and actuators that transform the habitat into a smart habitat.

Each data, each event, each action generating a stimulus is sent to the upper layer, the layer of controllers. This layer deals with the management of connected objects and the sensor network. It includes Sensors Controllers, Smart Lamp Controllers and Voice Command Controllers. This layer allows bidirectional communication between the connected objects and the middleware. The controller layer is implemented logically in our architecture by the access protocol management module.

Interoperability, subscription, notification, heterogeneity, and command execution are operations performed in the middleware layer. This layer offers mostly an abstraction to handle connected objects. It is just composed of few components: OpenHab and MQTT servers. It is deployed in a server running on a Raspberry Pi. Clients connect to an application server for data access. To ensure security, the Rest API is the only API able to connect to the Rapsberry Pi for data exploitation. All other layers consist of components that allow access and exploitation of data via Rest APIs or rich clients.

Fig. 2.
figure 2

Physical architecture of the IoT components for AAL system design.

Full size image

5 Architecture Deployment

The experimental evaluation of the proposed system was performed in two phases. During the first phase, a functional test of the user’s system assistance scenarios was run in the laboratory to establish the perceived usefulness of the system. During this phase, we emphasized the robustness and scalability of the system from a user and a technological point of view. During the second phase, we conducted a home experiment. We deployed the AAL architecture in five senior apartments in the city of Côte Saint-Luc, Canada.

The main objective of the proposed AAL system is to provide intelligent assistance and detect changes in the behavior of the occupant. The rest of the document focuses on the second phase experimentation that satisfies the requirements management on the heterogeneity, scalability and adaptation to the senior profile.

5.1 Materials and Method

The five participants involved in the experiment were living alone and showed quite diverse profiles (Table 1). They were between the age of 80 and 95. The proposed architecture of the system did not require any particular configuration for its deployment in different habitats. An installation at the participant’s house required between one and two hours, depending on the layout of his apartment. To this must be added two hours of configuration of each kit, then about five minutes to adapt the services to the needs of a participant. The adaptation of the services is done by activation or deactivation of the docker corresponding to microservices.

Table 1. Profile of participants.
Full size table

First in the laboratory, several user experiences and robustness tests were conducted to determine the behavior of software components in the face of profile changes, partial updating and technological scalability. Secondly, during the experience at home, a preliminary interview was conducted with each participant to explain technological tools. The participant was then invited during the usability testing phase to create real-life scenarios. Each situation was accompanied by a possible adjustment of the system, efforts were put to change as less as possible the participants’ habitat. To meet the needs of the citizens, four assistance mechanisms were proposed:

  • Automatic lighting controlled by voice;

  • Automatic lighting when the person comes out of the bedroom and goes to the bathroom during night. A light path is installed between the bedroom and the bathroom;

  • Spotlight lighting system to remind activity (It’s time to take medication) or objects (Do not forget the keys when going outside);

  • Automatic notification of community and social information organized by the town hall.

To illustrate the participation of seniors in the installation process, one of the participants preferred that the light path was installed along the stairs, instead of between the bedroom and the bathroom. He had expressed the need that the path from the garage to the ground floor be lit when needed. Another participant, presenting visual impairments, emphasized the advantage of ordering the turning on of lights by voice, as soon as she entered her home.

At the end of the installation, a summative evaluation of acceptability was requested from participants. Four of the five participants were satisfied with the test and would be curious to go further. They found the use of voice commands appropriate to their context.

The diversity of sensors and actuators used demonstrated the multiplicity of protocols and the technological scalability put in place. The 80 sensors used and distributed in about 20 devices per apartment materialize this part of the scalability. The local cache used for each installation makes it easier to partition the systems so that individual configurations and settings do not affect the entire system.

Figure 3 shows, for each AAL system requirement, the elements used to perform the evaluation.

Fig. 3.
figure 3

Elements used by each requirement to make the assessment.

Full size image

Many factors affect the performance of the AAL system, such as the performance of connected objects, the amount of available memory, the communication mode, the response time, the architecture and operating system of each component, the support of communication between the IoT, the algorithms used and the primary need of the system. In particular, heterogeneity induced by the disparity between IoT components may contribute to other factors, such as additional downtime while some components are waiting for others. It is therefore important to calibrate all relevant IoT components to provide information about events, such as communication time, system time, input output time and idle time. The six communication protocols and the eight services were interoperable to ensure the heterogeneity of the system.

The design of the modules in microservices brings a loosely coupling between component and a fault isolation these translate the reliability. Efficiency translates into the ability to perform non-atomic deployments and individually update components. For the moment, the number of five participants is too small to evaluate the capacity of our AAL infrastructure to support scalability. It is expected to deploy with more than 20 participants for better assessing this requirement.

6 Conclusion

This paper presents the design, development and deployment of an AAL environment which supports independent living in smart home for seniors. The system is based on a middleware that merges many different technologies to build the smart environment. The backbone of the system is its modular architecture based on microservices where different bundles (independent pieces of code) are in charge of providing the required functionalities. It allows adding easily new devices and new features, or replacing some devices without disrupting the system and minimizing the adaptation effort.

Another advantage of the proposed microservice architecture is its insulation quality and resilience. If one of the components fails, if the technology becomes obsolete or the code is out of date, the team can design another one without impacting the rest of the applications, which continue to operate independently.

The installation and evaluation of the AAL system in five seniors’ home has shown that the system developed meet seniors needs. The seniors have expressed also how it is easy to use.

Ongoing research is currently conducted for analyzing the collected data and proposing new applications for satisfying new user requests. It has also shown that a middleware architecture based on microservices fulfills the requirements necessary for connecting citizens to smart city services. More technical investigations are planned to evaluate the scalability of the architecture and to deliver city services to the seniors thanks to the connected devices installed at home.