# Development of an Ecosystem for Ambient Assisted Living

João Rosas, Luis M. Camarinha-Matos, Gonçalo Carvalho, Ana Inês Oliveira, Filipa Ferrada

<figure><img src="image_1.png" /></figure>

## To cite this version:

João Rosas, Luis M. Camarinha-Matos, Gonçalo Carvalho, Ana Inês Oliveira, Filipa Ferrada. Development of an Ecosystem for Ambient Assisted Living. 9th International Summer Workshop on Multimodal Interfaces (eNTERFACE), Jul 2013, Lisbon, Portugal. pp.200-227, 10.1007/978-3-642-55143-7_9. hal-01350750

HAL Id: hal-01350750

https://inria.hal.science/hal-01350750

Submitted on 1 Aug 2016

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Development of an Ecosystem for Ambient Assisted Living

João Rosas, Luis M. Camarinha-Matos, Gonçalo Carvalho, Ana Inês Oliveira, and Filipa Ferrada

Universidade Nova de Lisboa, Faculty of Science and Technology, Campus de Caparica, 2829-516 Monte Caparica, Portugal

{jrosas, cam}@uninova.pt,g.carvalho@campus.fct.unl.pt, {aio, faf}@uninova.pt

**Abstract.** Society is facing big demographic changes. In 2050, it is expected that the number of elders will reach 1500 million (about 16% of the world population). As people age, they become more dependent on assistance services. Care and assistance organizations start failing, as the number of people who need help increases beyond their ability to comply. The creation of an ecosystem for Ambient Assisted Living, facilitating partnerships creation between service providers, is proposed as a strategy to improve care provision and leverage its capacity. The specification of the ecosystem is based on canonical models and verified through simulation.

**Keywords:** Ambient Assisted Living, Ecosystem, Collaborative Networks, Information and Communication Technologies, Simulation.

## 1 Introduction

The society where we live is facing a big demographic change. People live longer, therefore life expectancy is increasing. In 2000, there were already 420 million people with more than 65 years old (which corresponded to about 7% of the world population). In 2050, it is expected that this number reaches 1500 million (about 16% of the world population) [1, 2]. The number of elder people who need care and assistance is also increasing, surpassing the number of youngsters who contributes with taxes.

This context brings new challenges to the traditional health care systems, as social security systems are becoming unable to afford the cost of providing assistance to this growing number of people. Therefore, there is an increasing necessity to search for new solutions that will allow people to live in the best possible way, in the last stages of their life. These systems would allow people to extend their life in their favorite environments, favoring confidence, autonomy, mobility and welfare.

Information and communication technologies (ICT) offer new opportunities for the provision of improved care and assistance services. Ambient Assisted Living (AAL) is a
concept focused on the use of technology as a way to improve the independence and welfare of aged or disabled people, at their homes.

With this research work, we aim at contributing to provide an answer to this need. Our goal consists of developing an Ecosystem for AAL. Our strategy is based on Collaborative Networks [3]. For such, our effort was focused on the instantiation of the conceptual architecture proposed in the AAL4ALL project [4]. We relied on the utilization of canonical models for the development of our system, allowing the formulation of more simple, yet useful, specifications. We tested the AAL ecosystem as a distributed simulation system. In this regards, we take simulation as a design paradigm [5]. Within this paradigm, we can predict how a system is likely to behave in the future. We can also test the system when it is subjected to specific situations, e.g. the failure of services provision, too many assistance services requests or infrastructure shutdown, and assess if it works adequately. Given that many of these failures can only be experienced after the system is put in operation, using simulation, we can anticipate them and modify the specification of the system, prior to the physical development.

This research work was performed during the eNTERFACE'13 summer workshop [6]. Given that the timeframe of this event is a single month, many of the features we started to develop during the workshop are continued in the context of the AAL4ALL project.

We start this work by firstly presenting an overview of the AAL concept and its most important aspects. In section 2, we present a literature review, mostly concerned with introducing and analyzing current aspects about assistance services, users, service providers, sensors and actuators, and supporting infra-structure. Section 3 is devoted to establishing the requirements, specification development and validation of the proposed AAL ecosystem. Finally, section 4 provides a synthesis of the work, achieved results and proposes the next steps for future work.

## 2 Ambient Assisted Living

The area of AAL can be addressed from several perspectives, as it comprises technological, strategic, economic, social, moral and regulatory aspects. During the literature review, we emphasize some of the mentioned aspects, aiming to provide an adequately general overview of AAL. Through this chapter, the current developments in the field of AAL, namely in terms AAL products, services, and available platforms are illustrated. Relevant international projects and roadmaps are also mentioned. In this regard, this work can also be seen as a contribution towards the effective development of solutions that may help to better deal with this demographic trend.

### 2.1 The Importance of AAL

As mentioned before, there has been a severe demographic change, faced by most developed countries, which leads to a rapid increase of the percentage of aged population. As
illustrated in Fig. 1, the projected percentage of people above 65 years old over the active population reaches 50% by 2050. This trend of having fewer youngsters, who have to support the growing elderly population, requiring increased assistance, raises costs and leads to the rupture of the social security and social care systems.

<figure><img src="image_3.png" /><figcaption>**Fig. 1.** Projected number of persons aged 65 and over expressed as a percentage of the projected number of persons aged between 15 and 64 (statistical data from [7])</figcaption></figure>

In order to maintain the care provision capacity at an affordable level in the future, there is an urgent need to find effective and affordable solutions to provide care and assistance to elderly.

## 2.2 The AAL Concept and Technology

Ambient Assisted Living is a concept in which technology is used as a way to improve the welfare and independence of elder or disabled people living alone at their homes. Typically, a variety of sensors and actuators installed at their homes or in their clothes are used to remotely monitor their wellbeing conditions. Fig. 2 illustrates a home and a user, which contains a number of sensors for remotely monitoring users' welfare. These devices operate supported by an infra-structure, usually of wireless type, which provides adequate connectivity. It is on top of these devices that AAL services operate.
<figure><img src="image_4.png" /><figcaption>Fig. 2. AAL environment: (a) environmental sensors; (b) physiological sensors</figcaption></figure>

Typical services in AAL include home environment services, like home safety and security, temperature monitoring, gas detection, smoke detection, intruder alert, fall detection. It can include welfare monitoring for people that are not ill, like monitoring heart rate, blood pressure, and body temperature. It can also include health support for ill people, like behavior monitoring (for people with dementia) and chronicle disease management. Furthermore, it may also include occupation and recreation services, which support the involvement of leisure services and the continuation of professional activities.

## 2.3 AAL Sensors and Actuators

AAL sensors are used to monitor the health and welfare situation of the users. If these sensors are combined with communication devices, usually wireless, we can monitor the users remotely. There are many types of AAL sensors, namely, blood pressure, cardiac, body temperature, pedometers, urinary salinometer, and so on. According to their characteristics, more specifically, the type of performed observations, they can be split into several categories. For instance, sensors can be classified as “home safety sensors”, which are used to monitor and protect from internal threats and ensure that users' homes are in safe conditions, regarding aspects such as temperature, smokes, floods, or gas leakages. Another sensor category, “home security sensors”, help protect users from external threats, e.g. for monitoring intrusion, detection of presence, or doors/windows opening. As illustrated in Fig. 3, home safety sensors hold a large number of sensor sub-classes, each one devoted to each aspect of users’ wellness, like monitoring home temperature, smoke detection, gas leakage, and carbon monoxide. These varieties can be organized in taxonomies.
<figure><img src="image_5.png" /><figcaption>**Fig. 3.** Sensor taxonomy illustrating several types of AAL sensors (Note: the “Thing” element is automatically included by the ontology editor [8])</figcaption></figure>

As opposite to home sensors, AAL sensors used to monitor users welfare or health can be classified as personal, which are used to monitor users welfare conditions.

Such great variety of types and technologies in sensors raises concerns related to integration and interoperability, because the available electronic devices on the market do not
provide standardized interfaces for integration. In a further section, we mention a number of research projects, which deal with integration and interoperability in AAL. There are also currently focused concerns related to the privacy of the data collected to monitor the elderly [9].

AAL actuators can perform interventions on the elders or on their homes, in order to adjust elderly welfare. If these actuators are equipped with communication devices, usually also wireless, interventions can be performed remotely. Fig. 4 illustrates a partial taxonomy of AAL actuators.

<figure><img src="image_6.png" /><figcaption>Fig. 4. AAL actuators</figcaption></figure>

According to each purpose, AAL actuators can be classified into broad categories in a similar way as the AAL sensors. There are, nevertheless, huge concerns in the utilization of AAL actuators because they are devices which allow remote changing of the state of the elder or his home, and this poses many security issues, such as: adequate performance, operation by non-authorized personal, etc., that may lead to harmful situations.

## 2.4 AAL Services

AAL services intend to enable people with specific needs to live an independent and save life. To this end, the services have to cope with a number of user and environmental challenges [10], namely, low or declining capabilities, distinct elderly needs accordingly to
health conditions, limited (human and financial) resources, low tolerance of technical problems, the desire to feel in control of their lives, avoid stigmatization and keeping privacy.

As mentioned in [11], past research and developments in elderly care services, as well as current market offers, are characterized by some fragmentation. The focus has been predominately put on the development of isolated services, e.g. monitoring of some health related parameters, fall detection, agenda reminder, alarm button, etc., each one typically provided by a single organization, and often showing an excessive techno-centric flavor. Contrasting to this situation, the concept of Care and Assistance Service (CAS) is proposed in [11], which refers to a category of services, either of a medical or social nature, aiming at helping senior citizens in their daily lives, compensating for the reduction of physical and/ or mental capabilities that comes with the ageing process. As mentioned in [11], the execution of a care and assistance service may involve a number of software services and human intervention (manual tasks). The actual structure of such service also depends on the interaction between the provider and the end-user, and may ultimately (and dynamically) vary according to the flow of that interaction.

Similarly to sensors, AAL services exist in multiple categories. In AAL4ALL, four categories of services, named as services for four specific life-setting, were considered, as identified in Fig. 5.
<figure><img src="image_7.png" /><figcaption>Fig. 5. Illustration of home safety and security services category, proposed in the AAL4ALL</figcaption></figure>

## 2.5 AAL Service Providers

Providing AAL services involves the participation of several types of entities, ranging from health care providers, to day care centers, to hospitals and fire departments. ICT providers are responsible for supplying of necessary technological infrastructures, which allows AAL services providing.

An important aspect, which is in fact addressed during this research work, is that in the AAL context, given the heterogeneity of these stakeholders, a single and isolated provider is not enough to satisfy every concrete need of AAL users. As described in Section 3 of this article, the proposed approach is to develop an AAL ecosystem, which allows providers to collaborate and establish partnerships. In such way, they can together be able to provide the adequate AAL services to each user.

These services require adequate ICT infrastructures for a proper service provision. Such infrastructure involves data models, hardware and software components, processes and people. Information flow includes observations from sensors, user profiles, services providers’ interactions and treatments. Additionally, a typical AAL environment includes
heterogeneous components of distinct technology, which need to interoperate. A useful approach for such interaction between these components is to rely on a service-oriented approach, such as the Enterprise Service Bus [12,13], in which the elements of heterogeneous nature are able to interact using a standardized protocol.

## 2.6 Current Research in AAL

**Research Projects.** As mentioned in [14], a considerable number of research projects are focused on developing systems that monitor the health or welfare conditions of the elder and their activities, looking for disturbances requiring assistance by the service providers. The most common architecture is based on a set of sensors, more or less extended, dispersed throughout the housing and allowing the control of a number of activities (for example, opening and closing of doors, stove utilization or the use of refrigerator water consumption / gas / electricity, etc.). By merging all the information gathered by different sensors, it is possible to determine the current activity of the person who is being controlled and identify deviations from his/her daily routines. These deviations can be used to detect emergency situations or changes in the condition of the person.

Internationally, there are several projects that have addressed these aspects. For instance, the projects: UbiSense [15], ROSETTA [16] and Dreaming [17] focused on the development of systems for elderly health and welfare conditions in order to keep their independence at their homes. The projects ITALH [18] and OASIS [19] addressed the interoperability issues between distinct technologies (zigBee, Bluetooth, GPRS, etc.). The i2Home project [20] was devoted to the development of new devices for AAL based on existing industrial standards. The AWARE [21] developed a social network for promoting the social inclusion of the elderly, aging workforce and contribution to society.

At the European level, there were several Roadmap projects in the area of AAL. For instance, the AALIANCE project [22] was devoted to the creation of innovative AAL devices and sensors. The ePAL project [23] was about promoting balanced and active life for retired people or in the process of retirement in Europe. The SENIOR project [24] was concerned with performing a systematic assessment of the social, ethical and privacy concerns in aging and ICT. Finally, BRAID project [25] addressed the research and Technological Development for active ageing, through the consolidation of the results from other existing roadmaps.

**Existing AAL Products.** The market of AAL products is very fragmented, as there are still not fully consolidated AAL solutions that meet the needs of all countries worldwide. Although they are still significantly expensive, it is expected that the products in the AAL area will decrease about 50% of the costs associated with health care services for senior people, envisaging, for example, that the U.S. market of AAL is in 20 million euros per year with a rising trend [14].
There are many products already available in the market. For instance, Equivital [26] is a system composed of several monitoring sensors connected to a wearable wireless module. Sensium [27] is a platform which continuously monitors a user's body using non-intrusive wireless sensors. The Hallo Monitoring [28] is a fall detector with automatic alarm sending service. Grand Care [29] is a system described used to monitor the daily activity and welfare of a person in a non-intrusive way. HomMed [30] is a monitoring unit placed at a person's home, which collects and transmits data on the person's health conditions to a service center that processes and presents this information to health care providers.

**Critics to Existing Approaches.** As we mentioned in [3], many of the AAL initiatives are characterized by being too techno-centric, without properly addressing social and strategic aspects. On the other hand, AAL services are too fragmented and provided by different service providers. These providers are also characterized by a deep heterogeneity. However, no single AAL provider can adequately fulfill the elderly needs. Given these factors, and as already mentioned, the best strategy for the provision of AAL would be through collaborative approaches.

As such, a trend identified in a recent work [3], shows the need to move from a scenario characterized by fragmented services, typically provided by single service providers, and often showing an excessive techno-centric flavor, to more integrated care services. In contrast, there is now a perception that is fundamental, for the success of future AAL support systems, to seek synergies between the areas of ICT, Ageing and Collaborative Networks. Integrated AAL services would then be provided by multiple stakeholders, through partnerships.

# 3 AAL Ecosystem Development

Considering the several aspects revised in previous chapters, we describe the specification and development of the AAL ecosystem support platform in this chapter. As suggested from the international trends, described on the BRAID project [25], the approach for creating the ecosystem is based on collaborative networks.

## 3.1 The AAL4ALL Conceptual Architecture

In order to adequately handle the mentioned issues, the adopted approach is to instantiate the AAL4ALL architecture illustrated in Fig. 6. We adopted the vision shared in AAL4ALL project of following a more socio-technological approach. As such, we are more focused on instantiating the top layer of the architecture, which is used to assist us in the specification and implementation of the AAL ecosystem that is proposed in this work.
<figure><img src="image_8.png" /><figcaption>Fig. 6. AAL4ALL Conceptual Architecture, inspired and adapted from [4]</figcaption></figure>

This architecture illustrates the adopted perspective of focusing on the socio-business aspects at the top layer, by providing functionality for partnership creation. The architecture is composed of the AAL ecosystem layer, the services layer, and the infrastructure layer. The ecosystem layer lies at the top of the architecture. In this layer, it is important to consider the management and governance principles of AAL ecosystem. It is based on a collaborative network philosophy, facilitating an effective collaboration between the stakeholders participating in AAL service provision.

For the services layer, given the large scope of the area and the complexity of AAL, which is of a multi-disciplinary nature, it becomes convenient to consider complementary perspectives of analysis. In the AAL4ALL project, four different life settings in an elder's life were considered, namely: Independent Living, Health and Care, Occupation in Life, and Recreation in Life. These perspectives help adequately organize the collections of assistance services in AAL services taxonomies as illustrated in the previous chapter. Such collections allow fulfilling the envisaged necessities corresponding to the elderly conditions. Additionally, as services are of distinct characteristics, e.g. ambient monitoring services versus health monitoring services, they might be provided by distinct service providers. As such, the service collections are organized according to the mentioned four life-settings.

The infrastructure layer plays the role of a facilitator (provides support) for the development and delivery of care and assistance services. Such infrastructure should provide, among other functionalities, channels and mechanisms for safe communications and information sharing and exchange among the members of a given AAL ecosystem. It has two sub-layers, the local infrastructure corresponding to the support infrastructure located in a specific "location", e.g. users' home, care center, health care center, human-centered
environment (intelligent cloth, mobile gadgets, etc.); and the global infrastructure, sup-
porting the network of "spaces" (or local environments) "inhabited" by the various stake-
holders. The global infrastructure illustrated in Fig. 7 supports the interaction between the
entities/nodes engaged in care provision and the assisted people. It supports multi-node
services, distributed processes, software services invocation and composition.

<figure><img src="image_9.png" /><figcaption>Fig. 7. Representation of a global infrastructure composed by several local infrastructures</figcaption></figure>

**3.2 Requirements Identification**

According to what was mentioned before, the adopted approach for the AAL ecosystem
development is based on canonical models specification. This type of model allows the
specification of a system with considerable complexity using simple, yet useful structures.
This allows developing the system within a limited timeframe, without undermining the
identified functional requirements.

**AAL Services.** Pursuing an approach based on canonical models, an AAL service can be seen as a set of actions designed to provide care to a user. A service can be identified by a name and a pre-established functionality. A service can be also composed for other services in a hierarchical composition structure, as shown in Fig. 8.

<figure><img src="image_10.png" /></figure>
<caption>**Fig. 8.** Hierarchical services definition</caption>

This complies with the notion of service established in the previous chapter, and as illustrated in Fig. 5. The combination of services results in "tailored / customized packages". It is a way to meet particular needs of certain users. The functional requirements for the management of the AAL services are described in Table 1.

<table><caption>**Table 1.** Functional requirements of AAL services management</caption><thead><tr><td>FR</td><td>Description</td></tr></thead><tbody><tr><td>FR_s1</td><td>Creation of services which can be adequately characterized by ID, name and type</td></tr><tr><td>FR_s2</td><td>Search, update and deletion of existing services</td></tr><tr><td>FR_s3</td><td>Creation of services as a composition of other services</td></tr><tr><td>FR_s4</td><td>Contract of services by users</td></tr><tr><td>FR_s5</td><td>Association of a running service to a user or users' home</td></tr></tbody></table>

**AAL Users.** In canonical terms, a user can be characterized by a name, an address and a set of pre-established AAL characteristics (e.g. in an ontology). The functional requirements for the management of users are listed in Table 2.

<table><caption>**Table 2.** Functional requirements for the AAL users management</caption><thead><tr><td>FR</td><td>Description</td></tr></thead><tbody><tr><td>FR_u1</td><td>Creation of new users, which can be adequately characterized by ID, name and a set of pre-established attributes for its AAL characterization</td></tr><tr><td>FR_u2</td><td>Search, update and deletion of existing users</td></tr><tr><td>FR_u3</td><td>Service contracts establishment with users</td></tr><tr><td>FR_u4</td><td>Track of AAL relevant events from a user's services</td></tr><tr><td>FR_u5</td><td>Billing of contracted services</td></tr></tbody></table>

**AAL Service Providers.** Providers can be characterized by name, location, and type. (Infrastructures providers, and AAL service deliver, care centers, surveillance and security providers, etc.). The functional requirements of providers' management are identified in Table 3.

<table><caption>**Table 3.** Functional requirements for AAL providers management</caption><thead><tr><td>FR</td><td>Description</td></tr></thead><tbody><tr><td>FR_p1</td><td>Creation of new providers, which can be adequately characterized by ID, name and a set of pre-established attributes for its AAL characterization</td></tr></tbody></table>
<table><tr><td></td><td>zation</td></tr><tr><td>FR_p2</td><td>Search, update and deletion of existing providers</td></tr><tr><td>FR_p3</td><td>Creation of providers as composition of other providers</td></tr><tr><td>FR_p4</td><td>Association of providers and the services they deliver</td></tr><tr><td>FR_p5</td><td>Participation of providers in services contracts with users</td></tr></table>

**AAL Ecosystem.** Given that an elder, or a group of elderly, may have got specific necessities, they require distinct types of assistance services. In these cases, it is necessary to provide customized AAL services. However, a service provider operating alone is not usually able to provide the necessary services to these elderly. A solution would be a costly investment to obtain the capacity to provide the necessary services. As a better approach, when tailored care provision is needed, service providers can organize themselves in partnerships, creating composed services that suit these needs. For instance, as illustrated in Fig. 9, *independent living*, *health*, *occupation* and *recreation* service providers can join in order to combine their services.

<figure><img src="image_11.png" /><figcaption>**Fig. 9.** Creation of composed services from providers of distinct types</figcaption></figure>

Inside such partnerships, it is now possible to create customized services, or service packages, as illustrated in Fig. 10, which are able to suit the particular necessities of a number of users.

<figure><img src="image_12.png" /><figcaption>**Fig. 10.** Customized packages of AAL services</figcaption></figure>
Following the approach of developing canonical models, we can assume that a partnership can also be seen as a single service provider. Therefore, a provider can be composed by a single entity or by several entities. Some entities participating in a partnership may, per se, be already a partnership. This leads to a hierarchical definition of service provider, as illustrated in Fig. 11.

<figure><img src="image_13.png" /><figcaption>**Fig. 11.** Single versus partnership service providers</figcaption></figure>

The AAL ecosystem, illustrated in Fig. 12, is composed of several service providers, each one delivering their own services. It is a virtual space in which members (service providers) agree to create partnerships as soon as good opportunities are found. It facilitates fast, dynamic, on-the-fly partnership formation. As members of the ecosystem, partners remain prepared to engage in partnerships [31]. When a market opportunity for a new customized service appears, they engage in fast partnership creation. The partnership remains while the service package is being delivered.

<figure><img src="image_14.png" /><figcaption>**Fig. 12.** Illustration of an AAL ecosystem</figcaption></figure>

Considering these aspects, the requirements for the AAL ecosystem are described in Table 4.
<table><caption>**Table 4.** Functional requirements of the AAL ecosystem management</caption><thead><tr><td>FR</td><td>Description</td></tr></thead><tbody><tr><td>FR_e1</td><td>Registering of users/elders</td></tr><tr><td>FR_e2</td><td>Registering of providers</td></tr><tr><td>FR_e3</td><td>Partnerships creation</td></tr><tr><td>FR_e4</td><td>Partnership life-cycle management</td></tr><tr><td>FR_e5</td><td>Business model (tailored packages, responsibilities, profit sharing approach, etc.)</td></tr></tbody></table>

## 3.3 Ecosystem Specification

The specification of the AAL Ecosystem requires the preliminary definition of a number of concepts, namely, the users, their homes, the Care Providers, and the AAL Services. These definitions will then be used in the specification of the ecosystem functionality. During the definitions set below, we use lower case for specifying single elements and upper case for sets.

**Definition 1 (AAL User)** - Can be an elder or a person that lives alone or with barely any assistance that wants to continue living in his own home. This user subscribes to one or more services that compensate his/her limitations, aiming to improve welfare and safety. A user can be abstractly defined as a tuple $u = (IDuser, Name, VAttr)$. The set VAttr represents the attributes that adequately characterize a user. From now on, let us consider the existence of the set of $U = \{u_1, u_2, \dots, u_n\}$.

**Definition 2 (User's Home)** - The environment where the user lives is also an important part of the AAL Ecosystem. If the user has limitations, it is important to monitor his/her surrounding environmental conditions, such as the temperature, the luminosity, the activity of potentially dangerous electric or gas devices, intruders alarm, etc. It can be specified as a tuple $h = (IDhome, location HomeAttr)$. The set HomeAttr represents a set of attributes that adequately characterizes the user's home. From now on, let us consider the set of $H = \{h_1, h_2, \dots, h_n\}$.

**Definition 3 (AAL Service)** - An AAL service can abstractly be defined as a tuple $s = (IDservice, Description, SAttr)$. The set SAttr represents a set of attributes, which adequately characterizes the AAL service. From now on, let us consider the set of $S = \{s_1, s_2, \dots, s_n\}$.

Recalling the recursive characterization of a service provider suggested in Fig. 11, a service provider $sp_i$ may be a single entity or composed of other service providers. When it is composed of multiple entities, say $sp_{i,1}, sp_{i,2}, \dots$ and $sp_{i,n}$, their respective sets of services
$S_{i,1}, S_{i,2}... S_{i,n}$ can be combined in appropriate ways with an abstract composition operator, resulting in the composed services, as illustrated in Fig. 13. The set $S_i$ is a subset of the all possible services composition $2^{B_i}$. Therefore, $S_i$ holds the useful or profitable compositions only. The elements of $S_i$ may in turn become basic services of other partnerships.

<figure><img src="image_15.png" /><figcaption>Fig. 13. A service provider as a composition of other service providers</figcaption></figure>

**Definition 4 (AAL Service Provider)** - Entity that is able to provide care and assistance services to elders or persons who need assistance. They can be formal care providers, such as a hospital or a clinic; or informal care providers, such as churches or voluntary groups. One provider has a structure composed of one or several associated providers forming a partnership and can be recursively defined as a tuple $pi = (\{p_{ij} | p_{ij} \neq p_i\}, S_i)$, in which $S_i \subseteq (\cup composition(2^{B_i}))$ and $B_i = \cup_{j=1}^n S_{i,j}$.

**Definition 5 (Subscription Contract)** - A subscription contract associates a user to a service provider by means of a number of services subscription. Each subscription can be specified as a tuple $sc = (sp_i, u_j, S)$. The set $S = \{s_1, s_2, ..., s_n\}$ represents the services subscribed by the user or delivered by the service provider.

Using these definitions, it is now possible to model mechanisms or rules to identify and select potential services that a user might subscribe.

**Definition 6 (Useful Services Selection)** - These are the services that a user or elder may need, according to its user attributes. The service selection can be formally obtained using the following query:

$$ \forall s \in \text{Services} \quad \forall u \in \text{Users} (\text{UsefulService}(s, u) \leftarrow \text{attributes}(s, SA) \wedge \text{attributes}(u, SU) \wedge SA \cap SU <> \emptyset). $$

In other words, the interception between service attributes and user attributes which are variables, results in a non-empty set.

In the last definition, SU and SA are free variables meaning they are not bound by universal or existential quantifiers. Using Definition 6, it is possible to select and propose services to a user, according to its characteristics or attributes, which can be a step before
contract subscription. The mentioned definition can also be improved in order to consider the attributes of the user's home.

**Definition 7 (AAL Service Market Opportunity)** - Corresponds to an opportunity identified in the market, which may lead to the creation of a new tailored AAL service. It can be specified as a tuple $MO = (ID, OPA attr )$, in which $OPAttr$ represents the set of attributes characterizing the opportunity. For now on, let us consider the set of market opportunities $MO = \{mo_1, mo_2, ..., mo_n\}$

**Definition 8 (AAL Service Provider Selection)** - Given a Market Opportunity $mo$ (Definition 7), we can identify adequate partners through the following query:

$$ \forall_{mo} \forall_{sp \in Providers} \forall_{criteria} (UsefulProvider (mo, sp) \\ \leftarrow HasService(sp, s) \wedge attributes (s, SAttr) \wedge attributes (mo, MOAttr) \\ \wedge (SAttr \cap MOAttr) <> \phi \wedge complies (sp, criteria)) $$

The abstract operator 'complies' checks that candidate service providers do not clash with given business/strategic constraints.

**Definition 9 (AAL Partnership Formation)** - Given a market opportunity $mo$, either concrete or abstract, a corresponding partnership, or new service provider $sp_i$ according to Definition 4, can be formed with the candidates service providers from the set $\{sp_j | UsefulProvider(mo, sp_j)\}$.

## 3.4 Data Models for the AAL Ecosystem

**The Global Infrastructure Model.** In general terms, the global infrastructure supports the interaction between the entities/nodes engaged in care provision, and the assisted people. It supports multi-node services, distributed processes, software services invocation and composition. The main functional blocks are: Global Infrastructure Management, Security Services, Software Services Composition, Safe Information Management Services at Global Level, Auditing Services, Safe Communication Service, and Auxiliary Services (including identification of critical issues, assessing performance, statistics, and reporting.

In our concrete specification, we assume that the global infrastructure takes care of a number of homes and users. Each home has got a number of ambient sensors (e.g. temperature, blood pressure, etc.). Periodic observations are taken from these sensors, which might trigger important events. Some events may require an adequate response, like sending an SMS alarm to the user's relatives, or sending an emergency team to the user's home. The conceptual model presented in Fig. 14 incorporates these requirements.
<figure><img src="image_16.png" /><figcaption>Fig. 14. Global infrastructure data model</figcaption></figure>

**AAL Ecosystem Data Model.** In general terms, the top layer of the architecture – AAL Ecosystem – has the main purpose of providing, under a socio-technical perspective, organization and collaboration support for the AAL multi-stakeholders, organized as a collaborative community. Members of the AAL ecosystem include the AAL services/product providers, the end users, regulators, and other support entities such as governmental entities. This layer supports functionalities for establishing links between providers and users, business models, collaboration processes and governance policies enforcement. Main functional elements of this layer include: Ecosystem Management, Assets Management, Governance Policies Specification, Business Models Management, Providers User Linking Mechanisms, Consortia Formation Mechanisms, and Collaboration Support Mechanisms.

In our concrete specification, the ecosystem allows the creation of service providers, users, contract subscription, services and services composition, AAL events and billing. The conceptual model presented in Fig. 15 illustrates these aspects.
<figure><img src="image_17.png" /><figcaption>Fig. 15. Ecosystem management data model</figcaption></figure>

Whenever a user subscribes a service, a subscription contract between user and service provider is established. An AAL service can be a simple service or be recursively composed of other services, resulting in tailored packages. Such packages, for composed services, may be supplied by a single service provider. As established in previous section, for completing the package, the services of an additional partner may be necessary. In such case, the model allows the creation of providers that are in fact the combination of partners, resulting in partnerships. The Events entity encodes the main episodes related to these contracts, like the addition of more services to the contract. The Billing entity encodes the periodic payments resulting from the contract.

Having the specification established in previous section and the corresponding data models, we need to select an infrastructure for an adequate implementation, which is the subject of the next Section.

## 3.5 Technological Infrastructure

Ambient Assisted Living is a multifaceted area as it harnesses a diverse range of technologies from various domains. Requirements like remote supervision of elderly, information management and business processes, just to mention a few, are quite demanding in terms of ICT for the physical architecture of AAL. One of such necessities is the data centers which hold information of elders and monitoring data. The choice for adequate infrastructures is very important in terms of the necessary budget for launching an AAL business.
**The Cloud Computing Infrastructure.** Cloud computing environment is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. The cloud computing model provides essential characteristics, such as broad network access and resource pooling. It has got three service models, namely, Software as a Service, Platform as a Service and Infrastructure as a Service. It also provides several deployment models: Private Clouds, Community Clouds, Public Clouds, and Hybrid Clouds [32]. The typical features of Cloud Computing are, for instance, faster development/installation time, lower initial capital, and "pay-per-use".

Based on the possible deployment models, several strategies and infrastructures modalities for the development of the AAL4ALL ecosystem with Cloud Computing, together with their main features, are summarized in Table 5.

<table><caption>**Table 5.** Cloud computing modalities that are useful for the AAL ecosystem.</caption><thead><tr><td>Modalities</td><td>Illustration</td></tr></thead><tbody><tr><td><strong>Dedicated infrastructure/datacenter</strong><ul><li>High initial cost.</li><li>High development and launch time.</li><li>Complex installation and configuration.</li><li>The stakeholders are responsible for maintenance.</li><li>Some advantages are the complete ownership and control over the infrastructure, services and information.</li></ul></td><td><div><strong>Dedicated infrastructure</strong></div><div><img src="image_0.png" alt="A dedicated infrastructure with a server, a network cable, and a yellow label."></div><div><img src="image_1.png" alt="A building with a red roof, a yellow label, and a network cable."></div><div><img src="image_2.png" alt="A network cable with red and yellow plugs."></div><div><img src="image_3.png" alt="A network cable with a yellow label."></div><div><img src="image_4.png" alt="A network cable with a red label."></div><div><img src="image_5.png" alt="A network cable with a yellow label."></div><div><img src="image_6.png" alt="A network cable with a red label."></div><div><img src="image_7.png" alt="A network cable with a yellow label."></div><div><img src="image_8.png" alt="A network cable with a red label."></div><div><img src="image_9.png" alt="A network cable with a yellow label."></div><div><img src="image_10.png" alt="A network cable with a red label."></div></td></tr></tbody></table>
### Public cloud (provided by 3rd party supplier)

* It is probably the fastest option to create and launch the ecosystem.

* Many suppliers of Cloud Computing infrastructures are available.

* Low initial cost. But if time is long, dedicated infrastructure may become cheaper.

* Short Setup/installation time.

* Cost is proportional ("Pay per use") to the number of users, utilization time, and used computational and storage resources, which might require some further analysis in face of the specific needs of AAL.

* A major issue is that information of users (elders, customers and stakeholders), like the profiles and clinical information, is stored on third-party infrastructures, which raises security and privacy concerns.

* An additional drawback is the lack of standards that allow portability. As such, once one provider is selected, solutions get too dependent on that provider.

<figure><img src="image_18.png" /></figure>

### Private cloud (owned by one stakeholder)

* Has similar/same advantages of the public cloud.

* Infrastructure is totally controlled by the stakeholder/AAL services provider.

* Better in terms security and privacy, as management and access to information is performed by the stakeholder.

* The stakeholder may start with a "small private cloud", with a lower initial cost, and scale up the capacity if it becomes necessary afterwards.

* This approach might suit a major services integrator.

<figure><img src="image_19.png" /></figure>
## Community cloud

* It has got similar advantages to private clouds.

* Ecosystem acquires Cloud infrastructure to be shared by the stakeholders.

* Ownership and control by the stakeholders of AAL4ALL ecosystem.

* Acquisition, launch, and maintenance costs can be shared by the stakeholders which means lower costs and reduced business risks for each one.

* Network installation and maintenance role can be assigned to a third-party provider, or rented/"outsourced" to a cloud-supplier, which already belongs to the ecosystem.

<figure><img src="image_20.png" /></figure>

## Hybrid cloud

* Similar characteristics of both public and private clouds.

* Combination of public/community and private cloud infrastructures.

* Computer load can be balanced between private and public clouds, whenever necessary.

* Stakeholders' profiles and clinical data are stored in the private cloud; information and processes that do not pose security/privacy issues can be located in the public cloud.

<figure><img src="image_21.png" /></figure>

## Combination of a private infrastructure/datacenter with a public cloud

* Similar advantages to hybrid clouds.

* Some limitations/disadvantages of dedicated infrastructures.

* Computer load can be balanced between private infrastructure and public cloud, whenever necessary.

* Stakeholders' profiles and clinical data are stored in the private datacenter; information and processes that do not pose security/privacy issues can be located in the public cloud.

<figure><img src="image_22.png" /></figure>
**The Ecosystem Web Portal.** From the available cloud-computing modalities, we developed the ecosystem portal in a public cloud (provided by third party supplier), as illustrated in Fig. 16. It was implemented using Microsoft Azure Cloud Computing [33].

A better choice for the Cloud Computing modality would be the community cloud described in Table 5. This modality allows benefiting from the cloud computing paradigm. But contrarily to a public could, it is owned by the stakeholders involved in AAL service provision. As a result, there would be fewer concerns in terms of the data and observations taken from the AAL users.

<figure><img src="image_23.png" /><figcaption>**Fig. 16.** Adopted cloud computing modality for the AAL ecosystem portal</figcaption></figure>

The web portal allows the services providers to register and be part of the ecosystem. It allows partners to advertise their services to other partners and create partnerships whenever an opportunity arrives. Global infrastructures, which may be owned by a simple partner or by service provider's partnerships, are also implemented in the Cloud infrastructure. The main advantage is that infrastructures from providers can scale as the number of users grow. In this way, each service provider can commit a lower initial budget and achieve reduced monthly cloud renting costs.

Fig. 17 illustrates the user interface regarding services subscription contracts established between service providers and users.
<figure><img src="image_24.png" /><figcaption>Fig. 17. Services subscription of a user</figcaption></figure>

**The Local Infrastructure Nodes.** For the local nodes, representing the elders and their homes, an application that simulates a local infrastructure, which represent each user's nodes a home was designed. As illustrated in Fig. 18, several AAL services were subscribed, ranging from ambient to physiological monitoring. Each UI represents a user and its home. Whenever an event is triggered, in this simulation approach performed by a click in the UI control, the information is recorded in the corresponding table of the data model instantiated in the provider's global infrastructure, illustrated at the right side of the mentioned figure.

<figure><img src="image_25.png" /><figcaption>Fig. 18. Local infrastructure node (at the user's home) and corresponding data model from global infrastructure</figcaption></figure>
**The Global Infrastructure Nodes.** The global infrastructure node was also developed using a simulation approach, as illustrated in Fig. 14, which also illustrates the corresponding data model. Each observation taken from the local nodes is stored in the database running in the global node. The database complies with the models illustrated in Fig. 14 and Fig. 15. Such observations might trigger events that are relevant for the comfort and health of the users. These are the events shown in the user interface of the global node shown in Fig. 19.

The set of rules that identify events from observations are hard-encoded in C# inside the application. In this regard, we are planning the development of a rules based knowledge base, which provides more advanced events detection and corresponding reach at user's homes. This is scheduled for future work.

<figure><img src="image_26.png" /><figcaption>**Fig. 19.** Global infrastructure node and correspondent data model</figcaption></figure>

The interactions between the global and local nodes are illustrated in Fig. 20. These nodes exchange information regarding the mentioned events that are generated inside the local nodes, according to the subscribed AAL services. The mechanism for sending the events is based on REST services, which is supported by the Windows Communication Foundation (WCF) framework [34].
<figure><img src="image_27.png" /><figcaption>Fig. 20. Global and local infrastructures interacting through WCF.</figcaption></figure>

**The AAL System as a Whole.** The AAL Ecosystem platform was assembled together as a complete simulation system, in which information regarding AAL events flow from users and users' homes (local infrastructures) into global infrastructure nodes (Fig. 21). Member's management, services subscription, billing and other previously established requirements are fulfilled in the cloud portal, illustrated at the top of the mentioned figure. Partnership creation is also registered through the mentioned portal.
<figure><img src="image_28.png" /><figcaption>Fig. 21. The AAL ecosystem implemented as a simulation system</figcaption></figure>

During the simulation of the entire system, we could verify and certify that implementa-
tion of the components follow the specifications established for the AAL ecosystem, and
that it also fulfills the functional requirements that were established for each component of
the ecosystem, namely, users, providers, services, and ecosystem management. Each time
a new user is registered, the corresponding UI of the local node is created. A pre-
specification number of AAL services is also launched.

While the complete system is operated, we can perceive its dynamics, in which each
local node sends observations from the AAL services to the service providers’ nodes.
Information regarding these observations and events is stored in the corresponding tables
of the ecosystem database.

**Analysis of the System.** Before ending the development description of the system, it is important to mention some remarks on the outcomes of the simulated ecosystem.

Although our approach for testing the ecosystem was based on simulation, the specifi-
cation and data models were used as if the system was a real one. Simulation of events
flowed in real clock, in which we could simulate specific situations in the user’s homes,
which would allow service providers to trigger assistance services and home interven-
tions. Furthermore, we are planning to integrate real nodes (e.g., real homes and users) in
the simulation system, in the future work.

The strategy of simulating the AAL ecosystem can be seen as prior step to design a real
ecosystem. That is because through the several performed simulations, we could find
mistakes and improve specifications. Without simulation, we would have to fix the mis-
takes during system development or operation, which would cause the increase of the
costs and potentially harmful effects on the users requiring remote monitoring and assistance services. In this regard, we take simulation as a system design paradigm [5].

# 4 Conclusions

## 4.1 Synthesis of the Work

During this research work, the implementation of an Ambient AAL Ecosystem was proposed, which uses technology as a way to improve the independence and wellbeing of aged people.

In order to define the best approach for such implementation, the first step was to review the state of the art, considering the technological aspects of an AAL structure, and its services and providers. With this literature review, we concluded that current approaches have been too techno-centric and realized that a collaboration-based approach would be more promising in terms of impacts in AAL area.

Our contribution to this effort was to specify and instantiate the ecosystem layer proposed by the AAL4ALL project. We started by identifying the functional requirements of the ecosystem management layer, followed by corresponding specifications and data models. These were formulated as canonical models, which allow the characterization of complex systems using simple, yet useful structures.

Afterwards, we developed the ecosystem management application in a Microsoft Azure Cloud Computing infrastructure. Local and Global nodes were implemented in C#. The interaction between these nodes was based on WCF.

The system was tested using a simulation approach, which allowed the understanding of the dynamics inside the ecosystem, certify the correctness of the specified models, fix both design and implementation mistakes, and perceive whether we could use our models for the development of real ecosystem.

## 4.2 Achieved Results

During this work, we focused on the specification and implementation of concepts and structures for developing an AAL ecosystem. As mentioned before, we used canonical-based specifications to simulate the dynamics of the ecosystem life-cycle. With this purpose in mind, several aspects needed to be studied, in order to take the best possible decisions and to achieve satisfactory specifications and models. The results that were achieved include the following:

* Study and characterization of the AAL structure that was used in this project.

* Specification of functional requirements and specification of corresponding AAL architecture.
* Development of the ecosystem management system using a Cloud Computing framework.

* Development of local and global infrastructure nodes, which interact through WCF.

* Verification of ecosystem specification and its partial validation through simulation.

## 4.3 Future Work

Before starting to suggest future lines of action, it is worth to mention the context of this work. As mentioned before, the study and creation of an AAL ecosystem is a task which currently involves tens of researchers inside the AAL4ALL project. In this project, each one is working on concrete parts of the ecosystem development. This is important for our lines of future work, because it is recommended our future effort complements those at the project. As such, our strategy for future work is more focused on aspects, which will increase the functionality and quality of our AAL ecosystem, and at the same time, will profitable complement the tasks and results for the AAL4ALL project.

Therefore, our set of future work action comprises the integration of real nodes and users in the simulated ecosystem. The integration of these nodes in the simulated ecosystem, would allow the progressive transformation of our system from simulation to a real one. Additionally, this would then be installed in a number of homes, as a way to certify that the proposed ecosystem was specified in a way that allows further development towards real products, which may be "marketed".

Other necessary and very useful component is the development of a knowledge-based system, which by making inferences with the observations taken from sensors, would trigger the corresponding events, from which service provider would provide corresponding assistance. For instance, this component would then select the adequate intervention regarding the event, sometimes sending an SMS to relatives, other times sending a rescuing team to the user's home.

Other functionality for future work is the integration of business processes and service composition inside the simulations of the ecosystem. This would allow providing more complete AAL services, which would require several steps and several actors for their execution. Finally, we would like to incorporate in our system the capacity of modeling users with newly or emergent necessities. This would allow determining how to automatically formulate tailored packages of services and formation of corresponding partnerships.

**Acknowledgments.** This work was funded in part by the Project AAL4ALL (QREN 13852), co-financed by the European Community Fund through COMPETE - Programa Operacional Factores de Competitividade. The authors also thank the contributions from their partners in this project.
5 Bibliography

1. Steg, H., Strese, H., Loroff, C., Hull, J., and Schmidt, S. "Europe is facing a demographic challenge Ambient Assisted Living offers solutions." IST project report on ambient assisted living (2006)

2. Destatis. Older people in Germany and the EU. Wiesbaden: Federal Statistical Office of Germany (2011)

3. Camarinha-Matos, L. M. and Afsarmanesh, H. Collaborative Ecosystems in Ageing Support. Adaptation and Value Creating Collaborative Networks, Springer: 177-188 (2011)

4. T113 - Arquitectura Tecnica AAL4ALL", http://www.aal4all.org (2013), seen on 16 Feb 2013.

5. Heilala, J., Vatanen, S., Tonteri, H., Montonen, J., Lind, S., Johansson, B., Stahre, S. Simulation-based sustainable manufacturing system design. WSC 2008 -Winter Simulation Conference. Winter, IEEE (2008)

6. eNterface 2013, http://eventos.fct.unl.pt/enterprise13, seen in 2013/09/05

7. Eurostat, "Population statistics",
http://epp.eurostat.ec.europa.eu/portal/page/portal/population/data/main_tables, seen in
2013/12/20.

8. "Protégé Ontology Editor", Stanford Center for Biomedical Informatics Research at the Stanford University School of Medicine (2013), http:// protege.stanford.edu, seen in 2013/09/13.

9. Kutz, O., Mossakowski, T., Galinski, C., and Lange, C. "Towards a standard for heterogeneous ontology integration and interoperability. "International Conference on Terminology, Language and Content Resources (2011).

10. Becker, M. Software architecture trends and promising technology for ambient assisted living systems, In: Proceedings of Assisted Living Systems—Models, Architectures and Engineering Approaches, Schloss Dagstuhl - Leibniz-Zentrum fuer Informatik, Germany, Dagstuhl (2008).

11. Camarinha-Matos, L. M., Rosas, J., Oliveira, A., and Ferrada, F. A Collaborative Services Ecosystem for Ambient Assisted Living, Collaborative Networks in the Internet of Services, IFIP Advances in Information and Communication Technology Volume 380, pp 117-127 (2012).

12. Fernández-Llatas, C., Mocholi, J. B., Sanchez, C., Sala, P., & Naranjo, J. C. Process choreography for Interaction simulation in Ambient Assisted Living environments. In XII Mediterranean Conference on Medical and Biological Engineering and Computing, pp. 757-760, Springer Berlin Heidelberg (2010).

13. Menge, F. Enterprise service bus. Free and open source software conference. Vol. 2, pp 1-6 (2007).

14. "T114 – Vigilância Tecnológica – Projectos Internacionais" (2012), http://www.aal4all.org, seen in 2013/09/04.

15. UbiSense (Ubiquitous Sensing and Behaviour Profiling), http://www.ubicare.org/projectsubisense.shtml, http://www.doc.ic.ac.uk/vip/ubisense/, seen in 2013/08/20

16. ROSETTA, http://www.aal-rosetta.eu/, seen in 2013/10/10

17. Dreaming (elDeRly-friEndly Alarm handling and MonitorING), http://www.dreaming-project.org/, seen in 2013/12/12
18. ITALH (Information Technology for Assisted Living at Home), http://www.eecs.berkeley.edu/~eklund/projecs/ITALH/, seen in 2013/04/05

19. OASIS (Open architecture for Accessible Services Integration and Standardization), http://www.oasis-project.eu/, seen in 2013/07/01

20. I2Home (Intuitive Interaction for Everyone with Home Appliances based on Industry Standards), http://www.i2home.org, seen in 2013/09/20

21. AWARE (Ageing Workforce towards an Active Retirement), http://aware.ibv.org/, seen in 2013/08/30

22. AALIANCE Project, http://www.aalliance.eu/public/, seen in 2013/04/12

23. ePAL Project, http://www.epal.eu.com/, seen in 2013/06/05

24. SENIOR Project, http://www.seniorproject.eu/, seen in 2013/06/10

25. BRAID Project, http://braidproject.org/, seen in 2013/06/10

26. Equivital, http://www.equivital.co.uk, seen in 2013/09/20

27. Sensium, http://www.toumaz.com/page.php?page=sensium_life_platform, seen in 2013/10/20

28. Hallo Monitoring, http://www.halomonitoring.com/, seen in 2013/12/12

29. Grand Care, http://www.tellaboomer.com/14.html, seen in 2013/07/21

30. HomMed, http://www.hommed.com/, seen in 2013/12/10

31. Rosas, J. and L. Camarinha-Matos. A Collaboration Readiness Assessment Approach. Innovation in Manufacturing Networks, pp. 77-86 (2008).

32. Mell, P., Grance, T. The NIST definition of cloud computing (2011). http://www.nist.gov/itl/cloud/, seen in 2012/07/20

33. Calder, B., Wang, J., Ogus, A., Nilakantan, N., Skjolsvold, A., McKelvie, S., Xu, Y., Srivastav, S., Wu, J., and Simitci, H. Windows Azure Storage: a highly available cloud storage service with strong consistency. Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, ACM (2011).

34. Mackey, A. Windows Communication Foundation. Introducing. NET 4.0, Springer: 159-173 (2010).