AN AGENT-BASED APPLICATION FOR HOME INTELLIGENCE
Ambra Molesini, Enrico Denti
ALMA MATER STUDIORUM- Universit
`
a di Bologna, viale Risorgimento 2, 40136 Bologna, Italy
Andrea Omicini
ALMA MATER STUDIORUM- Universit
`
a di Bologna a Cesena, via Venezia 52, 47023 Cesena, Italy
Keywords:
Home Intelligence, Ambient Intelligence, Agents, HomeManager, SODA.
Abstract:
Ambient Intelligence is an interesting research application area for Multi-Agent Systems. In this paper, we fo-
cus on the methodological support that the agent-oriented methodologies can provide to such kind of systems:
in particular we present HomeManager, an application for the control of an intelligent home designed through
SODA—an agent-oriented methodology. In this vision, the house is seen as an intelligent environment made
of independent and distributed devices, each equipped with an agent to support the user’s goals and tasks.
1 INTRODUCTION
The concept of Ambient Intelligence (AmI) intro-
duces a vision of the Information Society where the
emphasis is on greater user-friendliness, more effi-
cient services support, user-empowerment, and sup-
port for human interaction (Ducatel et al., 2001). In
this scenario, an “intelligent environment” is a space
that contains myriad devices that work together to
provide users access to information and services (Bru-
mitt et al., 2000; Kulkarni, 2002). So, people are sur-
rounded by intelligent intuitive interfaces that are em-
bedded in all kinds of objects and an environment that
is capable of recognising and responding to the pres-
ence of different individuals in a seamless, unobtru-
sive and often invisible way. As noted in (Lesser et al.,
1999), AmI implies several challenges concerning the
world of physical resources (sensors, actuators), the
existence of many forms of task or goal interactions, a
natural physical and functional distribution of control,
a requirement for actions to be taken in given time in-
tervals, and the integration of potentially conflicting
preference specifications.
Other features include (i) the adoption of suit-
able coordination models to manage the physical re-
sources, (ii) the support for the security techniques
access control, intrusion detection, etc. –, (iii) the
support for richer interactions with the users, and (iv)
a deeper understanding of the structure of the physi-
cal space. Due to these requirements, autonomy, dis-
tribution, adaptation and proactiveness emerge as key
features of the entities populating the intelligent en-
vironment (De Carolis and Cozzolongo, 2004). Such
features naturally lead to consider agents and Multi-
Agent Systems (MASs) as effective metaphors for
system design and implementation in AmI scenarios
(Zambonelli and Omicini, 2004).
Different works exploiting MASs in the context
of intelligent home (or smart home) an AmI spe-
cific scenario – can be found in the literature—among
these, IHome (Lesser et al., 1999), C@sa (De Carolis
and Cozzolongo, 2004) and MavHome (Cook et al.,
2003). There, the house is seen as a MAS where
agents perceive the environment by means of sensors,
and act upon it by means of actuators. However, these
works mainly present the application from the imple-
mentation viewpoint, providing only few guidelines
from the methodological viewpoint: so, the underly-
ing process supposed to guide designers from the re-
quirements analysis to the design choices in partic-
ular, to select an architecture among all the possible
ones – is somehow hidden and difficult to understand.
In this paper we adopt a different approach, fo-
cussing specifically on the system design process. In
particular, we discuss how SODA (SODA, 2008), an
agent-oriented methodology, can support the analysis
and design of HomeManager, an agent-based applica-
tion for the control of an intelligent home. Section 2
presents our reference scenario and discusses its main
requirements, while Section 3 is devoted to the anal-
ysis, the design and an outline of the first prototype
of HomeManager. Discussion and comparison with
some relevant related work are reported in Section 4.
Conclusions and future work follow in Section 5.
377
Molesini A., Denti E. and Omicini A. (2009).
AN AGENT-BASED APPLICATION FOR HOME INTELLIGENCE.
In Proceedings of the International Conference on Agents and Artificial Intelligence, pages 377-384
DOI: 10.5220/0001535603770384
Copyright
c
SciTePress
2 SCENARIO
We consider a home automation application, whose
goals are limiting the overall energy consumption
and supporting people’s activities inside the house
(Fontan, 2006). The application is supposed to medi-
ate between the desire for higher comfort and the ser-
vice cost, respecting technical constraints and users’
specifications; it should also be controllable both lo-
cally and remotely – e.g. via short messages on PDAs
or mobile phones – in a transparent way.
Two basic user categories can be identified: peo-
ple stably living in the house, and visitors. The latter
cannot operate on the system, but should be enabled
to exploit some support functionalities. Inhabitants,
instead, may have different authorisation levels. So,
at least three user types can be identified:
administrators can specify the management poli-
cies of any all the systems aspects, and decide
(other) users’ privileges;
standard users can express their preferences and
give commands via SMS, but cannot act on power
consumption nor can they change the privilege
level of other users;
visitors are occasional, unregistered users, which
can only receive basic assistance.
All users can specify their preferences about the avail-
able devices—e.g. the desired temperature in a given
room, the automatic switch-on of TV when entering
the room, etc.; the system should do its best to meet
such requirements, adopting suitable criteria to solve
possible conflicts. For instance, different priorities
could be assigned to different users based on tem-
poral precedence (i.e., who asked first), or following
ad-hoc policies imposed by administrators (e.g., a hi-
stereo and a TV set cannot be switched on in the
same room at the same time). The resulting plan will
take care both on users’ preferences and policies, and
power consumption policies: for the sake of simplic-
ity we assume that administrators can choose whether
to specify either the maximum power consumption al-
lowed, or the period of the day where to concentrate
most of the power consumption. Of course, many
other strategies could be devised, without affecting
the structure of the envisioned scenario.
2.1 Problem Analysis
The environment to be controlled is a family house:
its rooms are supposedly provided with input/output
sensors for identifying each (registered) user upon en-
try/exit into/from that room, via suitable identification
techniques; unrecognised users should be offered the
chance to identify explicitly via suitable system ter-
minals. If they remain unidentified, they should be
treated as visitors, with only a minimal set of actions
allowed (such as, for instance, turning on/off the room
light or the radio). These assumptions make it possi-
ble to know the exact position of each user at any time,
which is needed for the system to perform correctly
(e.g., to turn on the radio or TV in the right room).
Given the private nature of the house, we choose
not to limit the number of persons that can stay in
a room at any time, and to leave free access to any
room even without identification: the idea behind this
assumption is that the system should assist its users
in a constructive and positive way, rather than com-
plicating their life with annoying constraints. This
choice does not affect generality, since adding fur-
ther security requirements has no impact on the other
system requirements—specifically, on the user pref-
erences and on the system planning choices.
As outlined in the requirements, the system should
support users in three ways:
satisfying the users’ requests whenever possible,
and trying to anticipate their needs by suitably
pre-programming the available devices according
to their preferences (e.g. room temperature);
allowing users to give commands both directly
and remotely, via short messages;
minimising the house total power consumption.
Of course, different kinds of conflicts could arise: dif-
ferent users might express conflicting desires (for in-
stance, one might want to turn on the heater, another
the air conditioner), or their requests might involve
more power than it is actually available. The conflict
resolution policy is to be determined by administra-
tors, and should be able to define priorities in a clear
way. In this case, it should at least:
decide whether to keep into higher consideration
either the power consumption or the user requests;
give different priorities to the different users—for
instance, assigning higher priority to the (more
tired) family member who comes back home later
from work;
keep into account the temporal order of users’ re-
quests;
allow the system to postpone some non-critical
activities when needed—for instance, in order to
keep the overall power below the limit.
In order to carry out its management policy, the
system must obviously operate on the available
devices—to turn them on/off, adjust their parameters,
etc; our hypothesis is that such devices are never ac-
cessed directly, but, by asking them to perform some
ICAART 2009 - International Conference on Agents and Artificial Intelligence
378
Transitions
Tables
Requirements
Analysis
Analysis
References
Tables
Requirements Tables
Domain Tables
Relations Tables
Responsibilities Tables
Dependencies Tables
Topologies Tables
Analysis
Architectural
Design
Detailed
Design
Mapping
Tables
Entities Tables
Interaction Tables
Topological Tables
Agent/Society Design Tables
Environment Design Tables
Constraints Tables
Interaction Design Tables
Topological Design Tables
Design
Figure 1: An overview of the SODA process.
services via some suitable interaction protocol. Each
device is supposed to handle its low-level details, so
that the higher-level coordination system needs not be
aware of them, also enhancing scalability.
2.2 SODA
SODA (Societies in Open and Distributed Agent
spaces) (Omicini, 2001; Molesini et al., 2006a) is an
agent-oriented methodology for the analysis and de-
sign of agent-based systems, which adopts the Agents
& Artifacts (A&A) meta-model (Omicini, 2007) and
introduces layering as the main tool for scaling with
the system complexity, applied throughout the analy-
sis and design process (Molesini et al., 2006b).
The SODA abstractions (explained below) are log-
ically divided into three categories: i) the abstractions
for modelling/designing the system active part (task,
role, agent, etc.); ii) the abstractions for the reactive
part (function, resource, artifact, etc.); and iii) the ab-
stractions for interaction and organisational rules (re-
lation, dependency, interaction, rule, etc.). Moreover,
the SODA process is organised in two phases, struc-
tured in two sub-phases: the Analysis phase, which
includes the Requirements Analysis and the Analysis
steps, and the Design phase, including the Architec-
tural Design and the Detailed Design steps. Each sub-
phase models (designs) the system exploiting a subset
of SODA abstractions: in particular, each subset al-
ways includes at least one abstraction for each of the
above categories that is, at least one abstraction for
the system active part, one for the reactive part, and
another for interaction and organisational rules.
Figure 1 shows an overview of the methodology
structure: as we will show in the case study (Sec-
tion 3), each step is practically described as a set of
relational tables (listed in Figure 1 for completeness).
3 HOME MANAGER
In this section we present the analysis (Subsec-
tion 3.1), the design (Subsection 3.2) and the first pro-
totype (Subsection 3.3) of HomeManager. For space
reasons, only a limited set of tables is reported.
3.1 Analysis
Requirements Analysis
The first SODA step is the Requirements Analysis,
where the system requirements and the world of the
legacy systems are identified. Figure 2 shows the sys-
tem requirements at the core layer SODA supports
a layering principle: a system can be seen at differ-
ent levels of detail – so that only three coarse-grained
requirements are present, one for each “macro” cate-
gory identified: namely users, plans/policies, and de-
vices. The legacy systems individuated are the de-
vices placed in the rooms: each is in relation with the
three requirements above. This coupled relationship
Requirement Description
Users management management of the user data
and preferences
Plans management management of the plan
Devices management management of the devices
Figure 2: Requirement table.
between requirements and legacy systems is tied to
the particular kind of system, as in the home automa-
tion scenario the devices represents a very important
portion of the system to be controlled.
Analysis
The transition between Requirements Analysis and
Analysis is expressed by the References Tables: as
an example, Figure 3 reports the mapping between
the requirements and the tasks they generate. Even if
these tasks are more fine-grained than requirements,
they are still at a high level of abstraction, so they
could be in-zoomed in a more detailed layer.
Requirement Task
Users Management show data, show preferences,
update preference, add user,
canc user, update user
Plans Management show plane, show policy,
load policy, accomplish policy,
elaborate plan, execute plan,
detect conflict, solve conflict,
check request, check activity
Devices Management show status, add device,
remove device, check people
Figure 3: Reference Requirement-Task table.
During the Analysis step also the environmen-
tal functions that derive both from requirements and
legacy-systems and the topological structure of the
environment are individuated. This latter is already
AN AGENT-BASED APPLICATION FOR HOME INTELLIGENCE
379
identified by both the physical structure of the con-
trolled house and the position of the devices inside
the rooms. In this step the dependencies among the
tasks and functions are individuated, too. These re-
lationships are exploited to determine the interaction
spaces of the entities, the rules that govern interac-
tions, and the related social aspects like organisation
management, coordination and system security.
The reason why dependencies are derived from re-
quirements, legacy systems and topology is that some
access control rules are often expressed implicitly as
topological “requirements”—as for instance in “The
double room has a private bathroom”. If we analyse
such a requirement, we see that there are two con-
nected rooms – a double room and a bathroom that
represent a portion of the environment structure, and
recognise a clear, yet implicit, access control rule:
“only the people allowed to enter the double room
can access the bathroom”. In turn, this can be seen as
a prohibition for visitors to enter the bathroom, lead-
ing to an access control rule like “the role Visitor is
not allowed to enter in the double room’s bathroom”,
ready to be translated into an RBAC (Role-Based Ac-
cess Control) (RBAC, 2004) rule.
Coordination plays a key role in this kind of ap-
plications, because the right “implementation” of the
plan derives from the coordination of the different en-
tities that mediate between the users preferences and
the limitation of the energy consumption. The next
subsection focuses on the design of such rules.
3.2 Design
Architectural Design
During the Architectural Design, the system is de-
signed in terms of roles, resources, actions, opera-
tions, interactions, rules and spaces. These entities
derive form the abstractions outlined in the previ-
ous step: roles are responsible for the achievement
of tasks by executing actions, while resources offer
the functions outlined in the previous step by provid-
ing the corresponding operations. Typically the task-
role and function-resource mappings are not one-to-
one, as a role/resource is able to complete/accomplish
several different tasks/functions. For example, the
role “Preference Manager” is responsible for the
“show preference” and “update preference” (Figure
3) tasks. The SODA spaces are easily derived from
the topology, and map one-to-one the physical rooms
which compose the controlled house.
As noted in the Analysis, the core of the system
is the coordination among the entities, that is cap-
tured by the SODA abstract entities “interactions” and
“rules” derived from the dependencies. So, in order
to design such aspects, a reference model for coor-
dination (Papadopoulos and Arbab, 1998) has to be
chosen. Given the intrinsic features of this applica-
tion, where a multiplicity of user preferences have to
be considered altogether, prioritised and enforced at
any time, while users enter/exit the house rooms, an
approach based on mediated interaction seems more
suitable than, for instance, a bid-based approach. In
fact, mediated interaction makes it possible to dele-
gate the coordination medium for policy store and en-
forcement, thus reducing the time needed to enforce
the policy, and freeing roles from taking care of the
coordination burden. Also, any policy change affects
only a specific place, with no impact on roles—and
therefore transparently with respect to them.
This model leads to design interactions as if no
policies exist, delegating their enforcement and the
access control to the design of the coordination laws
expressed by the SODA rules. More concretely, if
a user asks HomeManager to switch on the dish-
washer, the request is managed by the role designed
for achieving this task (“request dispatcher”) by send-
ing the request to the “dishwasher manager” role.
Such a delivery, however, is not performed directly:
rather, it is managed by a coordination medium, that
is supposed to react according to the policy and thus
dispatching the request to the dishwasher manager or
send a notification to the request dispatcher if the ac-
tion is not allowed by the policy (for instance, if the
energy consumption is close to the top limit—see the
“MaxEnergy Rule” in Figure 4). The coordination
medium is “transparent” for request dispatcher and
dishwasher manager, as it represents a sort of “infras-
tructure layer” not directly perceived by roles.
For space reasons, Figure 4 shows only an excerpt
of the Rule table that lists and describes all rules—
namely, some representative rules for each “macro
category”. So, the first block includes the rules de-
voted to the general house policy energy consump-
tion and users priority –, the second represents the
rules concerning the use of devices, while the third
block lists the access control rules.
Moving from Architectural Design to Detailed
Design, the engineer should now operate a carving
operation, so as to choose the most adequate repre-
sentation level for each architectural entity: this leads
to depict one (detailed) design from the several poten-
tial alternatives outlined by the layering. In our case,
since the core layer is placed at a high level of abstrac-
tion, and no in-zoom operation is present, the carving
operation is simply not necessary, and the core layer
becomes the only layer of the Detailed Design.
ICAART 2009 - International Conference on Agents and Artificial Intelligence
380
Rule Description
MaxEnergy Rule The electrical power
cannot exceed 3 KW
Priority Rule The preferences of the
priority user have to be
satisfied
Default Rule Turn on lights when Visitor
goes inside room
Heating Rule Heating is more priority
then other devices
Visitor Rule Visitor cannot access
to the system
Role Rule User cannot modify
its role
User Rule User can modify only
its data and preferences
. . . . . .
Figure 4: Rule table.
Detailed Design
Detailed Design is expressed in terms of agents, agent
societies, composition, artifacts and aggregates and
workspace for the abstract entities; interactions, in
their turn, are expressed by means of concepts such
as use, manifest, speak to and linked to.
In HomeManager, agents play the roles individu-
ated in the previous step, while resources are mapped
onto suitable environmental artifacts—a kind of ar-
tifact (Omicini et al., 2006a) aimed at wrapping the
physical devices that constitute the MAS external en-
vironment, or realising functions derived by require-
ments but not available in the external environment.
Since the design level is very abstract, we indi-
viduate just one agent society. Moreover, spaces and
their connections are then mapped one-to-one onto
workspaces and the respective workspace connec-
tions. Interactions are mapped onto different detailed
abstractions in order to capture the different “nature”
of the interaction itself: more precisely, agent-to-
agent interaction is mapped onto speak to, agent-to-
artifact onto use, artifact-to-agent onto manifest, and
artifact-to-artifact onto link to.
In addition, in SODA each agent is associated to an
individual artifact (Omicini et al., 2006a) that handles
the interaction of a single agent within a MAS, and
is used to shape of admissible interactions of MAS
agents. Such individual artifacts play an essential role
in engineering both organisational and security con-
cerns: in fact, access control rules (third block of
rules in Figure 4) are mapped precisely onto agents’
individual artifacts. The rules in the first and sec-
ond block are mapped onto social artifacts (Omicini
et al., 2006a), as they rule the social interactions—
even though indirectly, since they technically mediate
interactions between individual, environmental, and
possibly other social artifacts.
Social artifacts in SODA play the role of the co-
ordination artifacts i.e., coordination media that
embody the rules around which agent societies are
built. Among the possible different social artifacts
“organisations” (discussed in Section 4), we choose
the one where each workspace is associated to a so-
cial artifact that rules the agents and the devices in-
side a room so as to manage the user priorities and
control the access to the devices. We also easily indi-
viduate an aggregate of these social artifacts that can
“enforce” the global rules of the house—like, for ex-
ample, the “MaxEnergy Rule” in Figure 4. Figure 5
shows only an excerpt of the Artifact-UsageInterface
table, which actually lists all the operations provided
by each artifact in detail.
Artifact Usage Interface
Room receive command
manager send command
send notification
set policy, get policy
get plan, get user. . .
Home set homepolicy, get homepolicy
manager send command
get homeplan, get userpos. . .
Device switch on
manager switch off. . .
. . . . . .
Figure 5: Artifact-UsageInterface table.
As said above, this is a simplified version of the
system we actually designed and implemented (Sub-
section 3.3). In fact, in a real scenario, each room
should be expected to contain a multitude of agents
and devices, which could not be reasonably managed
by a single social artifact for obvious performance and
reliability reasons—preventing bottlenecks, avoiding
delays in the system responses, etc. So, the social
artifact should rather be seen as an abstract view of
an aggregate of other social artifacts, each enforcing
some given kind of rules.
3.3 Prototype
Following the above analysis and design process,
we realised a prototype simulator (Fontan, 2006)
for HomeManager based on the TuCSoN infrastruc-
ture (TuCSoN, 2008; Omicini and Zambonelli, 1999).
TuCSoN is well suited for this kind of application,
since it provides “tuple centres” as coordination me-
dia, which allow a one-to-one map with the SODA
social artifacts.
In this prototype we simulated the control of a
house composed of four rooms: the main entrance,
AN AGENT-BASED APPLICATION FOR HOME INTELLIGENCE
381
Figure 6: The HomeManager main window.
the dining room, the bedroom and the bathroom (see
Figure 6). Each room has several devices, like a wash-
ing machine in the bathroom, a hi-fi and a tv set in
the dining room, another tv set in the bedroom, as
well as various devices for light management. The
main interface is organised in three areas (Fontan,
2006): the login area (top-left) where users authen-
ticate and modify the HomeManager parameters; the
view house area (bottom-left) which reports the map
of the house (in the left side) and the current position
of the people inside the house (in the right side): this
information, highlighted in the figure by the red rect-
angle, is currently expressed as a textual description,
but will be reported directly on the map in a future
version; finally, the system activities area (right side)
shows both the activities of the system and the mes-
sages sent by each device when working.
So, for instance, when an (authorised) user goes
into the dining room, HomeManager reacts by sig-
nalling the presence of the user in the room, turn-
ing on the light if necessary, and applying the user’s
preferences temperature, devices turned on/off to
that room. If there are two or more people inside the
same room with different preferences, HomeManager
reacts according to the preferences of the most im-
portant (priority) user. A simple default policy is ap-
plied to visitors i.e., users for whom no profile is
available: this just switches the light on/off automati-
cally when he/she enters the room, since no other as-
sumptions can be done about the visitor’s identity and
his/her preferences.
Figure 7 shows four further views of HomeMan-
ager. View (a) shows a screenshot of the policy-
management interface: for each room, the GUI re-
ports the temperature, the state of the lights and the
state of all the devices in the room.
The screenshot in view (b) shows the profile-
management interface: there, each user can change
his/her profile and preferences about the temperature
and devices. However, he/she cannot change his/her
role in the house, as this operation is reserved to ad-
ministrators.
The screenshot in view (c) is about the command
interface: the authorised user operates on the sys-
tem by choosing the room and the device (first two
rows), and then issuing the desired command. Home-
Manager replies by starting a new action plan for the
room where the device is placed. The GUI in view (d)
shows the current policy for the selected room: in par-
ticular, the GUI reports the current temperature mode,
the maximum priority user, the current priority factor
and the current max energy consumption.
4 DISCUSSION
The intelligent home scenario represents a good appli-
cation domain for testing the MAS approach in gen-
eral and the agent-oriented methodologies in particu-
lar. In fact, this scenario introduces several different
challenges from the methodology viewpoint, such as,
for instance, the management of the security aspects
and the energy consumptions limitation, that should
be balanced with the system fast reaction and user’s
comfort, wellness and entertainment.
In order to obtain the best balancing among these
requirements, the methodology should support the de-
sign of suitable coordination models so that the agents
can collaborate and fulfil the house control task. As
highlighted in Subsection 3.2, mediated coordination
seems the best solution for this kind of application.
This choice leads to structure the design of interac-
tions and coordination rules in a specific way, yet
without imposing any specific “architecture” for the
system. In particular, the model considers a “coor-
(a) (b)
(c)
(d)
Figure 7: Some screenshots of HomeManager: a) policy-
management interface, b) profile-management interface, c)
command interface and d) current-policy interface.
ICAART 2009 - International Conference on Agents and Artificial Intelligence
382
dination medium”, but makes no hypotheses on the
entities that should “implement” this role.
In SODA the coordination rules are naturally
mapped onto social artifacts, so the coordination ar-
tifacts are delegated to enforce the coordination rules;
in IHome (Lesser et al., 1999), instead, the centrally-
managed resources (IHome also considers decen-
tralised resources) are controlled by an “agentified”
coordination medium. Coordination is managed by
agents also in Cas@ (De Carolis and Cozzolongo,
2004) and Intelligent Room (Kulkarni, 2002).
Even if both approaches present strengths and
drawbacks, from the design-for-change perspective
delegating coordination to a coordination artifact
seems a better choice, as it leads to encapsulate a
coordination service in a specific entity, allowing
user agents to abstract from how the service is im-
plemented. As such, a coordination artifact is per-
ceived as an individual entity, but can be actually dis-
tributed on different nodes of the MAS infrastructure,
depending on its specific model and implementation
(Omicini et al., 2006b). In addition, coordination
artifacts are meant to support coordination in open
agent systems, characterised by unpredictable events
and dynamism. For this purpose, they have to sup-
port a specific form of artifact malleability—namely,
they should allow their coordinating behaviour to be
adapted and changed both by engineers (humans)
willing to sustain the MAS behaviour, and by agents
responsible for managing the coordination artifact.
So, coordination artifacts can be seen as engineer-
ing abstractions for designing, building and support-
ing at runtime coordination in agent societies, suit-
ably instrumenting their dynamic working environ-
ment (Omicini et al., 2006b).
Of course, one could also adopt agents working
so as to mimic coordination media, but that approach
seems less flexible in this context, for a house policy
modification would imply a modification of the coor-
dination rules and probably also of the coordination
protocols between the coordinator agent and the co-
ordinated agents, spreading the impact of the change
nearly everywhere. Instead, a coordination artifact
helps keeping such changes inherently encapsulated.
With respect to the choice of the social artifact
“organisation”, it should be noted that the design so-
lution mentioned in Subsection 3.2 is not the only
possible. In fact, we exploited a social artifact or
an aggregate of social artifacts as the room man-
ager, so that all the room managers form an aggregate
that coordinates the whole house: however, a differ-
ent architecture, not-so-tied to the physical environ-
ment structure, could also be possible. For instance,
an organisation based on the system functionalities
could be based on a social artifact devoted to coor-
dinate the entertainment devices tv set, hi-fi, . . . –,
another for heating and air conditioning, a third one
for lights, etc.—all forming an aggregate to coordi-
nate the whole house.
Currently, we do not have enough experimental
results convincing us to prefer an architecture to an-
other. We chose the first a social artifact manager
for each room for the prototype mainly because it
naturally bounds the “scope” of each social artifact to
the physical structure of the environment, making it
easier to define the coordination rules holding inside
each room.
5 CONCLUSIONS AND FUTURE
WORK
HomeManager is an agent-based application for con-
trolling an intelligent home. We discussed its analysis
and design with special regard to the coordination and
access control rules which motivate the architectural
design choices, from the coordination model to the
social artifact organisation. In particular, we stressed
the relevance of a mediated coordination model and
of delegating coordination to a coordination artifact,
so that agents can exploit coordination as any other
service, without being concerned about the possible
changes in the house policies.
The experiment was an interesting testbed for the
SODA methodology, highlighting some benefits as
well as some limitations that we mean to address in
the near feature. In particular, the tabular represen-
tation is clearly more suitable for an automatic tool
than for a human designer, due to the large amount of
tables to be filled in at each stage: so, we plan to de-
velop tools for supporting designers in doing so in a
consistent and complete way. Another interesting ex-
tension could be the definition – or the adoption – of a
language for specifying SODA rules in a more precise
and formal way, overcoming the implicit limitations
of the natural language which is currently adopted in
the tabular representation. We also plan to evaluate
whether to enrich SODA with methods for the internal
design of agents and artifacts—which are now uncov-
ered, since SODA currently does not deal with intra-
agent (and more generally with “internal”) issues.
Further work will be devoted to improve the cur-
rent version of the prototype, implementing all the
access control checks considered in the Design, and
comparing the two architectures discussed in Sec-
tion 4. Moreover, we plan to consider some fuzzy-set
theory methods to find a better compromise between
the profiles of different people, instead of the simple
AN AGENT-BASED APPLICATION FOR HOME INTELLIGENCE
383
priority policy which is currently adopted, and to test
our prototype in some real environment.
ACKNOWLEDGEMENTS
Authors would like to thank Dr. Claudia Fontan for
her contribution to the project and her work in the pro-
totype implementation.
This work has been supported by the MEnSA
project (Methodologies for the Engineering of com-
plex software Systems: Agent-based approach)
funded by the Italian Ministry of University and Re-
search (MIUR) in the context of the National Re-
search ‘PRIN 2006’ call.
REFERENCES
Brumitt, B., Meyers, B., Krumm, J., Kern, A., and Shafer,
S. A. (2000). Easyliving: Technologies for intelli-
gent environments. In Thomas, P. J. and Gellersen,
H.-W., editors, Handheld and Ubiquitous Computing,
volume 1927 of LNCS, pages 97–119, London, UK.
Springer.
Cook, D. J., Youngblood, M., Heierman, E. O. I., Gopal-
ratnam, K., Rao, S., Litvin, A., and Khawaja, F.
(2003). MavHome: An agent-based smart home. In
1st IEEE International Conference on Pervasive Com-
puting and Communications (PerCom 2003), pages
521–524, Washington, DC, USA. IEEE CS.
De Carolis, B. and Cozzolongo, G. (2004). C@sa: Intelli-
gent home control and simulation. In Okatan, A., edi-
tor, International Conference on Computational Intel-
ligence (ICCI 2004), pages 462–465, Istanbul, Turkey.
International Computational Intelligence Society.
Ducatel, K., Bogdanowicz, M., Scapolo, F. Leijten, J., and
Burgelman, J.-C. (2001). Scenarios for ambient intel-
ligence in 2010. final, IPTS European Commission’s
Joint Research Centre.
Fontan, C. (2006). Tecnologie ad agenti per una casa intel-
ligente. Master’s thesis, Universit
`
a di Bologna, Italy.
Kulkarni, A. (2002). Design Principles of a Reactive Be-
havioral System for the Intelligent Room. Bitstream:
The MIT Journal of EECS Student Research.
Lesser, V., Atighetchi, M., Benyo, B., Horling, B., Anita,
R., Vincent, R., Wagner, T., Xuan, P., and Zhang, S. X.
(1999). The UMASS intelligent home project. In
3rd International Conference on Autonomous Agents
(Agents ’99), pages 291–298, New York, NY, USA.
ACM.
Molesini, A., Omicini, A., Denti, E., and Ricci, A. (2006a).
SODA: A roadmap to artefacts. In Dikenelli, O.,
Gleizes, M.-P., and Ricci, A., editors, Engineering So-
cieties in the Agents World VI, volume 3963 of LNAI,
pages 49–62. Springer.
Molesini, A., Omicini, A., Ricci, A., and Denti, E. (2006b).
Zooming multi-agent systems. In M
¨
uller, J. P. and
Zambonelli, F., editors, Agent-Oriented Software En-
gineering VI, volume 3950 of LNCS, pages 81–93.
Springer.
Omicini, A. (2001). SODA: Societies and infrastructures
in the analysis and design of agent-based systems.
In Ciancarini, P. and Wooldridge, M. J., editors,
Agent-Oriented Software Engineering, volume 1957
of LNCS, pages 185–193. Springer.
Omicini, A. (2007). Formal ReSpecT in the A&A perspec-
tive. ENTCSs, 175(2):97–117.
Omicini, A., Ricci, A., and Viroli, M. (2006a). Agens
Faber: Toward a theory of artefacts for MAS.
ENTCSs, 150(3):21–36.
Omicini, A., Ricci, A., and Viroli, M. (2006b). Coordina-
tion artifacts as first-class abstractions for MAS en-
gineering: State of the research. In Garcia, A. F.,
Choren, R., Lucena, C., Giorgini, P., Holvoet, T., and
Romanovsky, A., editors, Software Engineering for
Multi-Agent Systems IV: Research Issues and Practi-
cal Applications, volume 3914 of LNAI, pages 71–90.
Springer.
Omicini, A. and Zambonelli, F. (1999). Coordination for
Internet application development. Autonomous Agents
and Multi-Agent Systems, 2(3):251–269.
Papadopoulos, G. A. and Arbab, F. (1998). Coordina-
tion models and languages. Advances in Computers,
46:330–401.
RBAC (2004). American National Standard 359-2004
Role Base Access Control home page.
http://csrc.nist.gov/rbac/.
SODA (2008). Home page. http://soda.apice.unibo.it
TuCSoN (2008). Home page. http://tucson.apice.unibo.it//
Zambonelli, F. and Omicini, A. (2004). Challenges and re-
search directions in agent-oriented software engineer-
ing. Autonomous Agents and Multi-Agent Systems,
9(3):253–283.
ICAART 2009 - International Conference on Agents and Artificial Intelligence
384