Integration and Deployment of Cloud-Based Assistance System in Pharaon Large Scale Pilots—Experiences and Lessons Learned

Abstract

The EU project Pharaon aims to support older European adults by integrating digital services, tools, interoperable open platforms, and devices. One of the objectives is to validate the integrated solutions in large-scale pilots. The integration of mature solutions and existing systems is one of the preconditions for the successful realization of the different aims of the pilots. One such solution is an intelligent, privacy-aware home-care assistance system, SmartHabits. After briefly introducing the Pharaon and SmartHabits, the authors propose different Pharaon models in the Ambient/Active Assisted Living (AAL) domain, namely the Pharaon conceptual model, Pharaon reference logical architecture view, AAL ecosystem model, meta AAL ecosystem model, and Pharaon ecosystem and governance models. Building on the proposed models, the authors provide details of the holistic integration and deployment process of the SmartHabits system into the Pharaon ecosystem. Both technical and supporting integration challenges and activities are discussed. Technical activities, including syntactic and semantic integration and securing the transfer of the Pharaon sensitive data, are among the priorities. Supporting activities include achieving legal and regulatory compliance, device procurement, and use-case co-designing in COVID-19 conditions.

1. Introduction

An aging society leads to a more significant number of older adults whose needs are not being adequately addressed. With the rise in overall healthcare costs, a significant increase in the number of older persons in need of care puts additional pressure on healthcare and national economies. The gap between the rising need to improve older persons’ quality of life, especially those living alone, and the availability of appropriate means of addressing those needs is increasing. This is even more evident in countries with weaker economies, where there is often less room for proactive and preventative actions.

Motivated by the trend of the aging society, as a part of the demographic change megatrend, Information and Communication Technologies (ICTs)-based Active/Ambient Assisted Living (AAL) systems have emerged as a way to improve the quality of life and increase the independence of older adults. However, one of the problems is that these solutions have low adoption rates and remain fragmented across different, typically niche markets. The low adoption rates result from different factors, ranging from poor technology execution and unclear benefits to non-adequate human support and unwillingness to use the technology.

The AAL Programme distinguishes AAL services and systems for aging well at home, community, and at work. The fact is that AAL systems cover a wide range of services, ranging from more hardware-intensive to less hardware-intensive, from ones requiring active user interaction to ones opting for minimum or no user interaction, from health-focused to lifestyle-focused services. In a recent review on enabling AAL technologies and scenarios, Manoj et al. [1] highlight five technologies: sensors, context awareness, IoT, machine learning (ML), and AI. The AAL systems provide support in indoor and outdoor environments. The older term Ambient Assisted Living is often related to the former indoor environments, such as homes and retirement residences. The newer term Active Assisted Living (used since 2014) makes the outdoor environments more apparent. Another term, Active and Healthy Aging (AHA), defined by the World Health Organization (WHO) [2], is used when referring to improving the quality of life for older people. The AHA also refers to the initiative promoting different ways to improve healthy living and aging.

This sizeable market opportunity is attractive for many companies. However, no one organization or company can create the proper large-scale ecosystem, so the solutions are often disconnected and isolated. This fragmentation is one of the reasons that the EU first invested in supporting the development of different AAL solutions and later in their connection. Interoperability, especially semantic interoperability, is challenging to achieve but is a critical prerequisite for achieving synergy among different technologies, devices, and solutions. The emergence of AAL ecosystems aims to overcome fragmentation and facilitate convergence on different levels. Gams et al. [3] systematically evaluated 18 chosen EU platforms in AHA and AAL domains. Most of them aimed to facilitate interoperability but approached this from different angles, using different programming frameworks, tools, and priorities.

The usage of standards, open platforms, and improved regulatory and market conditions fuels the advancements in the field. However, much work is still required to deliver cost-effective, reliable, easy-to-use, and easy-to-maintain AAL solutions. Such work includes more focus on the diverse needs of older people, resolving technical issues, improving reliability, lowering cost, nurturing and stimulating a multidisciplinary approach, improving reliability, trust, and ultimately increasing AAL technology acceptance.

Conceptual AAL models [4,5] are especially valuable to new entrants in the domain. However, they are often inadequate and fail to represent the AAL domain holistically. The lacking ecosystems and regulatory and legal support become more evident for those familiar with the field. This is especially noticeable when building upon existing already deployed solutions instead of providing the whole end-to-end solution. The well-established AAL platforms [6] rarely exist outside the projects that created them. One reason for this is that the AAL platforms largely fall back to IoT platforms, which are also not consolidated and serve various purposes. The heterogeneous hardware and sensor landscape [7,8] presents a moving target with new devices continuously being delivered to the market. Researchers and companies are constantly trying to assess the most appropriate ones in terms of cost, functionality, and reliability. Integration of the different devices, technologies, cloud-based services, and platforms is needed; one solution cannot cover a wide range of different AAL needs. However, much work is still needed to consolidate the processes and technology tools to make this process smoother and more efficient. This paper shares our experiences and lessons learned in integrating and deploying our previously developed and tested cloud-based, assisted-living solution into large-scale European pilots within the H2020 project Pharaon. We also share our views on AAL and AHA.

The rest of the paper is structured as follows. Section 2 shortly explains the background work of the H2020 Innovation Action (IA) project Pharaon and SmartHabits. Section 3 introduces different AAL and Pharaon models, namely the Pharaon conceptual model, Pharaon reference logical architecture view, AAL ecosystem model, Meta AAL ecosystem model, and Pharaon ecosystem and governance models as an original contribution of the authors. Section 4 elaborates on the holistic integration of the SmartHabits into the Pharaon. This explicitly provides architecture mapping and explains deployment sandboxes, data flows, and integration challenges. Section 5 discusses the challenges and lessons learned, while Section 6 concludes the paper.

2. Background

2.1. H2020 Project Pharaon—Pilots for Healthy and Active Ageing

2.1.1. Project Overview

Project Pilots for Healthy and Active Ageing, H2020-SC1-FA-DTS-2018-2, IA, #857188, 2019–2024, 21.3MEUR (PHARAON) [9] aims to support European older adults by integrating digital services, tools, interoperable open platforms, and devices. Technologies include IoT, robotics, edge and cloud computing, smart wearables, Artificial Intelligence (AI), and supporting communication systems. The project includes 41 partner organizations from 12 EU countries, including more via two planned open calls.

The project is funded under the umbrella program “H2020-EU.3.1.—SOCIETAL CHALLENGES—Health, demographic change and wellbeing” and, more specifically, “H2020-EU.3.1.4.1.—Active ageing, independent and assisted living”.

2.1.2. Ongoing Large-Scale Pilots (LSPs) and Targeted Users

Pharaon deployments are being realized as Large-Scale Pilots (LSPs), which are geographically distributed in five EU countries, namely, Portugal, Spain, Netherlands, Slovenia, and Italy. In Portugal, Spain, and Italy, there are two separate locations. In Netherlands and Slovenia, there is one location. In total, there are eight locations with a plan to involve 2500 users and 350 experts. Unique experiences involving older adults in Pharaon during the COVID-19 pandemic were provided in a paper by Moses et al. [10], where alternative methods were employed in face-to-face co-creation workshops. Fiorini et al. [11] reported on a study with 72 social professionals, which confirmed that the COVID-19 emergency is responsible for an increased perceived need for telepresence services. Identified barriers and limitations include the need for improved ease of use, lack of Internet connection in the homes of older adults, distrust in technology, too much bureaucracy, unclear use of data, and lack of technology managers. The outcomes of the study were taken into consideration for Pharaon. The process of determining the needs and preferences of older adult users in Pharaon Italian sites is described in a recent paper by D’Onofrio et al. [12]; the authors report the outcomes of interviews conducted with a total of 22 older adults, 22 informal caregivers, 13 professional caregivers, and 4 social operators.

The following table (

Table 1. Pilot sites and addressed high-level use cases.

Pilot Site	Country	Some of the Addressed High-Level Use Cases
Coimbra, Amadora	Portugal	Community engagement, a safe environment
Andalusia	Spain	Community participation, digital upskilling, cognitive stimulation
Murcia	Spain	Healthcare personalization, emergency detection
Netherlands	Netherlands	Community buildup, advice personalization
Izola	Slovenia	Wellbeing monitoring and improvement, social involvement
Tuscany	Italy	Personalized health management and monitoring
Apulia	Italy	Socialization and inclusion support

) aims to highlight the focus of each of the Pharaon pilots by introducing the notion of “high-level” use cases. Pharaon use cases include cognitive stimulation, health monitoring, health management, socialization, learning, a safe and comfortable environment, care and wellbeing improvement, and support to (formal and informal) caregivers. Note that this categorization is not the official view of the Pharaon and is introduced here by the authors of this paper.

2.2. SmartHabits Assistive System

2.2.1. Overview

The SmartHabits system is an intelligent, privacy-aware home-care assistance system that reassures family members that their loved ones are fine. The system is based on Artificial Intelligence concepts. It involves sensor data pattern detection and reasoning while relying on off-the-shelf, non-vision-based sensors for data collection, cloud computing for data storage and analysis, and telecommunication networks for data transfer. The focus is on data collection, preprocessing, and transformation to learn about the typical sensor data patterns of a person living alone and notifying informal caregiver(s) if some unusual (anomalous) event is detected, thus providing peace of mind to both sides.

The SmartHabits system comprises the Home Sensing Platform part, including sensors, device gateway, home gateway residing in a smart-home environment, and a cloud-based SmartHabits Platform (SHP), including the IoT Platform and SmartHabits Expert System), as shown in the following figure (Figure 1). More information about the system, including the system requirements, architecture, and implementation details, can be found in a paper by Grguric et al. [13].

For the smooth running of the solution in the older person’s home, an Internet connection had to be set up, which was complete using portable, SIM-enabled Wi-Fi dongles, which provided connectivity for the Home-Sensing Platform with off-the-shelf environmental and smart-home sensors. Maintaining these home installations in multiple locations requires substantial technical and first-line support in all the challenges and logistics needed to maintain the required operational level for the service 24/7. Here, the processes and technical support have to largely resemble those of the authentic product on the market to assess the solution and its benefits in as close to a real-world scenario as possible.

2.2.2. Target Users

The targeted users of interest were older adults needing proper support. The results from the pilot conducted in Zagreb, Croatia, in cooperation with the Foundation taking care of older people living alone, are also reported in the previous paper. Since ML algorithms need time and larger sets of real-world data to start producing outcomes that could meaningfully and confidently be reported to the caregiver users, the challenge was to explain this to non-technical users, who wanted to see and experience the benefits from the very start.

3. Pharaon and AAL Models

3.1. Pharaon and AAL Conceptual Model

In the following figure (Figure 2), we present the abstract conceptual model (CM) identifying basic concepts belonging to the AAL domain and Pharaon, their attributes, and relationships. The model is inspired by “ISO/IEC 30141:2018 Internet of Things (IoT)—Reference Architecture” [14], and more specifically on “Service, network, IoT device, and IoT gateway concepts.”

In Pharaon, primary users are older adults who interact with the AAL Application, a type of AAL Service emphasizing the AAL domain focus and the concrete assistance value brought to the assisted older adult. The following table (

Table 2. Pharaon and AAL concepts mapped to concepts in ISO/IEC 30141:2018.

Concept in Pharaon CM	Concept in ISO/IEC 30141:2018
Older adult (user)	Human User
AAL Application	Application
AAL Service	Service
Cloud Platform	Data Store
Device	IoT Device
Sensor	Sensor
Actuator	Actuator
Device Gateway	IoT Gateway
Telecommunication Network	Network
API Endpoint	Endpoint

) maps concepts from Pharaon CM (shown in Figure 2) and the concepts used in ISO/IEC 30141:2018.

Pharaon integration is primarily based on cloud-hosted Pharaon technology platforms with functionalities beyond data storage and use, which ingest, filter, transform, store and analyze the data coming from different sources (sensors, robots, AAL-focused systems and services, AI- and ML-based services, real-time communication systems, external third-party solutions). Pharaon has a broader focus than IoT alone and targets the AAL domain, which primarily utilizes the IoT as one of the enabling technologies to realize ICT-enabled Enhanced Living Environments (ELEs) [15]. Pharaon’s main types of integration connection points are Application Program Interfaces (APIs).

3.2. Pharaon Architecture View Mapping to CREATE-IoT 3D Reference Architecture Model (RAM)

In a recent paper, “Reference Architectures, Platforms, and Pilots for European Smart and Healthy Living—Analysis and Comparison” by Grguric et al. [16], Pharaon’s work and reference architecture is analyzed and compared with six other eHealth and AAL (Ambient/Active Assisted Living) projects (five of which are in progress, in parallel with Pharaon). After the online survey and additional analysis of different RAMs, the same paper proposes using CREATE-IoT 3D RAM as a standard RAM for future digital healthcare and AAL projects. We build on the results of this paper and present the following figure (Figure 3) with a visual mapping of the Pharaon (technology-agnostic) logical or functional layers to horizontal functional layers of the CREATE-IoT 3D RAM [17], with the most relevant Cross-Cutting Functions (CCF) and Properties (PROP) for Pharaon.

In Pharaon, we opted to describe the architecture using the 4 + 1 View Model [18] of architecture, which organizes a description of the architecture using five views (each focusing on a specific set of concerns), which are: logical/functional view, process view, development view, physical view and scenarios (or use cases).

Pharaon (horizontal) logical/functional layers are as follows:

• The Device and Communication layer encompasses physical devices and supporting infrastructure enabling data transmission to and from cloud-hosted Pharaon platforms. Both publish-subscribe and request-response communication patterns are supported.
• The Platform layer encompasses data filtering, storage, processing, usage, transmission, and supporting functionalities.
• The Service layer encompasses functionalities relying on the below Platform layer, such as data analytics, transformation, enrichment, and uplifting.
• The Application layer encompasses information delivery to Pharaon end-users following appropriate and common practices in Human-Computer Interaction (HCI) and Human-Environment Interaction (HEI).

Since Pharaon operates in the domains of eHealth and AAL, the data are highly sensitive, and there is even a legal GDPR requirement that the data remain private and secure. For this reason, privacy and security in Pharaon are top priorities. Pharaon data sources are distributed, so to communicate with central Pharaon platforms, connectivity is a critical precondition. The third most crucial identified CCF is identifiability, enabling the unique identification of Pharaon entities and assets, including users, devices, services, data sources, and interfaces. Unique identification is essential for further communication, monitoring, traceability, data processing, and analysis.

Interoperability in Pharaon is of critical importance since the different input technologies and platforms have to exchange relevant information smoothly. As every Pharaon input technology is hosted on its own designated infrastructure, Pharaon employs multi-cloud hosting scenarios leveraging multiple Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) services. Pharaon uses a hybrid cloud, as Pharaon technology providers utilize private and public clouds. Pharaon’s focus is on the integration of solutions that were proved in other scenarios, including scenarios related to AAL. The composability property emphasizes that Pharaon input services are reused and rearranged to offer new ones that fulfill Pharaon-specific scenarios. The intelligence property highlights the usage of Artificial Intelligence (AI) principles and techniques.

3.3. AAL Ecosystem Model

In a systematic review of the AAL domain, Calvaresi et al. [19] report that most works in the AAL domain do not simultaneously consider the entire AAL ecosystem, with patients, physicians, caregivers, and relatives. They confirm the tight coupling between patients and caregivers and patients and relatives. Furthermore, the same review argues that this limited attention might be a reason for the lacking AAL needs and requirements analysis or technical immaturity. After investigating the requirements, implementation challenges, reference models, and architectures of AAL systems in a state-of-the-art survey, El Murabet et al. [5] confirm that the “AAL system by definition is a socio-technical system.”

The AAL systems have to appropriately address many functional and quality requirements to answer the different specific needs of the heterogeneous user group. Many papers in the field report on these [20,21], so we will not go into the details of such requirements here. Apart from technical requirements, national, legal, security, privacy (including GDPR), market, and ecosystem issues put additional constraints on the AAL service or product providers. This means that a multidisciplinary approach is preferable and is needed to deliver a quality AAL product. In a systematic literature review, Poh et al. [22] identified macro-level regulations (operational authorization, care quality assessment, and infrastructural requirements), meso-level regulations (operational management, staff management, and distribution, service provision and care monitoring, and crisis management), and micro-level regulations (clear criteria for resident admission and staff hiring) that are important in the governance of assisted living.

Rapid digital transformation has resulted in many digital platforms facilitating resource- and data-sharing among various, loosely connected providers and consumers. These digital platforms inherently support ecosystems as complex networks of different organizations and institutions. Sometimes, the connection between organizations (including service or product providers, consumers and users) is explicit (often formalized as subscriptions or other types of contracts), while, other times, this is only implicit. In a recent (2021) systematic review of platform ecosystems, Kapoor et al. [23] confirmed that Platform Ecosystem (PE), as an “assemblage of a platform, its actors and the offerings developed on that platform,” supports co-creation between a platform, platform’s actors and the offerings developed on that platform. The central technology platform acts as a core system, realizing the “plug-in architecture pattern” (often also referred to as the microkernel architecture) within each socio-technical AAL ecosystem, exposing the extension and integration points where plug-in systems join to add additional functionalities. The stability and sustainability of an AAL system that is included in the AAL ecosystem introduce network effects to the whole ecosystem, implying that good stability and sustainability positively influence the AAL ecosystem, and a lack of stability and sustainability influences the AAL ecosystem in a negative way.

Fadrique et al. [24] showed that the primary problems causing disparity between existing and accessible technologies are non-technical issues (user interfaces, vocabulary, social and cultural norms) and lack of integration between existing technologies. Jaschinski et al. [25] proposed a conceptual model of AAL technologies’ acceptance based on a survey of 1296 older adults. The main model pillars were the attitude towards using AAL, social norms, personal norms, and perceived behavior control. We recognize the importance of providing technical support for the AAL service and application developers, but we argue that this alone is insufficient. We use the term “socio-technical” to emphasize the complex links between people (with certain beliefs, culture, behaviors, knowledge, goals, roles, preferences) and technology (including software and hardware) and the fact that there is a “human in the loop.” The delicate balance of human control and machine automation is constantly evolving with new technologies, which makes the (re)design decisions inherently complicated. On top of the implicit or explicit functional and quality requirements, implicit or explicit assumptions make the choices between often conflicting options even harder.

An AAL ecosystem can be considered an interdependent multisided market with multiple players, including AAL service or product manufacturers and providers, healthcare providers, social service providers, insurance providers, formal and informal caregivers, technology providers, telecommunication service providers, and end-users (as individuals or represented by sponsors or a particular public or private organization). The AAL ecosystem can thus also be also considered as an Innovation Ecosystem (IE) where some actors (e.g., AAL service providers), enabled by other actors (e.g., finance, regulatory and telecommunication service providers) can more efficiently coordinate and deliver value to target users (typically older adults). The collaboration and interdependencies between the involved actors and stakeholders within the AAL ecosystem can be emphasized with the notion of a “partner ecosystem.” According to a systematic literature review based on an analysis of 136 studies and the latest knowledge of IEs, Gu et al. [26] identify five streams of current IE research. The identified streams are Platform IE (including its cooperative development and organization), technology innovation, regional development (e.g., national or city-wide), IE conceptualization and theorization, and entrepreneurship and innovation (at the individual, company, or university level).

Our vision of the AAL ecosystem emphasizes the socio-technical aspects and the interconnection of different stakeholders in the ecosystem that must work together to achieve the maximum value for all. Depending on the point of view and the observed output benefit, the AAL ecosystem can be described using many adjectives. We used and explained the adjectives technical-platform-enabled, socio-technical, business, innovation, multisided-market, partner, and Pharaon. The following figure illustrates our vision of the technology-platform-enabled socio-technical AAL ecosystem (Figure 4).

AAL applications are one type of AAL service (as mentioned in Section 3.1) and are particularly responsible for managing (human) user–system interaction. However, different user roles, such as family members (belonging to the informal caregivers’ category), deliver AAL services. In the center are end-users, who are primarily older adults. The end-users are involved in passive or active interaction. In passive interaction, users do not explicitly interact with the AAL service (e.g., sensors in their environment collect the data without their conscious or active involvement). In contrast, they explicitly interact with the provided (voice, graphical, or multimodal) user interfaces (UI) during active interaction [27].

Technology platforms and systems act as a technical subsystem and an enabler for the technical delivery of the AAL service, supported by the social subsystem concerned with the input from the (formal or informal) caregivers. Therefore, AAL systems are only one of the ingredients in a more complex AAL ecosystem.

The formal caregivers typically arrive from the health- or social-service-providing organizations. At the same time, the technical solutions in AAL arrive from the AAL service and product providers, with the help of telecommunication service providers, since connectivity is a prerequisite for many of the service offerings.

Governments may support the ecosystem (which varies from country to country) at the national, regional, or local levels, while policymakers and regulators should set the input and rules.

3.4. Meta AAL Ecosystem Model

Sawaragi et al. [28] argue that to target society and community instead of single persons and individuals, understanding complex structures of interactions between people, technology, and the environment is necessary to understand the “System of Systems.”

Building on this notion, we drew a parallel by conceptualizing the Meta AAL ecosystem as a system of AAL ecosystems and illustrate this in the following figure (Figure 5). We argue that, although all AAL ecosystems seem similar on a conceptual level (as shown in Figure 4), their realization in the real world has some specifics that must be approached differently. One apparent distinction comes from county-specific circumstances, as countries have specific laws, regulations, and healthcare systems that set different playing fields for the AAL ecosystem actors. In such circumstances, it is beneficial to have cross-national cooperation, knowledge-sharing, and frameworks that can support the delivery of AAL services in a trustworthy manner.

One possible list of the aimed added value for such a Meta AAL ecosystem, according to the authors of this paper, includes:

• Governance (where the governance standards and policies are defined centrally, while the management responsibility is decentralized following a federated approach recognizing the AAL (sub)ecosystem autonomy, particularly decision making, managing expectations, and relationships);
• Cybersecurity and data sovereignty (to emphasize the focus on data security, privacy, information asset management, legal ownership, and regulation);
• Trust (to emphasize the efforts and practices allowing the end-users to feel safe when using the services and allowing the providers to feel safe and supported while offering the services individually or in partnership with other ecosystem actors; to define quality standards and controls, support knowledge exchange, and manage risks);
• Technology support (emphasizing the ecosystem support for technical-related activities such as integration, defining entry-level requirements, managing licenses, and sharing architectural decisions).

3.5. Pharaon Ecosystem Model

Pharaon applications and services fall under the eHealth and AAL domains, which extensively use digital technologies to improve the efficiency, quality, and scale of care. Both eHealth and AAL are complex domains that can be approached from multiple perspectives, and both use multiple disciplines to deliver added value to end-users. While both domains involve formal and informal caregiver networks, the AAL primarily focuses on older adults, while in eHealth, they are only one of the end-user groups.

Most Pharaon input technologies have a Technology Readiness Level (TRL) of at least 7, meaning that the system prototype was previously demonstrated in an operational environment. Respecting the previous independent evolution and governance of all Pharaon input technologies, it was decided that this aspect will not be changed during Pharaon. However, to accommodate the Pharaon-specific adaptation, Pharaon activities are governed, led, and supported by Pharaon technical work packages and further coordinated by a single project-wide technical task force responsible for the overall alignment and prioritization. Therefore, Pharaon focuses on combining, evolving, and integrating relatively mature solutions instead of developing them from scratch.

The plug-in architecture pattern (as explained in Section 3.3) allows for the evolution and onboarding of new technologies and AAL services within each Pharaon pilot. Considering the specific use-case scenarios, geographical distribution, local support, and specific national regulations and processes (including country-specific ethics approval), we considered each Pharaon pilot as a socio-technical AAL ecosystem enabled by a technology platform(s). Instead of using only one central technology platform, we considered the possibility of having more platforms in each AAL ecosystem to avoid vendor lock-in and promote openness and free-market conditions. The emphasis is on the interoperability and usage of standards to allow for interactions and data exchange. In the context of Pharaon, we use the term technology platform to refer to the (typically cloud-hosted) software environment and supporting resources that facilitate the development and delivery of (typically web-based) applications and services.

The multi-cloud deployment of Pharaon technologies has pros and cons. The benefits include the freedom to choose the best fit for each technology provider, continue using the familiar providers, reduce vendor lock-in, and increase redundancy and reliability. The drawbacks include more complex coordination and management, loss of precise quality control from the initial stages of the Software Development Life Cycle (SDLC), a somewhat increased latency (although not much as all solutions are hosted in the EU), greater cyber-attack surface, and more work to minimize cybersecurity risks.

To provide technical support, we recognize the recent work by Valero et al. [29] proposing ACTIVAGE IoT Ecosystem Suite (AIoTES) as an approach to creating IoT ecosystems for AHA. AIoTES emerged from the Activage (H2020 contract no. 73267) project to ensure data interoperability in the ecosystem, facilitate application development, facilitate ecosystem building, and provide security and privacy data protection and trustworthiness, following the European regulations and policies. AIoTES proposes “a reference architecture in creating and extending IoT-enabled AHA ecosystems”; therefore, in the following figure (Figure 6), we present the mapping of the Pharaon and AIoTES layers. The AIoTES Device Layer focuses on integrating devices and offering information access via specific communication protocols. The AIoTES Platform Layer contains different IoT platforms, while, in Pharaon, we considered other types of platforms. The AIoTES Semantic Interoperability Layer (SIL) consists of Inter MW, which is responsible for syntactic interoperability through purpose-built platform bridges and a designated broker, and Inter Platform Semantic Mediator (IPSM), which is responsible for semantic interoperability and mappings between platform ontologies. The AIoTES Service Layer includes analytics, Key Performance Indicator (KPI) management tools, development tools, and deployment tools. The tools used in Pharaon are considered in the Collaboration and Processes Layer, a layer that has no equivalent in AIoTES architecture. The AIoTES Application Layer contains applications and a Marketplace as a one-stop online shop for uploading, finding, and sharing applications. In Pharaon, Security and Privacy are considered a cross-cutting concern, while in AIoTES, they are considered a layer, but they refer to the same things in both cases.

We considered Pharaon pilot sites (as identified in Table 1) as socio-technical AAL ecosystems. When considering the geographical distribution, Pharaon operates at a cross-national level, Pharaon pilots at the national level, and Pharaon pilot sites at the regional level. Therefore, the Pharaon ecosystem can be considered a macro-level, while Pharaon pilots are meso-level. Similar to a “business ecosystem,” where a network of different organizations provide, consume, and collectively create and share value by creating synergies, the Pharaon ecosystem increases the value of each input and scales this by delivering it to a more significant number of end-users. Building on the notion of a Meta-AAL ecosystem (as defined in Section 3.4), we envisioned the Pharaon ecosystem as a Meta-AAL ecosystem and illustrated the Pharaon ecosystem’s governance model in the following figure (Figure 7). The figure illustrates the coordination and centralization of the common aspects of all Pharaon pilots while allowing for federated and decentralized decision-making and autonomy specific to each Pharaon pilot and, more specifically, the Pharaon pilot site.

In a systematic literature review of software ecosystem governance, Alves et al. [30] confirm that governance includes technical decisions and social aspects involving the coordination of players and business strategies, thus impacting all three dimensions of the ecosystem (technical, social, and business). From the 63 analyzed studies, the same authors conclude that software ecosystems governance is defined as all processes by which a player creates value, coordinates relationships, and defines controls. The Pharaon ecosystem’s added values are precisely those defined for the Meta AAL ecosystem (Section 3.4): governance, cybersecurity and data sovereignty, trust, and technology support. The benefits aim to cover the social, technical, and business aspects at different levels of granularity.

The following figure (Figure 8) illustrates the Pharaon ecosystem according to the authors of this paper.

The Pharaon ecosystem is based on several pillars. Governance refers to the Pharaon governance model and coordination between different Pharaon pilots. Open reference architecture defines the common functionalities and serves as a basis for the concrete architectures of each Pharaon pilot. A secure interoperability framework supports both syntactic and semantic interoperability between Pharaon platforms and technologies. Technology-support tools facilitate smooth cooperation and technical work, while privacy and trust emphasize privacy by design and regulatory compliance. The main actors in the Pharaon ecosystem are the end-users, caregivers, Pharaon technology providers, health and social service providers, and third-party providers. The latter includes telecommunication service providers, hardware suppliers, cloud infrastructure suppliers, and additional technology providers onboarded via two planned open calls. The actors are in line with the actors mentioned in the AAL ecosystem model (introduced in Section 3.3). We recognize that the notion of “Pharaon” is less important than the goal of this work, which is not to create a monopoly under the Pharaon name but to promote further work, collaboration, evolution, and synergies toward supporting sustainable, open, and value-creating AAL ecosystems.

4. SmartHabits Platform within Pharaon

One of Pharaon’s aims is to integrate and orchestrate different technology-based solutions on a large scale. In this work, we used the SmartHabits Platform as an example of an AAL system and Pharaon input technology to elaborate the integration process within the Pharaon ecosystem and specific Pharaon pilot sites as examples of socio-technical AAL ecosystems.

4.1. SmartHabits Platform (SHP) in Pharaon Architecture

The mapping of SmartHabits Platform architecture to the Pharaon architecture logical view (introduced in Section 3.2) is shown in the following figure (Figure 9). The figure focuses on SmartHabits supporting Italian and Slovenian pilots (introduced in Section 2.1.2). Aside from SmartHabits-specific parts (yellow), only tightly related Pharaon parts are depicted (blue—related to functional layers, green—related to interoperability cross-cutting functions, and orange—related to security and privacy properties).

In the Device and Communication Layer, different hardware devices were selected to those from the original SmartHabits system’s Home-Sensing Platform. Different Pharaon partners took care of device procurement, installation, maintenance, and support, while more specialized Pharaon edge technology was used for sensor data collection and aggregation. In this way, the process became more efficient, considering the different Pharaon partners’ geographical and organizational distribution, especially during the challenges introduced by the COVID-19 pandemic. The different types of sensors that generate output in the form of digital data needed for Pharaon Italian and Slovenian pilots can be grouped into health, environmental, and wellbeing, according to the type of data being measured.

The “IoT Platform” layer of SmartHabits Platform (SHP) was upgraded to fulfill Pharaon’s current and, to some extent, possible future needs. The integration between another Pharaon edge platform and the SmartHabits Platform is realized in the Platform Layer. Since the two open calls are planned in Pharaon, with one undergoing application review at the moment of writing this paper, other technologies will be onboarded (and integrated) in the future for all Pharaon pilots (including Italian and Slovenian). Data Ingestion was responsible for receiving the structured data from another Pharaon platform within the JavaScript Object Notation (JSON) encoded messages over Message Queuing Telemetry Transport Secured (MQTTS) or Hypertext Transfer Protocol Secure (HTTPS) protocols. Data validation and filtering were carried out within the Data Processing component to inspect the messages that arrived, ensuring that only valid data were accepted and stored in Data Storage. Since most of the data were structured and time-series data, the NoSQL databases were the main destination. The Rule Engine accomplished more advanced data processing, making predefined conclusions based on stored or incoming data for more complex decisions and data transformations. Platform Administration refers to managing, configuring, and maintaining the SHP components on top of the underlying private cloud infrastructure. Device Management refers to provisioning and managing the digital representation of devices, typically sensors, residing in the Device and Communication Layer. Monitoring refers to the real-time visibility of crucial SHP system health indicators. Logging refers to the management and storage of timestamped events that are especially important and useful if some unexpected or unwanted incident occurs, allowing for backtracking and debugging.

In the Service Layer, relevant multidimensional new data are continuously analyzed to detect the repeating patterns in sensor data within Data Analysis, Pattern Recognition by using contextual information (such as configuration data) from the Context Management component. Newly arriving data are compared, using near-real-time stream processing, with the learned patterns within the Anomaly Detection component. If an unusual pattern is detected by identifying a subsequence contextual (aka, conditional) outlier, the notifications are issued via another Pharaon technology component.

In the Application Layer, the input from the SmartHabits is received and used alongside other inputs to deliver application functionality via specific user interfaces to different users and user roles, according to the pilot-defined requirements.

In the Collaboration and Processes Layer, the SmartHabits business and organizational processes involving people, software engineering tools, and practices such as Development, Security, and Operations (DevSecOps) are addressed. The established SmartHabits DevSecOps practices provide a focused and speedy delivery. The Pharaon DevSecOps process defines processes at the project-wide level and coordinates technical activities concerning multiple (Pharaon input) technologies (including SmartHabits) that are being adapted, evolved, and integrated. SmartHabits’ intra-team communication and coordination are not visible to other Pharaon partners. To ensure the success of Pharaon, communication between different DevSecOps teams must be efficient and effective. For this reason, essential information on SHP and other Pharaon technologies was made available via designated private Pharaon repositories hosted on GitLab.

Interoperability is tackled at different Pharaon layers to allow for the meaningful sharing of the different Pharaon data. Device Interoperability deals with the data exchange, mostly between sensors and Device Gateways. Platform Interoperability focuses on exchanging the data between Pharaon platforms at the intra-pilot and inter-pilot levels. Syntactic Interoperability, often referred to as technical interoperability, emphasizes the connections and understanding of data structures and protocols between different Pharaon systems and services. In the case of SHP, the data are received via MQTTS or HTTPS connections in a standard, text-based JSON format to represent the structured data and is exposed via HTTPS REST APIs, also in the JSON format. Semantic Interoperability tackles the top-level understanding and meaning behind the exchanged data, which is often related to the ontologies, representing different entities and their relationships, representing the real world. Legal Interoperability focuses on making the interoperability agreements explicit (by signing contracts) and compliant with the EU and national legislations of the Pharaon pilot countries. In terms of the software, this includes an assessment of software licenses and usage rights. Organizational Interoperability deals with the Pharaon business processes, expectations, and organizational preconditions enabling Pharaon’s technical work, including the interoperability of SHP with other Pharaon platforms and services. Interoperability is of critical importance in Pharaon. It allows for the “plug-in” integration of different systems into Pharaon and facilitates the creation of new capabilities by combining existing functionalities. In terms of the Pharaon ecosystem, it increases the cost-effectiveness and reach of every single technology. Pharaon input technologies were designed before and outside Pharaon, so their integration in Pharaon relies on existing interfaces which in some cases are additionally extended and adapted for Pharaon purposes. For SHP’s integration in Pharaon, there was a particular focus on assessing and understanding the data that would be ingested, their definitions, data models, and data semantics.

Security and Privacy in Pharaon focus on ensuring and preserving the Confidentiality, Integrity, and Availability (CIA) of the Pharaon data. In the Device and Communication Layer, the focus is on Network Security and protocol communication and Pharaon’s Devices Security. In Pharaon, the Transport Layer Security (TLS) cryptographic protocol is widely used to provide logical communications security between different processes running on different hosts, which are connected over a network. Cloud Security refers to the security implemented by providers or a cloud-hosting infrastructure. Both public and private clouds are used to host Pharaon technologies on Pharaon. Platform Security refers to the security of entire Pharaon technology platforms, such as SHP. The Identity and Access Management refers to authentication, role-based access control (RBAC), and role customization for Pharaon users and systems. Only SHP admins are able to manage and administrate the SHP, while only machine interfaces are securely exposed for the Pharaon. In a recent survey on security trends in IoT, Harbi et al. [31] provide a taxonomy of IoT attacks based on layers, purposes, and countermeasures. This also applies to AAL solutions, which build on IoT and other emerging solutions, including edge computing, fog computing, blockchain, and Machine Learning (ML). The Privacy by Design (PbD) addresses and incorporates privacy throughout Pharaon’s and SmartHabits DevSecOps and software lifecycle. In the SmartHabits DevSecOps team (and the authors of this paper), there is a commitment to proactively enforcing high standards of privacy. The purpose of data collection is communicated to the end-users and confirmed within consent documents. Only the data that are needed for Pharaon use cases are collected. SHP only deals with pseudo-anonymized sensor data provided by other Pharaon partners to minimize the information privacy risk, ensuring that the SHP admin cannot identify the Pharaon end users. Legal and Regulatory Compliance ensures all the legal and regulatory requirements are met to allow for the smooth running of Pharaon pilots. End-user consent, ethical approval, and Data Processing Agreements for each Pharaon pilot have been defined and signed. Furthermore, the model and methodology for ethical management of the large-scale implementation of ICT solutions for Active and Healthy Ageing, also based on the Pharaon work, is described in Dantas et al. [32].

4.2. SmartHabits Platform Deployment Sandboxes

Pharaon’s technology providers use different isolated deployment environments (referred to as sandboxes) for different phases of their work. The development sandbox for SHP is hosted on a private cloud and is not publicly available. The integration (often called staging, test, or pre-production) sandbox exposes the MQTTS and HTTPS interfaces for data input and JWT (JSON Web Token) HTTPS REpresentational State Transfer (REST) APIs for data output via a public Universal Resource Locator (URL), with the addition of an OpenAPI-based, always up-to-date, interactive language-agnostic REST API documentation, which also offers the automatic generation of the client Software Development Kit (SDK) code based on the given documentation and exposed data schemas. The integration sandbox only handles test data from the test environment (there are no real user data in the integration sandbox). The production sandbox is similar to the integration sandbox but is additionally secured and restricted. There is no exposition of the OpenAPI and Swagger documentation. Any access is restricted and only allowed by using proper API tokens and whitelisted IP addresses belonging to partner platforms, thus reducing the cybersecurity attack surface. A full range of additional security measures is applied to the SHP production sandbox, which significantly reduces security and privacy risks. SmartHabits Platform deployment sandboxes are compared in the following table (

Table 3. SmartHabits deployment sandboxes comparison.

	Development Sandbox	Integration (Test) Sandbox	Production Sandbox
Configuration	Development configuration	Test configuration	Production configuration
Ingested data	Local test data	Integration test data	Data from real users
Objective	Feature evolution	End-to-end integration test	Real user interaction
Security and privacy risks	Low	Medium	High
Change management	Easy	Medium	Hard
Organizations included	SHP partner only	Pilot technical partners	All pilot partners
Deployment frequency	High	Medium	Low

).

SHP is deployed using (Docker) containers with sandbox-specific configuration files. Easy-to-reuse deployment and standardized deployment components with all needed dependencies facilitate portability, isolation, a quick setup time, and ensure the same behavior across all SHP deployment sandboxes. Furthermore, decoupling the deployments from the underlying Operating System (OS), hosted on SHP Virtual Machines (VMs) running the Docker Engine, allows for a more manageable underlying Operating System (OS) and security patches.

4.3. End-to-End Data Flow

The following figure (Figure 10) shows data flow related to SHP participation in the Italian and Slovenian pilot use cases. The components owned by other Pharaon providers are shown in blue, while the SmartHabits components included in selected Pharaon use cases are shown in yellow.

After the on-site sensors send the data via the Device Gateway (or directly, depending on the sensor type) to another Pharaon (edge) Platform, the arriving sensor data are validated within the Data Ingestion of the SHP and dropped if they do not comply with the expected input. Examples of sensor data arriving in SHP are given in the following table (

Table 4. Selected arriving sensor data.

Sensor Category	Data Category	Data Parameters
Wellbeing	Steps	total value since last reported, timestamp, sensor id
	Calories	total value since last reported, timestamp, sensor id
	Activity type	inferred activity, timestamp, sensor id
	Heart rate	value, timestamp, sensor id
Environmental	Contact (open/closed)	true/false, timestamp, sensor id
	Temperature	value (°C), timestamp, sensor id
	Humidity	value (%), timestamp, sensor id
	Motion	true/false, timestamp, sensor id
	Particulate matter 25	value (µg/m3), timestamp, sensor id
	Particulate matter 10	value (µg/m3), timestamp, sensor id
	TVOC (Toxic chemicals levels)	value (ppb), timestamp, sensor id
	CO2	value, timestamp, sensor id
Other	Battery level	value (% of remaining battery level), timestamp, sensor id

). Only TLS-secured connections from the pre-approved IP addresses are allowed. The popular, especially in the IoT domain, lightweight, asynchronous, binary, MQTT(S) publish-subscribe messaging protocol is used. It allows for fast message delivery via efficient (smaller than heavy text-based HTTP) packet sizes. Messages are sent to the appropriate topic to which the specific SHP subscriber(s) are subscribed for further processing and storage. Timeseries sensor events, as recorded observations correlated in time, are stored in the NoSQL database, while other profiling and contextual (including configuration) information are stored in the MySQL database. The ML-based Anomaly Detection component continuously uses different available data to detect an anomaly. An HTTP message is sent to another Pharaon system responsible for notification delivery via localized user interaction if an anomaly is detected.

SHP only handles pseudorandomized data in Pharaon, including pseudonyms for sensor device identification. For the input data format, the SHP can support any JSON-formatted message with the minimum of a key:value pair that identifies the sensor and telemetry value. The data transformation and mapping between the data arriving in SHP Data Ingestion and data used in SHP are illustrated in the following figure (Figure 11).

The output of data ingestion is SensorEvent, which contains timestamp and telemetry values. These sensor events are further processed, enriched, aggregated, and analyzed to produce higher-level context events. They represent higher-level processed data and could contain multiple dimensions for a single origin (sensor). For example, for each motion sensor event, there is a corresponding context event of dimension MOVEMENT_DETECTED with a value representing the minute of the day at which the event happened. However, other dimension events are generated from a single sensor event, such as duration of movement (DURATION) or total movement duration per day (DAILY_DURATION).

4.4. Integration Challenges

The following figure (Figure 12) roughly illustrates the different selected technical and supporting activities in the AAL system integration process as the authors see them.

The technical and supporting activities were conducted to integrate the SmartHabits into Pharaon. The first activity was to obtain consent forms from end-users and ethical approvals from the pilot countries to begin the project activities concerning end-users. The use-case definitions, completed in a co-design process, were incredibly challenging during the COVID-19 pandemic [10], especially since the Pharaon target users are older adults, the same user group at most risk during the pandemic. In terms of the technical activities, after establishing the way of working, most of the time was spent on achieving technical (syntactic) and semantic interoperability, which included the agreements between the data formats, protocols, adaptation of interfaces, and APIs to accommodate for the newly added ontologies and data models, etc. Standards-based interfaces and implementations facilitated this process; however, the overhead of collaborating, communicating the meaning of the data, frequency of exchange, security details, etc., was not negligible. The problems with the procurement of the devices, especially sensors, for pilot sites resulted in the information models’ changing to accommodate the alternatives. Pharaon partners observed that ordering more devices was beneficial since devices can easily break or may be needed for additional testing in parallel. Additionally, some sensors did not behave as advertised and had to be replaced, which confirmed that starting with the lab integration phase, to check if everything worked as expected before the pilot deployments, was a good decision.

Coordination and collaboration activities, especially ones that involve a more significant number of stakeholders and project participants, are a necessity but also introduce more overhead, especially for the key persons. Different views, geographical distributions, internal organizations, and time plans, and conflicting priorities, introduce planning and effort distribution challenges, which means that some activities take longer than expected. The addition of new technologies in the future, as in the case of Pharaon, where two open calls are planned, means that the architecture and requirements will continue to evolve throughout the project lifecycle, which requires a delicate balance between current needs and future-proofing for the architects. Furthermore, the effort required for future-proofing can be unlimited and can reduce focus on the priority tasks. This is similarly true for the over-optimization of some parts of the system.

With its integration into the Pharaon, the SmartHabits Platform became part of the pre-validation process to enable end-to-end sensor data flow and basic processing. Large-scale validation with many users has yet to be carried out within Pharaon and is currently (March 2022) in the final preparation phase.

5. Discussion and Lessons Learned

Continuous communication on all levels is essential. If the expectations and goals are not appropriately communicated, a lot of extra time and effort is spent fixing the problems afterward. Here, we refer to both the administrative and top-level communication at the project level and the technical communication for coordination at the team level.

The following figure (Figure 13) summarizes some of the challenges and choices faced by players in the AAL domain. We base our elaboration of these challenges on our 10+ years’ experience working in this domain and share the lessons we have learned.

AAL ecosystems are needed. Different actors in the domain can benefit from the ecosystem(s), but establishing them is not easy and involves many things. The governance and management of an ecosystem involve managing every possible relationship, facilitation and coordinating different go-to-market business models, ensuring regulatory, legal, and medical compliance for different countries and regions, and many other activities. The orchestration of different types of actors is challenging when realizing and operationalizing such activity. The added value from the participation should be much higher than the cost of participation to attract participants. Since there is no way of knowing the exact requirements that may arise in the future, our experience is that, apart from delaying some architectural modifications for as long as possible, this is futile and can even be counterproductive. The ecosystem can also help to set up the playing field in this regard. The influence of AAL ecosystem governance, management, and integration processes is significant and must be clear, supportive, and strict to facilitate that maximum benefits are delivered to all actors.

The platform landscape is and will be very fragmented. In our view, there will not be a single AAL platform. The IoT platforms, which are largely used as the basis in the AAL domain, are many, and are purpose-built with a different focus, with academic research being a top priority in many cases [33]. Furthermore, the ecosystems around such platforms are more advanced than non-free platforms, while free and open-source platforms have different capabilities. There is still a lot of uncertainty and a lack of support for new entrants that want to create and monetize their added value by offering some AAL services based on the underlying ecosystem and platform. For this reason, the need to achieve efficient and quick interoperability is even more important.

Standards are a must. They are needed in data formatting (e.g., JSON, XML), physical and data link layer protocols (e.g., IEEE 802 collection of networking standards such as Ethernet and WiFi), data layer protocols (e.g., TCP, UDP), application layer protocols (e.g., MQTT, HTTP, CoAP, AMQP, XMPP), APIs (e.g., RESTful, JSON-RPC, SOAP), APIs documentation (e.g., OpenAPI specification-based documentation of the RESTful APIs), API design, the usage of standard terminology, etc. In our cases, using standards and standard ways of describing exposed APIs increased the speed and minimized the need for push notifications on every API update. When it comes to ensuring semantic interoperability, the landscape is still too fragmented. Many countries have different approaches and terminologies, and widely accepted ontologies, taxonomies common data models, and data quality assurance frameworks are still missing.

Integration comes with a tradeoff. While integration brings many benefits and facilitates the combination of different AAL systems and their synergies, decisions regarding the depth and scale of the integration are not straightforward. For example, when AAL systems are interoperable on technical and semantic levels, this does not imply that the UX of those systems can also easily be integrated. If both systems come with a specific UI, the transition from one “look and feel” to another comes with the cost of their being perceived as two separate systems by the user. Some AAL platforms and projects have invested in separating their content and presentation and used the notion of Abstract User Interfaces or pluggable user interfaces to decouple the content from the presentation. Mayer et al. [34] conducted a comparative study of the mechanisms used to design flexible user interfaces in AAL and showed that there is no commonly accepted way of describing the UIs on the abstract level, which would lead to desirable and practical user interaction. We approached the integration of original SmartHabits solutions (as introduced in Section 2.2.1) into Pharaon without the original UI. A new web-based UI is being built by a different partner for the Pharaon use cases to merge all the functionalities needed in the Pharaon pilot site within the new purpose-built UI. This means that additional effort is being invested in achieving a consistent look and feel.

Cross-border health data sharing is challenging. This is especially true for secondary uses that are not yet clearly defined and is becoming increasingly important with the emergence of data-intensive AI. Trusted data-sharing and the realization of a trusted data market, as considered in the International Data Spaces Reference Architecture Model (IDS RAM) 3.0 [35] are steps in this direction. IDS RAM aims to become a blueprint for European Data Sharing Spaces, implementing the EU strategy for data. Data ownership does not imply revenue sharing. The user data are often used for further system improvements that can be monetized, but those who provide these data are not compensated. With an increasing number of AAL services, data from real environments are also growing. This is especially evident in global digital platforms that older adults often use. To facilitate the trustworthy, secure, and regulated exchange of health data, the EU Commission made the creation of a European Health Data Space (EHDS) in 2019–2025 a priority [36]. The EHDS is to be built on three main pillars: strong data governance and rules for data exchange, data quality, and robust infrastructure and interoperability. The European Data Act [37], adopted by the Commission on 23 February 2022 as a vital pillar of the European data strategy, aims to maximize data’s value in the economy by further clarifying who can create value from the data. These efforts are critical in the future development of the AAL domain and AAL ecosystems.

Not all AAL solutions are mature enough. There is a large gap between the prototype and production-level system, where every aspect of the system has to be mature enough to fulfill the expectations. All devices must be mature enough to be suitable for deployment in real environments. All aspects of data management, from legal to data security and privacy, must be met. The external interfaces must be tested for vulnerabilities, and the cybersecurity attack surface must be minimized. The ability to scale up the solution from a few to several hundred while maintaining the desired Quality of Experience (QoE) requires performance testing, and possibly additional adaptations and upgrades. All this takes time and may require the additional building of competencies and knowledge absorption from the team performing the (DevSecOps) work. AAL ecosystems should define the integration requirements of some AAL solutions, including the maturity level. In addition, there may be different phases within the process. Experience can also be derived from the Apache Software Foundation Incubator (ASFI), which aims to help projects become self-sustaining. Yin et al. [38] analyzed the ASFI projects and developed interpretable models that can forecast a project becoming sustainable with 93+% accuracy, within 8 months of incubation start. Such models, with possible adaptations, might be helpful in predicting the sustainability of AAL projects as well.

Cost is important. When researchers build AAL systems, they often only aim to show Proof of Concept. However, in the real-world production setting, the price, reliability, scalability, and sustainability of the proposed overall solution, meaning the technical part and human support in setting up, installing, maintaining, and supporting the system, also exist. For many older people, especially ones with a lower income, the price of AAL solution is too high. Regional and national governments largely still do not recognize the benefits of AAL systems, or finance them directly, as their primary concern is traditional healthcare services. In our case, we had to balance the available equipment budget and the availability of the same type of devices with a good enough quality (which became additionally challenging in the COVID-19-influenced disruption in supply management chains), and the time plan of the installations. Many preconditions in terms of setting up the telecommunication infrastructure and ensuring good enough connectivity and bandwidth on pilot sites and the high availability of the cloud infrastructure also had to be ensured, which meant that the total budget had to be planned accordingly.

User Experience (UX) should be the primary concern and top-most priority. Often, the benefits and added value of the technology are not appropriately conveyed to end-users, which ultimately leads to poor acceptance and rejection of the system. UX influences the acceptance of the solution and summarizes the overall satisfaction of the end-users. No matter what process is used, whether it is User-Centered Design, co-design, or some other design, is ultimately less important than the end result, and the end user’s acceptance is the ultimate goal. The right balance of usefulness, perceived benefit, accessibility, desirability, and usability must be achieved to obtain a good UX. Since the user interfaces (UIs) are the points at which the user and system interaction is realized, they are of pivotal importance. Grguric et al. [27] surveyed how different AAL systems and platforms approached the design of the multimodal user interaction mechanisms and discussed ongoing development challenges in the field. Over the years, different technology adoption models have emerged. One of the most popular is the Technology Acceptance Model (TAM) [39], focusing on individuals’ beliefs, perceived usefulness, and ease of use.

6. Conclusions

Much work has been carried out in AAL and AHA to create AAL applications, systems, and frameworks and advance domain knowledge. Awareness is increasing among all the actors, and several good initiatives have been started to bridge the digital divide gaps. With the increasing maturity of devices and technology, the focus is shifting from building prototypes to establishing ecosystems to use mature AAL services and products. Although the benefits of this technology are highlighted, it is clear that a holistic approach is needed to deploy AAL solutions on the market successfully. The AAL products, especially those closer to the medical domain (using certified medical equipment), need to be regulated and adequately supported before they are delivered to the market and placed in the hands of end-users. All socio-technical preconditions have to be met to ensure peace of mind and the desired level of support in a trustworthy manner. All players in the ecosystem have to work together to provide safe, practical, reliable, trustworthy, affordable and reliable AAL systems. This multisided collaboration and knowledge exchange will lead to a higher number of smart, healthy, and inclusive assisted environments, capable of reducing the burden on caregivers while promoting wellbeing.

This paper reports on the experiences and lessons learned from the integration of SmartHabits into Pharaon’s large-scale pilots. Since the large-scale validation of Pharaon has yet to be completed, future research will include a collection of feedback from a more significant number of users. In addition, new onboarded solutions via project open calls will include integrating additional capabilities in Pharaon pilots to fulfill the requirements of the Pharaon ecosystem. This is because not all technological parts could be included at the time of project creation.