A context-aware reference architecture for ambient assisted living information systems

Published Online February 2019 in MECS DOI: 10.5815/ijitcs.2019.02.02

AAL seeks to provide an active and a productive aging. Due to the uniqueness of the field and its sensitivity in matter of time and performance, these systems has countless concerns to come up with reliable solutions for these special groups of people. The multiplicity of applications used to control such an environment, the differences in families of technologies and the contrast between the backgrounds of each application made the integrations an impossible mission. Furthermore, the time and the costs paid to grant the development of new adapted systems is a dilemma. The end-users of this field are exceptional. Where in all other fields applications are developed and used directly by the stakeholders, in this field many adjustments has to be done before reviling the end version on each application. When developers deal with the elderly population, they deal with a number of limitations that are exclusive for each targeted individual.

Our objective is to deliver a reference ground for the AAL developers. A suitable, standard and abstract guide to develop these applications relying on a common infrastructure. The standardization of the elements used in all the systems would give the opportunity to adjust the functionalities and integrate the available systems into creating novel ones. An approach that can be applied in different scenarios for conceiving AAL systems. The concepts of uniformity, homogeneity and consistency are major axis of our proposal.

We believe that a RA will help align the various, disparate and irregular infrastructures under a common vernacular. As a result, we will have a common baseline between all the system’s contributors. In addition, the high-level of abstraction intended to help understand the specific requirements and the application of a given scenario.

In this paper, we present a novel approach for the AAL RA. We cope with the ambition of creating systems capable of evolving depending on the context where they are meant to be executed. The RA is designed to answer to the dynamic nature of the field. In additions, to survive the daily evolutions of technologies and patterns used by developers. We aim to give the ability of simple, adequate and cost-friendly adaptations in the process of integrations, escalations and modifications of the already existed systems. The ultimate goal of this effort is to be able to link different systems in one homogenous environment in a meaningful, feasible and coherent way. Furthermore, to benefit from the experience and the efforts done by previous engineers.

In the next section, we discuss the related work. The third section is devoted to the examination of the context awareness in AAL systems, where we propose a process of extraction and an examination of it according to its background. The forth section concerns the presentation of three different views of our approach, starting by the overall view, the structural view and ending by the behavioral one. Finally, we conclude with a summery.

• II.    Related Work

The main problems that appear from the divergence of architectures adopted in the process of developing AAL systems seems to be countless. Technologies are evolving rapidly which made systems that relay on theme useless upon small periods. The ambiguity resulted from the different patterns made the integration a challenging mission. Employing different elements, ignoring substantial ones and adding insignificant components presents critical problems in a domain where the cost is the major concern. Moreover, we cannot ignore the complications resulted from the differences in the exploitation of the available resources, nor the mechanisms applied for the interpretation of the knowledge resulted from the processing of the collected data.

Relaying on the results presented in the two reviews [1] and [2], we can affirm that the architectural side of the AAL systems is very rarely investigated. The largest scale of the contributions are objective oriented ones. A number of projects has proposed an architectural design such as [3-7] which are individual approaches with irregular mechanisms. According to the reviews, very few of them had discussed the idea of independency or flexibility. In [8], although the authors claim that their architecture is adaptive and technology-independent yet in their description we found several dependencies to technologies. Their overview of the system architecture holds elements of defined components and specific devices used, which is inconsistent with their aim of independency. In [9], the authors had considered only architectural operations in their vision. This proposal is lacking the major concepts of a reliable architecture, which is the homogeneity between the goal, the context and the design. In the PERSONNA [10] project they described a RA for the AAL space, their main purpose was restricted in the determination of the flow from context to service. A key limitation of these researches is the lack of standardization. Most of them are not adaptable to different scenarios. The non-suitability to different environments is also a dilemma. Moreover, the scalability is ignored and the adjustability to the elderly needs is limited.

• III.    Context Awareness in AAL Systems

Context awareness plays a critical role in deciding the actions of the actuators. Context allowed a clear understanding for the event, statements and ideas by clarifying the circumstances and the substances. The context description holds any information that might change or affect or characterize the understanding of the current situation and the prediction of events [11]. Uncovering and understanding the context will provide a clear vision for manipulating the services as illustrated in Fig.1. It reveals all the relevant aspects of a field including the users and the application itself [12]. The categorization of the context would classify the types of the system’s interactions according to the situation taxonomy. The context is continuously changing, it has a temporal and a spatial character which makes it imperfect and uncertain [13].

Therefore, the instant extraction of context might cause problems while simulating the correct action. Using the context history and background reveals importance when selecting the services. The system learns from the past context to adapt the behavior to a better response. This reveals the importance of storing the context and using its history elements to provide relevant interactions to adequate situations [14]. Furthermore, it gives clear instructions to the situation reasoning.

Context contains elements related to the data implication. As the AAL systems have to be context-aware computing platforms they have to take in consideration the context in which the data was acquired in order to apply appropriate reasoning and actions.

• A.    Context Extraction process

The specification of the context addresses a high-level of precision in decision-making. In our process, we favor the specification of behaviors using the extracted data to determine the context. The acquisition using the sensors provides the data that have to be interpreted. The delivery of the context to the situation reasoner has to take in consideration the context history provider. When the context is useful, the system selects the appropriate context-aware behavior.

Fig.1. Flow from the context extraction to the selection of the services

The context is influenced by the perimeter of the execution, which made describing the parameters and the specifications of the environment a necessity. The data providers, whether the internal or the external ones, affect the quality of the information, which in the process weakens the reliability of the system. Designers have to take into consideration the stakeholders. Their state and statue influence the nature of functionalities and restrict the interface’s design to present an easy interaction for different families of users. Finally, the services provided by the system have to be determined according to the extracted contexts. In modeling AAL systems, the data extracted from the sensors, the activities structure, the user profile and preferences are important aspects to assemble the overview of the functionalities required [15]. In our analytics, we describe four basic concepts that assimilates the context in an AAL environment.

An AAL system is in need of an active-contextawareness by which the applications can automatically reveal the context out from the situation parameters. This extracted context has to obey a certain representational structure to facilitate its use by the situation reasoner. Simplifying the general form of it would help gathering the proper information and extracting knowledge. Interchangeability is also one of the context important aspects as well as its decomposition to help maintaining the distributed frames of data.

The overall objective of our vision is standardization. Therefore, we rather maintain the uniformity of the interpretation to help integrate the systems. Extensibility is a mandatory element in the context formality to ease the scalability issue.

As we propose in Fig.1, the context extracted by heterogeneous perception devices in a given environment is annotated accordingly to the AAL ontology. It works like a provider for the situation reasoner in addition to the context history provider and the context background to reason the process of the information collected and order a suitable reaction to the service orchestrator. The controller identifies the suitable actuator to perform a certain process.

• B.    Examination of the context

To expose the background of the AAL field context, we consider all the concepts that might have an effect on the system [16]. The investigation of the environment and its necessities resulted on the determination of the concepts and their elements as illustrated in Fig.2. In this concept map, we gathered all the context background elements that would provide a highly qualified image of the situation taxonomy for any AAL system [17].

We used a concept map to emphasize the context background concepts. The data providers in an AAL environment feed the context by the collected data. The AAL space influences the context according to its specifications and parameters. Considering the stakeholders’ status and state the context can use all the above information and data collected to determine the adequate services to launch in the proper timing. In the next paragraphs, we explain in details each of these elements.

Existence of objects

Determination of Space

Personal environment

Shared environment

Shared workplace

Public space

Diseases

Characteristics

Tolerance to electronic

The goals

The problem being addressed

Targeted situation

A triggered event

Fig.2. A scope of the context background major concepts

Data integration process Data acquisition policy

Sensor

Actuator

We arable

Embedded

Nature of extracted values

Number of extracted values

has a state

Elded/

Mentally disabled.

Physically disabled

Context Backeround

Adjustments Adaptations Scalability Behaviors

• •    Environment

AAL Space is a smart environment centered on its human users. A set of embedded networked artefacts, both hardware and software are used in this space. Both the users and the environment influence one another. The augmentation of different families of sensors and actuators gives the space a sense of consciousness and awareness. Rich context information can be obtained by analyzing and fusing the data collected as illustrated in Figure 3. However, these analyses should take in consideration the specifications of this environment. The shared spaces such as hospitals, work places…etc. have different specifications than personal ones. Designers have to consider the existence of objects, stairs, the space limitations and determinations…etc. in order to give appropriate sense and adequate illustration to the collected data.

On the other hand, the system itself will influence the environment. Providing a smart-environment, where not only clinical devices could be reachable, but even assistance and care giving, implicates high communication requirements, sophisticated data bases all in affordable limits.

• •    Data Providers

The data extraction in an AAL environment embedded with several families of devices is not an easy task. The developers have to take into consideration many aspects of data corruption resulted from the remote acquisition, the delay of collection and the obstacles of timing. The uncertainty of the used devices and the criticality of the wearable ones are influencing factors for the data reliability and certainty [18]. Therefore, choosing the appropriate collection technology is forced by the structure of the environment and the other concepts related to the context extraction.

The data providers represent the heart of an AAL system. As illustrated in Figure 4, they are the source of knowledge in which the system relies to purchase the needs and executes its services. The dilemma encountering this concept in the context extraction process is the data in motion (data in transit) between the system and the external providers. The devices embedded in the user’s space extracts different natures of values as well as different numbers of them. The actuators execute the actions accorded by functionalities driven by the events. Each of them has a definitive state as a reactive, proactive, or extensible features [19]. Advanced processing paradigms have to be involved in the real time extraction from the external data sources. All these combinations insure the quality of knowledge extracted as well as the coherence between the context and the executed action. The ideal gain is to have the ability of taking decisions in the minimum amount of time and as soon as the data can be turned into meaningful context.

Embedded artifacts

Other concepts

Concept property —

Types of —

Space Features conditions

Location

Furniture longitude latitude affects

Controllable

Noise level

Environment

_________ ^ Uncontrollable

Shared workplace

Public space

Personal environment

Shared environment

Space Condition outdoor

Indoor

Fig.3. The environment visibility toward the context extraction

Fig.4. Clarification of the Data providers

• •    Service

The context background determines the service adequate to a specific situation to be executed. These are the multiple mechanisms to address certain functionalities that answer to a specified need [20]. In the process of providing a service several components may be involved (software and hardware ones). The context background provides the context awareness in the benefit of the user. It guaranties an adequate service to be launched in the objective of executing a specific task. The specification and the description of the overall services provided by the system has to take all the possible attention from developers to avoid redundancy and the overlap of functionalities, which might consume the resources in a non-logical way.

The context identifies the actions and tasks that the system can perform in the AAL space. This awareness may result on invoking several actuators and defined functionalities. The system must reach a coherence while launching the actions based on the extracted events. The interaction of such elements has to rely on the situation taxonomy to have a harmony between the needs and the offers. The interactions of the actuators should be highly monitored. The illustration of the context has to consider all the described concepts to complete the vision of the situation. Mainly the services have to be triggered according to a situation’s demand where its performance is evaluated by the result. Figure 5 illustrates the different aspects of a service.

Fig.5. The Service related concepts description

• •    Stakeholder

The stakeholders interact with the system and affects the actions as illustrated in Figure 6. The designers should take in consideration the user’s experience, whether it would contain preferences where the user will be able to personalize the services or it would be an active interaction where the services will act autonomously. The designer should also determine if the

AAL environment will achieve the context independently in a self-contained way or it has to use external support. These contexts have to be considered in knowledge achievement and to trigger a meaningful reaction from the system. The actions have to be determined by the situation extracted from the global context that has specified the events and resolve the states.

Fig.6. A scope of the stakeholder concepts

• C.    Context possibilities

Although the limitations and the restrictions of the context types might cause a lack of variety of operations thus the major problem is that context may not reveal importance due to the enormous data collected and treated by the system. Therefore, the context types have to be predetermined to narrow the possibilities and regulates the complications. In our vision, we determine a set of various context possibilities related to the AAL field. These contexts are an abstraction to the real time possibilities that may reveal in an AAL environment. In all these proposals, location, identity, time and activity are primary parameters for characterizing the situation criticality.

• •    Emergency Management

• •   Urgent Problems

• •   Regular Situations

• •   Regular Treatments

• •    Autonomy Enhancement

• •   Comfort

• •   Basic First Aid

• •   Major Medical Situation

• •   Post Recovery Attentions

The selection of the context possibilities enhances the determination of the system components and their connections [21]. These determinations hinder the efforts used in the development process and restricts the targets. The advantage of this selection is the assurance of developing only senior services, which higher the performance and regulates the costs.

• IV.    Architectural Synthesis

The RAFAALS 2.0 (RA For AAL Systems) is an abstract representation. It is a composite of multiple views used to address the AAL space structure. As experiences have shown, diagrams are sufficient to represent the RAs independently from the application domain [22], consequently we will use different sets of views to clarify our vision. Our main concern is to present the division of the functionalities of the system with a specification of the data flow between the elements. Throughout the development, we considered the fluid relation between the context, the goal and the design as the key factor of the RA’s successes [23].

needs

Central consideration

AAL

Data

AAL System

Emergency management Regular treatments Autonomy enhancement

Confidentiality

Privacy

Security

Further examinations;

specification

Infrastructure requirements

- Distributed sensors

- Exchange data with other resources

- Assigning actuators’ missions

Situations taxonomy

- Track regular routine

- Anticipate emergencies

- Proactively reacts

Context

Integrity

Performance

Availability

Safety

Adaptivity

Scalability

"[ ^

Embedded determine

Validate

Satisfy

Goals

Fd by

Consider

Quality Characteristics

Reliability

Critical Attributes

Interop er ability

Fig.7. A scope of the proposed AAL reference model [25]

We relied on the RM presented in Fig.7 to develop the RA. AAL solutions based on particular architectures and technologies offer a limited set of interfaces to interoperate with [24] where is E-health services are not impermeable to novel technologies. According to [2] the fusion between the RM and the architectural patterns made RA come to life. These two concepts serves as the paradigms to build the regulations of the RA.

Our design concentrates on the context-description provided by section 3, where we described the extraction process and the relevance of the context. The interactions among the parts of the system are articulated using the different protocols (we ignore any specified one to maintain the abstraction). The architecture offers a total integration in an homogenous AAL space despite the heterogeneity of each used device and other software components. These following graphical representations will reflect the system components with more details and the data flow between these elements.

We abstracted all the engineering components of an

AAL space with the purpose of reflecting an overall image of the infrastructure demanded of implementing an AAL system, which makes the infrastructure flexible for further scalability or maintainability progresses. With RAFAALS2.0 we identify the basic building blocks necessary for implementing a concrete AAL architecture for AAL systems. The cooperation between the views facilitates the implementation and provides suitable understanding of the needs represented in the AAL domain. It gives the ability to create AAL integrated environments easy to interoperate and to maintain.

• A.    The global view of RAFAALS2.0

An architecture view represents a model of interest for the stakeholders to emphasize their interest [26]. We have chosen to present an abstract diagram of the system using the system view in an hierarchy architecture. This view helps visualizing the hardware and the software elements and their virtual interactions. The sensing and the acting layer is based on the number of hardware elements embedded in the user space. The data processing layer is the directly connected layer in which the data is aggregated, prepared and transformed in favor of the analysis process and knowledge extraction. All these steps are mandatory for the software elements to feed the context extraction and provider that helps the situation reasoner to process the situation in order to command the process choreographer while choosing the appropriate process to be executed with the objective of answering to a specified service.

Depending on the scale and nature of the scenarios treated by the system, the implementation of this RA may be portioned to further elements. The arrangements could develop more details, but should not collapse elements for the sake of preserving the clear vision for further integration possibilities.

In the overall view illustrated in Fig.8, we define a high level of aggregation as it presents a standardized approach. We ignored the details and the specifications, as our ambition is to unify the visions of creating AAL systems. For achieving interoperability, further information is provided regarding the elementary elements of the RA in the next paragraphs of this manuscript. We preserved the high level of abstraction. Thus, we gave the freedom for each engineer, architect and developer to concrete the architecture according to its own goals.

Fig.8. a scope of the overall system view of the layered RAFAALS2.0.

The presented hierarchical view of the overall architecture presents the major dimensions of the AAL environment. The sensing and acting layer reflects a standard vision of an AAL space. Where we find the stakeholder surrounded with different families of devices. The extracted data from these sensors is transported to the data layer here it is aggregated with the data collected from remote resources presented by the hospital’s servers, laboratory’s data centers…etc. The transformation of the data feeds the other major software elements presented by the context extraction, the situation reasoner, the process choreographer and the service orchestrator. The view also illustrates the different interactions between these elements. further details are available in the next section.

• B.    The RA structural View

Sensing

Feedback

Assimilation

Embedded Actors & Actuators (Physical Devices)

Middleware

Gateway

Service

Orchestrator

Context Extraction

Edge Analytics

Knowledge extraction

- Remote Gateway .

Hospital Data Bases

Laboratory Servers

Insurance Information

Pattern's Development

Context Background

Data

Layer provision of new devices

Discover

Register.

Context History j Provider Context

— Layer

Devree

Interface

Reaso ning Annas Time & Space

Reasoning Across

Situation

Reasoner

Profile            ' User 's requirements

Fig.9. The structural view of RAFAALS2.0

The structural view of RAFAALS2.0 presented by Fig.9 describes six different layers. Starting from the sensing layer up to the service one. The sensing layer holds all the elements responsible for sensing the space of the stakeholder. It contains the embedded devices and their connection points presented by the device Interface and the device gateway. The user profile is also a part of this layer as it affords the background and preferences of the targeted user. The discover, register and provision of new devices is a mandatory step to be performed by engineers as it offers simplification to the maintainability team as well as the scalability team. Being able to add or remove devices has to be performed according to the specification of the team to prevent any side effects over the performance of the system.

The resources layer is provided by a remote gateway to acquire data from different remote sources. These resources might be the hospital data centers, the laboratory servers or any other information source of the user’s profile, medical history or preferences. The information gathered from these resources are vital in adjusting the system into reactions according to the different contexts.

The data layer is responsible of aggregating the values from the sensing and the resources layers. Cleaning and transforming the data takes several stages to achieve a complete processing chain. The analytics and the knowledge extraction offers new visions for pattern’s design to accelerate the response of the system and made it more adequate to frequent situations.

The context extraction is associated with the context layer. It uses the context history provider and context background to raise the performance factor. The situation reasoner takes in consideration reasoning across time and space and across the user’s requirements. More details over the context extraction and the situation reasoner are presented in previous sections of this manuscript.

The service layer contains the processes and the services of the system that were built over the functionalities listed by the architects. The orchestration between the service and the choreography between the processes is maintained to avoid any lapse of functioning between the system’s components.

• •    Process & Services

‘’Process’’ and “Service” are two concepts used in our visions. These concepts are complementary views on the same capability of the system. A process sharpens the understanding for the operations, which gave the power to achieve a goal, using single of multiple tasks. Its performance influences the delivery of the goal. The service on its way can be seen as a black box where one or multiple processes can be performed to achieve the outcome of a service. The response time, the quality standards and the adequate performed tasks are all judged using the service outcome.

The autonomy of services has to be a major concern while implementing this RA. The interoperability cannot be achieved unless the services are independent. At the same level, it offers a better site for achieving new goals using a coupled number of services. It is highly recommended for developers to separate the services according to the goal models based on the system and the architecture requirements. To prevent the laps of repeated elements (which may raise the cost of the system) as well as the intersection of interest between the services (specially that this intersection might affect the time of response of the system).

In our vision, everything seems to be a process. A number of tasks are executed in a predetermined behavior to answer to a need. Each of the system services can be decomposed to a composition of processes, where services are bringing them all together. The feedback assimilation is an important element of the architecture to insure better reactions and interactions in future situations in addition to detecting failure or weak points of the AAL environment.

• •    Data Filtering & Data Flow

The data collected from the sensors and from other resources connected to the system is uncertain. The system has to embrace multiple functionalities that reduces the volume of the undesirable data collected by the devices. These processes have to be triggered and applied frequently to enhance the storing capacity. Learning from this data has to be a core functionality of the system to develop reliable patterns of incidence or situations [28].

The data flow in the AAL systems is exceptional. The collected values from the embedded sensors combined with the data aggregated from other resources made the filtering a complicated process. Our fusion model simplifies the processing and made it optimal in a matter of time and cost. Using several filters all across the processing will approve the validity of the decisions taking by the system. A recursive learning process is a mandatory one to keep the system up to date according to the changes that may appear in the stakeholder space.

• C.    The RA behavior view

The behavior view outlines the principle system behavior over all its operational contexts. It gives a clear path for the system analysis and drives the development activities. To reason about the system’s completeness the behavioral description can be used. The architectural view of the behavior provides support for managing the quality attributes of the system in the very early development process. The internal behavior of the system together with the interaction between its components ease the clarification for developers and help achieving all the defined requirements of the system.

This view illustrated by Fig.10 facilitates the communication between the architects and developers during the system design. The behavior of each component of the system influences its structure and its quality. With this view, we aim to decompose the vision of the system from a different approach.

We present a model using the simulation of standard actions all along with the flow of data from a component to another as well as time-related constraints, which we judge very important in AAL system’s architectures.

Fig.10. A scope of the behavioral vision of RAFAALS2.0

The initial behavior of the system starts with activating the system’s related devices. Sensing is the driving core of AAL spaces. When the system collects data from the sensing equipment, the processing chain is launched to assimilate the context and trigger the actions appropriate for responding to a specific goal. This behavioral vision is not the only presented one thus; we aim to develop many others in our further studies.

• V.    Conclusion

RAFAALS2.0 is an outright RA that coordinates the data flow between different layers. It grants an orchestration between different components of realistic AAL environment. In this paper, we processed the design of our vision of a standard, technology-independent and context-aware RA for AAL systems. We proposed three views starting from the overall structure of the architecture to the structural and behavior views. We illustrated all the aspects of the layers to indicate separated behaviors of the system while staying independent from any particular solution. All these elements require special attention while designing AAL systems.

In our future work, we aim to emphasize the role of the situation reasoner as well as the system’s response procedure. As an objective, we want to describe in details the steps from the data aggregation to the pattern’s developments, as we believe it is a mandatory element of an AAL system. The system’s middleware is also one of our major concerns and we will study it in future papers.