Distributed Interfaces and Context-oriented broadcast services in a smart-home

environment

José Manuel Negrete Ramı́rez∗ , Philippe Roose† , Marc Dalmau‡ ,

Université de Pau et des Pays de l’Adour
IUT de Bayonne - LIUPPA, Anglet, France 64600
∗ Email: jose-manuel.negrete-ramirez@univ-pau.fr
Email: {Philippe.Roose};‡ {Marc.Dalmau}@iutbayonne.univ-pau.fr
†

Abstract—In this paper, which describes a work in progress,
we wish to propose context aware service delivery, and we
focus on distributed human computer interface, in order to
exploit the variety of interaction mode/capabilities according
to current situation, users, and context. Our aim is providing
new kind of more dynamic interaction modes. We particularly
focus on the domain of smart-home (including digital health
home preoccupations). One objective is the use of distributed
interfaces associated to interactive services in order to help in
maintaining old people at home (Digital Health Smart Homes).
Keywords-Smart-Health; context modeling; context aware;
distributed interfaces
I. I NTRODUCTION
Currently, everybody wish to access to applications from
a wide variety of devices (PC, Tablet, Smartphone, Set-top-
box, etc.) in multiple situations, including various interac-
tions and modalities (mouse, tactile screen, voice, gesture
detection, etc.). At home, users interact with many devices
and get access to many multimedia oriented documents
(hosted on local drives, on cloud storage, online streaming,
etc.) in various situations and with multiple (and sometimes
at the same time) devices and interactions capabilities. In
this work-in-progress paper, we wish to propose context
aware service delivery, and we focus on distributed hu-
man computer interface in order to exploit the variety of
interaction mode/capabilities according to current situation,
users, and context. We aim at providing new kind of more
dynamic interaction modes (migration/duplication of parts
of graphical interfaces, dynamic modification of interaction
mode while applications are running). We particularly focus
on the domain of smart-home (including digital health home
preoccupations). One objective is the use of distributed
interfaces associated to interactive services in order to help
in maintaining old people at home (Digital Health Smart
Homes).
II. G ENERAL FRAMEWORK
The general framework of this work-in-progress paper
is shown in Figure 1. It will be explained throughout this
paper in order to introduce the proposal to the reader. The
framework includes eleven main components: a scenario (1)
designed under iCASA (2) with the help of the iPOJO (3)
components, Data collection (4) and Data storage (5), a list
of activities performed at home (6), the criteria required for
evaluating situations (7), a situation model (8) for identifying
and deducting situations from daily activities within the
home environment, a context model (9), a DSL (10) which
will integrate the different types of context information, and
the Kalimucho (11) middleware, which provides dynamic
service deployment and migration, for implementation.
III. R ELATED WORK
The approach of our work is focused on the field of smart
health, where topics related to interfaces, context manage-
ment, e-health, smart environments, dynamic deployment,
are present. We will offer a software architecture that will
allow to adapt the deployment of interactive services (in
order to help in maintaining old people at home). Therefore,
we will present the literature related to this latter.
Due to the fact that a context-aware system needs to
design the context information; important issues should be
taken into account. Ones are considered internal, such as
the system own awareness of current internal status and
capabilities; and some others are external concerning to the
real world, for example: place, time, user preferences and
needs [1].
In order to propose health-related applications enabling
elderly people to react, the application designer must be able
to desing such application. A Domain-Specific Language
(DSL) is an appropiate tool for this goal.
A textual Domain-Specific Language which is adapted
for modeling context information called MLContext, was
carried out by Hoyos et al. [2]. It has been implemented
by applying ModelDriven Development from context mo-
dels. A domain analysis has been applied for getting the
requirements and design choices in order to create the DSL.
The generative approach has been applied to two different
middleware platforms for context management: OCP [3]
and JCAF [4] middleware platforms. The advantages of ths
approach are that its DSL provides high level of abstraction
and the possibility of reusing context models. Moreover, the
language is easy lo learn. Neither adaptive services, which
should be built on top of any corresponding middleware, in
order to create complete ubiquitous computing applications;
 ❧✪✥ ✬✹ ✩✬✦✦✤✢★✩✜✧★✬✢ ✷✥❅★✩✥ ⑨❻❶
✁❈❉❊❉ ⑨❷❶
❨❙❩❲❘❙❬ ❧✪✥ ✬✹ ✴✜✧♠✯✬✬✦
✖✠✞✻✝✞✡✎ ♥❧✢♦✷✯✥✪✪★✢✣
☞✎✗✌✠☞ ❃✎✌☞✍✞☞✓ ✔✍✞☞✎✝✠✞✌✡✍✘❋ ✰✬✬♣★✢✣
▲✝●☛☞✞ ✒✝✎✞ ❪✝✞✠P ✵✜✧★✢✣
☞✎✗✌✠☞ ✾✻●☛✌✠✝✞✌✡✍✘ ✒✝✎✞✾P✡✍☞ ✖✠✞✌✗✌✞❍ ✞✎✝✠❫☞✎ q✜♣★✢✣ ✤✮
✛★✥ ✙✬r✢
☞✎✗✌✠☞ ✌✍✘✞✝✍✞✌✝✞✌✡✍ ☞✞❏✞✡✾ ❭✡✑ ❴☞✝✎✝●☛☞ ✘☞✍✘✡✎✘ ✚★✧✧★✢✣
☞✎✗✌✠☞ ✘✡☛✻✞✌✡✍ t✱✣★✥✢✥ ♥✤✯★✢✜✯✱ ✉ ✹✥✩✜✭ ✥✭✥✦★✢✜✧★✬✢♦
☞✎✗✌✠☞ ✓✌✘✠✡✗☞✎❍ ✰♠✜✢✣✥ ✬✢✥ ✮✬✪★✧★✬✢ ✧✬ ✜✢✬✧♠✥✯
✫✯✜❅✥✭ r★✧♠★✢ ✧♠✥ ✮✭✜✩✥ ✬✹ ✯✥✪★✷✥✢✩✥
s★✢✷ ✧♠✥✦✪✥✭❅✥✪ ★✢ ✧★✦✥ ✜✢✷ ✪✮✜✩✥
■✡✍❏✕✻✍✠✞✌✡✍✝☛ ✠✡✍✠☞✎✍✘ ✈✥✧✧★✢✣ ✬✤✧ ✹✯✬✦ ✯✥✪★✷✥✢✩✥ ♥♠✬✦✥♦
✛✬✣★✩✜✭ ✩✬✦✦✤✢★✩✜✧★✬✢✇ ✜✩✧★✢✣ ✜✢✷ ✴✥♠✜❅★✬✤✯
✟✡✍✞☞✑✞ ✔✍✕✡✎✒✝✞✌✡✍ ①✯✥✮✜✯✜✧★✬✢ ✜✢✷ ✩✬✢✷★✧★✬✢ ✬✹ ✦✥✜✭✪
✟✡✍✕✌✏✻✎✝✞✌✡✍ t✬✤✪✥ ✩♠✬✯✥✪
❡ ✐ ✖✠✞✌✗✌✞✌☞✘
❑☞✎✘✌✘✞✝✍✠☞ ❛❞ ❦ ①✯✥✪✩✯★✮✧★✬✢ ✜✢✷ ✦✜✢✜✣✥ ✧✯✥✜✧✦✥✢✧
❝ ❥ ②✤✱★✢✣ ✮✯✬✮✥✯✭✱ ✉ ❅✬✭✤✢✧✜✯★✭✱
☞✠✻✎✌✞❍ ❜ ❛
❛
❵ ❤✐ s✤✢ ✜✩✧★❅★✧★✥✪ ✜✭✬✢✥ ✬✯ ★✢ ✣✯✬✤✮
❣❢

⑨❼❶
❄✥✩✬✣✢★✧★✬✢ ✬✹ ✩✬✢✩✤✯✯✥✢✧
⑨❾❶ ✜✩✧★❅★✧★✥✪❆
✺ ✖✠✞✌✗✌✞✌☞✘ ❄✥✩✬✣✢★✧★✬✢ ✬✹ ★✢✧✥✯✭✥✜❅✥✷
⑨❸❶ ✆✝✞✝ ⑨❹❶ ⑨❺❶ ✟✡✍✞☞✑✞ ⑨❽❶
✌✞✻✝✞✌✡✍ ✜✩✧★❅★✧★✥✪❆
✞✡✎✌✍✏ ✒✡✓☞☛
✁✂✄☎✄ ✠✡☛☛☞✠✞✌✡✍ ❄✥✩✬✣✢★❇★✢✣ ✜✦✴★✣✤★✧✱ ✬✹
✆✝✞✝ ✼✡✓☞☛
★✢✧✥✯✮✯✥✧✜✧★✬✢ ✬✹ ✜✩✧★❅★✧★✥✪❆
❄✥✩✬✣✢★❇★✢✣ ✜✩✧★❅★✧★✥✪
✮✥✯✹✬✯✦✥✷ ✴✱ ✦✤✭✧★✮✭✥
✯✥✪★✷✥✢✧✪❆
✐ ❢
❦❝ ✐
❢ ❛ ✽✻✍✠✞✌✡✍✝☛
✐
❤⑥ ❦
❛ ⑤ ✠✡✒✾✡✍☞✍✞
✳✴✪✧✯✜✩✧ ✪✱✢✧✜✲ ⑤ ⑧ ✼✡✗☞✒☞✍✞
⑨⑩❿❶ ④ ❦ ✔✍✞☞✎✝✠✞✌✗☞
◗❘❙❚❯❱❲❳ ⑨⑩❶ ✛✜✢✣✤✜✣✥ ③ ⑦
✰✬✢✩✯✥✧✥ ✪✱✢✧✜✲ ✠✡✒✾✡✍☞✍✞
▲✌✒☞ ✙✚✛ ✚✥✦✜✢✧★✩✪
▼✍✗✌✎✡✍✒☞✍✞ ◆✘☞✍✘✡✎✘❖
✔✍P✝●✌✞✝✍✞✘ ✫✬✬✭ ✮✯✬✩✥✪✪
✆✝✞✝
⑨⑩⑩❶
✆✌✘✾☛✝✠☞✒☞✍✞ ✰✬✢✧✥✲✧ ✧✱✮✥✪ ✿✖❀✔✼❁✟❂❃
✵✜✪✱ ✧✬ ✤✪✥
✶✬✷✥✭ ✯✥✤✪✥
✸✢✷✥✮✥✢✷✥✢✧ ✹✯✬✦ ✜✮✮✭★✩✜✧★✬✢ ✷✬✦✜★✢
✶✬✷✥✭✪ ✬✹ ★✢✷✥✮✥✢✷✥✢✧ ✮✭✜✧✹✬✯✦✪

Figure 1. Integrated framework showing the components of the general architecture of our proposal.

nor also those related to context information (e.g. context context of each user is maintained, allowing users to be
discovery, reasoning), are considered in this work. aware of their neighbors and of the existence of content
The survey research of Raychoudhury et al. [5], provides that may be of interest for them. The main drawback
the identification of different design dimensions of pervasive found is that it needs to be extended on terms of the
computing middleware, and investigates its uses in various efficient management of heterogeneous context information
system services, which can be potentiallly helpful for our (mainly related to heterogeneous sensing devices), as well
approach. In-depth analysis of the system services have been as the implementation of services based on opportunistic
carried out, and middleware systems have been carefully computing.
studied. With a view to aid future middleware developers,
some challenging open research issues are also identified. The research of Lee et al. [8], focuses on a sensor-based
context-aware system with three inference processes: rule,
The work of Preuveneers et al. [6], relies on the feasibility
inference and pattern driven. An electrical lighting is used
of using HTML5 and related web application standards
as an example for demonstrating the proposed context-aware
for developing advanced mobile and context-aware health
system by using pattern data from five families for a working
self-care application, presenting as key features: context-
week and establishing rules and inferences. The processes
awareness and visualisation of multivariate data with pa-
to develop a smart home are described in order to improve
rallel coordinates for decision support for certain activity
the personalized services to meet the needs of residents.
recognition, visualization and security features; by means of
However, it is still required to implement the framework
a diabetes monitoring application as a practical use case.
with more complicated scenarios and construct the ubiqui-
Results are indicated through detection devices, helping to
tous residential environments with a verified context-aware
prevent the beginning of serious health issues. This system
inference system.
uses context awareness smoothly and proactively. The only
disadvantage is that it is necessary to mitigate performance The research of Bricon-Souf and Newman [9] consists
concerns with computationally expensive code. on a review on how context-awareness is applied in various
CAMEO, a light-weight context-aware middleware plat- healthcare projects that may be relevant for the reader, in
form for mobile devices, is introduced by Arnaboldi et al. order to extend his knowlodge about the subject matter. A
[7]. it is designed to support the development of real-time requirement management approach is also described in [10].
mobile social network application; to collect and reason
about multidimensional context information derived by the The remainder of this paper is structured as follows:
local device, the local user, and their physical interactions Section IV is a presentation of benefits of using iCASA tool
with other devices and users. It provides a common ap- for seeting up a daily living scenario for the elderly. The
plication programming interface to mobile social network general architecture of our approach is presented in Section
applications through which context- and social-aware func- V, and Section VI contains conclusion and brief discussion
tionalities can be exploited to optimize their features. The of this wok-in-progress paper.
 IV. I CASA
A. Scenario
iCASA [11], is a smart home simulator which allows
to have control over: time, environment, inhabitants, de-
vices, a graphical user interface, scripting facilities (for
the environment), notification facilities [14], as shown in
Table I. iCASA is used in order to set up a simulated
scenario. The purpose of employing iCASA, which is based
on OSGi [12] and iPOJO [13], is that it takes advantage of
the versatility and dynamism of the two latter, which are
provided as a set of modules and components (e.g. bundles
and iPOJO components) that are deployed on a OSGi/iPOJO
framework.
Table I
ICASA TABLE
Time Possibility to slow down, speed up or stop time during
the simulation. Simulation of long-term actions such as
as energy consumption to skip to important actions.
Environment Definition of different zones in a house. An administra-
tion interface to modify different physical properties
(temperature, luminosity, etc.) of the different zones,
is provided.
Inhabitants Insertion or removal inhabitants from the environment.
Inhabitants, can move from zone to zone, may be
carrying physical devices.
Devices Devices can be simulated or real. At any time, the user
can add or remove new simulated devices and modify
their localisation in the rooms.
A graphical The interface displays a map of the house and the
user interface localisation of the different devices. It allows to create
and configure devices, create and move physical users
and watch their actual configurations.
Scripting facilities Support to the scripts writing to control the
environment. Scripts provide a convenient way to test
the applications under reproducible conditions.
Notifications iCASA is event-based and is able to notify subscribers
facilities of any modifications in the environment.
A data file with the information of the activities that
were performed for the inhabitants of the simulated environ-
ment will be returned. Information such as location of the
inhabitant(s) within the home environment, date and time
about the performed activities, among other relevant data;
by means of simulated sensors which will allow to identify
several situations, i.e.: sensors involving light within rooms,
temperature, fridge door, flush mechanism of the bathroom.
Such information will be recovered in the file previously
mentioned. It will help to collect the information from the
simulated activities on the iCASA platform. Subsequently,
the information previously mentioned will be used to deduct
situations.
iCASA, a smart home environment simulator was intro-
duced to the reader in order to describe how a scenario will
be set up. Relevant information that will help to deduct situa-
tions subsequently will be obtained. The general architecture
of our proposal will be described in the following section.
V. G ENERAL A RCHITECTURE
We will offer a software architecture that will allow to
adapt the deployment. Therefore, we will present the tools
related to this latter, which include topics related to inter-
faces, context management, e-health, smart environments,
dynamic deployment. The previous aspects will be included
in the next subsections, where the roles of activities of
daily living, determining situation types, a situation model,
a context model and the Kalimucho middleware, will be
explained in order to describe how our architecture will
achieve the deployment adaptation.
A. Activities
A list of possible activities is necessary as a preliminary
inventory. Such inventory will be used as a tool that is
going to permit us determining different types of situations
in the beginning; only then, these situations will be part of a
situation model and a context model that will help to deduct
new situations.
Wilde [15] conceived an activity as a systemic whole in
which all elements have a relationship to other elements, It is
also stated that in the reality, an activity requires contextual
information, from other related activities (whether it is in
terms of time, space, etc.), and that the activity is in itself
contextual information for other activities.
A list of possible activities will be required, it will be
considered as an inventory which will be used as a tool in
the beginning. Such inventory will play an important role for
identifying different types of situations. It will be necessary
to infer (based on data from iCASA) the possible activities
that will be performed.
Due to the fact that not all the activities are at the same
level, in order to make them suitable for different kind of
situations, a categorization is proposed in Table II. Those are
based on the AGGIR [16] grid (which classifies autonomy
levels to various environmental factors affecting a person’s
activities and social life); which is currently the legal tool
in France for measuring the autonomy of the elderly.
Among the activities related to home care of people, we
will consider:
• Relevance: With reference to the frequency of occur-
rence of an activity, i.e. the times that the inhabitant
eats per day.
• Right criteria: Localisation, history and time: for de-
tection of parameters of the elderly activities within
the home environment.
• Recurrence of an activity: for identifying which activi-
ties that take place in the storyline can be considered
logic or not; i. e. the fact that the inhabitant eats times
per day can not be considerd as logic.
 Table II
C ATEGORISATION OF ACTIVITIES
Hygiene Use of bathroom, (un)dressing, urinary/fecal elimination
Living at home Use of communication devices
Feeding Cooking, eating, preparation and condition of meals,
house chores.
Moving at home Wake up, lie down, sitting, change from one position to
another, travel within the place of residence.
Orientation Find themselves in time and space.
Coherence Logical communication, aging and behaviour, prescription
and manage of medical treatement, buying properly/
voluntarily, fun activities alone or in group.
• Interleaved activities: for determining if the perfor-
mance of an activity will be affected if another one
needs to be carried out; and that those activities do not
overlap each other; i. e. if the inhabitant stops cooking
to attend a phone call. Once it is over, he continues
cooking.
For determining the situations we have proposed the
following criteria: Geography, history and time. Over this
latter, we can also find:
• Concurrency: For recognizing activities which take
place simultaneously, but they do not necessarily re-
quire the user’s interaction at the same time. That is,
activities that have been started but not yet ended by
the inhabitant [17].
• Precedence: For establishing a logical order of the
activities, i.e. going to the bathroom; and then washing
his hands.
• Simultaneity: For identifying which activity takes most
of the time from the user, when multitasking capabi-
lities might be present, i.e. preparing meal and calling
on the phone; or watching television while eating.
• Recurrence: For determining a logical sequences of
situations.
Where the useful information considered relevant is time
and geography, because these two latter will provide in-
formation of the actvity type. We can take the performed
activities once, twice, etc., and place them into the history
records. Then, it would be possible to infer when they are
going to occur next time.
A list of possible activities will be required, as a preli-
minary inventory that is going to be used as a tool in the
beginning. Then, these activities will allow us to determine
different types of situations.
A description of the activites which are going to be used in
our approach has been presented, in which a categorisation
is also shown, in order to set a prelimitary inventory that
will help to deduct different types of situations.
B. Situation types
Different types of situations will be recovered from data
related to activities. How they will be obtained from spatio-
temporal data, as well as a history of previous activities, will
be pointed out in the following paragraphs.
Simultaneous activities (which occur at the same time) can
appear, if those activities are concurrent, it can be assumed
that they are incompatible. For instances, watching TV while
eating might not represent an important issue. But it would
be the opposite case if the shower is on and the inhabitant
is eating.
It is necessary to keep history of all the activities per-
formed by the users, due to the fact that there can be
differences among the activities occurred; because there are
those that are instant activities and there are others that last.
An instant activity is not necessarily instantaneous. That is
the reason why keeping a log file able to precise whether an
activity begins or ends, will help to manage which activity
has begun, or which activity has already ended; or to specify
that an activity has already begun, while in the meantime
there is another one that occurs and that it is not finished yet.
We also consider the logical aspect to describe situations,
For example, if you are eating and it’s noon, it is logical,
therefore, there are no alerts to propose; but the fact that
you’re eating in the toilet is not logical.
The sources for establishing the criteria to determine rules
for the examples of the previous paragraph, are: time and
place, and within time, we also have: sequence, precedence,
recurrence, simultaneity.
In the case where there is a recurrence of an activity, it
is essential to define where this activity comes up regularly;
for instances, the fact that someone eats ten times in one
day can not be considered very logic.
It is possible to have situations that are not logical, one
activity after another that is not considered normal, for
example: do the dishes and then eat.
What can be done is that when it is necessary to deduct
(from families of activities), from here, the possible activities
will be inferred. For this issue, we imagine the use of fuzzy
logic, combined with a workflow of activities.
Fuzzy logic is a solution for reasoning similarly to a
human being when ambiguity is present. A fuzzy set is
characterized by its membership function that calculates the
degree of membership of an element of the universe to the
fuzzy set. The most commonly used range of values of
membership functions is the unit interval [0,1] [18]; whereas
in the classical set theory, membership of an element is 0
or 1.
At this point, these tools will have to take into account a
temporal and localisation history (of previous probabilities)
and also new probabilities, to try to infer a situation with
a known probability. For example: in the history logs, two
activities were performed at the same time several occasions
before, with a probability of 90%; but it’s worrying If such
activity is performed with a probability of 3% later. For
example: if the inhabitant does not eat, and does not go
to the bathroom either; then he begins to prepare meal and
after he goes straight to the toilet; he is suposed to have meal
when he comes back. But, instead, the time he spent in the
toilet is more than 15 minutes, then, there is the possibility
that he is about to eat in the bathroom. With fuzzy logic, all
the issues presented in the environment should not be noticed
either too often, and warning situations that are important
must not be missed out. It is not necessary to raise an alert
when there is no need. Fuzzy logic can be used to describe
an imprecise logical system, in which the truth-values are
fuzzy subsets of the unit interval with linguistic labels such
as true, false, not true, very true, quite true, not very true
and not very false [19].
the process how situation types will be obtained was
explained in the previous paragraphs. It also discussed how
data related to localisation, time and a history of activities
play an important role on prediction of activities. Those si-
tuation types will take part in the modelisation of situations.
C. Situation model
There is a notion of time that appears throughout the
whole process, because time goes by in every case, where
we constantly analyze every situation where the person is
performing a task. In addition, geography (space), plays a
very important role, because very litlle can be accomplished
without considering where and when the meaningful situa-
tions occur [20].
It is necessary to find an algorithm that identifies the
current activity, being cautious with the disambiguation of
activities, and also taking into account the task of predicting
situations. Letting this algorithm to create a tendency for
knowing which activities would be performed before or after
another one. We must have a good idea of the possible
order in which activities can performed daily/weekly by
every inhabitant, because sequence between activities can
be present; there could also be overlays in the storyline of
the activities performed, as well as certain tasks that are not
correct at a certain point in time, for example: eating in the
middle of the night.
At one point, where one person is about to perform
a specific activity, the algorithm would return a sum of
activities, but it is not sure they are exclusive, i. e., if the
inhabitant eats, then, he is not trying to wash. However, if
he eats at the same time that he is washing; or if the shower
is on and he is about to eat; then, there could be a problem.
Each situation has a sum of parameters, we should
associate each and everytime a kind of validity intervals:
geographic and temporal, but they will be from the same
type. In fact, for the meal, example we would have a kind
of probability curve during a specific period of time: meal
time between 12 and 14 hours present the same probability,
however, if the person eats in advance, or if he has postponed
it, the probability decreases.
The probability will prevail if the meal takes place into the
dining room, kitchen, the living room, But if it takes place
in the bedroom or the bathroom, the probability decreases.
It is necessary to study every situation in order to get
them identified, by associating time and place for each and
every of them. Those will be used subsequently by a context
model, which is introduced to the reader on the following
paragraphs.
D. Context model
Dey et al. [21], consider that context information is any
information related to the use of characterization of the
situation of any entity. This latter could be a person, a place,
a physical or abstract object, or an event that is considered
relevant to the interaction between a user and an application,
including the user himself.
It is necesarry to consider that the information which is
part of a context may come from several sources, such as
a sensor, a tablet or smartphone, etc.; and that those may
also require different formats to represent the information
they provide. There is a gap between sensor output and the
abstraction level of the useful information for applications,
and this gap may be bridged by various types of context
information processing as explained by Henricksen et al.
[22]. In addition, contextual information should be modeled
at a high level of abstraction, near the user-level, preferring
to mantain the ease of use, over the optimal efficiency, as
indicated by Vildjiounaite and Kallio [23].
Göker and Myrhaug [24] indicated that a context model
should normally include information on temporal and spa-
tial aspects. Spatial information describes concepts such
as location, direction or places. Temporal aspects can be
characterized as static or dynamic. The value of static
information remains unchanged over time while the value
of dynamic information may vary depending on the time
instant it is requested.
When modeling context, it is required to establish a
difference among different types of context information [2],
so that a taxonomy is useful to model the concepts. However,
some current approaches do not define such a taxonomy.
They rather define a single type of context, no matter what
type of context information they are handling [22], [23].
Some taxonomies have been proposed such as [24], [25],
and when they are compared, it is found that the social
context or the physical context are common in most of the
the approaches,
Henricksen et al. [22] stated that “context information is
imperfect” and the system must assure information reliability
and availability (as much as possible). The user profile and
the context history are also considered [26].
A context model will be necessary, because it will provide,
parting from data and information previously recorded in
history file, a list of potential activities; and alongside with
the use of certain rules, we will get to define a situation. The
proposed context model is shown in figure 2. In addition,
the types for the context information for the approach that
we propose are summarised in Table III; where information
for each type is suggested.
✙✄✚✎✛✂✄✟✆✄☎
✜✑✍✢ ✥✂✏✎✑✡
✁✂✄☎✆✝☎
✒ ✞✓ ✦✑✄✠✎✏✑✣✣✆✠
✔✓✕✖✗✘✞ ✟✂✠✆✡
✙✡✠✆✛✡✌ ☛☞✌✍✎✏✑✡
✁✂✟✣✤☎✑☎✎✂✄✑✡
Figure 2. Context Model
Table III
T YPES OF CONTEXT INFORMATION
Physical Information obtained by exploiting pervasive devices
(i.e. time, temperature, light level, etc.); for deducing
context events from activity recognition.
Environment/ Comprehending information on the people and objects
Space nearby the user (i.e. location, distance): for asking for
help to the nearest person related to the inhabitant in
case of emergency need.
Computational This source provides information from software and
hardware systems (i.e. hardware status, network conditions,
etc.): for assuring operational effectiveness of the technolo-
gy equipment, deployment / network availability.
Personal Information describing the profile of the person/user
(i.e. competences, preferences, age, gender, illness,
physical, mental, or emotional disabilities, etc.).
Social Data that describes ths social condition of the user (i.e.
individual interests, preferences, and the activities within
his social environment, for opening new ways to interact
with other people).
Tasks/chores Information about the different tasks the user can carry out
(i.e. activities that need to be performed, those that are
currently being performed, chores that the user is able to
execute). For reminding when to eat, to take medicines
and/or regular health checks, etc.
Elderly / Information related to elderly / people with special needs
Handicapped or disabilities; in order to fulfill their health care
expectations in the in the best way possible.
In the context model we find a list of activities we have
proposed and some others that are deducted. The context
model will identify one/several of the proposed activities,
and it will indicate in which situation the person is; i. e. the
inhabitant is currently eating, sleeping, etc., and therefore,
it will provide whether it is a kind of situation/situations
or a sum of activities, which will be equal to a situation.
Information will be recovered about all the activities that
the user performs, what the user does in a specific time of
the day, and what he is about to do as next task. Then, this
information will be taken into account into the historic log
file. Moreover, it will be important to consider data related
to the temporal aspect for future references, i.e., start time
of a determined activity, as well as its end time. This may
develop new conclusions based on existing activities.
E. DSL requirements
The context model is described by a DSL. We need to
be able to express to situations that respond to the fields
of persons with a physical or mental disability, support
for elderly, diseases connected to aging. According to the
proposed context model, it is also indicated a need for a DSL
which will now consider the integration of different types of
context information: physical, environment, computational,
personal, social, tasks. The types for the context information
for the approach that we propose are summarised in Table
III; where information for each type is suggested.
The use of the proposed DSL will make possible to write
textual specifications. The requirements for this latter are
listed in Table IV.
Table IV
DSL R EQUIREMENTS
Context types In order to be close to reality, the language should
handle different types of context (i.e. physical,
social, computational) (see Table III).
Ease of use Easy and intuitive language in order to be used, so
that users will be able to write / understand.
Model reuse The language should allow the reuse of context
models by different context-aware applications.
Independence from The language should allow the modelisation of
application domain contexts despite of the context application.
Model of independent Implementation details should not be carried out by
platforms the user.
Implementation will be explained in the next paragraphs,
where services will be deployed by means of the Kalimucho
middleware.
F. Kalimucho middleware
The Kalimucho middleware [27] allows dynamic deploy-
ment and migration. It also integrates another competences
such as distributed interactions [28]; and Health domain
[29].
 Kalimucho is a software platform for mobile and embed-
ded hardware. Kalimucho uses service factory enabling the
creation of instances of software components. This factory
allows making the most suitable configuration according
to services decision managing reconfiguration. The recon-
figuration service decisions depend on data sent by control
interfaces and the users defined rules (via the platform and
control interfaces).
The aim is to monitor elderly people who are at home,
so when some incoherent behaviour is detected at their own
environment, applications will be deployed, whether it is
on TV, on a tablet, etc.; in order to force the person to
interact with the device, focusing on the needs of the elderly
individual, thus enabling coherence in their interventions.
The objective is to dynamically deploy from health
services on the set top box, smartphone, tablet, desktop
computer, television, among other smart devices; according
to profiles and data received from sensors. The deployed
applications will dynamically adapt itself according to smart
devices availability, including its business logic as well as
its interactions with users.
The challenge is to discover and to select the best available
services, as a response to a given event or demand, to
make the association of reconfigurable services, according to
different situations and to ensure the continuity of services,
whatever the context of the resident or the home capabilities
are, from medical assistance to keeping a social contact to
combat the feelings of loneliness. in order to identify the
different possible scenarios that will be considered and used
to validate the different technical.
Useful cases and situations related to the daily life of an
elderly or dependent person will be considered in the form
of one or more detailed scenarios, i.e.:
• In a case when the health smart home detects an
urgent event like a fall or a heart attack, some actions
must be taken rapidly, as a response to the event:
contacting a qualified person to confirm the alert and
then calling the emergency telephone number if needed.
This type of service may require the consultation of
some data stored in several databases or to perform
some mappings between a set of data obtained from
different sources, such as repository services, contact
lists related to the resident, their availabilities, their
addresses or their positions.
Therefore, several contextual parameters will be consi-
dered to refine the contact establishment with the exter-
nal environment as a response to an alert. The provided
service has to avoid systematic calls to emergency when
it is not necessary. The system should be able to identify
which person/people to contact, depending on the kind
of incident and the availability of the people registered
in some databases and having a relationship with the
resident. The system could identify categories of people
who are able to intervene (neighbor, relative, skilled
health provider) with a preference order. According to
these priorities, and contacts availabilities, one or more
contacts will be informed (phone call, sms, email).
Actually, a contact with a higher priority will be notified
first. In case of unavailability, the system will try to
contact the next one.
• A service for notification about when it is necessary
to take medicines (drug reminder) would be another
suitable example of use. The drug reminder would be
a local service which is very useful depending on the
inhabitant profile, such as those suffering from certain
diseases (i.e. alzheimer). Thus, when provided, this
service will be in charge of reminding the resident the
drugs that must be taken, as ordered by doctors during
daytime. Such service may be based on contextual data
stored locally at the home box/gateway (where data can
be easily updated). This service could be provided using
any media formats (e.g., text, HTML, audio, video) and
its implementation should be adaptable.
Kalimucho was presented to the reader in order to under-
stand how the architecture we propose will be implemented.
Due to the fact that we will work with an open architecture,
we will be able to apply it to the home care support, by using
the AGGIR grid, but we can also use it for other categories,
i.e. for deaf handicaps, or for specific diseases, by means of
reprogramming applications, but using the same architecture.
VI. C ONCLUSION
In this work-in-progress paper, we introduced to the reader
a proposal context aware service delivery, in which a general
framework of the architecture was explained; as well as
some other important aspects that are described throught
the lecture, such as: a review of related work, the tools
employed for generating case scenarios (iCASA, iPOJO), a
description of the general architecture with each and every
one of its components of our proposal: activities, situation
types, situation model, context model and the Kalimucho
middleware. With this latter, we focus on distributed hu-
man computer interface in order to exploit the variety of
interaction mode/capabilities according to current situation,
users, and context. We aim at providing new kind of more
dynamic interaction modes (migration/duplication of parts
of graphical interfaces, dynamic modification of interaction
mode while applications are running). We particularly focus
on the domain of smart-home (including digital health home
preoccupations). One objective is the use of distributed
interfaces associated to interactive services in order to help
in maintaining old people at home (Digital Health Smart
Homes).
ACKNOWLEDGMENT
This work is supported by the CONACyT.
 R EFERENCES
[1] D. Kramer, J. C. Augusto, and T. Clark, “Context-awareness to
increase inclusion of people with ds in society,” in Workshops
at the Twenty-Eighth AAAI Conference on Artificial Intelli-
gence, 2014.
[2] J. R. Hoyos, J. Garcı́a-Molina, and J. A. Botı́a, “A domain-
specific language for context modeling in context-aware sys-
tems,” Journal of Systems and Software, vol. 86, no. 11, pp.
2890-2905, 2013.
[3] J. A. Botia, A. Villa, J. T. Palma, D. Pérez, and E. Iborra,
“Detecting domestic problems of elderly people: simple and
unobstrusive sensors to generate the context of the attended,” in
International Work-Conference on Artificial Neural Networks,
2009, pp. 819-826.
[4] J. E. Bardram, “The java context awareness framework
(JCAF)-a service infrastructure and programming framework
for context-aware applications,” in International Conference on
Pervasive Computing, 2005, pp. 98-115.
[5] V. Raychoudhury, J. Cao, M. Kumar, and D. Zhang, “Middle-
ware for pervasive computing: A survey,” Pervasive and Mobile
Computing, vol. 9, no. 2, pp. 177-200, 2013.
[6] D. Preuveneers, Y. Berbers, and W. Joosen, “The future of
mobile e-health application development: exploring HTML5
for a context-aware diabetes monitoring assistant,” in 3rd
International Conference on Current and Future Trends of
Information and Communication Technologies in Healthcare,
2013.
[7] V. Arnaboldi, M. Conti, and F. Delmastro, “CAMEO: A novel
context-aware middleware for opportunistic mobile social net-
works,” Pervasive and Mobile Computing, vol. 11, pp. 148-
167, 2014.
[8] J. H. Lee, H. Lee, M. J. Kim, X. Wang, and P. E. Love,
“Context-aware inference in ubiquitous residential environ-
ments,” Computers in Industry, vol. 65, no. 1, pp. 148-157,
2014.
[9] N. Bricon-Souf and C. R. Newman, “Context awareness in
health care: A review,” international journal of medical infor-
matics, vol. 76, no. 1, pp. 212, 2007.
[10] J.-J. Chen, W.-C. Su, P.-W. Wang, and H.-C. Yen, “A CMMI-
based approach for medical software project life cycle study,”
SpringerPlus, vol. 2, no. 1, p. 1, 2013.
[11] P. Lalanda, C. Hamon, T. Leveque, and others, “iCasa, a
development and simulation environment for pervasive home
applications”, in 2014 IEEE 11th Consumer Communications
and Networking Conference (CCNC), 2014.
[12] Osg. Alliance, “OSGi Alliance: OSGi Service Platform, Core
Specification, Release 4, Version 4.2,” OSGi Alliance, 2009.
[13] C. Escoffier, R. S. Hall, and P. Lalanda, “iPOJO: An extensi-
ble service-oriented component framework,” in IEEE Interna-
tional Conference on Services Computing (SCC 2007), 2007,
pp. 474-481.
[14] P. Lalanda, J. A. McCann, and A. Diaconescu, Autonomic
Computing. Springer, 2013.
[15] A. G. Wilde, “An overview of human activity detection
technologies for pervasive systems,” Department of Informatics
University of Fribourg, Switzerland, vol. 212, 2010.
[16] J. Vetel, “AGGIR: guide pratique pour la codification des
variables,” Rev. Geriatrie, vol. 3, pp. 249-259, 1994.
[17] R. Helaoui, M. Niepert, and H. Stuckenschmidt, “ Recogniz-
ing interleaved and concurrent activities: A statistical-relational
approach,” in Pervasive Computing and Communications (Per-
Com), 2011 IEEE International Conference on, 2011, pp. 1-9.
[18] G. Klir and B. Yuan, “Fuzzy sets and fuzzy logic”, vol. 4.
Prentice hall New Jersey, 1995.
[19] L. A. Zadeh, “Fuzzy logic and approximate reasoning,”
Synthese, vol. 30, no. 34, pp. 407-428, 1975.
[20] D. J. Cook, J. C. Augusto, and V. R. Jakkula, “Ambient
intelligence: Technologies, applications, and opportunities,”
Pervasive and Mobile Computing, vol. 5, no. 4, pp. 277-298,
2009.
[21] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith,
and P. Steggles, Towards a better understanding of context and
context-awareness, in International Symposium on Handheld
and Ubiquitous Computing, 1999, pp. 304-307.
[22] K. Henricksen, J. Indulska, and A. Rakotonirainy, “Mode-
ling context information in pervasive computing systems,” in
International Conference on Pervasive Computing, 2002, pp.
167-180.
[23] E. Vildjiounaite and S. Kallio, “A layered approach to
context-dependent user modelling,” in European Conference
on Information Retrieval, 2007, pp. 749-752.
[24] A. Göker and H. I. Myrhaug, “User context and person-
alisation,” in Workshop proceedings for the 6th European
Conference on Case Based Reasoning, 2002.
[25] L. Ardissono, R. Furnari, A. Goy, G. Petrone, and M. Segnan,
“Context-aware workflow management,in International Con-
ference on Web Engineering, 2007, pp. 47-52.
[26] J. Hong, E.-H. Suh, J. Kim, and S. Kim, ”Context-aware
system for proactive personalized service based on context
history,“ Expert Systems with Applications, vol. 36, no. 4, pp.
7448-7457, 2009.
[27] K. Da, M. Dalmau, and P. Roose, ”Kalimucho: Middleware
for mobile applications,“ in Proceedings of the 29th Annual
ACM Symposium on Applied Computing, 2014, pp. 413-419.
[28] R. Karchoud, P. Roose, M. Dalmau, I. de Courchelle, and
P. Dibon, ”Kalimucho for smart-: One step towards eternal
applications,“ in Industrial Technology (ICIT), 2015 IEEE
International Conference on, 2015, pp. 2426-2432.
[29] T. Lemlouma, S. Laborie, and P. Roose, ”Toward a context-
aware and automatic evaluation of elderly dependency in smart
homes and cities,“ in World of Wireless, Mobile and Multi-
media Networks (WoWMoM), 2013 IEEE 14th International
Symposium and Workshops on a, 2013, pp. 1-6.