The UniversAAL Platform for AAL (Ambient Assisted Living)

1 Introduction

As the proportion of elderly people in the population continues to increase, so too does the need to create a society where older people can be self-sustaining as long as possible, to maintain a satisfactory quality of life. Self-sufficiency, both in daily activities and in social relations, is the target of research in this sector. Thus, it is fundamental to develop services that help elderly people carry out everyday activities safely and effectively and, as far as possible, independently. This leads us to believe that the potential market for Ambient assisted living (AAL) solutions is huge, and that the adoption of a platform that helps developers produce such solutions can be a key factor facilitating the creation of new innovative services. Several developments in the fields of AAL already exist; however, these realizations are often based on proprietary architectures and, in many cases, they do not easily allow integration of external components or devices. This has some negative consequences, such as the fact that effective solutions in different regions in Europe are incapable of connecting both to relevant external systems (such as public health systems and social care systems) and to each other. Also, end users such as elderly people suffer consequences, when, for instance, hardware devices and sensors are not interchangeable. Non-integrability makes customers dependent on a specific vendor for products and services, impeding the acquisition of different devices to extend functionality, or to replace obsolete hardware.

To overcome these obstacles, the EU-FP7 project UniversAAL was set up in 2010, with its main goal being to design and develop an open platform that provides a standardized approach for an easy and economic development of AAL solutions. The UniversAAL platform benefits: (i) the end users (i.e., older adults and people with disabilities, their caregivers, and family members), by making new solutions affordable, simple to configure, and to deploy; (ii) the solution providers, by making it easier and cheaper to create innovative AAL services or to adapt existing ones by using a compositional approach based on existing components, services, and external systems; and (iii) the authorities with responsibility for AAL, by introducing a standardized approach for the development of AAL solutions that reduce vendor lock-in and generate an AAL market that lowers the prices and increases the availability of products. To stimulate an AAL market, UniversAAL has been designed to simplify the installation of UniversAAL-compliant applications by creating uStore, an online one-stop-shop for UniversAAL end-user services.

The UniversAAL platform is the result of the consolidation of the best aspects from existing available platforms in order to avoid fragmentation, reuse the functionalities already present in the other platforms, and avoid duplication by providing one common European implementation. An overview of these is provided in Section 2.

The concept of “platform” is used in a very broad sense in UniversAAL, and an overview of this is provided in Section 3. The task of designing a platform that takes account of numerous stakeholders and their requirements, deals with many technical issues, and successfully consolidates input projects is a very complex one. This needs to be approached in a systematic way, and the way we did this is described in Section 4.

The core part of the article is in Sections 5, 6, and 7, which describe the architecture of the UniversAAL platform. Section 8 reports on the work done in the project to evaluate the platform, and the article concludes by summarizing achievements in Section 9.

2 Related AAL Projects

Most of the AAL solutions nowadays available are still prototype solutions that are developed and maintained within different research projects. Often, such solutions are preliminary and lack maturity. There are some mature commercial products; however, these are typically provided as a closed solution.

Among the European research projects, we refer to projects AMIGO [2], MPOW-ER, PERSONA [19], SOPRANO [18], OASIS [15], VAALID [24], and GENESYS [7], which we call the UniversAAL “input” projects. These projects formed part of the e-Inclusion program of the FP6-IST (Information Society Technologies) framework. The projects obtained excellent results, although some weaknesses make them unsuitable candidates for widespread adoption. First, the projects are fragmented: the platforms adopted are based on the architectures and requirements specified within the respective consortium. Often, the requirements of these projects avoid the task of gathering wide acceptance around the architectural design of the platform. Second, the projects are targeted to demonstrate only some particular challenges of AAL. Some notable examples are as follows: show the performance of the designed platform, show the effectiveness of the semantic interoperability, or highlight the benefits of the integration with heterogeneous hardware. These projects lack an integrated approach for all the technological challenges that arise from the AAL research domain. Third, the projects overlap with each other, in particular offering similar functionalities and addressing similar use cases. Often, we found that the differences between the projects are mostly concerning the techniques they adopt, or the specific technologies adopted (e.g., for sensors). All the previous points illustrate the need for a consolidation effort.

The design of the UniversAAL platform has taken into account the past experience of European Union research in AAL. UniversAAL exploits the best results coming from the existing platform architectures, and addresses two key-goals: form the basis for design of a commercial product and establish a standardized AAL platform.

3 The UniversAAL Platform

The UniversAAL platform provides support in three main areas: runtime support, development support, and community support. Figure 1 shows the main components of each of the areas and its utilization.

Figure 1:

Overview of the UniversAAL Platform and Its Utilization.

The UniversAAL project adopted a holistic approach. It includes runtime support for the execution of services and applications; it offers support for the development of new AAL services (development support); and it offers support for the collaboration among different communities (community support).

Runtime support consists of a set of software components that can be installed on different types of hardware; such hardware is typically adopted in several AAL scenarios. Common hardware devices are smart phones, laptops, and tablet PCs, but also include more powerful server installations. Runtime support is composed of different building blocks:

• The execution environment (EE), which provides a set of core functionalities such as discovery of devices and AAL services, communication capabilities among devices, context and user interaction management, security, remote control, and interoperability.

• The generic platform services, which provide some core services available for all the AAL services (or applications as their software parts) installed on top of the runtime support. Some notable examples are context awareness, [1], and support for security and personalization.

• The AAL platform services, which are the set of core AAL services such as messaging, health record, and the fall detection service.

Development support consists of four building blocks that provide some resources for developers. Such resources aim to speed up the design and implementation of new AAL services. Development support provides the following resources:

• Guidelines: the documentation for developers. It provides the guidelines for developing a new AAL service on top of the UniversAAL EE. The guidelines include tutorials for using the main platform features, a description of platform APIs, and documentation for the integrated development environment developed in the project (called AAL Studio).

• Developer tools: a rich set of tools for developers to facilitate the creation of services or ontologies, to check the conformance of the code against some rules, to upload and deploy applications into the uStore, and other essential tools that speed up the development process. These tools are integrated to form a development environment called AAL Studio.

• Developer Depot: the server that hosts the resources needed for developers of AAL applications. It represents the starting point for developers; indeed, it includes the runtime support and development support resources listed above. The Developer Depot provides common repository functionalities such as upload, download, search, and removal of binary and source code resources depending on level of access.

Community support is a collection of resources for the end users (elderly persons and their care providers), including

• Roadmap: a set of guidelines for research and design in future versions of the AAL reference architecture (RA).

• Training: material for training new technical users. It includes documents, presentations, videos, and material for courses.

• Examples of AAL services: a collection of basic AAL services that can be used to show some features of the UniversAAL platform. The set of AAL services currently available includes the following: Agenda and Reminders, an intelligent reminder of daily events; Safety at home, a system that detects potential risks related to the home; AAL efficiency, an application for energy management; and Help when outdoor, a service that provides support in case the user gets lost or is in an emergency.

• uStore: the UniversAAL market where suppliers can publish the services they offer, and end users can search for, buy, and download the AAL services available. The uStore represents a helpful server to advertise AAL services and solutions to the final users or other service providers. The uStore has been designed to be accessible and personalized according to the user’s profile; it allows managing complex services including software, hardware, and human resources in their complete life cycle. Moreover, the uStore can be directly accessed from the AAL Studio, to upload new AAL services.

4 Development Approach

This section describes the technical approach that was used to develop the architecture of the UniversAAL platform. The project placed a lot of emphasis on following a structured approach for this because the domain is complex, the variety of stakeholders is wide, the number of requirements is large, and the technical approaches of the “input” projects (see Section 2) somehow need to be consolidated. The approach we selected was to use ARCADE. It is a domain- and technology-independent architectural description framework for software-intensive systems [3]. We also made use of the IEEE 1471 standard for “Recommended Practice for Architecture Description of Software-Intensive Systems” [13].

As described in Reference [3], ARCADE is intended to support software developers to create, understand, and describe the architecture of a complex software system. The framework can be used in the design process of the architecture of a new system, as well as for documenting an existing system. It provides the structure for documenting the architecture and for addressing quality-related concerns, reusability, and maintainability.

ARCADE bases its fundamental concepts on the IEEE 1471 standard framework “Systems and software engineering – architecture description.” IEEE 1471 identifies the assets and the different views the system architecture should cover. In the first instance, it requires the identification of assets, stakeholders, and concerns. The assets are the artifacts (software and standards to be used), the legacy systems, the databases, and generally everything that will provide an input to the architecture.

With respect to the UniversAAL project, the assets come from the consolidation of those AAL projects that have been used as input to our platform. UniversAAL’s stakeholders are the intended users and all those entities that could have an influence on the design of the system. UniversAAL’s concerns identify the expectations each stakeholder has for the system. Assets, stakeholders, and concerns represent the building block to elaborate the models (use cases, diagrams, etc.), also named “views.” Every view addresses a specific “viewpoint.” The difference between viewpoint and view is that a viewpoint is a way of looking at a system, while a view is what you see when looking from the chosen viewpoint. A set of views eventually constitutes an architectural description.

In ARCADE, viewpoints are specified [3], whereas views are created when documenting some target system, the UniversAAL platform in our case.

The following sections show the design artifacts (documents and models) that constitute the UniversAAL design for AAL platforms. From the most abstract to the most detailed, the following are presented:

• The stakeholders and their concerns, as defined in the IEEE 1471 framework.

• The scenarios and the reference use cases (RUCs), which describe the typical functionalities of the AAL domain in an abstract and informal way.

• The architectural description, which provides a formal description of the platform from the reference model (RM) and RA, which defines a generic AAL platform, to the concrete architecture (CA), which defines the structure and the design decisions of the specific case of the UniversAAL platform.

The following sections describe each of these artifacts in detail.

5 The Reference Model

The RM establishes a common understanding of the AAL domain. It is also the starting point for the design of the UniversAAL architecture.

The main characteristic of an RM is that it “consists of a minimal set of unifying concepts, axioms, and relationships within a particular problem domain, and it is independent of specific standards, technologies, implementations, or other concrete details” [4]. Thus, the UniversAAL RM provides simple definitions of the key concepts that make up the AAL domain, and shows how these fit together. This provides a common basis for understanding the AAL domain as a whole: a common “language.” The RM was produced as part of a consolidation process from the input projects; in particular, it defines a new model by combining the concepts from the input projects.

The RM uses a hierarchy of concept maps [26] to provide a structured, but easily understood, way of showing how the different concepts relate to each other. Each concept map is supported by some text providing simple definitions of each new concept introduced in it. Some concepts are expanded in further detail in lower-level concept maps. The top-level concept map is called the “root” concept map. We include it here to illustrate the concept map technique, and to define the highest-level concepts. The full set of concept maps is available in project deliverable D1.3 [23].

The root concept map of AAL RM is depicted in Figure 2. It presents the top level of the AAL domain. The concepts identified are defined as follows:

Figure 2:

Root Concept Map of the AAL Domain.

• AAL stakeholder: an individual, team, or organization (or classes thereof) with interests in, or concerns relative to the AAL domain (e.g., service providers, end users, authorities etc.).

• AAL service: a combination of software, hardware, and human resources that support people who need some assistance in carrying out everyday activities.

• AAL RA: provides a common/standardized view of software architectural elements (building blocks) in the AAL domain.

• AAL platform: a set of hardware and software artifacts (standardized and compliant with the AAL RA) that help developers and service providers with the provision of AAL services (at all stages in the life cycle, including design, development, deployment, and execution).

• AAL space: environments where people may need assistance (e.g., homes, airports, railway stations, supermarkets, and cars) with defined boundaries of hardware, software, and human resources in the context of, e.g., access control, multimodal user interfaces, etc.

• Software and hardware component: one or more pieces of computer software and/or special devices (sensors, displays, switches, controls for domestic appliances, etc.) that, together with any relevant human resources, are used to provide AAL services.

The AAL domain is all about the provision of AAL services to end users (e.g., assisted persons and/or caregivers). AAL services, which take place in an AAL space, make use of the hardware and software components embedded in it. The cooperation between such distributed components in an AAL space is facilitated by AAL platforms that implement the AAL RA to provide for resource sharing, and let users experience an integrated world easy to interact with based on natural communication.

6 The Reference Architecture

The RA models the abstract building blocks in the AAL domain, independently from the technologies, protocols, and products that are used to implement the domain (SOA-RA) [12]. It is consistent with the RM defined in Section 5.

The RA differs from the RM in that the latter describes the important concepts and the relationships in the domain focusing on what distinguishes the elements of the domain, whereas the RA further elaborates the model, to show a more complete picture that includes what is involved in realizing the model.

The design of the RA is the result of the analysis of the RUCs, the reference requirements, and the RM. We followed two different parallel processes for designing the RA:

• The top-down process: the RA is seen as the “natural” extension of the RM. This approach assures high abstraction, a minimum gap of abstraction with respect to the RM, and, potentially, a model suitable for a larger audience. The main limitation of this process is the partial lack of a technical focus. Such limitation makes the RA more difficult to connect to the real implementation (also named the concrete architecture). The top-down process resulted in a set of collaboration diagrams that show the relationship among the components of the RM. Moreover, this process also provides a service capability analysis by means of the service-oriented architecture modeling language (SOA-ML) notation.

• The bottom-up process: an abstraction process that takes into account the concrete implementation of the input projects. In particular, this process has identified the commonalities and the weaknesses of the input projects. In this case, the result is a set of abstract building blocks that represent the structural aspects of the platform. We have adopted the system decomposition model defined by the ARCADE [3] specification.

The next two subsections report the results we obtained both with the bottom-up and top-down processes.

6.1 Results of the Top-Down Process: Service Capabilities Supported by the RA

The main stakeholders and the concerns have been presented in Section 5. The goal of this subsection is to describe how such concerns are addressed in the form of services exchanged among the stakeholders. The result of the top-down process is named the RA services (RASs).

The value network of the AAL domain is mapped to an SOA-ML service architecture diagram in Figure 3, where the “participants” are the stakeholders and the “service contracts” denote the services exchanged among the stakeholders. Client stakeholders are shown in orange (gray in black-and-white print), and platform stakeholders are shown as rectangles with thick borders.

Figure 3:

Service Architecture for AAL Main Stakeholders and Their Service Capabilities.

According to SOA-ML [20], services exchanged among stakeholders are modeled by using a specific type of collaboration called service contract. In Figure 3, each service contract is a placeholder for all the RASs exchanged between the two parties involved.

For instance, the example in Figure 4 illustrates the services that the runtime platform provides to the community and developer support platforms. The explanation of Figure 4 is given in Table 2.

Figure 4:

Platform-to-Platform Services Provided by the Runtime Support Platform.

Table 2:

Reference Architecture Services (Example).

RAS id	Service	Provided to	Description
RAS#1.1	Remote maintenance and configuration	Community support platform	To allow remote configuration, management, and maintenance of software installed in AAL spaces
RAS#1.2	Audit data management	Community support platform	To allow acquiring usage data about service usage in AAL spaces
RAS#1.3	Service testing support	Developer support platform	To support sandbox testing of services before real-world deployment

6.2 Results of the Bottom-Up Process: Abstract Building Blocks of the RA

In this subsection, we provide the model for the runtime support platform (RSP) only. The RSP comprises the building blocks that allow the AAL applications to be executed in the space of the end user (Table 3). For a better understanding of the runtime, it is presented in a relaxed layered model, where each layer can access interfaces provided by layers below it (Figure 5).

Table 3:

The Building Blocks.

Building block	Description
Middleware	This building block is the core of every runtime platform; its goal is to hide distribution, supporting seamless connectivity, and to allow the communication among all the elements deployed in the AAL system. It acts as a broker between the communicating parties and hides the heterogeneity of the technologies adopted. The data representation framework belongs to the basics of the middleware software. The selection of a unified data representation framework makes it possible that data from diverse domains can be exchanged using the same middleware. Reliability has to be provided at middleware level and above, to provide the ability of a system or a component to perform the required services under specific conditions for a specified period of time. This includes the failure probability, and the system availability and maintainability of a complex entity of interconnected components.
Context management	This building block provides for adequate communication (both push- and pull-based) between providers and consumers of context data. Data are expressed according to a common model.
Service management	The service management building block facilitates service-based interoperability. It handles service registration, and act as brokers between service providers and the consumers to handle the service requests. As an example, service management finds a match between a received service request and the matching service providers that are available. Moreover, it provides service composition and orchestration features.
User interaction (UI) management	The UI management building block addresses the challenges related to the explicit interaction between an AAL space and its human users. It provides independence of applications from the concrete I/O infrastructure available in AAL spaces, as the latter might differ in its occurrences considerably. It defines a framework for capturing user input and presenting system output to human users. The UI management is documented as a Publicly Available Specification by the International Electrotechnical Commission (IEC) with the reference IEC/PAS 62883 Ed. 1.0 and title “The UniversAAL Framework for User Interaction in Multimedia Ambient Assisted Living (AAL) Spaces.”
Local device discovery and integration (LDDI)	This building block facilitates the integration of heterogeneous hardware devices with the UniversAAL platform. Indeed, several AAL applications often require special-purpose devices. Such devices are packaged without the possibility of manipulating the device. Hence, it is required as a specialized building block that is able to integrate such devices in a seamless way.
Remote interoperability	This building block is responsible for managing platform tasks in the context of interactions between AAL spaces and the outside world. Some common AAL applications include the provision of remote assistance by service providers, remote monitoring, remote access to services available within an AAL space, importing services from the outside world, and communication between AAL spaces.
Security	The security block provides trust, privacy awareness, and access control. An artifact that joins an open system like AAL systems must possess a certain level of trustworthiness and, hence, the question here is about the right balance between the openness of the system and the level of control needed. At the level of joining the system, the level of trust needed is that the artifact at hand has not any malicious intention, and it respects the game rules assumed in the system.

Figure 5:

Consolidated Decomposition Model of the Runtime Support Platform at the Level of Abstract Building Blocks.

7 The UniversAAL CA

As discussed in the previous section, RA is technology-independent model. It can be used to design and implement different concrete implementations. The implementation of the RA is named the CA. The UniversAAL project has defined one open-source CA as the reference implementation of the project.

The main components of the CA are the Developer Depot, the AAL Studio, the UniversAAL control center (uCC), the uStore, and the EE. Figure 6 shows an overview of such components.

Figure 6:

Overview of the Components of the UniversAAL CA.

The Developer Depot provides the resources required by a developer to start developing AAL applications. Some examples of resources are the AAL Studio development tools, the binary and source code for the execution platform, and the AAL service examples together with the platform documentation.

The AAL Studio is a customized Eclipse-based development environment for AAL applications. It provides a set of development tools to support the developers during all parts of the development process: design, implementation, test, and deployment. AAL Studio and Developer Depot are bound together. Indeed, we have designed and implemented a specific AAL Studio plug-in to upload or download resources to the Developer Depot.

The UniversAAL EE is a set of software components that are installed on a device or AAL-aware node (such as a smart phone, a PC, or a tablet). The goal of the EE is twofold: first the EE installs updates or removes AAL services (AAL service life cycle management [16]); second, the EE executes one or more AAL services installed on the device.

More precisely, the management of the AAL service life cycle is implemented with the uCC. The uCC is a well-integrated user interface that provides three main features: request installation, configuration, and customization. The end user can use the uCC user interface to select the AAL service available on the uStore and request the installation on its device. End users can also configure and customize the AAL service according to their needs.

The last component of the CA is the uStore. The uStore allows the end users to find and to purchase an AAL service. The uStore provides two interfaces: a Web-based interface and the uCC interface. Hence, the end users can browse the AAL services available on the uStore both for a standard Web browser and from the uCC.

8 Evaluation Process

This section describes the evaluation process that we followed during the UniversAAL project with what regards architectural aspects of the platform. Several evaluations were performed during the execution of the project, and feedback has been collected on several occasions. Some of the more important results are presented in the following.

9 Summary of Achievements

The design framework presented in this article proved suitable for the creation of a complex platform like the one of UniversAAL. The development of the example services showed that having a platform allows avoiding programming several common functionalities of distributed, ambient technologies, and easily program services without having to cope with technology-dependent aspects like networks, sensor protocols, non-interoperable data models, different kinds of user interfaces, and adaptation to disabilities, among others.

UniversAAL had a strong focus on standardization activities. In the following, activities related to the architecture and design are highlighted. The architectural models presented hereby aim at becoming an official standard. At the moment, some efforts are in progress for standardizing some aspects of the UniversAAL reference design. An example is the participation in and contribution to IEC SG 5 on AAL, which aims to manage and coordinate AAL standardization work in IEC technical committees to establish and achieve interoperability and interconnectivity of AAL systems [25]. It provides the opportunity to standardize AAL solutions from UniversAAL and other projects. The UniversAAL framework for user interaction has obtained the official IEC PAS status for its specification. It is documented as a Publicly Available Specification by the International Electrotechnical Commission (IEC) with the reference IEC/PAS 62883 Ed. 1.0 and title “The UniversAAL Framework for User Interaction in Multimedia Ambient Assisted Living (AAL) Spaces” [11]. In the same technical committee (IEC TC100), some of UniversAAL’s use cases are an input to the standardization of use cases related to AAL (IEC/TR 62907/Ed. 1), IEC, IEC/TR 62907 Ed. 1.0, Use cases related to ambient assisted living (AAL) in the field of audio, video and multimedia systems and equipment.

UniversAAL has also contributed to data protection by specifying an IHE Document Encryption profile for data in the health-care and AAL domain. Consequently, the specification was implemented and feedback was provided to IHE. It has obtained the trial implementation status and passed the IHE Connectathon validation. Furthermore, UniversAAL has contributed to the Zigbee API and Device Abstraction Layer in the OSGi Alliance resulting in the requirements definitions (RFP 142 and RFP 147) and resulting in the technical solutions (RFC 192 and RFC 196) expected in 2014.

For exploitation through standardization of the RM and RA, a detailed plan has been elaborated. The key idea is to support various stakeholder groups in different activities, ranging from the researchers and developers (baseline), to authorities (regulatory, policy), to service providers (process, cope), and finally to follow-up standardization activities (technical).

The UniversAAL project was completed in January 2014, and a fully operational version of the platform here described was produced. All technical results (including all software) and documents are openly available via the project’s Web site at www.universaal.org. The platform is now being applied in large-scale pilots being conducted in the ReAAL project (see http://www.cip-reaal.eu/home/).

Funding: This work has been cofunded in the framework of the UniversAAL project: UNIVERsal open platform and reference Specification for Ambient Assisted Living, FP7 Programme, FP7-ICT-2009-4-Objective 7.1b “Open Systems Reference Architectures, Standards and ICT Platforms for Ageing Well,” contract no. 247950. Web site: www.universaal.org.