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 efﬁ-

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 conﬂicting

preference speciﬁcations.

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-

ciﬁc 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 difﬁcult to understand.

In this paper we adopt a different approach, fo-

cussing speciﬁcally 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 ﬁrst 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 Artiﬁcial Intelligence, pages 377-384

DOI: 10.5220/0001535603770384

 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’

speciﬁcations; 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 identiﬁed: 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 identiﬁed:

• 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 conﬂicts. For instance, different priorities

could be assigned to different users based on tem-

poral precedence (i.e., who asked ﬁrst), 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 identiﬁcation

techniques; unrecognised users should be offered the

chance to identify explicitly via suitable system ter-

minals. If they remain unidentiﬁed, 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 identiﬁcation: 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—speciﬁcally, 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 conﬂicts could arise: dif-

ferent users might express conﬂicting 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 conﬂict

resolution policy is to be determined by administra-

tors, and should be able to deﬁne 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

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 ﬁrst pro-

totype (Subsection 3.3) of HomeManager. For space

reasons, only a limited set of tables is reported.

3.1 Analysis

Requirements Analysis

The ﬁrst SODA step is the Requirements Analysis,

where the system requirements and the world of the

legacy systems are identiﬁed. 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 identiﬁed: 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 ﬁne-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 conﬂict, solve conﬂict,

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

identiﬁed 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 speciﬁc 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 notiﬁcation 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 ﬁrst 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

satisﬁed

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 ﬁrst 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 notiﬁcation

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 simpliﬁed 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-ﬁ 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 ﬁgure by the red rect-

angle, is currently expressed as a textual description,

but will be reported directly on the map in a future

version; ﬁnally, 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 proﬁle 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 proﬁle-

management interface: there, each user can change

his/her proﬁle 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 (ﬁrst 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 fulﬁl 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 speciﬁc way, yet

without imposing any speciﬁc “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) proﬁle-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 “agentiﬁed”

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 speciﬁc 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 speciﬁc 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 speciﬁc 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 ﬂexible in this context, for a house policy

modiﬁcation would imply a modiﬁcation 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-ﬁ, . . . –,

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 ﬁrst – 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 deﬁne 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 beneﬁts 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 ﬁlled 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 deﬁnition – 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 ﬁnd a better compromise between

the proﬁles 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. ﬁnal, 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 ﬁrst-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