Towards the Deployment of Open Platform AAL Services in Real

Life-advantages and Lessons Learned

uSmAAL: A Case Study for Implementing Intelligent AAL Services in Real Life

based on the Open Platform universAAL

Jan Stengler, Gouri Gaikward and Helmi Ben Hmida

∗

Fraunhofer Institute for Computer Graphics Research IGD, Fraunhoferstr. 5, 64283 Darmstadt, Germany

Keywords:

Showcase, AAL Services, Standardization, Real Life Deployment, Semantic Interoperability.

Abstract:

Nowadays, most Ambient Assisted Living systems are conﬁned to individual projects. They are primarily

closed products with a limited set of features, thus reducing its extension, adoption and reuse. The aim of this

paper is to make a ﬁrst attempt to increase standardization and interoperability oriented efforts by focusing

on open systems. We aim to share our experience with developing and deploying Ambient Assisted Living

solutions on the top level of the standardized open platform universAAL in real life. This paper identiﬁes

the essential aspects of the system architecture and investigates the advantages of providing generic services,

shared and reusable components in real life. In addition, this paper presents an evaluation protocol of the

different components, focusing on system sustainability and reliability.

1 INTRODUCTION

Ambient Assisted Living (AAL) is an umbrella con-

cept for a multitude of devices, services and informa-

tion and communication technologies (ICT) assisting

citizens in their own home and supporting their mobil-

ity by means of innovative technology (Wichert and

Eberhardt, 2011). Through the literature study, sev-

eral landscape papers come with the conclusion that

despite the huge effort in the ﬁeld of AAL, the real

world exploitation of the platform and research output

seems to be fairly limited to a minority of closed sys-

tems, speciﬁc devices and protocols (Memon et al.,

2014). Thus, the real life AAL services use fre-

quency is always under the expectation, where shar-

ing software component, exchanging hardware and

easily adding new services component seems to be too

far from the application scope (Wichert et al., 2012).

As a solution, the best practice for interconnecting

different standards, exchanging data between services

and easily integrating new services will be the key for

development of new generation of AAL services and

technology (Kung and Jean-Bart, 2010).

Nowadays, open platforms are supported by a

∗

Corresponding Author: Helmi Ben Hmida, Fraunhofer

IGD, Fraunhoferstr. 5, 64283 Darmstadt, Germany. E-

mail: helmi.ben.hmida@igd.fraunhofer.de.

large community of stakeholders, often have no own-

ership of the code, and usually adopt open standards

(Boudreau, 2010). Following this tendency and due

to the fact that interoperability, standardization add to

security are reported and judged as the major IT chal-

lenge in Europe, we believe that it is not efﬁcient to

develop AAL solutions for individual project.

Looking forward to face this challenge, we aim

to minimize the gap among the real world use case

requirements and the capabilities of today’s available

standard open platform solutions through demonstrat-

ing an AAL use case based on the European stan-

dard open platform universAAL (Tazari et al., 2012)

for AAL service implementation and deployment in

real life. In the next section we will make an attempt

to cover the actual AAL system including its architec-

ture, advantages and the system performance through

the evaluation framework.

2 RELATED WORK

AAL technologies are nowadays used for support-

ing, assisting, preventing and improving wellness and

health conditions for different categories of people,

mainly the elderly ones (Stevenson, 2014). A smart

environment can be presented as a regular looking

Stengler J., Gaikward G. and Ben Hmida H..

Towards the Deployment of Open Platform AAL Services in Real Life-advantages and Lessons Learned - uSmAAL: A Case Study for Implementing

Intelligent AAL Services in Real Life based on the Open Platform universAAL.

DOI: 10.5220/0005450200670074

In Proceedings of the 1st International Conference on Information and Communication Technologies for Ageing Well and e-Health (ICT4AgeingWell-

2015), pages 67-74

ISBN: 978-989-758-102-1

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

home by the installing different types of sensors, ac-

tuators and diverse intelligent system where the in-

formation from different sensor will help to provide

a very good overview about the environment status.

In fact, the deduced context will be mainly used for

providing, guiding and orienting the system behav-

iors, and decisions toward safer, healthier and more

comfortable environment. Most of AAL systems in-

cluded in smart environment aims to improve comfort

and security, therefore dealing with medical rehabili-

tation, monitoring mobility and physiological param-

eters, and delivering remedies (Dlodlo et al., 2013).

Thus, many research and development projects are

private ﬁnanced or funded by international and gov-

ernmental organizations.

Some of the AAL application occupancy includes

helping with mobility and automation (Dubowsky

et al., 2000) and also increasing the social connec-

tion and communicating tools between peers, family

and friends (Mynatt et al., 2001). The ACHE system

(Mozer, 2008) in Colorado aims to permanently mon-

itor the environment, control the resident action, thus

saving energy resources in desire with the resident.

The Georgia Aware Homes system is based on intel-

ligent sensors which in return provides information to

robots which help to assist, monitor and support el-

derly people (Kidd et al., 2009). In Japan, almost 15

care apartment have been built, where the objective is

to improve the quality of life of both elderly people

and their caregivers. From the perspective of med-

ication management and health support related do-

mains, the related AAL systems aim to take control of

the heath conditions of elderly people (Qudah et al.,

2010), (Khan et al., 2010), where the safety of the

elderly people plays a big role in the future of AAL

systems. Many Smart home have also been developed

in European countries. In UK, the Gloucester’s Smart

House mainly are geared up to help subjects with de-

mentia by monitoring houses all day (Barnes et al.,

2008). In more sophisticated project, the US Hospi-

tal on Home project aims to bring hospital to home

through implementing a tele care system (Paul III,

2013). Liao et al. have created a robust sleep mon-

itoring system based on the vital sign analysis (Liao

and Kuo, 2013).

2.1 Discussion

Although the diversity and the high quality of the

available AAL solutions, they have a main common

factor which is their “CLOSED” aspect. Closed plat-

form are considered as a software system where only

the service developer and/or provider have access and

control over the application. From devices inter-

connection point of view, only pre-implemented sen-

sor and actuator can be taken in consideration, where

no new functionalities, sensor and actuators can be

straightforwardly added to the originally exploited

ones.

2.2 Open Platform

Within the broader question of how to best organize

the development and commercialization of the tech-

nology as ambient intelligence system, an innovator

may choose to “open its technology”. Thus, allow-

ing outsider to participate to its development, grow-

ing and commercialization. This will help mainly to

the improvement of individual component; creation

of extension, add-ons and upgrade; the elimination of

bugs and error, quality and cost improvement (Tazari

et al., 2012). An Open Platform is a software sys-

tem build based on open standards which implies that

the vendor allows, and perhaps supports the ability to

collaborate and contribute toward the development of

several “compatible” solutions. Thus, by using such a

platform, , all hosted open platform AAL services are

imperatively interoperable and can interact and sur-

vive with each other providing ﬂexibility and freedom

to ﬁt the end user’s needs.

Tazari et al have presented the AAL open plat-

form universAAL. It has consolidated the work done

among other European projects to produce a “Stan-

dard” AAL system for large scale deployment of AAL

solutions. Similarly, Schmidt et al has started from

the assumption that due to the diversity of AAL solu-

tions, the scope of its commercialization is also re-

duced. Looking at this hypothesis, they only have

suggested an open Middleware that can be used to im-

plement, develop and conﬁgure AAL solutions. Be-

sides, after a deep framework literature study (Spi-

talewsky et al., 2013), most of open platform pro-

vide a “partial solution, and are not ready to support

the full pledged solution ready for real world deploy-

ment”. As a main consequence based on open plat-

form, we can synthesize that one of the major chal-

lenges of the actual AAL domain, is to test, validate

and deploy the created platform with all their capa-

bility of openness, interoperability, service integra-

tion and data sharing in real life scenarios. Or else,

what are the main requirements for a successful de-

ployment of an AAL service based on open platform

in real environment? How can we judge that open

platform is sufﬁciently mature, sustainable and reli-

able, thus ready to be installed in real life? To spec-

ify the necessary requirement, and to answer this en-

tire question, next sections will make an attempt to

bring the universAAL open platform from research

ICT4AgeingWell2015-InternationalConferenceonInformationandCommunicationTechnologiesforAgeingWelland

e-Health

to industry. This will be done by presenting a use

case of AAL services deployment in real environment

and demonstrating the full capacity of open platform

through tracing our evaluation framework.

3 SYSTEM ARCHITECTURE

3.1 uSmAAL System Overview

The universAAL Smart AAL System (uSmAAL)

forms an open, ﬂexible, reusable and mainly expand-

able system for providing smart AAL services based

on the open source platform universAAL. As seen in

Figure 1, uSmAAL inspires its robustness, ﬂexibil-

ity and extendibility from its system architecture. It

consists mainly of ﬁve main blocks: hardware, con-

troller, exporter, AAL smart services and the univer-

sAAL open platform. From a Service oriented Ar-

chitecture (SoA) point of view, the uSmAAL system

rely on the semantic open platform uAAL which can

totally avoid a priori agreed APIs by purely relying

on externalized ontological models so that not only

data can be shared based on a universal solution for

data representation, but also control functions can be

accessed in a goal-based way using one single API.

Such an approach can be classiﬁed as true semantic

interoperability which enables sharing both data and

functionality based on pluggable ontologies. There-

fore, the uSmAAL will have the ability to:

• Read data from various integrated sensors and

combine them to recognize relevant situations.

• Utilize functionality provided by diverse devices

distributed in the intelligent space and orchestrate

it.

• Achieve an effective behavior in response to the

recognized situations.

Figure 1: uSmAAL System Overview.

Despite the above cited success key and innova-

tive features, several rumors have unfortunately ac-

companied platforms born within the research insti-

tutes and the public funding. Accompanied reasons

are related to “proof of concept” thus doubt about the

platform maturity, reliability, stability and robustness

to reach the market breakthrough. Several interested

industries have always asked the question: “how far

is the platform able to resist to long time execution

under stressed condition”. The suggested system ar-

chitecture will refute rumors about the research origin

software component since the system has proved to be

highly stable and reliable while deploying in real life

environment.

3.2 uSmAAL Current AAL Services

Adding to the complete overview of the robust and

functional system running on the top of an open plat-

form in the next subsections, we will start with the

AAL service block as one of the main uSmAAL sys-

tem components since it presents the “functional”

one, where all the interaction with the hardware side

and the platform are done through its intermediate.

The uSmAAL system has created and installed sev-

eral AAL services that aim to maintain information

like status, events or consumption situation about sev-

eral electronic sensors and actuators and control them.

The services provide access to sensors as well as ac-

tuators within each of the homes. Table 1 presents a

sample of the implemented AAL services.

Table 1: A sample of uSmAAL AAL services.

AAL Service Service description

Dim Light Automatic control of the

light system (value in %)

Get Motion status Detect persons activities

Control Heating Controls the heater

through setting a speciﬁc

modus)

Get Person position Detect the person position

Fall detection Automatic recognize falls

Alarm function Automatic control of the

alarm system (on/off)

Get CO2 value Get information about the

CO2 value in a room

3.3 UniversAAL Platform

The above highlighted uSmAAL individual AAL ser-

vices are running on the top of the semantic open

platform universAAL (Tazari et al., 2012). The latter

one has been built in a community effort since 2010

and ﬁnally established in January 2014 thus combin-

ing the best approaches of EU FP6 and FP7. It pro-

vides the result as an open source software platform

TowardstheDeploymentofOpenPlatformAALServicesinRealLife-advantagesandLessonsLearned-uSmAAL:A

CaseStudyforImplementingIntelligentAALServicesinRealLifebasedontheOpenPlatformuniversAAL

for AAL domain. The universAAL platform is an

open-source software platform for the development,

operation and marketing of AAL applications. It is

offered with the Apache Software-License 2.0 and is

especially designed for the development of open and

distributed AAL systems. As a semantic open plat-

form and thanks to its unique features, universAAL

will allow the creation of a sustainable ecosystem of

AAL applications and service providers. From de-

veloper point of view, the open platform-universAAL

offers a set of development features that are relevant

for development time:

• Assisted development environment to create AAL

application based on the universAAL open plat-

form.

• Distribution of AAL services over different pro-

cessing components in a network

• Sharing information and composing services be-

tween all developed application and services upon

universAAL.

• Cross-exploitation of the offered functionalities.

• Facilitating the extension of an application in

terms of functionalities and devices.

• Simplifying the adaptation of a certain application

to new circumstances.

3.4 Exporter

After highlighting the software level, mainly com-

posed of the platform and the uSmAAL AAL ser-

vices, the exporter aims to build the interface be-

tween the real world presented by the hardware and

the related protocol from one side, and the virtual

part presented by the services and an abstraction of

the hardware devices from the other. It receives com-

mands from the AAL services and translates them

into low level instruction depending on the addressed

controller. This means if a speciﬁc device is turned on

by some AAL service, the exporter receives this com-

mand and redirects it to the corresponding controller.

Based on the hardware protocol, it transfers the latter

one to the addressed device and vice-versa. If a de-

vice is manually turned on, the AAL services have to

be instantly notiﬁed about this through the informa-

tion transferred from the device to its controller, then

to the service through the exporter. Due to the fact

that the exporter builds the bridge between the ser-

vices and the hardware devices, it also represents a

core component of the interoperability in uSmAAL.

Due to the platform capability from one side, and

to the OSGI framework capacity from another, the

exporter has knowledge about the existing controller

and their hardware devices. Thus a developer of an

AAL service can concentrate on implementing differ-

ent AAL service without taking in consideration the

speciﬁc controller and hardware protocol.

3.5 Controller

A controller speciﬁes a standard for the communica-

tion where different hardware devices, mainly in a

smart environment, are connected to it.

Within the uSmAAL system, the controller aims

to establish the communication between the AAL ser-

vices and the device layers, it can track the state of

these devices and perform actions that will change

their status. To ensure a maximum capability of in-

teroperability, the uSmAAL system makes it possible

to combine different controller in parallel. Examples

are PLCs (Programmable Logic Controller), KNX or

ZigBee controller. In case of a PLC, the devices will

be connected to its modules and controlled through

the written value in PLC memory. The controller will

receive the commands for controlling devices from

the exporter and change the value in the memory of

the corresponding module accordingly. For example

a lamp can be turned on or off by writing the required

value in the memory address of the module the light

is connected to. If the status of a device is changed

manually, the controller will notice this and the value

in the memory address is changed too. In such a case

the controller will report this change to the exporter.

3.6 Hardware

The current hardware block of the uSmAAL system

is mainly deﬁned by two components: actuators and

sensors. The actuators represent hardware devices

which can be controlled, e.g. lights, heaters, outlets,

blinds, etc. This means it is possible to change the

status of the device by performing some interaction.

This interaction can be performed by directly chang-

ing the actuator values, or automatically through the

system itself (e.g. reasoning). In both cases the con-

troller will perform an action which will result in the

desired outcome. It may also be possible that an actu-

ator is controlled manually like switching a lamp by

pressing a button. If so, the controller will be auto-

matically notiﬁed about such an action.

The second component is represented through the

sensors. A sensor measures values and registers mod-

iﬁcations in the environment and notiﬁes the con-

troller about it. A sensor can be for example a mo-

tion sensor, a temperature sensor or a CO2 sensor.

Since sensors are measuring speciﬁc variables of the

environment (temperature, CO2 value, etc.), they can

ICT4AgeingWell2015-InternationalConferenceonInformationandCommunicationTechnologiesforAgeingWelland

e-Health

keep track of the actual status of it. Thus they build

the basis for speciﬁed rules and reasoning. For ex-

ample reasoning like “turn on the light in a room if

there is movement at night”, is based on the sensors

for movement and daytime.

4 SYSTEM ARCHITECTURE

ADVANTAGES

Figure 2 illustrates the ﬂexible modular architecture

of uSmAAL. Because of the possibility to use several

exporters, the uSmAAL architecture ensures a max-

imum of interoperability. This means all the hard-

ware components are editable, exchangeable and are

able to work in parallel. The AAL services are imple-

mented in the different plug-ins, which are establish-

ing the communication to the exporters. It is possible

for a plug-in to interact with more than one exporter

and thus control many different types of hardware de-

vices.

Figure 2: uSmAAL System Overview.

4.1 Interoperability

Interoperability describes the extent to which diverse

system are able to work together to achieve a com-

mon goal. Thus systems and devices can exchange

data and hardware resource easily. Adding to its re-

liability, stability and auditability, interoperable solu-

tions based on open platform offer a very important

cost advantage for their end users. Consequently, bet-

ter adherence to open sources will permit competition

in the market, thus reducing vendor lock and price

monopoly. Last but not least, interoperability offers

a big room of ﬂexibility and freedom to ﬁt the end

user’s needs. uSmAAL system has proﬁt from the

universAAL platform capability and enriches it based

on its modular architecture and the use of Exporter

as an interface between the real environment (Hard-

ware) and the abstract one (Services). In fact, the

exporters are deﬁning a protocol for the communica-

tion between the plugins and the hardware devices, no

matter where they belong to; smart home, eHealth or

other linked domain to the AAL.

In fact, cutting the direct link between the AAL

service plugins and related hardware offer the possi-

bility for changing and/or adding new hardware tech-

nology without being restricted by the solution con-

straint. This was proved with the uSmAAL system

through changing the PLC controller and related de-

vice with a KNX one, with the use of the same AAL

service.

Adding to it, the designed architecture of uS-

mAAL offer one of the main needed capability by

AAL system which is the system integration, where

several new AAL services “plug-ins” can be easily

added to the actual ones, then dynamically linked to

the appropriate hardware layer.

4.2 Reasoning and Service Evolution

As observed from the beginning, the uSmAAL sys-

tem as a SoA is classiﬁed as a “modular” architec-

ture, since it’s mainly composed of several basic AAL

services able to respond the elementary functionali-

ties, dynamically communicating together due to the

available semantic layer. The modular approach, as

a key for future programming technology, aims to di-

vide the set of complete application to basic modules.

It intends to facilitate the re-combination of modules

differently, thus offering several new sets of services

and/or recognized states dynamically and in a more

ﬂexible way.

The recombination process is reinforced through

several components developed within the univer-

sAAL system, the situation reasoning and the Drools

reasoner. Based on these components, it will be too

easy to separately create new intelligent rules, thus

combining several individual AAL services and com-

ing with new situation or a combination of AAL ser-

vices. For example, one key technology installed be-

hind the uSmAAL is the localization of residents in

their homes and neighborhoods. Once installed, many

services can be placed together such as modular fall

detection, intrusion detection, alerts when leaving the

house or if the window is still open; and much more,

Figure 3. Modular technologies will be the main key

toward offering better services with minimum cost.

TowardstheDeploymentofOpenPlatformAALServicesinRealLife-advantagesandLessonsLearned-uSmAAL:A

CaseStudyforImplementingIntelligentAALServicesinRealLifebasedontheOpenPlatformuniversAAL

Figure 3: Modular Approach Overview.

5 EVALUATION

Let us recall that the purpose of this paper is to sci-

entiﬁcally reject all negative feedbacks around open

platforms, mainly the fact that they are not stable,

neither reliable and have never been tested in real

environment and only used for research. This will

be demonstrated via an opposite example: the uS-

mAAL system. Indeed, the suggested system solu-

tion is created upon an open platform, thus proﬁting

from all the advantages previously highlighted in the

earlier section. The exploitation of the uSmAAL sys-

tem will only make sense if it is in parallel tested and

proved. It is therefore crucial for the evaluation to in-

clude real pilot sites and test in realistic conditions.

The evaluation framework should assess a system’s

quality, which thus will be held to valuable informa-

tion in addition to hands-on practical information on

the performance. To do so, the evaluation framework

assesses the uSmAAL system reliability and sustain-

ability. Unfortunately, the literature study revealed

that currently no AAL speciﬁc evaluation model ex-

ists. We aim through this section to evaluate the uS-

mAAL system such that each part and the whole sys-

tem functions successfully and with stability.

5.1 Evaluation Approach

The uSmAAL system performance will retain open

till ﬁnding a concrete answer, mainly related to its

sustainability and reliability, to judge its readiness for

industrialization and deployment in real life environ-

ment. To evaluate the system thoroughly, we will di-

vide it such that each level can be analyzed and tested

individually and together to achieve our goal of a sta-

ble and reliable system. As a matter of fact, the sta-

bility factor will be validated if every bounded input

will be held in a bounded output over an optimal time

interval. Concerning the reliability factor, a system is

reliable if, including all hardware, ﬁrmware, and soft-

ware, will satisfactorily perform the task for which it

was designed or intended, for a speciﬁed time and in

a speciﬁed environment. For example, it is very im-

portant to have a stable and a reliable system when

checking the connection between the PLC controller

and exporter, thus to conﬁrm that the socket connec-

tion is successfully established every time. To achieve

our goal, the system evaluation will be composed of

two main evaluation block: The Functional testing

and the Stress testing. While functional testing will

help to validate the functionality of each individual

service, the stress testing will validate the system sta-

bility and reliability.

5.2 Functional Test

The uSmAAL system is actually composed by run-

ning single services based on four main ontologies:

Physical things, devices, furniture and proﬁles. Func-

tional testing is a quality assurance (QA) process and

a type of black box testing that bases its test cases

on the speciﬁcations of the software component un-

der test. Functions are tested by feeding them in-

put and examining the output, where internal program

structure is rarely considered. Functional Testing usu-

ally describes what the system does. Within the uS-

mAAL system, the different AAL services are tested,

to check if all are executed accurately to get the re-

quired output. Some of the examples of test cases

that were tested to check functionality include test-

ing whether the universAAL application runs success-

fully, the conﬁguration ﬁle is parsed successfully, also

to check if the devices can be controlled without any

errors, each device have their respective correct mem-

ory addresses. Each use case is tested for all the de-

vices of the device type. For each test case expected

output was obtained, e.g. when a light was turned on,

it did turn on as expected and thus the functional test

is validated.

5.3 Stress Test

Stress testing is a software testing activity that deter-

mines the robustness of software by testing beyond

the limits of normal operation. Stress tests com-

monly put a greater emphasis on robustness, avail-

ability, and error handling under a heavy load, than

on what would be considered correct behavior under

normal circumstances (Zhang et al., 2008). Putting

uSmAAL under high usage condition will be the way

to validate its robustness and readiness for the market.

5.3.1 Looping the Service Requests

The automatic loop for starting the entire uSmAAL

service for all registered devices every minute aims to

ICT4AgeingWell2015-InternationalConferenceonInformationandCommunicationTechnologiesforAgeingWelland

e-Health

restart almost 50 services every minute. The test aims

to validate the communication reliability and stability

between the AAL services and the Exporter. After 2

weeks of test, uSmAAL Service execution is achieved

without exceptions and delay. Figure 4 shows the

graph of delay in milliseconds for each AAL service

execution. Observing the x-axis we can see that dur-

ing more than 3000 service execution within the uS-

mAAL system, an execution delay of 1020 to 1030ms

is obtained where the service call execution time is

only 10ms (AAL Smart Service level) where as the

hardware part (AAL Hardware level) consumes more

than 95% of the execution time . Taking onto ac-

count the complexity of the PLC processing and same

the network communication, the delay has kept a sta-

ble average along the test period with a granularity of

±30 millisecond due to the above mentioned factor.

Figure 4: Delay in milliseconds versus service calls.

5.3.2 Proving the Connection Stability Between

the Exporter and the PLC

After proving the bridge between the AAL service

layer and the Exporter, it is now time to stress the con-

nection between the exporter and the Controller, thus

the purpose of this test case is to check the stability of

the established socket connection between both lay-

ers. After running the protocol for the same test pe-

riod (2 Weeks), more than 600 000 established socket

connections were error free based on the log ﬁle.

5.3.3 Analyzing the Service calls

In a more qualitative test, we have analyzed the uni-

versAAL open platform log ﬁles looking for logged

call status for each services. Based on the univer-

sAAL platform, the call status can end with val-

ues: Succeeded; No matching service found; Re-

sponse timed out ;Service speciﬁc failure

Figure 5 presents a log portion about the status of

a service call. After analyzing all the log ﬁles with

more than million lines, all services execution are al-

ways returned with the “:call succeeded” status, thus

reﬂecting the reliability of the platform from one side

and the uSmAAL system from another one.

Figure 5: CallStatus succeeded.

5.3.4 Memory Usage

The memory usage issues are considered as most

common issues for open platform extracted from the

research environment. For the created uSmAAL sys-

tem, and due to its critical impact on the system fu-

ture, we have tracked the memory evolution through

the standard java tools “visualvm” for more than one

month, the memory evolution was always stable and

never exceeded a heap of 250MB. Figure 6 presents a

sample of the memory evolution.

Figure 6: Memory consumption Graph.

6 CONCLUSIONS

Nowadays, existing AAL systems are bound to al-

ready implemented services and special types of hard-

ware devices. This lack of dynamic makes them

rather unusable for the long term usage in a real life

environment. From the other side, and despite the

wide spread support for openness and heterogeneity,

most projects have not yet sufﬁciently reached a ma-

ture level allowing them to access the industrial mar-

TowardstheDeploymentofOpenPlatformAALServicesinRealLife-advantagesandLessonsLearned-uSmAAL:A

CaseStudyforImplementingIntelligentAALServicesinRealLifebasedontheOpenPlatformuniversAAL

ket where only a very few AAL open platform archi-

tecture are linked to the industry by producing a sta-

ble and sustainable system mature enough to break

through the market. Moreover, there is no best prac-

tice about how to use them in real life deployment.

We have made an attempt through the current pa-

per to refute all negative feedback and misunderstand-

ings around AAL Open Platform. The presented uS-

mAAL system builds upon the open platform univer-

sAAL and has proven a very advanced degree of sta-

bility and reliability, while being deployed in a real

life environment. It has been recently deployed in 22

apartments for elderly people thus supporting them

for their daily activities, and increasing their comfort

and security in the meantime. In addition, this paper

has presented the best practice related to the combi-

nation of the needed components, while deploying it

in real environment. The delivered system is expand-

able. Thus extra-AAL services can be implemented

and the set of hardware devices/protocols can be ex-

tended and/or exchanged and the set of supported de-

vices can be extended. At the end the required result

is obtained and our goal of a stable and reliable sys-

tem is achieved and approved.

Further future work will mainly articulate com-

plex situation recognition in an AAL smart environ-

ment add to the enrichment of the actual service cata-

logue with more health oriented AAL services.

REFERENCES

Barnes, N., Edwards, N., Rose, D., and Garner, P. (2008).

Lifestyle monitoring-technology for supported inde-

pendence. Computing & Control Engineering Jour-

nal, 9(4):169–174.

Boudreau, K. (2010). Open platform strategies and innova-

tion: Granting access vs. devolving control. Manage-

ment Science, 56(10):1849–1872.

Dlodlo, N., Smith, A., Montsi, L., and Kruger, C. (2013).

Towards a demand-side smart domestic electrical en-

ergy management system. In IST-Africa Conference

and Exhibition (IST-Africa), 2013, pages 1–12. IEEE.

Dubowsky, S., Genot, F., Godding, S., Kozono, H., Skwer-

sky, A., Yu, H., and Yu, L. S. (2000). Pamm-a robotic

aid to the elderly for mobility assistance and monitor-

ing: a helping-hand for the elderly. In Robotics and

Automation, 2000. Proceedings. ICRA’00. IEEE In-

ternational Conference on, volume 1, pages 570–576.

IEEE.

Khan, D. U., Siek, K. A., Meyers, J., Haverhals, L. M., Cali,

S., and Ross, S. E. (2010). Designing a personal health

application for older adults to manage medications. In

Proceedings of the 1st ACM International Health In-

formatics Symposium, pages 849–858. ACM.

Kidd, C. D., Orr, R., Abowd, G. D., Atkeson, C. G., Essa,

I. A., MacIntyre, B., Mynatt, E., Starner, T. E., and

Newstetter, W. (2009). The aware home: A living lab-

oratory for ubiquitous computing research. In Coop-

erative buildings. Integrating information, organiza-

tions, and architecture, pages 191–198. Springer.

Kung, A. and Jean-Bart, B. (2010). Making aal platforms

a reality. In Ambient Intelligence, pages 187–196.

Springer.

Liao, W.-H. and Kuo, J.-H. (2013). Sleep monitoring sys-

tem in real bedroom environment using texture-based

background modeling approaches. Journal of Ambient

Intelligence and Humanized Computing, 4(1):57–66.

Memon, M., Wagner, S. R., Pedersen, C. F., Beevi, F.

H. A., and Hansen, F. O. (2014). Ambient assisted liv-

ing healthcare frameworks, platforms, standards, and

quality attributes. Sensors, 14(3):4312–4341.

Mozer, M. C. (2008). The neural network house: An envi-

ronment hat adapts to its inhabitants. In Proc. AAAI

Spring Symp. Intelligent Environments, pages 110–

114.

Mynatt, E. D., Rowan, J., Craighill, S., and Jacobs, A.

(2001). Digital family portraits: supporting peace of

mind for extended family members. In Proceedings of

the SIGCHI conference on Human factors in comput-

ing systems, pages 333–340. ACM.

Paul III, D. P. (2013). An innovation in healthcare delivery:

Hospital at home. Journal of Management Policy and

Practice, 14(6):73–91.

Qudah, I., Leijdekkers, P., and Gay, V. (2010). Using mobile

phones to improve medication compliance and aware-

ness for cardiac patients. In Proceedings of the 3rd

International Conference on PErvasive Technologies

Related to Assistive Environments, page 36. ACM.

Spitalewsky, K., Rochon, J., Ganzinger, M., Knaup, P., et al.

(2013). Potential and requirements of it for ambi-

ent assisted living technologies. Methods Inf Med,

52(3):231–238.

Stevenson, S. (2014). 6 ways ambient as-

sisted living improves quality of life.

http://www.aplaceformom.com/blog/10-29-14-

ambient-assisted-living/. Accessed: 2014-12-14.

Tazari, M.-R., Furfari, F., Fides-Valero,

A., Hanke, S., H

oft-

berger, O., Kehagias, D., Mosmondor, M., Wichert,

R., and Wolf, P. (2012). The universaal reference

model for aal. Handbook of Ambient Assisted Living,

11:610–625.

Wichert, R. and Eberhardt, B. (2011). Ambient assisted liv-

ing. Springer.

Wichert, R., Furfari, F., Kung, A., and Tazari, M. R. (2012).

How to overcome the market entrance barrier and

achieve the market breakthrough in aal. In Ambient

Assisted Living, pages 349–358. Springer.

Zhang, B.-j., Pan, X.-z., Wang, J.-b., et al. (2008). A re-

coverable stress testing algorithm for compression and

encryption cards. Journal of Zhejiang University SCI-

ENCE A, 9(10):1398–1405.

ICT4AgeingWell2015-InternationalConferenceonInformationandCommunicationTechnologiesforAgeingWelland

e-Health