Situation-awareness as a Key for Proactive Actions
in Ambient Assisted Living
Alencar Machado
1,2
, Ana Marilza Pernas
4
, Iara Augustin
3
, Lucinéia Heloisa Thom
1
,
Leandro Krug Wives
1
and José Palazzo Moreira de Oliveira
1
1
PPGC, Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, Brazil
2
Politécnico, Universidade Federal de Santa Maria (UFSM), Santa Maria, Brazil
3
Programa de Pós-Graduação em Informática, Universidade Federal de Santa Maria (UFSM), Santa Maria, Brazil
4
Centro de Desenvolvimento Tecnológico, Universidade Federal de Pelotas (UFPEL), Pelotas, Brazil
Keywords: Situation-aware, Ambient Assisted Living, Context-aware, Proactive Actions.
Abstract: With the augmentation of population's life expectancy as a whole, there is a need for intelligent applications
to assist citizens in their daily activities. Ambient Assisted Living – AAL – are emerging as a way to allow
technology and medical assistance to help people who need special supervision, providing support to medi-
cal emergencies. AAL are equipped with ubiquitous technologies, and use sensors as their main element for
environmental data collection, providing systems with updated information. To offer personal home assis-
tance, these computer-supported environments detect situations of interest such as the patient´s current
health state, and proactively act to adapt the home environment accordingly to the patient´s specific needs.
This paper presents results from an approach to support adaptive behavior in AAL. In particular, we discuss
the design of intelligent systems for monitoring and adaptation of AAL. Additionally, we describe a mid-
dleware for the management of pervasive applications, which is capable of detecting the current situation of
a citizen and identifying the most suitable action.
1 INTRODUCTION
Recent studies show that population is aging (Chris-
tensen et al., 2009). Diseases associated with ageing
or decreased ability to perform individual activities
make people with reduced cognition more prone to
risky situations in their daily activities. Proactive
Ambient Intelligence could improve the quality of
life in a residence, providing a semi-automated as-
sistance for people who reside in it. Ambient Assist-
ed Living (AAL) are environments equipped with
ubiquitous technologies, which provide technology
in a non-invasive way, offering contextual data
needed to achieve environment´s adaptations that are
specific to personal preferences (Sun et al., 2009).
The inclusion of context-aware systems (Dey and
Abowd, 2006) in AAL makes these systems more
intelligent, proactive and reactive to support the life
of citizens with decreased cognitive ability. The
identification of the current citizen’s situation in
different contexts helps the adaptation of environ-
ments to individual features. Situation-aware behav-
ior is especially useful in AAL, where the situation
abstraction allows the modeler or pervasive applica-
tion (appPerv) designer to manage each piece of the
world being represented in order to deduce the spe-
cific situations in which each entity being evaluated
is, or to detect a situation change (Ye et al., 2012).
To design situation-aware applications in AAL,
it is necessary to model the infrastructure of these
environments. Thus, this paper presents a conceptual
model to determine the vision of world for appPerv,
allowing triggering proactive actions according to
the situations detected. To enable these features, we
developed a middleware that provides the manage-
ment of SItuations as a Service (SIaaS) for any ap-
pPerv being developed. The proposed SIaaS mid-
dleware is able to manage the context and the situa-
tions of interest for an appPerv. We also developed a
solution to build generic appPerv (deployed in SI-
aaS) to be executed in specific domains.
We have applied our approach in a specific case
study that is based on an agitation behavior model.
In fact, it is a process model that describes an elderly
person presenting mood and behavior changes. In
418
Machado A., Marilza Pernas A., Augustin I., Heloisa Thom L., Krug Wives L. and Palazzo Moreira de Oliveira J..
Situation-awareness as a Key for Proactive Actions in Ambient Assisted Living.
DOI: 10.5220/0004418004180426
In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 418-426
ISBN: 978-989-8565-60-0
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
particular, an appPerv based on this process model
was implemented. To support appPerv, we have
implemented a SIaaS prototype. The prototype can
detect situations of interest defined by the appPerv
and is able to send proactive actions supported by
simulated environment. This paper is organized as
follows: section 2 discusses our vision of ubiquitous
environments; section 3 presents the proposed archi-
tecture for deploying and running appPerv based on
our approach; section 4 presents the appPerv devel-
oped to analyze the case study already discussed;
section 5 present our conclusions and future work.
2 UBIQUITOUS
ENVIRONMENTS
In a ubiquitous environment, sensors represent ob-
jects in the world. In this work, the worldview is
obtained by information captured by the sensors but
the action in the world is achieved by functionalities
implemented as Web services that are embedded in
objects as mobile phones, televisions, microwave
ovens, among other incorporated in the environment.
The ubiquitous environment can be characterized
as a flow for aggregation of data that the sensors
collect, thus seeking to express what is happening.
From a high-level of aggregation, called as “situa-
tion”, it is possible to act on the environment
through capabilities that electronics provide, thus
seeking to automate the environment according to
the detected situation and preferences of citizens.
Figure 1: Viewing and Acting in the World.
These concepts are represented in Figure 1, where
the arrow means the flow for: (i) aggregate raw data
collected from sensors, to (ii) process this data, and
to (iii) infer the world and the current situation. The
part most accentuated of the curved arrow (Situa-
tion/Proactivity) contains algorithms that employ the
services to act proactively in the environment ac-
cording to a detected situation. These algorithms are
inside the appPerv
and implement solutions for
managing specific situations.
2.1 Defining Situation
Proactive systems in smart environments act on
behalf of the user. The key problems of proactivity
in computer-supported systems are (i) to meet ade-
quately and satisfactorily the needs of the user,
without explicitly or intrusively showing this control
and (ii) to allow users to maintain the perception of
control about the environment. To meet these re-
quirements, we consider situation-awareness as the
key element for designing the system.
To ensure an accurate understanding of the pro-
posed model and how the user’s situation is repre-
sented, some definitions are illustrated in Figure 2
and explained as: Sensor (S): According to Compton
et al. (2009), sensors are observers of the physical
quality (temperature, depth, among others) of a re-
source; they also publish these observations. These
are represented in Figure 2 by rectangles; Context
Data (D): Raw data captured from the environment
without semantic characterization. These data con-
nected to an entity become abstract or physical qual-
ity. In Figure 2, context data is represented by solid
circles; Entity (E): Concrete or abstract concepts
used to reason about a domain of interest. For exam-
ple: person, place, time, sensor, electronic device
and appliance. They are the source under which data
is captured and contextualized Entities are repre-
sented by circles with the letter E inside, in Figure 2.
Dey and Abowd (2006) characterize context as
the situation of an entity. In the present work, the
environment is represented by a set of entities and
their semantic relations which characterize the con-
text of the environment. All appPerv that make sub-
scriptions in the proposed SIaaS middleware are
interested in a subset of the context, which is known
as the context of interest of an appPerv, as shown in
Figure 2. The context of interest of an application is
all contextualized data (entities and their data) and
their semantic relationships. Following this defini-
tion, each appPerv has its special Context of Interest
(C), which represents a group of semantic relations
that are valid in a specific moment.
Thus, we represent the context of interest from a
specific appPerv by the following statement (1):
C: (app, {R})
(1)
Where: (C) Context of Interest; (app) a specific
appPerv; {R} consists of a set of semantic relations,
each one represented by <Es, P, Eo> where Es
Situation-awarenessasaKeyforProactiveActionsinAmbientAssistedLiving
419
Figure 2: Representation of Ambient, Situation, Context,
Context Data, Sensor and semantic relations.
are entities that are contextualized and are the sub-
ject of the relationship; P are predicates (relations)
and Eo are entities that are and are the object of the
relationship. Therefore, the context of interest is a
subset of contextualized data (entities, their data and
semantic relations) and the application itself, i.e. the
information of interest to an application for making
decision on which proactive action triggers.
A situation of interest is viewed as the state of
the entities that characterize an event in the envi-
ronment. It is composed by {R} and logical rules {L}
that, when evaluated to true, characterize a fact in
the environment. A situation is formally represented
by the following statement (2):
S: (app, {R}, {L})
(2)
Where (S) Situation of Interest; (app) represents a
specific appPerv; {R} set of semantic relations pre-
sented in (1) and {L} logical rules. The logical rules
{L} are defined according to each situation, and are
related with specific values that are relevant in the
activity of AAL. For example: heartbeat > 100 per
minute. A formalized situation rule {L} related with
the ontology build for this work (in OWL language)
is presented inside the Environmental Architecture,
in subsection 3.2.
2.2 Defining of Proactive Actions
and Services
An environment can be impregnated of sensors for
data collection. Sensors are aggregated to provide
relevant information about the current situation. In
addition, the ambient can provide services (actions)
for the citizens who are or live in it. Objects can
provide specific actions to adapt the environment
based on the citizen's needs. In this work, services
represent features (functions) of Entities inserted in
the environment. These features are provided by
device themselves or obtained by suppliers of AAL
services. Services are defined as statements contain-
ing inputs (I) and one output (O). A service is for-
mally represented by the following statement (3):
Se: ({I}, O);
(3)
For example, a service to warn the user using sounds
could receive, as input, the specific device to be used
in a service and the warning message to be repro-
duced, as presented below:
Se: warningSound;
{I}: Radio_Device, “take drug”;
O: Device.
The set of services {Se} for Proactive Actions is
organized in a logical order (i.e., linked list) of exe-
cution, where the logical order matches correspond-
ing actions in the environment, and can be grouped
under some logical aspect (e.g., location, run time).
A proactive action is formally represented by
rule (4), as follows:
PA: ({Sp}, {Se}, {R});
(4)
Where: {Sp} consists on a situation that must be true
for the correct execution of proactive actions; {Se} is
a set of Services and {R} set of semantic relations
presented in (1). For instance, a proactive action can
have agitation as a pre-condition (Sp). This action
sends a SMS for a caregiver (Service 1) and calls
emergency (Service 2). The relations that determine
interactions with the device to activate the service
are represented by semantic relations {R}, as exem-
plified below:
(hasService(Device_Radio,Song));
(hasService(Device_TV,Image));
3 ARCHITECTURE
FOR DEPLOYING PERVASIVE
APPLICATIONS
Knowing the existing complexity in ubiquitous envi-
ronments with heterogeneous technologies of sen-
sors and electronic objects, the design of an architec-
ture that reduces the complexity to generate intelli-
gent applications (pervasive) becomes necessary.
This article proposes a software architecture to ena-
ble the execution of appPerv in the described AAL.
As represented in Figure 3, the entities of the envi-
ronment are invariant in their normal state
(a standard state with semantic links pre-defined as
stable). Occasionally, unwanted situations may be-
come true. These are situations that are pre-
requisites for firing automatic actions in the envi-
ronment. But the decision of which action should be
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
420
triggered in the environment due to some detected
situation is a task of appPerv.
Figure 3: Flow to Trigger Proactivity Actions.
They contain the knowledge to trigger the most
suitable action to a particular situation. The proac-
tive action is triggered by the appPerv itself, which
should attempt to reconstruct the invariant to its
normal state. To support this flow, a service-oriented
architecture is employed (see Figure 4), which pro-
vides a stable environment to install third-party
solutions (appPerv).
Figure 4: Architecture for Pervasive Applications.
3.1 Physical Environment
The Lower Level (3) layer in Figure 4 corresponds
to the physical environment containing a sensor
network infrastructure and providing means for
monitoring and capturing raw data from the ambient.
This level includes the physical infrastructure of the
residence, with standardization of protocols for
communication and home automation (Domotic /
Home Automation) (Gill et al., 2009).
3.2 Situation as a Service (SIaaS)
The Intermediate Level (2) contains the software
layer (SIaaS middleware) to provide a stable and
secure environment for pervasive applications (ap-
pPerv) requesting actions for the SIaaS. It notifies
the appPerv whenever situations of interest for the
application become true. This layer monitors the
environment and provides contextualized infor-
mation (context of interest) according to the interest
of the appPerv. This layer builds a link between the
physical environment and the appPerv. SIaaS pro-
vides interfaces to context information that is gener-
ated and to the services available. So, it can be used
by third-party applications to design solutions that
could be incorporated in the residential architecture.
Conceptual Model: The conceptual model (‘a’
in Figure 4) is an ontology that describes everything
in the environment (context model). The ontology is
developed in OWL file (Ontology Web Language)
(Bechhofer et al., 2004), sublanguage OWL-DL. It
requires concept specialization at the moment of an
inclusion of the terms that describe the specific resi-
dence managed by the SIaaS middleware. Their
instances reflect the real entities in a particular home
domain.
Through a copy of this file, the applications can
identify which types of entities and semantic rela-
tions can be handled. Thus, when the application is
built, it can be preprogrammed so that the behaviors
become sensitive in relation to this conceptual mod-
el. The Situations are implemented as rules in Se-
mantic Web Rule Language (SWRL), which consists
on Horn-like rules added to the OWL language as
axioms in OWL-DL (Horrocks et al., 2005). The
rules are defined in the ontology and reason over the
current values of existent instances. The valid values
defined in the relationships will make the difference
between a situation S#1 or S#2. For this situation, we
have the following statement in FOL (First Order
Logic), according to the OWL notation defined in
(Horrocks et al., 2005), where “EC” and “ER”
means concept and relationship respectively.
(p, s, v, y, w ) Є EC(OWL : Thing)
( (p) Є EC (Patient)
(s) Є EC (SensorHeartBeat)
(p,s) Є ER (hasSensor)
(5)
(s,v) Є ER (valueCollected)
(v,y) Є ER (greatherThen)
(p,w) Є ER(isSituationOf))
The above rule (5) translated into SWRL is present-
ed in (6).
Patient(p)^SensorHartbeat(s)
^hasSensor(p,s)^valueCollect(s,v)
^swrlb:greaterThan(v, 40)
isSituationOf(p,Emergency_Situation);
(6)
Related with the situation rule in (2), section 2.1,
where the logical rules {L} are represented, in the
example, by the SWRL operator in rule (6). Rules
are defined according to the critical values defined
Situation-awarenessasaKeyforProactiveActionsinAmbientAssistedLiving
421
to each patient, which is formulated when the ap-
pPerv development and instantiated by the Subsys-
tem to manage appPerv.
To services related with the rule in (3) and (4),
section 2.2, a proactive action is represented by a
started situation, a set of services (which implement
the action) and a group of semantic relations (that
must be true for this proactive action). The set of
services is also described in the ontology (using
Semantic Markup for Web Services - OWL-S). In
(7) and (8) we show rules, also in FOL, that repre-
sent the services and their respective group of se-
mantic relations and in (9) the composition these
services through a proactive action.
(7): service to play music in a radio device
(a, r, m, z) Є EC(OWL : Thing)
( (a) Є EC (PlayMusic)
(r) Є EC (Radio)
(m) Є EC (Music)
(r, a) Є ER (hasService)
(a,m) Є ER (hasInput)
(a,r) Є ER (hasOutput)
(a,z) Є ER(executeService))
(7)
(8): service to call an ambulance of health provider
( c, h, p, e, k) Є EC(OWL : Thing)
( (c) Є EC (CallAmbulance)
(h) Є EC (HealthProvider)
(p) Є EC (Patient)
(e) Є EC (Status_Emergency)
(h,c) Є ER (hasService)
(c,h) Є ER (hasInput)
(c,p) Є ER (hasInput)
(c,h) Є ER (hasOutput)
(c,k) Є ER(executeService))
(8)
Proactive Action (in (9)): if emergency situation (5)
is detected in the environment, it will trigger the
service to play music (7) and call an ambulance on
the health provider (8).
( f, a, c, w, v, z, w, o) Є
EC(OWL : Thing)
( (f) Є EC (ProactiveAction)
(a) Є EC (Service)
(c) Є EC (Service)
(w) Є EC (Situation)
(f,z) Є ER (hasInput)
(f,k) Є ER (hasInput)
(f,w) Є ER (hasPrecontition)
(w,v) Є ER (situationDetect-
ed)
(f,o) Є
ER(executeProactiveAction))
(9)
Subsystem to Manage Pervasive Applications:
(SMPA) (‘b’ in Figure 4) registers the appPerv ac-
quired to the user´s residency. For that, it verifies if
the OWL file, which contains the situation and con-
text of interest provided by the appPerv, has the
same structure of the ontology (OWL file of the
SIaaS) that describes the environment. It also tests
the consistency in the OWL file provided by ap-
pPerv. Finally, it registers the application with their
situations and context of interest in the Subsystem to
Manage Inferences.
Subsystem to Manage Inferences: (SMI) (‘c’ in
figure 4) is part of the worldview (section 2). This
subsystem processes the conceptual model each time
that it is notified by the SMC.
Subsystem to Manage Context: (SMC) (‘d’ in
Figure 4) is part of the worldview (section 2). This
subsystem receives requests of the SMI containing
appPerv and its context of interest. It monitors this
context and detects possible changes.
Subsystem to Manage Proactive Actions:
(SMPAct) (‘e’ in Figure 4) is part of the actions of
the world (section 2). This contains a repository of
semantically described actions, a set of services that
can be requested by appPerv. This subsystem re-
ceives notifications for the execution of one or more
proactive. These actions result in the consumption of
services, which are features from the electronic
devices which are in the physical environment. This
semantic description links the services to its respec-
tive device or companies (e.g., Health Providers),
and they are described in the conceptual model.
3.3 Pervasive Applications
The Upper Level (1) offers a stable computing
environment for appPerv . In this research, appPerv
are software applications that request trigger actions
proactively due to the situations detected by SIaaS in
the environment and alter their behavior due to the
existing contextual information. Designers of ap-
pPerv must implement SWRL rules which corre-
spond (when inferred) to specific situations of the
environment and that are of interest of the appPerv.
To inform its context of interest, the designers
should generate instances of a particular type (e.g.,
Patient, Sensor, and make the linking semantics
between them, as hasSensor). Therefore, during
registration of the appPerv in SMPA, these instances
are compared to the actual instances of the environ-
ment (existing in the conceptual model of the mid-
dleware).
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
422
4 CASE STUDY
To evaluate the feasibility of the proposed approach,
the architecture was tested by developing an appPerv
that uses the concepts presented so far. This applica-
tion has the main goal to manage agitation moments
of patients with lightweight dementias.
4.1 Case Study Scenario
For the case study, the following fictitious scenario
was considered. Imagine ‘John’, a 78 years old citi-
zen without need for hospitalization, but has light-
weight dementias and needs continued treatment. In
addition, John has some memory problems. His
doctor identified he is presenting agitation behav-
iors. This situation causes problems for his health.
The residence of John is an AAL with enough tech-
nology to assist his health management and improve
his life quality as well as to adapt to his needs. To
assist with John´s implications, his daughter
Michelle purchased a software solution that interacts
with John’s residence in the case agitation situations
are detected.
Thus, there is an embedded infrastructure in
John’s residence that provides automated electronic
resource consumption. These resources are provided
in terms of services that each residential object with
some kind of communication skills can provide. To
manage this environment, there is an automated
system (SIaaS) who has knowledge of John´s needs
(i.e., a conceptual model), as well as knowledge of
what the environment can provide to assist those
needs. This system provides residential resources for
other applications can interact with the environment.
This is the scenario we have designed for a first
partial validation of our approach. In this context, an
appPerv, called appPervAgitation, was developed
and it manages agitation situations in patients with
Alzheimer disease based on the process illustrated in
Figure 5. This workflow has as objective to show
which action may be performed when a patient with
Alzheimer disease is agitated. For designing the
proposed solution, we defined relevant situations of
interest within their respective context of interest
and the proactivity actions, all described hereafter.
4.2 Situation of Interest
To identify the level of agitation of a given patient,
appPervAgitation registers three situations for agi-
tated patient, namely high, medium and low, corre-
sponding to the formalization proposed in (2), sec-
tion 2.1. The situation of interest is:
S: (appPervAgitation,{Ra,Rb},{S1,S2,S3});
where:
app = Pervasive Applications for Manage Situa-
tions of Agitation (appPervAgitation)
Ra=(hasSensor(John,Sensor_Heartbeat1);
Rb=(hasValue(Sensor_Heartbeat1,CollectValue)
L = High Agitated (S1):
Patient (John) SensorHeartbeat (Sen
sor_Heartbeat1) hasValue (Sen-
sor_Heartbeat1, CollectValue)
swrlb:greaterThan(CollectValue,200)
isSituationOf (John, Emergency_Situation)
L = Medium Agitated (S2):
Patient (John) SensorHeartbeat (Sen-
sor_Heartbeat1) hasValue (Sen-
sor_Heartbeat1, CollectValue) ∧
swrlb:greaterThanOrEqual(CollectValue,90)
swrlb:lessThanOrEqual (CollectValue,200)
isSituationOf (John, Emergency_Situation)
L = Low Agitated (S3):
Patient (John) SensorHeartbeat (Sen-
sor_Heartbeat1) hasValue (Sen-
sor_Heartbeat1, CollectValue)
swrlb:greaterThanOrEqual(CollectValue,50)
swrlb:lessThanOrEqual (CollectValue,89)
isSituationOf (John, Emergency_Situation)
4.3 Context of Interest
To identify which proactive action must be trig-
gered, the context of interest was based on the for-
malization presented in (1), section 2.1, the context
of interest is:
C:(appPervAgitation,
{R1,R2,R3,R4,R5,R6,R7,R8});
where:
Entity Person/Patient and Caregiver: the ap-
pPerv needs to know the location of patient John and
of his caregiver (Michelle) to trigger actions when
situation of interest is detected. For example, play
music (steps “n” and “h” of Figure 5).
R1 = (hasLocation(John,Location_X);
R2 = (hasCaregiver(John,Michelle);
R3 = (hasLocation(Michelle,Location_Y);
Entity Music Services: should contain a list of
appliances (with their respective locations) that
provide such service; so, the appPerv can identify if
the patient is in a location close to some of these
devices to execute steps “n” and “h” of Figure 5
(play music);
R4 = (hasMusicService(Radio_X,Serv_1);
R5 = (hasMusicService(TV_X,Serv_2);
R6 = (hasMusicService(Smartphone_X,Serv_3);
Entity Messaging Services: should contain a list
of devices that provide this service, so that the appli-
cation can perform step “i” of Figure 5.
R7 = (hasSMSService(Smartphone_X,Serv_4);
Situation-awarenessasaKeyforProactiveActionsinAmbientAssistedLiving
423
Figure 5: Agitation behaviour process of a patient with Alzheimer Disease (Siang Fook et al., 2006).
Entity Health Provider: must contain one or more
health care providers, within their contact details, so
that the application can notify them in step “d” of
Figure 5.
R8 = (hasHealhtProvider(John,HosptalX);
4.4 Proactive Actions
To demonstrate the formalized proactive actions, we
present below steps “n”, “h” and “d” of the Figure 5.
Pervasive Application needs consumed play mu-
sic of device, based on the formalization presented
in (3) and (4) section 2.2.
Service: playMusic;
Inputs: Device, Music;
Output: Device.
Service to requests assistance for health provider:
Service: sendMessage;
Inputs: Device_Smarthphone, Emergency;
Output: HealhtProvider.
Proactive Actions to manipulate the agitation sit-
uation: PA: Proactive Action for Emergency
{Sp}: S1,S2,S3;
{Se}: playMusic, sendMessage;
{R}: R1,R4,R5,R6,R7.
This PA is described on the pool of services, this
pool is managed for SMPAct and implements
through an OWL-S file.
4.5 Results of Experiments
A pilot prototype for the proposed architecture was
developed, considering the concepts discussed in
this paper, and to evaluate the impact of SIaaS in the
execution of appPervs.
Integration testing was developed to demonstrate
the integration of the subsystems and follow the
sequence diagram of Figure 6. In (1) the application
is registered on the SIaaS. At the moment, the
SMPA reads the situations of interest of the appPer-
vAgitation (agitated high, medium, low). It also
reads the context of interest (patients, caregivers,
healthcare providers, music services and message).
After this process, (1.1) the SMPA carries the con-
ceptual model (CM) to (1.2) run the alignment con-
text. In (1.3) the application together with their sit-
uations of interest and context are subscribed in the
SMI. The SMI initially (1.3.1) subscribe the appPer-
vAgitation with its context of interest in the SMC.
The SMC subscribes in sensors (1.3.1.2) that are of
interest to the appPervAgitation (as RFID sensor to
locate the patient and caregiver) and obtains the
remaining data (1.3.1.1) contained in the context
database (DBCtx). The SMC (2) processes in pa-
rameterizable times the context data.
If identified any changes, (3) it publishes/notify
for the SMI, informing which appPervAgitation had
its context changed. In (3.1) the SMI performs the
rules to detect if these situations become true. Case
some situations were detected, (4) it notifies the
appPervAgitation sending the context of interest and
the situation detected. The appPerv is trig-
gered/initiated by the notification of SMI. The ap-
pPervAgitation executes its workflow (4.1) and
decides which proactive actions of the environment
should be triggered (steps 'n', 'h', 'd', 'i' of Figure 5)
to the agitated situation be handled. Thus, (4.2) the
appPervAgitation asks SMPAct to execute one or
more proactive actions in the environment. Later the
SMPAct processes this request (4.2.1) and con-
sumes/triggers on the correct device the desired
service by the appPerv (4.2.2).
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
424
Figure 6: Sequence Diagram for proactive actions in environment.
5 CONCLUSIONS
In this paper, we presented current issues for build-
ing Ambient Assisted Living – AAL – systems.
These systems should be proactive and finely in-
tegrated with the needs of the inhabitants which
living in the AAL environment. To the system be
able to offer utility, usability and ubiquity, at the
same time that provide management of the environ-
ment and interacts with the users, it is necessary to
express situation awareness.
To support this awareness our architecture pro-
vides a Situation as a Service middleware offering a
possibility of proactive action. The middleware
SIaaS decreases the need to cope with heterogeneity
in these environments, using a shared conceptual
model and allowing its manipulation through OWL
files. Using this conceptual model, developers of
pervasive applications can generate software to be
deployed in a standard home for specific user needs.
The main contributions of this research are (i) the
formalization of the environment of AAL (situation
awareness and proactive actions); (ii) the design of
an architecture that provides resources to run third-
party pervasive applications; (iii) the use of the con-
ceptual model to semantic interoperability; and (iv)
a method to build generic pervasive applications for
specific domains.
Possible directions for future research include (i)
the study more advanced of context model in AAL
to provide wide usage of semantic to Pervasive Ap-
plications in the domotics industry; and (ii) the ex-
pansion of the prototype to real physical environ-
ment.
REFERENCES
Bechhofer, S.; van Harmelen, F.; Hendler, J.; Horrocks, I.;
McGuinness, D.L.; Patel-Schneider, P.F.; and Stein,
L.A. (2004) OWL Web ontology language 1.0 refer-
ence. W3C proposed recommendation
(www.w3.org/TR/owl-ref).
Bettini, C., Brdiczkab, O., Henricksen, K., Indulskad, J.,
Nicklase, D., Ranaganatha, Riboni, D. (2010) A survey
of Context Modelling and Reasoning Techniques. Per-
vasive and Mobile Computing, 161-180.
Christensen, K., Doblhammer, G., Rau, R. & Vaupel, J.
W. (2009) Ageing populations: the challenges ahead.
Lancet 374, 1196–1208.
Compton, M.; Henson, C., Lefort, L., Neuhaus, H.: (2009)
A survey of the semantic specification of sensors. In
2
nd
International Workshop on Semantic Sensor Net-
works, CEUR-WS, 17-32,2009.
Dey, A., and Abowd, G., (2006) The Context Toolkit:
Aiding the Development of Context-Aware Applica-
tions, In Proceedings of Human Factors in Computing
Systems: Pittsburgh, PA: ACM Press, pp.434-441.
Friedman-Hill, E. (2003): Jess in Action: Java Rule-based
Systems, Manning Publications Company, June, ISBN
1930110898, http://herzberg.ca.sandia.gov/jess/.
Gill, K. S, Yang, F. Yao, and X. Lu, (2009) A ZigBee-
based home automation system. Consumer Electron-
ics, IEEE Transactions on, vol. 55, no. 2, pp. 422–430.
Horrocks, I., Patel-Schneider, P. F., Bechhofer, S., Tsar-
kov, D. (2005) OWL Rules: A Proposal and Prototype
Implementation. Journal of Web Semantics, v.3, p. 23.
Klusch, M, B. Fries, and K. Sycara. (2009) OWL-S-MX: A
hybrid Semantic Web Service matchmaker for OWL-S
services, Web Semantics: Science, Services and
Agents on the World Wide Web, 7(2):121-133.
Moore, P., Hu, B., Zhu, X., Campbell, W., Ratcliffe, M.
(2007) A Survey of Context Modeling for Pervasive
Cooperative Learning. In: Internet Symposium on In-
formation Technologies and Applications in Education
- ISITAE 07, Kunming, Yunnan, China, p. 23-25.
Sun, H. De Florio, V. Gui, N. Blondia, C. (2009), Promis
Situation-awarenessasaKeyforProactiveActionsinAmbientAssistedLiving
425
es and Challenges of Ambient Assisted Living Systems,
Sixth International Conference on Information Tech-
nology: New Generations, ITNG ’09. pp. 1201-1207.
Siang Fook, V. F., Tay, S. C., Jayachandran, M., Biswas,
J., and Zhang, D. (2006). An ontology based context
model in monitoring and handling agitation behaviour
for persons with dementia. PERCOMW ’06, Washing-
ton, DC, USA. IEEE Computer Society.
Ye, J., Stevenson, G., Dobson, and S. McKeever, (2012)
Situation identification techniques in pervasive com-
puting: a review, Pervasive Mobile Computing, pp 36-
66, Vol. 8, Issue 1, February 2012.
Ye, J., Stevenson, G., Dobson, S. (2011) A top-level on-
tology for smart environments. Pervasive and Mobile
Computing. v. 7, p. 359-378.
ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems
426