Practicas para el laboratorio de Domótica:

COURSE PROGRAM: Domótica y Electrónica para Arquitectura (DyEpA) -

LABORATORY Dr. Juvenal Rodíguez Reséndiz Enero 2022

I. COURSE INFORMATION

Course name: Optativa I (Domótica y Electrónica para Arquitectura) LABORATORY

Clave: MAQ14-452
Credits: 6
Course time: 15 weeks
Hour/week: 1 theoretical, 2 practice
Total hours: 45 hours
Program Author: Juvenal Rodríguez Reséndiz
Modality: Four-Month / face to face

1_SalidasYEntradasDigitales.txt 2_LecturaAnalogicaConImpresionSerial.txt 3_ComunicaciónSerial.txt

4_TonoDeBuzzer.txt 5_CadenaSerialDeEntrada.txt 6_ ControlMotorDCPorADC.txt 7_LedRGB.txt

8_ServomotorControladoPorSerial.txt
/*

En este código se cambia el estado de un pin de salida digital entre

apagado y encendido dependiendo del estado del botón sujeto al pin 2.

(Ej. led asociado al pin 13).

Se utiliza el pin 2 como entrada digital asociada a un botón activo alto.

La declaración de la variable global pushButton de esta manera representa

una alternativa para hacer una "definición" que simplifique la legibilidad y

migrabilidad del código.

La función void setup() siempre se declara. En ella se realizan las configuraciones y

todo aquello que deba ejecutarse una sola vez.

La funcion void loop() es equivalente al main con un while infinito.

*/

int pushButton = 2;

void setup()

pinMode(13, OUTPUT); // Se establece el pin 13 como salida digital.

// Es importante configurarla previamente.

void loop()

//Declaración con inicialización de la variable auxiliar que representa el estado del boton.

int buttonState = digitalRead(pushButton);

if(buttonState == 1) {digitalWrite(13, HIGH);} // Cambio a alto del pin de salida digital.

else {digitalWrite(13, LOW);} // Cambio a bajo del pin de salida digital.

}
/*

En el código se lee la entrada analógica del pin A0 e imprime el

valor de la conversión digital por el puerto serie a través de la

terminal de Arduino.

*/

void setup()

Serial.begin(9600); //Solo se especifican los baudios. Por defecto 8bits, sin paridad, 1 stop.

//Para otra configuración, se acude a definiciones y se incluyen como segundo

// argumento de la función:

//Ejm: Serial.begin(9600, SERIAL_8E2); (8bits, paridad even(par), 2 bits stop)

void loop()

unsigned long time = 0; //Capacidad del entero más largo que representa el tiempo.

int sensorValue = analogRead(A0); //Variable declarada e inicializada, Pin A0 de canal analógico para sensor.

Serial.println(sensorValue); // serial.println incluye por defecto el salto de línea. No es necesario especificar el tipo de
dato.

//El dato es transmitido directamente como string

Serial.println(time); //Imprime el tiempo leido por la función millis.

delay(1); //Tiempo de conversion e impresión (ms)

time = millis(); //Retorna el tiempo en milisegundos desde que el Arduino arrancó. Existe riesgo de overflow cerca de
los 50 días.

}
/*

En este codigo se lee un único caracter de entrada por el puerto serie cuando está

disponible y se imprime el eco.

En el ejemplo se presenta cómo se transmite una cadena constante de caracteres junto al dato leido en formato
decimal.

*/

int incomingByte = 0; // Variable que representa el byte leído.

void setup()

Serial.begin(9600); //Velocidad bits por segundo.

void loop()

// Prueba si hay un caracter en el buffer de entrada.

if (Serial.available() > 0) // Si hay un caracter de entrada ( Serial. available es 1)

incomingByte = Serial.read(); // Lee el caracter de entrada.

Serial.print("I received: "); // Cadena constante de impresión (Sin salto de línea)

Serial.println(incomingByte, DEC); //Imprime el caracter en formato decimal segundo argumento es

sobrecargado (DEC).

}
/*

En este código se lee la salida de un sensor foto sensible configurado para una

entrada digital (pin A0) y se emite un zumbido acorde a la intensidad leida a travez de un

zumbador (buzzer) conectado al pin 12.

La onda cuadrada de control se mantiene activa hasta que se llame a la función

noTone().

*/

int zumbador = 12;

int fotoelectrico = 0;

void setup()

void loop()

int lecturaADC = analogRead(fotoelectrico); // Lectura ADC.

int tono = 200 + lecturaADC / 4;

// Escalamiento de la frecuencia Hz

tone(zumbador, tono); //Se emite un pwm al 50% con la frecuencia calculada por tono

}
/*

Código de ejemplo donde se lee una cadena de datos serial y se interpreta el comando recibido como una función

que controla el estado de encendido

y apagado de un LED sujeo al pin 13.

Los comandos validos ON, OFF encienden o apagan el led.

Cualquier otro comando, no tendrá efecto.

La cadena debe ser enviada en mayúsculas.

*/

int led = 13; //Led sujeto al pin 13.

void setup()

pinMode(led,OUTPUT); //Configuración de la salida digital.

Serial.begin(9600); // 9600 baudios, 8 bits, 1 stop, sin paridad.

Serial.flush(); //Mantener limpio el buffer de comunicación

void loop()

String input=""; //Inicialización de la cadena que servirá para leer las tramas de entrada.

while (Serial.available()>0) //Mientras exista un caracter disponible para leer.

input += (char)Serial.read(); //Concatena el dato en la variable input, es importante el casting del tipo de dato a
caracter.

delay(5); // Hasta 5 milisegundos de espera para probar si hay aún datos en el buffer de entrada.

if(input=="ON") //Si se recibe la cadena <ON> (omítanse los caracteres <>)

{
 digitalWrite(led,HIGH); //Enciende el led

else if (input=="OFF") // Si se recibe la cadena <OFF>

digitalWrite(led,LOW); //Apaga el led

else //Si no es ninguno de los anteriores

//No se ejecuta alguna acción.

}
/*

En este código se utiliza una salida digital para controlar mediante pwm un motor de DC.

La velocidad de giro es dependiente de una lectura analógica sujeta al pin analógico 3.

La salida de control se da a travéz del pin digital 9.

*/

int motorDC = 9; // Salida a motor

int analogPin = 3; // Pin de lectura de adc.

int val = 0; // Variable auxiliar de lectura.

void setup()

pinMode(motorDC, OUTPUT); // Configuración como salida digital.

void loop()

val = analogRead(analogPin); // Guarda el valor de lectura (0-> GND, 1023->VCC)

analogWrite(motorDC, val / 4); // Escribe un PWM en el pin del motor con ciclo de trabajo dependiente de la lectura.

//Se divide por 4, dado que la lectura es a 10 bits (ma 1023), y el pwm es de 8 bits (max 255).

delay(10); // 10 milisegundos antes de la siguiente muestra del adc.

}
/*

En este código se controla un led RGB que permite establecer una tonalidad y especificada en sus componentes azul,
verde y roja.

El led RGB debe ser de tipo ánodo común.

El uso de pwm sujeto a la función analog write tiene una frecuencia constante de al rededor de 980 HZ.

*/

int redPin = 11; //asignación de pin PWM para color rojo

int greenPin = 10; //asignación de pin PWM para color verde

int bluePin = 9; //asignación de pin PWM para color azul

//Comenta la línea si el led es cátodo común.

#define COMMON_ANODE

void setup()

pinMode(redPin,OUTPUT);

pinMode(greenPin,OUTPUT);

pinMode(bluePin,OUTPUT);

void loop() {

setColor(255,0,0); //prueba de color rojo puro.

delay(1000);

setColor(0,255,0); //prueba de color verde puro.

delay(1000);

setColor(0,0,255); //prueba de color azul puro.

delay(1000);

setColor(255,255,0); //prueba de color amarillo puro

delay(1000);

setColor(170,0,170); //prueba de color púrpura

delay(1000);

setColor(0,255,255); //prueba de color cyan.

 delay(1000);

setColor(255,255,255); //prueba de color blanco

delay(1000);

setColor(130,240,8); //Color sorpresa (ver tabla RGB)

delay(1000);

//Función personalizada.

void setColor(int red, int green, int blue) //Establece el color en el led rgb.

#ifdef COMMON_ANODE //Esta operaciones tomaran efecto solo si se comento la línea en la cabecera. (#define
COMMON_ANODE)

red=255-red;

green=255-green;

blue=255-blue;

#endif

analogWrite(redPin,red); //Establece el valor de rojo

analogWrite(greenPin,green); //Establece el valor de verde

analogWrite(bluePin,blue); //Establece el valor de azul

}
/*

Este codigo utiliza una recepción serial de cadenas de datos para controlar el paso de un servomotor.

Se debe incluir el archivo cabecera Servo.h para su correcta operación.

Si recibe una letra D, entonces se moverá un paso de 10 grados aproximadamente a las derecha.

Si se recibe un letra I, entonces se moverá un paso de 10 grados aproximadamente a la izquierda.

El ángulo nuevo es modificado y escrito en el pin del motor, cuando una trama es recibida correctamente.

*/

#include <Servo.h> //Incluisión del archivo de cabecera para poder controlar el servomotor.

int ServoPin = 6; //Pin 6 para salida directa al servomotor.

int angle = 90; //Ángulo de giro, inicialmente a 90 grados lo que implica una posición neutra.

Servo servo; //Instancia del tipo Servo, necesaria para la llamada a las funciones de escritura de ángulos.

void setup()

Serial.begin(9600); //9600 bps, 8 bits, 1 stop, sin paridad.

Serial.flush(); // Mantener el buffer de comunicación limpio.

servo.attach(ServoPin); //Establece el pin de servomotor.

void loop()

String input=""; //Inicializa la variabla que toma la cadena de datos para la recepción de datos.

while (Serial.available()>0) //Mientras exista un caracter disponible para leer.

input += (char)Serial.read(); //Concatena el caracter (casting).

delay(5); //Espera 5 milisegundos para probar si hay aún datos en la entrada serial.

if(input=="D") //Paso a la derecha detectado

{
 if(angle>=0&&angle<=180) //Mientras el ángulo esta entre 0 y 180 grados.

angle=angle-10; //Modifica el paso por 10 grados a la derecha.

else {angle=0;} //Si el paso llega al mínimo posible, lleva el servo a la posición derecha.

servo.write(angle); // Escribe el ángulo modificado.

if(input=="I") //Paso a la izquierda detectado

if(angle>=0&&angle<=180) // Mientras el ángulo esta entre 0 y 180 grados.

angle=angle+10; //Modifica el paso por 10 grados a la izquierda.

else {angle=180;} //Si es un número excedido llévalo a la máxima posición izquierda.

servo.write(angle); // Escribe el ángulo modificado.

}
 KEY ISSUES REGARDING DOMOTIC APPLICATIONS
Santiago Lorente
Telecommunication Engineering School, Universidad Politécnica de Madrid
Ciudad Universitaria, E-28040 Madrid, Spain
Phone: + 34-639-567-115;/ax: + 3491-336-73-20; e-mail: slorente@etsit.upm.es

Keywords: Domotics, Automation, Control, Information, Communication, Teleservices

Topic: Emerging Technologies and Applications

Extended Abstract:
Domotics, in Latin languages, is a term meaning automation ofhouses. In English this is generally
referred to as "Smart House". In Spain, other ways of calling this is "Digital Home" or "Electronic
Home". It should be mentioned that in the literature, "home", "house" and "household" are used
alike. So far, Domotics has been approached predominantly, if not uniquely, as a technological
platform having to do with automatíon and control. The house was conceived of pretty much, using
the cybernetic analogy, as a machine whose goal was controlling it by way of various automatic
devices. Yet, the main contention of this paper lies in the fact that technological convergence
between Control and Automation Technologies, on the one side, and Information and
Communication Technologies, on the other, very interestingly contributes both to the enrichment of
the technological infrastructure of the home and to the benefits of its dwellers, which eventually
should be the main purpose oftechnological endeavour. That is to say, the state ofthe art in present­
day technology provides easy avenues for adequately putting together electricity, electronics,
computer and telecommunícatíons in a single technological mix. Under this perspective, the
conceptual application scheme derived from an integral technological approach could be put
forward as follows:

General Concept Applications

Meters (watermeter, gasmeter, electricity
meter ...)
Heating
Air conditioning
Lighting
(Tele)Management ofthe house
Plugs
Active security (cameras; smoke, water,
fire and intruder sensors ... )
Passive security
Window shades, window canopies ...

Beds
Washing machine
Drier
Vacuum cleaner
Refrigerator
Daily (Tele)Tasks
Toaster
Díshwashíng machíne
Oven
Microwave Oven
Kitchen

0-7803-8482-2/04/$20.00 ©2004 IEEE. ·121

 Radio
-.
TV
(Tele) Leisure Videotape
HiFi
(Tele) Activities Digital Photography
PDA
PC
(Teleservices)
Printer
I Scanner
Some implications can be derived from the above-mentioned integral application scheme that can
additionally be considered as myth-overriding approach:

- Any technology based on electricity, and especially on electronics, can be profitably be used.
- Thcsc tcchnologics encompass automation, control, information and communication. It is not
true that domotics are uniquely related to automation and control.
- Both broad and narrow band are useful for this purpose, depending on the application
requirement. The "only broadband" discourse should be downgraded.
- Both isolated products and overall systems are useful, too, for this purpose, depending on the
degree of "domotization" that is pursued. "Domotizing" a house is not an allhothing activity,
but rather a gradual one, and here economic considerations should be at stake.
- Both new and already built houses can be the target of domotics. Wireless technology emerges
as an answcr to installing domotic tcchnology in thc lattcr houscs.

The main social needs underlying the social demand are comfort, statudprestige, and security, and
these needs should be met, adapting technology to that end.

Markets that should most particularly be thought of as targets, following marketing research, should
be, firstly, those of highly mobile young couples with no children, who have clear needs of
controlling the house from the outside and of tcleservices that kcep them from additional
commuting, and secondly, the no mobile elderly and the handicapped, who have also clear needs of
controlling the house from the inside, together with teleservices that they can otherwise reach.

Among the main teleservices to be considered are those of tele-assistance, tele-information and
telebanking.

0-7803-8482-2/04/$20.00 02004 IEEE. 122

 A power line communication stack for metering,
SCADA and large-scale domotic applications
Filipe Pacheco1, Maksim Lobashov2, Miguel Pinho3, Gerhard Pratl4
Instituto Superior de Engenharia do Porto
Porto, Portugal
{1ffp|3lpinho}@dei.isep.ipp.pt
Abstract—This paper describes the communication stack of
the REMPLI system: a structure using power-lines and IP-
based networks for communication, for data acquisition and
control of energy distribution and consumption. It is
furthermore prepared to use alternative communication
media like GSM or analog modem connections. The REMPLI
system provides communication service for existing
applications, namely automated meter reading, energy billing
and domotic applications. The communication stack,
consisting of physical, network, transport, and application
layer is described as well as the communication services
provided by the system. We show how the peculiarities of the
power-line communication influence the design of the
communication stack, by introducing requirements to
efficiently use the limited bandwidth, optimize traffic and
implement fair use of the communication medium for the
extensive communication partners.
Keywords-Power line communication, remote metering,
SCADA, communication protocol stack, communication
architecture, bandwidth sharing.
I. INTRODUCTION
The REMPLI project aims at creating a communication
infrastructure that is suitable for data acquisition (e.g.
reading of utility meters in private households), control of
metering and SCADA devices and domotic applications.
REMPLI is based on a power-line communication system
(PLC), which is designed within the project. We focus on
low-bandwidth and long-distance data transmission over
low-voltage (LV) and medium-voltage (MV) power lines
with redundant and alternating communication paths
(meshed and switched power line). The upper level of
REMPLI network is an IP (Internet Protocol) backbone,
which connects PLC segments to metering, SCADA, and
domotic systems.
This paper presents the architecture of PLC
communication, including network, transport and
application layers with focus on the specific solutions for a
large-scale deployment. A detailed description of the
REMPLI system can be found in [1] and [2].
II. REMPLI COMMUNICATION
The REMPLI PLC network spans from private
apartments to a secondary (MV/LV) transformer station
and then further to a primary (MV/HV) transformer station.
This work is being partly supported by the EC within project REMPLI
(NNE5-2001-00825) and by FCT (CISTER UI 608)
0-7803-8844-5/05/$20.00 c 2005 IEEE.
Vienna University of Technology
Institute of Computer Technology
Vienna, Austria
{2lobashov|4pratl}@ict.tuwien.ac.at
These two segments are coupled using PLC Bridges (we
write the terms Bridge, Node, and Access Point starting
with a capital letter, since these terms refer to the
components that are designed in the REMPLI project).
From the application point of view Bridges are transparent:
they forward data up- and downwards. Nodes, installed in
households (or any other energy consumption location),
communicate directly to the local metering and SCADA
equipment. Another device, the Access Point, terminates
communication over power line at the primary transformer
station. The upper side of the Access Point is connected
directly to the IP backbone. Application servers at the
utilities communicate to Access Point(s), typically, in a
request-response mode. Access Points send these requests
via PLC, over Bridges if necessary, to Nodes. Responses
from Nodes are transported back to the servers. The system
also supports non-request/response communication: Nodes
can generate alarm messages, which are delivered to an
appropriate server without explicit request.
The REMPLI project does not attempt to develop new
software for utilities. Instead, the REMPLI system
transparently tunnels protocols that are understood by
application servers and metering/SCADA devices. The
majority of metering and SCADA protocols are not
session-oriented, meaning that one request results in one
response without any prior connection setup.
The Communication stack at both Nodes and Access
Points is conceptually symmetric and includes the
following layers (Figure 1):
The physical layer implements power line medium
coupling. Design of the physical layer is outside the scope
of this paper.
The network layer implements a master/slave time
division network with basic error recovery and short-
distance routing mechanisms, and is responsible for
maintaining information about whether a Node is currently
active in the network ("logged in") or not.
The transport layer supplements the network layer
with inter-network routing, fragmentation, request/response
pairing, address translation and reverse-channel (Node to
Access Point) alarm service. The current transport layer
that uses PLC communication may be replaced by new
61
implementations supporting other communication mediums
like GSM links, phone line modem, etc…
Finally, the application layer carries out two tasks:
• conversion of metering/SCADA protocols into a form
that is suitable for transmission over PLC (including
reverse process on the other side);
• multiplexing of data from different application servers
and their respective sets of equipment over the same
PLC channel.
Metering SCADA Energy SCADA
System Server meter switchgear
Access Point
Driver A Driver B Driver A Driver B
Appl. Layer Appl. Layer
De/Multiplexer De/Multiplexer
PLC Transport Layer PLC Transport Layer
PLC Network Layer PLC Network Layer
PLC Physical Layer PLC Physical Layer
PLC network
Figure 1. PLC communication stack
The communication stack at the Bridge is similar.
However, in case no SCADA or metering devices are
installed at the MV/LV transformer, the application layer is
not used by utility applications. MV and LV parts of the
Bridge share the same transport layer, which performs bi-
directional data forwarding.
III. NETWORK AND TRANSPORT LAYERS
These two layers provide communication functionality
to the Application Layer. Services available at the Access
Point side include: the Send Unicast Request with or
without response, the Retrieve Alarm Message, the
Retrieve Status Service and the Node Login/Logout
Notification.
Services available at the Node side include: the Receive
Request/Send Response, the Send Alarm Message, the Set
Status Service and the Access Point Login/Logout
Notification.
Communication services in each PLC network level are
handled by the Network Layer, the Transport Layer takes
care of end-to-end communication (see Figure 2).
Network Transport
Layer Layer
A ccess A ccess
P oint P oint
Medium
Voltage
PLC
Network
Bridge Bridge
Low Voltage
PLC
Network
N ode N ode N ode
Figure 2. Network Layer and Transport Layer
Node communication services
The Network Layer uses a master-slave time slot
scheme and multiple masters may share the medium either
using different slots in each cycle or using separate
frequency bands. The minimum time slot cycle is 3 slots
and typically 2 master networks sharing the same frequency
band will use 4 slots cycles: 2 for each master (see Figure
3). The drawback of multi-master networks using different
frequency bands is that a slave cannot be connected to
several masters at the same time in this situation. In this
case a slave can “switch” masters when needed but this
process will take considerable time.
The “connection” process is fully automated by the
Network Layer: each master device has a list of authorized
slaves (using unique serial numbers) and will periodically
scan for new devices. The authorized slaves will connect to
the designated master or masters and will automatically
adjust themselves to the masters’ frequency bands and
other communications parameters. If a slave detects a lost
connection to all its masters it will try to connect to other
masters scanning all the frequency bands.
This solution enables easy setup of very large networks
simply configuring parameters on the easily accessible (and
small number) Access Points. It also automates the
installation of new Nodes or Bridges: the system manager
simply has to configure the new serial numbers in the
Access Point and after a while the new Node or Bridge will
be available on the network.
In terms of data communication services the Network
Layer implements not only basic “unconfirmed send“ and
“send confirmed” services but also an automatic poll
system (not only to check slave connectivity, but also to
find new devices) and a slave-based repeater mechanism to
increase the coverage of the master/slave network (at the
expense of additional delays). Optionally it can be
configured to do automatic retries on the confirmed service
exchanges.
62
 S3 connected to M1 and M2
S4 connected to M2 time
delay in slave responses
Device inactive Master/slave transaction
Slave waiting for Slave waiting for
master’s request master’s connection
Figure 3. Multiple master network
The timings of the Network Layer services are handled
by an internal dispatcher service. The dispatcher manages
the traffic from the 3 different priorities (only 2 on slaves)
queues, the polling cycles and additional confirmed
requests to retrieve data from slaves that have pending
information on their queues.
Access Points act as masters in the network; Nodes are
slaves. Bridges have a Slave Network Unit at the Medium
Voltage (MV) side and a Master Network Unit at the Low
Voltage (LV) side.
The Transport Layer extends the fixed-size master/slave
packet service of the Network Layer to the
Request/Response end-to-end services required by the
Applications: for this task it will fragment the data at the
source and rebuild it at the destination. Since the MV PLC
and the LV PLC may have different frame sizes, Bridges
have to store and join/split fragments as needed.
Fragmentation in this system must be aware of two
limiting factors in terms of header data:
• the limited data payload available in each frame.
This implies that absolute fragment numbering
schemes are not acceptable and an offset based
system is implemented.
• the high error rate that may occur in certain
periods of time. This implies that any fragment
identification method must be robust enough to
survive the loss of several fragments.
To solve these issues our basic implementation uses 6
bits for fragment identification and 6 bits for packet
identification. Depending on the final field conditions this
numbers may be adapted to a particular deployment.
The system must also handle huge packets in-transit on
the Bridges. Since several large packets cannot be stored in
the limited Bridge memory we use temporary buffers to
store fragments as they are received, and try to forward the
data as soon as possible. As soon as the forwarded data is
delivered the temporary buffers are discarded. There is also
63
a system to confirm correct delivery of the fragments of
large packets even if the original application service is non-
confirmed. When a delivery failure is detected the rest of
the packet is discarded at the Bridge and this information is
forwarded to the origin.
The Transport Layer also does automatic address
translation and route discovery using as little information as
possible after the basic device information is exchanged.
When a Network level connection is established, the
Transport Layer is informed, so that it can build a map of
available paths (and respective Network Layer addresses)
from each Access Point to each Node. The map of available
paths also includes information about each link quality
(delay/error rate).
The starting point for this process is a table configured
in each Access Point with information about each device:
node address (used by application drivers), unique serial
number and Bridges that can be used to reach the device.
Then the Access Point Transport Layer transfers the unique
serial numbers to the local Master Network Layer. When a
Bridge connection is detected the Access Point Transport
Layer sends special packets with the list of connection data
for the nodes that are authorized for that particular Bridge.
The Bridge Transport Layer transfers this information to its
local Master Network Layer. When a device is connected
do a Bridge, the Bridge Transport Layer first allocates a
Bridge ID to the new device and sends this Bridge ID and
the node Unique Serial Number to the Access Point. When
the Access Point wants to send information to the node it
will include the Bridge ID on the Transport Layer header.
The Bridge Transport Layer forwards periodically the table
with link quality of the nodes in a particular Bridge to all
the connected Access Points so the latter can have an
estimation of current network link status.
Some of these services depend on reliable delivery of
the Transport Layer’s own data packets. The Transport
Layer has special internal services that ensure trustworthy
transfers of data not only from Masters to Slaves but also
on the reverse direction.
Finally, the Transport Layer must do its best to
guarantee a fair use of the network paths and to enforce
application requests priorities in a meshed dynamic
network with variable link capabilities and requests. The
links change not only due to physical reconfiguration of the
network (power distribution switching devices) but also
due to external electromagnetic interference (e.g. motors,
welding machines, etc). This task is accomplished using an
internal scheduler that analyzes the current requests and the
available path map (see Figure 4).
The Transport Layer handles redundancy (see Figure 5)
for a particular Access Point – Node data transfer. When a
packet is sent from an Access Point the Transport Layer on
the source checks the available paths and selects the most
appropriate for the given moment. To limit the complexity
of the system all the fragments of a request (and the
possible response) follow the same route. This has the
additional benefit that for most requests the routing
calculations are done in the Access Points, the devices with
more computing resources in the system.
Access Point - HV/MV St.
Bridge - MV/LV St MV Node
LV Node
Logical Connection LV Power Line MV Power Line
Figure 4. Examples of geographical network layout with power and
logical connections
In terms of routing packets from the Access Point to a
Node are processed by Bridges simply reading the routing
information from the transport layer header and replacing it
with backtrack information if needed (for requests with
response). To limit the usage of data in the transport layer
header all this routing information is used using (low-bit
length) local indexes that are only valid for a particular
master/slave combination.
The application priorities processing algorithm is
configurable and a system may have strict priority serving
(i.e. higher priority queues are completely served before
lower priority queues) or have a minimum bandwidth share
for each priority class (i.e. higher priority queues are served
until they are empty or lower priority queues with
guaranteed bandwidth are not serviced yet). If needed the
Transport Layer’s application priority system may be
completely overridden by applications and requests are
mapped directly to the Network Layer’s priorities (2
priorities in the slaves, 3 priorities in the masters). Since
Bridges must also handle packed priorities (as well as Node
responses), the priority information must be included in the
Transport Layer header of most packets.
64
IP
TL redundancy De/Mux redundancy
(multi Bridge) (multi AP)
Figure 5. Transport Layer redundancy and Driver De/Mux redundancy
When it comes to spontaneous information from the
Nodes, there are two alternative services each with its own
characteristics. The Status Services is a low-bandwidth
process that enables Nodes to update a local status multi-bit
field and this information will be transmitted over the
network to all the Access Points to whom the Node is
connected. This service is a non-confirmed service and uses
very few network resources. For critical Node to Access
Point information transfer the Alarm Service guarantees
fast delivery of the data to at least one Access Point. This
service uses a lot of network resources and so it should be
used only in exceptional situations.
All this Transport Layer features combined results in
services for the Application Layer that provide:
• Unconfirmed request service and Request/Response
service that map easily to several application
scenarios
• Node-to-Access Point Alarm service with
guaranteed delivery and high priority
• A (small byte count) Status Service that provides a
simple and effective way to keep track of Node
status
• Variable length data transfer services, exceeding the
memory capacity of the foreseen devices
• Low network overheads for most used requests
• Large network support: up to a thousand Nodes per
Bridge, hundreds of Bridges per Access Point, and
thousands of Nodes per Access Point
• Plug&Play operation: Nodes can simply be
connected to the network and the Transport Layer
will establish a connection to the authorized devices
IV. APPLICATION LAYER
The application layer, available at both Node and
Access Point (and Bridges, if required), consists of:
• De/multiplexer (one component at every entity);
 • protocol drivers (one driver per protocol, both at
Node and Access Point side).
Protocol Drivers at the Access Points interface with
utility software over IP. At the Node side protocol drivers
implement the interface to the equipment, namely meters
and SCADA devices. There is one driver per protocol;
multiple homogenous devices, such as M-Bus meters, can
be connected to the same driver. Depending on the
application, different standardized protocols are
implemented (using Drivers), namely IEC 60870 series, EN
62056 (also known as IEC1107), and EN 1434-3
commonly known as M-Bus.
The De/Multiplexer merges streams of messages,
received from different drivers (these are requests from
servers, responses from equipment and internal traffic
between the drivers). The multiplexed stream is transmitted
to a receiver device, where the De/Multiplexer distributes
it, so that a target driver receives only the data that was
designated to it. This requires transmitting additional piece
of information (1-byte destination driver address) in every
packet, which allows for up to 255 sender/recipient drivers
at every node and Access Point. This concept is somewhat
similar to port numbers in the TCP/IP suite.
In the REMPLI system drivers, implementing tunneling
of a particular protocol, talk strictly to each other. For
example, all drivers for an IEC 60870 protocol may be
assigned the same address (say, 10) on all Access Points
and Nodes. This means, that communication always occurs
between pairs of drivers: a driver at the Access Point sends
packets to its siblings at the Nodes; responses are delivered
back to the same address. In fact, apart from sharing PLC
bandwidth, different protocol drivers do not influence each
other at all; communication between pairs is transparently
multiplexed onto the same medium without “intervention”
from drivers themselves.
Apart from multiplexing communication, the
De/Multiplexer at the Access Point implements one more
function: if an Access Point cannot reach target Node, the
De/Multiplexer can re-route request from a driver (on
behalf of an application server) through another Access
Point. Re-routing is done over the IP backbone (see
Figure 5), which links all Access Points to the application
servers and “horizontally”, between each other.
In a switched PLC network, where a given
communication path between Access Point and Node pair
can terminate at any time, every possible path to the Node
should be covered by a separate Access Point (PLC
65
Master). Redundant paths in a meshed PLC are handled by
the Transport Layer, as described above. PLC switching is
handled by the Application Layer. Application servers and
drivers do not need to be aware of duplicate and alternating
communication paths. A server can connect over IP to any
Access Point. Its requests are re-routed via other Access
Points whenever necessary.
In a meshed network special attention is paid to
transmitting multicast and broadcast requests. Since a
single Access Point may not be able to reach all Nodes,
such messages have to be re-routed by De/Multiplexer to
several, or even all Access Points, which altogether provide
complete coverage of the addressed nodes. Since every
Access Point then sends the request over PLC
independently, target Nodes can receive duplicate
messages. These are filtered out by De/Multiplexers at the
Nodes.
Since the De/Multiplexer and the underlying PLC stack
isolate communication between different driver pairs, the
system is easily extendable to support tunneling of future
protocols that are not anticipated at the project design stage.
V. CONCLUSIONS
This paper presented the communication stack used in
the REMPLI system, which provides communication
service for existing utilities applications. This paper focuses
on the architecture of the network, transport and application
layers with focus on the specific solutions for large-scale
systems. We presented how the design of the
communication stack is influenced by the particular
requirements of the power-line communication, particularly
to provide efficiency in the use of the available bandwidth,
optimizing traffic and guaranteeing fair use of the
communication medium.
VI. REFERENCES
[1] A. Treytl, T. Sauter, G. Bumiller. "Real-time energy
management over power-lines and Internet”;
Proceedings of the 8th International Symposium on
Power-Line Communications and its Applications, vol.
ISPLC’04 no. 8, March 2004, pp. 306-411.
[2] G. Pratl, M. Lobashov. "Remote Access to Power-Line
Networked Nodes: Digging the Tunnel"; WFCS 2004
5th International Workshop on Factory
Communication Systems, Vienna, Austria; Sept. 2004;
p. 323-326.
 AN INTEGRATED SOLUTION FOR HOME AUTOMATION
G. Giorgetti1, E. Gambi2, S. Spinsante3, M. Baldi3, S. Morichetti3, I. Magnifico1
1
AUTOMA Srl, ITALY, 2Università Politecnica delle Marche, ITALY, 3ArieLAB Srl ITALY
ABSTRACT
The increasing diffusion of home area networks (HANs),
intended for the delivery of multimedia contents (e.g. TV
programs, movies, music) as well as home automation data
(e.g. household appliances, lighting and surveillance
controls), represents a new challenge for networking.
However, at present, most of the available domotic and
building automation solutions provide single answers to the
market requirements, and their heterogeneousness makes
very hard an integration process. In this paper, a project for
an integrated solution is presented, based on both
commercial and customized devices developed ad-hoc.
Since the convergence of many traditional services over IP-
based infrastructures drastically increases the amount of IP
data traffic to be delivered to the users, questions about the
Quality of Service management arise and must be taken into
account.
Index Terms— Domotic automation, building automation,
multimedia home systems, Quality of Service.
1. INTRODUCTION
Modern houses are requested to be provided with digital
control systems for functional services, like household
appliances, lighting and surveillance. Moreover, digital
entertainment contents must be delivered in each single
room, as, for example, digital radio and television services,
movies, music and others. Many standards have been
approved for the exchange of home automation data, and
industrial protocols can also be adapted to fit home
automation applications. All these protocols can be used for
short-distance and low-cost connectivity of sensors and
actuators. However, when considering the integration of
home automation services with multimedia services over IP
based networks, gateways must be provided, able to
interface and adapt home automation data transport to IP-
based networks, in order to allow an easy management of
the connected devices, both from the home internal network
and from external networks [1], [2]. In this integrated
scenario, Quality of Service (QoS) becomes a fundamental
issue when several streams, carrying both control and
entertainment data, with different time and rate
requirements, must be transferred over a local area network
comprising heterogeneous devices [3]. In this paper, we
present the project of a Home Area Network, called WENO
Project, in which entertainment and home automation
services must coexist, in order to provide all users with
unified access stations for either entertainment applications,
the delivery of home data (such as video surveillance
streams), and the control of domestic facilities.
2. PROJECT DESCRIPTION
The system architecture we propose must satisfy two major
requirements:
i) the need for a high speed communication bus able to
deliver high quality services, like video entertainment, video
interphone, and IP telephony;
ii) the implementation of low cost local nodes used for
sensoring and control execution.
The first requirement is satisfied through the adoption of an
Ethernet bus that interconnects the system control blocks. A
five-port switch represents the core of the interconnection
structure, concentrating all the communications towards the
System Server, that allows a centralized management of the
whole network. In its turn, the System Server may be
remotely controlled and configured via Internet, by means
of a web-based application, being interfaced towards a
communication provider over an ADSL connection. From a
functional point of view, the system may be divided into
three sub systems:
1) room control;
2) room and external communication;
3) entertainment signals delivery.
As a matter of fact, an XN-Player (XeNo-Player) is
responsible for the delivery of multimedia contents to the
users, controlled by a sort of Electronic Program Guide and
Selection, that allows to transmit the programs selected by
the users. At the same time, users are equipped with an
IPTV player and a TV monitor. Communication among
rooms and towards the external is ensured by the
implementation of an IP Telephony Server, interfaced
through the System Server with the ADSL link. The
communication subsystem includes an external video
interphone, implemented by means of a device located
outside the user’s premise, and equipped with a
videocamera and bidirectional audio. The device can
communicate over the Ethernet link with an internal “twin”
device, provided with an LCD monitor. The presence of this
stand alone receiver, usually located near the main entrance
door, is required by the users, but, according with the
proposed architecture, any Room Board, equipped with a
monitor, may interface the external video interphone. The
Room Boards (XN-CPU) are able to collect all the
communications originating in a room towards the System
Server, for remote monitoring purposes.
Fig. 1 – Block scheme of the proposed system
Inside any room, the requirement of controlling sensors and
actuators is satisfied through the adoption of a low speed,
but very robust, communication bus. The CAN bus was
selected as the best suited transmission technology, due to
its high transfer rate and the low cost of enable nodes,
mainly due to the availability on the market of
microcontrollers implementing the CAN protocol together
with its physical interface. As a consequence, any Room
Board implements an Ethernet interface to communicate
a) b)
CAN
bus
Fig. 2: Realized boards of XENO Project
with the System Server, and a CAN Interface to monitor the
Local Nodes. The Local Nodes provide room monitoring
functions and command execution, like presence monitoring
and light switch on/off, but also external light intensity
sensing and internal light intensity variation. With the aim
of making the whole system more robust against unexpected
Room Board switches off, the network of Local Nodes can
act as an independent network, being the “in-the-room”
commands executed independently from the whole system.
Finally, the Room Boards are equipped with a Zigbee [4]
wireless interface for a remote control of the system
functionalities.
3. THE REALIZED BOARDS
The choice of hardware components for the board design
has been principally lead by the need of an easy, and low
cost, acquisition of the components from resellers, jointly
with a simple and effective PCB design. Mechanical
compatibility with cases of commercial light socket/switch
has been also considered. Fig. 2 shows four realized boards,
that are, respectively:
a) XN-CPU: the bridge between the Ethernet and the CAN,
able to manage all the room functions and to act as a
supervisor. Its core is a UBICOM IP2022 processor,
with 2 Ethernet interfaces and 1 CAN interface; a web
server is implemented, provided by UBICOM.
b) XN-3OUT: the digital output board, that manages up to
three relais over the CAN bus. Its core is a Microchip
PIC24F-16 bit.
c) XN-3IN: the input board that can manage up to three
analog and/or digital inputs over the CAN bus. Its core
is a Microchip PIC24F-16 bit.
d) XN-HOME + XN-XBEE: the ZigBee board with SPI
interface that can act as a brigde between the ZigBee
network and the CAN network. Its core is a Microchip
c)
CAN
d)
bus
 PIC24F-16 bit. the total bandwidth available on the uplink port of the layer
All the boards were designed, developed and tested at the 2 switch down to 10 Mbps. In this scenario we simulated
AUTOMA laboratories. different congestion conditions by means of an additional
“noise” traffic, generated through Iperf [8].
4. SYSTEM PERFORMANCE EVALUATION

Once defined the hardware of the system, it is necessary

to ensure the correct providing of all services. In order to
assess the system performance, we considered the case of a
home network based on a home server platform, able to
concentrate all the user’s services in a unique
hardware/software solution. To this aim, we adopted the
LinuxMCE client/server software platform [5], that allows
the management of all home entertainment and automation
services. LinuxMCE integrates a media and entertainment
system for music, movies, and TV, a home automation
system to control lighting and household appliances, a
phone system with video conferencing, a security system
with video surveillance and a home PC solution.
Fig. 3: Implementation of a QoS framework for HANs.
LinuxMCE, that relies on MythTV for the management
of digital television services [6], does not re-transmit
directly the received DVB-T transport stream. Instead,
digital television contents are first saved in local buffers, Quality of Service
thus allowing the implementation of a personal video
1) Measured Parameters
recorder (PVR) service, and then retransmitted on unicast
links. No real time protocols are adopted for retransmission;
The system model we are interested in relies on TCP
instead, TCP connections are used for point-to-point
instead of RTP protocol for audio/video streaming,
streaming. Differently from RTP, TCP implements
therefore we adopted a different approach to evaluate the
congestion control, so we want to verify the need and
Quality of Service. Differently from the previous case, no
effectiveness of QoS management also in this different
real time capabilities are implemented and, instead, TCP
scenario.
connections are exploited; therefore, QoS is mostly related
The implementation herein described for the QoS
to the allocated bandwidth.
framework is depicted in Fig. 3. As shown in the figure, we
A first set of measurements have been performed on the
considered the case of a unique home server, that exposes
ingoing traffic for the considered client. For the sake of
multiple services, and interfaces an Internet gateway that
brevity, we focus on the IP bandwidth allocated to the
ensures broadband data connectivity; multiple clients are
audio/video stream. Other measurements have been
located on the HAN. We focused on one of such clients, and
performed on the layer 2 switch uplink port, to evaluate its
analyzed its ingoing traffic through the Wireshark [7]
total allocated bandwidth, and the partial bandwidth
network traffic analysis software tool.
allocated to each service.
Hardware and Software Infrastructure
2) QoS Rules
The setup previously discussed relies on the adoption of
the following components:
Table I reports the QoS traffic classes and rules for the
1) QoS router: Pentium III 800 MHz with 256 MB RAM
considered system.
and Zeroshell Linux operating system.
We varied the guaranteed bandwidth allocated to the
2) Home server: Pentium IV 2.8 GHz with 512 RAM and
DVB-T service, in order to verify whether, in the case of
Linux operating system with LinuxMCE.
network congestion, such a traffic can be effectively served
3) Internet gateway: Intel Mobile 1.2 GHz with 512 RAM
by means of the QoS router.
and Windows XP operating system.
4) Clients: Pentium processors with at least 512 MB RAM
and suitable software clients.
In order to simulate a high number of clients, we reduced
 association with the QoS rules reported in Table I, we
TABLE I obtained results that confirm the effectiveness of the traffic
QOS RULES FOR THE SECOND IMPLEMENTATION. shaping function of the QoS router. They are shown in Fig.
Class Priority
Maximum Guaranteed 4. The priority assigned to the digital TV service, with
Bandwidth Bandwidth respect to the Internet service, reflects on its available
noise high variable variable bandwidth in different congestion conditions. The total
home guaranteed bandwidth is allocated to the different (3, in our
high 500 kbps 500 kbps
automation case) audio/video streams, in order to preserve their quality.
Internet In presence of congestion, however, a TCP connection may
low 1 Mbps 56 kbps be released, as occurs for the 6 Mbps guaranteed bandwidth
traffic
DVB-T curve in Fig. 4 (a), that exhibits a change in its slope. In
medium 7 Mbps variable such a case, the remaining connections can exploit
service
additional bandwidth, thus improving their quality. The
3) Test Results Internet service, on the contrary, has low priority, so its
allocated bandwidth is immediately reduced when
We have verified that, in absence of additional traffic, the congestion increases, with a substantial quality loss.
services we simulated (i.e. 3 audio/video streams for the
DVB-T service and a broadband Internet data stream) 5. CONCLUSIONS
require 8.2 Mbps total bandwidth, that is 82% of the
available bandwidth. Then, we have added a “noise” traffic In this paper we presented the so called XENO Project, a
with variable bitrate (namely 800, 1200, 1800 and 2300 complete solution for home and building automation,
kbps) in order to simulate different congestion conditions currently under development, and discussed the case study
(that can be due to other network services) and verify the of a home area network where a digital television service
effectiveness of the QoS rules set for the uplink port of the must be delivered in the presence of video surveillance,
layer 2 switch. automation, and Internet traffic. We described the most
important blocks of XENO, their main features, and verified
2.4 that the introduction of a Quality of Service router permits
to effectively regulate the priority and bandwidth assigned
Service BW [Mbps]

2.3
to each service, through the definition of proper QoS rules.
2.2
Therefore, the introduction of such an element in the home
2.1
3 Mbps network architecture should be recommended, in order to
2.0 5 Mbps avoid bottlenecks and ensure continuous availability of the
1.9 6 Mbps basic and essential home functional services.
7 Mbps
1.8
0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2 2.4 REFERENCES
Noise Traffic BW [Mbps]
(a)
[1] O. Martikainen, “Internet Revolution in Telecom,” in Proc.
1.2
IEEE JVA '06, Sofia, Bulgaria, Oct. 2006, pp. 58–62.
Service BW [Mbps]

1.0 [2] I. Han, H.-S. Park, Y.-K. Jeong and K.-R. Park, “An integrated
0.8 home server for communication, broadcast reception, and
home automation,” IEEE Transactions on Consumer
0.6
3 Mbps Electronics, vol. 52, pp. 104–109, Feb. 2006.
0.4 5 Mbps [3] C. Bae, J. Yoo, K. Kang, Y. Choe and J. Lee, “Home server
0.2 6 Mbps for home digital service environments,” IEEE Transactions on
7 Mbps Consumer Electronics, vol. 49, pp. 1129–1135, Nov. 2003.
0.0
0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 2.2 2.4 [4] IEEE 802.15.4, “Wireless Medium Access Control (MAC) and
Noise Traffic BW [Mbps] Physical Layer (PHY) Specifications for Low-Rate Wireless
Personal Area Networks (LR-WPANs)”, IEEE, August 2003.
[5] http://linuxmce.com/
(b)
[6] http://www.mythtv.org/
Fig. 4: Measured bandwidth (Mbps) for the DVB-T service (a) and for the [7] http://www.wireshark.org/
Internet service (b), as a function of the noise traffic bandwidth, for several [8] http://dast.nlanr.net/Projects/Iperf/
values of the maximum guaranteed bandwidth for the DVB-T service.

In the presence of all the considered streams, in

IST-Africa 2010 Conference Proceedings
Paul Cunningham and Miriam Cunningham (Eds)
IIMC International Information Management Corporation, 2010
ISBN: 978-1-905824-19-9

An Ontological Framework for the Elderly

to Control their Home Environment
Kostas KALOGIROU1 Gerrit TELKAMP2,
1
Hellenic Institute of Transport, Thessaloniki, 57001, Greece
Tel: +302310 498461, Fax: +302310 498269, Email: kalogir@certh.gr
2
DOMOLOGIC GmbH, BȨltenweg 23, D-38106 Braunschweig, Germany
T: +49 531 3804 340, F: +49 531 3804 342, Email: g.telkamp@domologic.de
Abstract: One of the main contributors to independent living for the older society is
the efficient management of their home, without the need for help by others. The aim
of the OASIS project is future oriented, aiming at an ambient intelligence
infrastructure enabling the sharing of data and resources between heterogeneous
domotic appliances leading ultimately to contextual awareness of environmental and
subject-related conditions. In this paper, starting with a short introduction into
OASIS aim, the domotic application use cases are presented, followed by the logic
behind the design of the ontological framework for the domotic application.

Keywords: domotic, ontologies, elderly

1. Introduction
The older population is growing at a considerably faster rate than that of the world’s total
population. In absolute terms, the number of older persons has tripled over the last 50 years
and will more than triple again over the next 50-year period [1]. The profound, pervasive
and enduring consequences of ageing population present enormous challenges as well as
enormous opportunities for Information Society Technology.
The World Health Organisation defines independence as the ability to perform the
activities of the daily life with little or no help from others. It is generally regarded as
having a positive impact on quality of life. Health, impairment and functioning are very
important determinants of independent living... The goals of independent Living
Applications or Services are to maximise empowerment, independence and productivity of
individuals and their integrations and inclusion into the mainstream of society. Two options
arise here. First to provide aids to mitigate the loss of independence and second empower
the conditions that make a person to continue being independent. This second approach is
the one adopted by OASIS Integrated Project.
OASIS is a five-years European project co-financed by the European Commission, with
33 partners and 5 subprojects. Its aim is to develop a multi-system application that will
enable and facilitate interoperability, seamless connectivity and sharing of content between
various services and ontologies, covering the elderly population needs.
Taking into account all previous research, OASIS proposes an innovative approach of
integration of many AAL-enabled Independent living applications through the use of a
common set of interconnected ontologies. In this paper, the relevant concept and
developments for assisting the elderly to manage their home environment efficiently, is
presented.

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 1 of 7

2. Domotics Application in OASIS
The home environment is very heterogeneous, composed of different application domains,
devices, communication standards, user needs and wants, etc. These diverse devices use
different integration and communication systems that currently exist in the market (i.e.
KNX/EIB, LonWorks, LCN, CAN, proprietary RF communication, and other) or are
emerging. This leads to several incompatible “communication islands” at home that are not
interoperable thus limiting their functionality to what they were designed to do in the first
place and not allowing collaboration and resource management, that is essential for the
creation of an Ambient Intelligence infrastructure. Currently, multi-standard applications
are based on the pragmatic approach of developing interfaces for many different standards,
connecting them to a central platform.
Within OASIS, integration goes a step further, aiming to define a common ontological
framework for content and functionalities (including home devices safety applications). A
first such ontology has been defined within AMIGO project (IST-2004-004182), but
requires severe revision, extension and integration into OASIS Common Ontological
Framework.
Since the early stage of the project work, specific use cases were defined and analysed,
covering the whole project applications range. Three use cases refer to the domotics
application. These are presented and shortly explained below:
1. Automatically detect the user in the house and his/her exact position
While the user is in the house, or as soon as he/she enters his/her house, the system
detects him/her and performs some pre-defined actions, altering the status of certain home
appliances (according to the user’s previous settings), e.g. the heating is turned on to x0C,
the TV is switched on, etc.
2. Check the status of home appliances
The user can check the status of a connected home device (i.e. if the heating system is
on/off, if the window is closed, etc.) while in or out of home, through the environmental
control module (comfort unit).
3. Monitoring and automatically change of the status of home devices
The system monitors the status of a connected home device and changes it by itself (i.e.
decrease the house temperature while the user is out of the home, close a window, while the
user is out, turn off the oven when the habitant is out, etc.).

3. OASIS Domotics Ontologies Framework

One of OASIS main research and development pillars is the unification of the domotics
environment under an interoperability umbrella, which will be based on ontologies. In
ASK-IT integrated project, significant developments took place regarding the
communication and interfacing of heterogeneous devices that comply with different widely
accepted or proprietary standards. In OASIS the integration of heterogeneous devices
evolves on a higher semantic level towards the provision of the technical means for the
integration of domotics to the semantic web using a description language, understandable
by machines, aiming to render domotic devices exploitable by web services and in more
generic terms a web based AmI.
Relevant OASIS work focuses on the integration of technologies, products and services
in the domestic environment. The goal is to improve the quality of life, security and the
possibilities to communicate with the outside world. Relevant functionalities that
potentially can be included in the final ontological description are the following:
x Security and safety: Monitoring of the environmental parameters, reminder of
locking, security procedures during a break-in attempt, safety procedures in cases of
storms, overvoltage, etc.

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 2 of 7

 x Energy saving: Energy efficient consumer products (washing machine, dishwasher,
fridges, IT, lights, etc.), efficient heating, efficient ventilation, automatic lowering of
the heating in unused rooms and at non-attendance.
x Additional functions: Emergency call, monitoring of subject vital parameters,
telemedical services, support of housework.
x Comfort: Networked appliances give a better overview of the household, central
remote control of most of the functions, desired temperature in the whole house, sun
protection.
x Flexibility: Flexible connection technology and wiring, comfortable multimedia
infrastructure.
x Entertainment: Home cinema, home server and networking.
Lassila and McGuiness [2] categorised ontologies according to the information they
need to express. Even though their classification ascribes the name “ontology” to nearly
everything that is at least a finite controlled vocabulary with unambiguous interpretation of
classes and term relationships and with strict hierarchical subclass relationships between
classes, ontologies that meet more elaborate criteria contain a much richer internal
structure, and have therefore been dubbed “heavyweight ontologies” [3]. Among the
mentioned criteria are: formal “is_a” relation, properties, value restrictions, general logical
constraints, and disjoints.
The basic structure of the ontology was developed manually in order to secure the high
standard of reality/knowledge representation mentioned above. For future maintenance and
extensions, automated and semi-automated procedures have to be devised.
We apply four principles used in the development of ontologies. These principles are:
realism, perspectivalism, fallibilism, and adequatism. These principles are a crucial part of
the attitude one has to adopt regarding the development of any ontology. Besides those
principles, several aspects of a more technical nature were taken into account by the
developers of OASIS ontologies such as fulfilling the basic needs of the developers of
ontology-based applications/tools. Hence the OASIS ontological framework at the moment
does not include real world instances but only universals. The hierarchy of the universals is
one of the major features of any ontology which may serve to prove its consistency and
compliance with other formal standards. One of the golden standards to be followed, in
order to ensure a proper structure of the taxonomy of universals, is the avoidance of
“informal is_a” relations [2].
In general, we embrace the belief that a properly constructed ontology should steer
clear of a taxonomical tree that allows multiple parent classes for the same child class (i.e.
one child that inherits from multiple parents). The central aim is to avoid polysemy that
often results from multiple inheritances. In OASIS we completely avoided multiple
inheritances. Another problematic case that can be found in quite a number of databases,
terminologies and even “ontologies,” is the presence of classes or types like “UnknownX”
(“UnspecifiedDevice”, “UnknownAffiliation”). However, “universals” like these do not, in
fact, have any instances, they merely hint to a lack of data or knowledge. The alleged
instances of those universals do not exhibit any shared properties, at least not necessarily.
Therefore, we avoided such classes in the OASIS domotics ontologies.

4. Methodology
Three possible approaches are considered for the creation of the OASIS common
ontological framework for domotics which are described next, followed by the three-
layered ontology, as a solution that is being followed in OASIS.

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 3 of 7

 4.1 One Main Class Serving All Devices

In order for one class to be applicable on each domotic device, it should be designed in a
very abstract way so as to include only the functionalities that are common in all
appliances. Such a design however would make a lot of core functionalities inaccessible by
the overall AmI system and would require further customization steps during development.
In the following schema the concept of such a generic ontology is depicted.

Figure 1 : Ontology Schematic

Potential class properties are listed in table that follows:
Table 1: Properties of Class Device
Property name Description
Name The name of the device (e.g. washing machine)
Status The current status value of the device (e.g. On/Off, 55 %)
Control Optional data; is used to characterized the device (e.g. switch, state, light etc.)
Environment The house ID where the device resides
Room The room name where the device resides

4.2 One Class Per Device

The extreme opposite of the previous concept is the development of one ontology class per
domotic device. This approach provides the means for the complete functional potential
exploitation since these become accessible via the ontology framework. However there is
the need for each domotic developer to provide the appropriate device description class so
that it becomes integrateable to the OASIS platform (an approach that could be conceived
as the analogous to the well known device drivers used by the computer operating systems).
Each device-class has different properties, which characterizes itself. For example, the
‘light’ device-class can have status and luminance properties. The temperature class can
have status properties. Table 2 shows examples of devices as stand-alone classes.
Table 2: Light‘s and Washing Machine’s Properties
Light Washing Machine
Status Status (On/off)
Luminance Running Program
Spin speed
Water temperature
Remaining wash duration

4.3 One Class Per Category of Device

The final case is a compromise between the previous two designs. Different categories will
be formed depending on the common functionalities and characteristics of domotic devices.

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 4 of 7

For each of these categories different classes will be designed, in order to provide
description and accessibility to specific, common functionalities.
Such a categorisation in classes could be, for example:
• White goods
• Brown goods
• Lighting
• Heating
• Alarms & Security Devices
• Sensors
• Other
Based on the above categorization, the following ontology is designed:

Figure 2: Categorisation in Classes

The ‘Device’ class is assumed as a separate category. This class is useful in order to
describe a new device in an abstract way. The approach described in paragraph 4.1 above
will be applied. It was also used for ASK-IT project.
The hierarchy of ‘white goods’ class is as follows:

Figure 3: White Goods Schema

The classes of brown goods, lighting, heating, etc. are described in a similar way.

5. Developments and Results

The three approaches mentioned above suffer from limitations on the functionality detail
level they can represent. For example the first one can only include very basic functions
that are common to all domotic devices (e.g. ON/OFF). This limitation leads to a very poor
exploitation potential for this device by the OASIS platform. On the other hand the very

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 5 of 7

detailed functionality description provides access to the full domotic device potential;
however it is not so easy to obtain since it can only be provided by the vendor of the device.
The second approach is just a compromise between the two extremes which doesn’t
address the problems but only provides one more detailed level of functionality description
when compared to the first approach.
The solution to the above issues comes from the use of a combination:
x An upper ontology layer that is the abstract generic ontology.
x A medium layer with a categorization.
x A lower, detailed functionality layer, which contains custom classes that are specific
for each device and is provided by the vendor.
This last ontology can be created using specific guidelines or even a tool developed
within OASIS and will be accessible to the domotic provider via the web.

A domotic
appliance

A white
good

A coffee
maker

Increased functionality
Increased availability

Figure 4: Three-Layered Ontology

By using this three-layered ontology the access to the functionalities of the device
becomes modular. Depending on the availability of data all three, or less, layers may be
populated and the OASIS’s accessibility and operability level for the specific device will
vary accordingly.
The Domotic ontology is developed using the Protégé Toolkit. In the last phase of its
developed, some plug-ins may be used such as the Bean Generator for JADE middleware.
The ontology will be based an OWL/RDF ontology standard description (W3C
recommendations). The overall ontology is schematically presented below:

Figure 5: Overall Ontology Schematic

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 6 of 7

 The selection criteria for domotic devices used in the OASIS pilot sites are (a) easy to
install and (b) low cost. Devices can easily be installed using a “Plug, Touch and Play”
approach. Many different devices are available, e.g. plugs, remote controls, sensors, motion
detectors or energy meters. A simple GUI, implemented in JAVA is underway, to be
installed on any PC that is connected to the Domotic Server. This GUI will connect to the
Domotic Gateway by using Web-Services and allows to control the plugs.

6. Business Benefits
One of the most important points of the domotics system is that sensors are set up so they
can be easily integrated into household equipment (including the wiring) already available
in the domicile. Examples for this are on/off sensors for light and oven, occupancy sensors
for bed and couch (pressure sensors), and temperature sensors for air and oven. This is in
line with the fact that elderly people do not want to buy new apparatus or equipment.
OASIS sees itself as a pioneering approach to the unification of heterogeneous domotic
appliances which will be possible by the provision of an ontology-based higher level of
interfacing that acts as an umbrella for the various functionalities and communication
standards. This ambitious goal however entails the involvement of a critical mass of
domotics vendors that will abide with OASIS’s technology approach. In order to achieve
this objective, OASIS will provide a graphical user interface in order to support the vendors
and companies to add new devices with their properties. Moreover, properties of existing
devices can be used or updated.
The new ontology encompasses all types of communication protocols (including older
ones and wireless), does not require specific infrastructure (i.e. fiber optics or fast internet),
is easily expandable and not brand-specific, thus is ideal for fast, cost-efficient and yet
reliable applications in countries under development.

7. Conclusions
In this document the current status towards the design of the OASIS domotics ontology is
reported. This research builds upon the work done in ASK-IT in relation to the
communication of heterogeneous devices and home appliances. In OASIS domotics
integration in a higher level is pursued by providing the semantic representation of
domotics functionalities in order to take advantage the developments of web services and
the emergence of semantic web. The design of this kind of ontological framework brings
the opportunity for standardization and harmonization in functionalities and communication
levels of different devices from different vendors and in that way facilitates the
management of distributed data sources towards more detailed context awareness by the
AmI (Ambient Intelligence framework).
The relevant ontology is publicly available at http://babel.informatik.uni-
bremen.de/ontologies and can be interfaced by a content alignment and authoring tool,
which is a stand-alone application, running on any Java-enabled PC; so that existing
emerging domotic applications at user homes or/and hospitals, elderly homes and other
rehabilitation establishments can be easily connected to it and through it to a wide number
of elderly support services.

References
[1] OASIS (ICT-215754) Description of work, 2007.
[2] Lassila O, McGuiness D. The Role of Frame-Based Representation on the Semantic Web. Technical
Report. Knowledge Systems Laboratory. Stanford University. KSL-01-02. 2001.
[3] Gómez-Pérez A, Fernández-López M, Corcho O, “Ontological Engineering.” Springer, London, 2004.

Copyright © 2010 The authors www.IST-Africa.org/Conference2010 Page 7 of 7

 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing
Anticipating health hazards through an ontology-based, IoT domotic environment
Vittorio Miori
Institute of Information Science and
Technologies (ISTI)
CNR -- National Research Council of Italy
Pisa, Italy
vittorio.miori@isti.cnr.it
Abstract— Embedded intelligence entails a vision of the
Internet of Things oriented to “Ambient Intelligence”, which
can be defined as the capacity to collect and analyze the digital
traces left by people when they interact with the environment
and with such “intelligent things”. In such a vision, the
ultimate aim is to acquire knowledge about everyday life and
human behavior.
We apply these concepts to the automated home, in which even
nowadays devices (sensors and actuators) are already Internet-
capable “things” endowed with their own intelligence.
This work introduces a semantic knowledge representation for
domotics following the principles of the semantic Web (Web
3.0). We have implemented specific ontologies that
automatically take account of distributed environmental
context information.
The first result was to achieve a natural abstraction of
different, incompatible devices in order to support
interoperability in a consistent technology-independent
manner and impart awareness to the domestic environment in
which “things” such as furniture and other objects, as well as
the rooms themselves, take on computational significance.
This goal includes leveraging the development of a
comprehensive intelligent ecosystem that, by applying machine
learning and artificial intelligence techniques, gains knowledge
of the occupants’ behaviors and habits and can thereby adapt
itself to the specific setting and anticipate their needs without
direct human intervention.
The same modeling process serves as the basis for
implementation of an e-health system that can anticipate, and
thereby prevent, possible health hazards before emergency
situations arise (especially for the sick and elderly).
Keywords- Ambient Intelligent; domotics; home automation;
DomoNet; SOA; XML; Ontology; Machine Learning; E-Health
I. INTRODUCTION
The evolution of Web technology has made great strides
in recent years [1]. Such advances have been driven by
changes in Web users’ needs and the consequent creation of
new Web services. This evolution has led to the creation of
more and more sophisticated applications aiming to extend
Web functionalities.
Semantic Intelligence is one of the main paradigms
underlying the Web 3.0 (W3C). In this new revision, the
World Wide Web becomes an environment where any
978-0-7695-4684-1/12 $26.00 © 2012 IEEE
DOI 10.1109/IMIS.2012.109
Dario Russo
Institute of Information Science and
Technologies (ISTI)
CNR -- National Research Council of Italy
Pisa, Italy
dario.russo@isti.cnr.it
documents published become interpretable because they are
enriched with information and metadata specifying the
semantic context to allow for automatic processing and
enhancing of the query process by exploiting interpretation
of such Web content.
The Semantic Web is an Internet space that includes
documents, or portions of documents, describing explicit
relationships between things and containing semantic
information intended for automated processing by our
machines.
Not just Web pages, but databases, programs, sensors and
even household appliances will be able to present data,
multimedia, and status information in ways that powerful
computing agents can use to search, filter and prepare
information in new and exciting ways. The data sources are
able to share information using the Resource Description
Framework (RDF) language, the basic instrument proposed
by the W3C for the encoding, exchange and reuse of
structured metadata, making information on the Web
significantly more machine-readable.
The interpretation of document contents that the
Semantic Web furthers will offer a number of important
advantages. It will enable building networks of relationships
and connections between all kinds of resources, and such
networks will moreover be much more powerful and
effective than those created with mere hypertext links.
In the Semantic Web, then, an ontology [2] is a partial
conceptualization of a given knowledge domain, shared by a
community of users, that has been defined in a formal,
machine-processable language for the explicit purpose of
sharing semantic information across automated systems.
The domain description is provided using a formalism
called Web Ontology Language (OWL) that explicitly
represents the meaning and semantics of terms, capturing
their intrinsic structure and their relations.
A computational ontology consists of Classes
(Concepts), Individuals (Instances) and Relations. A Class
represents a group of different Individuals that share
common characteristics. The Individuals are the domain
objects that the ontology describes, such as people,
machines, devices and so on. A Relation can be declared
between Individuals or between Classes and describes how
they are associated to each other.
With the use of ontology query languages (e.g.
SPARQL), it is possible to interact with the ontology to
745
request and receive data in a standardized format. Such data
may come from any type of source and can be placed in
relation to each other. This allows achieving integration and
interoperability amongst heterogeneous information.
The high-level description of the semantic structure of a
given domain achieved through the use of ontologies cannot
be attained using tools such as databases or XML technology.
In fact, XML schemas deal primarily with the physical
structure of documents, and XML tags lack the explicit
semantic modeling that support computer interpretation.
The Internet of Things vision [3] promotes the ubiquitous
and pervasive paradigms where context and intelligence are
embedded into objects and physical locations, each of which
conveys a small amount of useful information. Such
information can be automatically extracted and processed in
order to better support current user activities and satisfy their
needs. For these reasons, interoperability and semantic
environments are the keywords underlying the Internet of
Things paradigm, which enables creating smart Ambient
Intelligence applications.
II. OBJECTIVES
Today’s e-health solutions provide important
contributions to the health management of the elderly and
chronically ill within their own homes. Indeed, they provide
for constant monitoring of many vital parameters via
portable sensors (inserted into shirts, bracelets, watches,
etc.), in order to be able to identify and opportunely signal
any hazardous situations requiring intervention. In most
cases, however, by the time the call for help is issued, the
emergency is already in progress. A system able to anticipate
danger before life-threatening situations arise would
certainly lead to faster, more effective intervention. The
ability to anticipate and recognize certain behaviors or events
heralding serious health problems in time can often save
lives.
The path undertaken in this research to attain such
objective is to supplement such a monitoring system with
software able to learn the habits and behaviors of people in
their own residence, and hence the ability to recognize any
abnormal behavior patterns signaling potential imminent
health crises.
One clear prerequisite for the satisfactory functioning of
such a system is that it act within an environment made up of
completely integrated, interoperable devices and systems.
In previous work, our research laboratory has addressed
the thorny issue of interoperability by developing the
middleware [4], an integral part of which is an Ambient
Intelligence application module that learns from experience
and people’s habits [5].
However, one intrinsic limitation of the software
developed is that its operates on a purely syntactic way. The
system does not possess any awareness of the environment
or its contents, being limited to identifying sensors and
actuators through their numerical addresses.
The work at hand aims to overcome this limitation by
developing a semantic layer at the highest level of the AI
framework that will enable the system to fully exploit a
knowledge-based representation of the environment. To this
746
end, the system must be endowed not only with knowledge
of the devices and their functions (knowing what a lamp,
thermostat or switch means), but also with tools that enable it
to learn concepts such as room, furniture, object position and
the repercussions (effects) of the use of such objects in the
environment.
In this way, for example, it will be possible to assign the
system a specific goal to perform without however having to
specify each and every single action making it up.
III. RELATED WORKS
One interesting work in this regard is INCASA [6],
which uses middleware based on a Service Oriented
Architecture. It focuses on citizen-centric technologies to
help the elderly in their own homes. This goal is pursued by
integrating solutions for health/environment monitoring that
collects and analyzes data in order to profile user habits and
implement alert services. The results of the project are very
promising and the next natural step seems to be to learn
people’s actual habits rather than just profiling them.
The work presented by Martìnez-Lòpez [7] combines
ontologies, inference engines, data mining techniques and
machine learning procedures to develop an advanced
telemedicine system. However, it neglects to tackle the
issues regarding both the interoperability between
heterogeneous devices and contextualization of the
environment surrounding the user.
The SAPHIRE project [8] proposes a pilot application for
bedside monitoring of cardiac patients at hospitals and for
homecare monitoring of cardiac patients rehabilitated after
revascularization therapy. The monitoring is accomplished
via an interoperability layer that exploits semantic Web
technologies. The result enables accessing the patient's vital
signs from wireless medical sensors and electronic
healthcare records in order to be able to seamlessly exploit a
decision-making process.
Preuveneers et al. [9] propose an adaptable and
extensible context ontology that creates a context-aware
computing infrastructure, ranging from small embedded
devices to high-end service platforms. The proposed
ontology has been designed to solve several key challenges
in Ambient Intelligence, such as application adaptation, code
generation, code mobility and generation of device-specific
user interfaces automatically. Lafti et al. [10] exploit the full
potential of ontologies to describe the specific domain of
interest, in order to provide an effective basis for the
development, configuration and execution of software
applications. They adopt a Bayesian networks paradigm to
recognize patient activities by exploiting a learning process
of their life habits. SOPRANO [11] is a EU-funded project to
assist elderly Europeans to lead more independent lives
through application of smart home and ambient intelligence
technologies. The solution is based on the creation of a
context ontology that focuses on the concept of device state.
It abstract concrete sensors inputs and actuators outputs from
the knowledge base.
 IV. SEMANTIC DOMONET refer to completely different devices. “Turn on”, for
The existing DomoNet framework is based on Web instance, can be directed to a lamp, a television or an
Services and Service Oriented Architecture (SOA). electric oven. Each functionality takes some
Development of the software implementation was based on a parameters as input and return other parameters as
syntactic approach using an XML-compliant language called output.
DomoML.
DomoML enables abstraction of heterogeneous systems
in order to describe device functionalities, data types,
messages and models of the interactions and
communications among framework entities. It represents a
“lingua franca” that links several single domotic systems,
providing them with common information and control
exchange mechanisms. As such, it can be used as a sort of
universal domotic language to be applied in any domotic
context.
It is up to human interpretation to undersatand the
significance of that which devices represent and which are
the effects of their actions inside the environment.
The supplementing of DomoNet with a new semantic
level makes the system a more powerful tool for abstracting
domotic devices, household objects and the surrounding
spaces. Such semantic level enables it to gather crucial
information in order to be able to contextualize the overall
environment and its contents.
The system includes solutions for implementing:
• semantic interoperability among heterogeneous
technological systems and devices, while masking
their technological differences from the framework;
• equipping the user environment, the domotic devices
and their functionalities with semantic capabilities;
• defining the position of domotic devices and
furniture to provide routing within a specific home
environment (e.g. the night-table lamp, the kitchen Figure 1. Semantic DomoNet platform architecture.
TV);
To describe how the environment is modified when
• modeling the effects within the environment of
a functionality is activated, the ontology utilizes the
activation of domotic functions in order to
effects class, whose individuals represent the
understand the impact that a device will have on the
possible functional consequences. For example, the
environment.
effect “more light” is related to the functionality
The general architecture of the overall platform is
“setPower” of a lamp by setting its input parameter
composed of four layers (figure 1): the Semantic,
to “on”. The same individual effect can be used for
DomoNetWS, TechManagers and Domotic Bus layers.
another functionality and so “more light” can be
The Semantic layer supplies a general semantic to
associated to the functionality “setStatus” of roller
devices, objects, actions and the overall environment
blinds, by setting its input parameter to “open”.
potentially making up a generic home. This level contains no
personalization or contextualization to any particular • FurOnt (Furniture Ontology): is made up of a simple
environment. taxonomy of home furniture. In particular, it defines
Four ontologies were developed for the semantic level: and classifies objects such as tables, chairs, mirrors
and so on.
• DomOnt (Domotic Ontology): this includes an
integrated taxonomy of domotic devices and their • EnvOnt (Environment Ontology): is the ontology of
functionalities. the environments within which devices and furniture
This ontology defines separate classes of devices, can be positioned. It describes the home
their functionalities, input/output parameters and the environment, that is, defines the meaning of different
effects they have in the environment. The relations rooms, such as “bathroom”, “kitchen” or “bedroom”.
amongst the classes are defined as follows (figure 3): It includes relations such as “contains bed”, “the
a device has some functionalities and any single place for eating”, etc. In this way it is possible to
functionality can be owned by more than one device. locate a specific environment without explicitly
For example, the meaning of a command (which is a calling it but by simply referring to it by its
particular type of functionality) can conceptually characteristics (e.g. “the room with the bed”).

747
 • LexOnt (Lexical Ontology): defines words
specifying the positions of objects and devices inside
the environment and their inter-relations. The
defining words here are, for example, “near”, “on”,
“under” and so on.
The DomoNetWS layer defines its own ontologies by
instantiating those defined at the semantic level. This is done
by creating an Individual of the various classes (defined at
the semantic level) and relating them based on the specific
configuration of the environment and the objects on which
the system has to operate. In the resulting model the
interactions between various system entities and any
reference to specific objects are defined by such Individuals.
The ontologies defined at this level are inherited directly
from those defined at the semantic level. They are
characterized by the models of the Individuals and are
respectively: DomOntInd(n), FurOntInd, EnvOntInd and
LexOntInd.
There can be from 1 to n numbers of DomOntInd,
depending to the number of domotic systems present in the
environment. There will therefore be a different ontological
instance for every application domain formed by the devices
belonging to each domotic system.
DomOntInds are the ontologies that implement the
functionalities necessary for interoperability. Express
relations have been created between Individuals that act on
device functionalities and between those that act on
parameters. In this way, when the “setStatus” push button
functionality is called, the “setPower” function of a lamp is
also called, using the same input parameter value (on or off)
for the two functions.
The TechManagers layer is responsible for creating the
domotic device instances regarding real environments. At
this level a mapping is made between every Individual
defined in DomOntIndns and the physical address of the
various devices.
The Domotic Bus Layer includes the physical
infrastructures of the domotic systems. They are substantially
represented by the communication channels, which can
wired or wireless, depending on the domotic system in
question.
The entire communications infrastructure between
ontologies belonging to the same or different levels have
been implemented using the JADE open-source library [12].
JADE provides for an agent-based network architecture in
which each agent is responsible for managing a specific
ontology. The various agents used for manipulating the
ontologies have instead been built using the JENA library
[13].
V. ANTICIPATING POTENTIAL HEALTH HAZARDS
In our everyday lives we usually carry out the same,
often related, actions to achieve certain goals. By way of
example, when we leave home, we usually switch off all the
appliances, close all the windows, activate the alarm system
and so on. With the passing of time, these actions become
habits and are often performed at specific times of the day or
are related to certain events. DomoPredict [5] is a software
module of the DomoNet framework able to learn the
748
behavior and habits of home inhabitants in order to anticipate
their needs. It is an adaptive, context-aware application that
thus works in a fully interoperable environment.
It includes two complementary, interoperable modules
that perform real-time analyses to identify user behaviors and
verify the rules learned. The first module applies a Data
Mining paradigm to learn action sequences that represent
user habits, the second module is designed to learn
parameters of scenarios using a statistical approach to
analyzing the frequency and percentage of use of appliances.
The DomoPredict framework can also be applied to the
medical field (figure 2). Supposing that someone exhibits a
significant change in sleeping, eating or toileting habits.
These can be considered early indicators of potential
problems and can be analyzed and recognized as such by
DomoPredict.
Figure 2. Smart home telecare devices.
The results of this analysis must then be integrated with
data on the user’s vital signs, which are obtained by constant
monitoring through the use of special portable sensors
(integrated in shirts, bracelets, clocks, etc.) and organized
according to specific configuration of a Body Area Network
(BAN). This process leads to an evaluation workflow that
may culminate in actions such as sounding alerts and/or
automated calls. Clearly, the process must be efficient
enough to eliminate, or at least minimize false alarms. It is in
such process that the functionalities offered by the
framework’s new semantic level become fundamental in
ensuring that the application provides satisfactory results.
Indeed, the current system now acts in a contextualized
environment, which enables it to recognize the user’s actions
in a “conscious” manner. And this is only made possible
through the notions furnished by the special ontologies,
which give “meaning” to rooms, objects, devices and so
forth.
VI. CONCLUSIONS
The developed framework is currently in operations at
the Domotics Lab of the CNR in Pisa. It is an integral part of
the faithfully simulated home environment set up for
demonstration and continued research purposes.
The introduction of the semantic level, which has enabled
the system to learn context, has provided numerous benefits.
The system now “reasons”, referring to devices based on
their physical position rather than through syntactic-based
references such as, for instance, a physical address. The
command “Turn on the living room light” is valid in any
home and will simply be contextualized in any given
instance for the specific residence in which it is used.
The system is able to produce “intelligent” behaviors, for
example, anticipating a user’s wish “to have more light” by
taking account of the environmental context and
autonomously deciding whether to turn on a lamp or,
alternatively, open the blinds.
The software module that learns the inhabitant’s habits
and acts to anticipate his needs, is a step forward both in the
direction of providing efficient e-health and toward realizing
the vision of ambient intelligence. A good deal of work will
certainly be needed on the part of both the computer science
and the strictly medical fields. Nevertheless, the framework
makes an important contribution to allowing the elderly and
disabled to live in a safe environment custom-designed to
their own personal needs and state of health.
During the testing stage, particular attention has been
devoted to validating the ontologies, which have been found
to be wholly free of consistency errors [14]. The first checks
were effected at startup-time to detect and correct any
possible logical contradictions. Since fully populating the
ontologies necessarily calls for the continuous introduction
of new objects and relations, careful checks were carried out
with each and every update. All stages of validation have
been carried out using the JENA library reasoner.
VII. FUTURE WORK
The results obtained allow us to envision and plan for the
future evolution of the platform A first step will be the
creation of a friendly human-machine interface (HMI) based
on the use of natural language, whence enable the use of
utterances such as “the lamp on the table” or more simply
“more light in the bedroom” in order to achieve the desired
effects.
With the support of the ontologies it will then be possible
to build more powerful and more interoperable medical
information systems, and thereby support the needs of the
healthcare process for the transmission, re-use and sharing of
patient data. This process can be supported by providing
semantic-based criteria to support different statistical
information aggregations to simply represent complex,
detailed medical data unambiguously.
Further interesting developments will come from
supplementing DomoPredict with real-time systems for
conducting behavioral analysis of elderly users in their home
settings, including qualitative movement analysis [15], and
evaluating emotional states.
Data on such aspects is directly or indirectly linked to
pathologies suffered by the elderly, such as quality of
movement, personal emotional state and behavior in general
(troubled, nervous, confused and so on). Considering these
factors, the aim is to determine methodologies and
algorithms for automatic or semi-automatic evaluation of
these aspects in order to provide direct support to the elderly,
disabled or sick (with feedback, focused exercises, etc).
749
The feedback from such tools would moreover serve to
increase the cognitive base used by DomoPredict to make
deductions and provide important indications for
determining whether living conditions are optimal and
suitable for the person’s needs.
A further development will be to supply the platform
with special Human-Computer Interaction (HCI) tools. Such
work will aim at creating an advanced graphical user
interface for configuring the system. The envisioned
interface will enable drawing a detailed graphical layout of
the home environment, in which the devices recognized by
the framework, as well as furnishings and other objects, can
be positioned using the “drag and drop” technique.
Exploiting the fact that such elements will already include
the necessary semantics, their positioning inside the map will
involve automatic creation of the necessary ontological
relations.
REFERENCES
[1] Juan M. Silva, Abu Saleh Md. Mahfujur Rahman, and Abdulmotaleb
El Saddik, “Web 3.0: a vision for bridging the gap between real and
virtual”, Proc. of the 1st ACM international workshop on
Communicability design and evaluation in cultural and ecological
multimedia system (CommunicabilityMS '08), ACM, New York, NY,
USA, pp. 9-14, 2008, doi:10.1145/1462039.1462042.
[2] B. Chandrasekaran, J.R. Josephson, and V.R. Benjamins,
“Ontologies: What are they? why do we need them?” IEEE Intelligent
Systems and Their Applications, 14(1), pp. 20–26, 1999. Special
Issue on Ontologies.
[3] ITU. Internet Reports 2005, “The Internet of Things”, November
2005.
[4] V. Miori, D. Russo, and M. Aliberti, “Domotic tecnologies
incompatibility becomes user transparent”, In: Communications of
the Acm, vol. 53 (1), pp. 153 - 157. ACM, 2010.
[5] V. Miori, and D. Russo,. “An adaptive and anticipatory AmI
approach tailored to user needs”, Proc. 5th International Symposium
on Ubiquitous Computing and Ambient Intelligence 2011
(UCAmI11), Riviera Maya, Mexico, 5-9th december 2011.
[6] G. Lamprinakos, E. Kosmatos, and D. Kaklamani, I.S. Venieris, “An
integrated architecture for remote healthcare monitoring", 14th
Panhellenic Conference on Infomratics (PCI), pp. 12-15, 10-12 Sept.
2010, doi: 10.1109/PCI.2010.20
[7] R. Martínez-López, D. Millán-Ruiz, A. Martín-Domínguez, and
M.A.Toro-Escudero, “An architecture for next-generation of telecare
systems using ontologies, rules engines and data mining”, Intl. Conf.
on Computational Intelligence for Modelling, Control and
Automation, pp. 31-36, 2008
[8] O. Nee; A. Hein; T. Gorath; N, Hulsmann, G.B. Laleci; M. Yuksel,
M. Olduz, I. Tasyurt, U. Orhan, A. Dogac, A. Fruntelata, S.
Ghiorghe, and R. Ludwig, “SAPHIRE: intelligent healthcare
monitoring based on semantic interoperability platform: pilot
applications”, Communications, IET , vol.2, no.2, pp.192-201,
February 2008 doi:10.1049/iet-com:20060699
[9] D. Preuveneers, J. Van den Bergh, D. Wagelaar, A. Georges, P.
Rigole, T. Clerckx, Y. Berbers, K. Coninx, V. Jonckers, and K. De
Bosschere, “Towards an extensible context ontology for ambient
intelligence”, Proc. of the 2nd European Symposium on Ambient
Intelligence (EUSAI 2004), pp. 148-159, 2004.
[10] F. Latfi, B. Lefebvre, and C. Descheneaux, “Ontology-Based
Management of the Telehealth Smart Home, Dedicated to Elderly in
Loss of Cognitive Autonomy”, Proc. of the OWLED 2007 Workshop
on OWL: Experiences and Directions (2007),
[11] M. Klein, A. Schmidt, and R. Lauer, “Ontology-centred design of an [13] B. McBride "Jena: a semantic Web toolkit," Internet Computing,
ambient middleware for assisted living: the case of SOPRANO”, IEEE, vol.6, no.6, pp. 55-59, Nov/Dec 2002
Proc. of Towards Ambient Intelligence: Methods for Cooperating doi:10.1109/MIC.2002.1067737
Ensembles in Ubiquitous Environments (AIM-CU), 30th Annual [14] P. Haase, and L. Stojanovic, “Consistent evolution of OWL
German Conference on Artificial Intelligence (KI 2007), Osnabrück, ontologies”, Proc. of the 2nd European Semantic Web Conference
2007. (ESWC-05), pp. 182-197.
[12] F. Bellifemine, G. Rimassa, and A. Poggi, “JADE - A FIPA- [15] L. Ball, D. Bradley, A. Szymkowiak; S. Brownsell, “Linking
compliant agent framework”, Proc. of the 4th International recorded data with emotive and adaptive computing in an eHealth
Conference and Exhibition on The Practical Application of Intelligent environment," Healthcare Informatics, Imaging and Systems Biology
Agents and Multi-Agents, London, 1999. (HISB), 2011 First IEEE International Conference on , vol., no.,
pp.198-204, pp. 26-29, July 2011 doi:10.1109/HISB.2011.33

Figure 3. Some DomOnt classes with their related relations.

750
 2013 19th International Conference on Control Systems and Computer Science

A Review on Vision Surveillance Techniques in Smart Home Environments

Marius Brezovan, Costin Badica

Department of Computer and Information Technology
University of Craiova
Craiova, Romania
Email: {mbrezovan, cbadica}@software.ucv.ro

Abstract—Video surveillance is an important area of com-
puter vision research, its applications including both outdoor
and indoor automated surveillance systems. In the context of
smart home environments, the In-House Video Surveillance
systems have as main goal to control the safety and the security
of materials and of people living in a domestic environment.
This paper provides an overview of various methods and
techniques from the computer vision research area that address
the problems of representation, recognition and learning of
events, actions and activities of inhabitants from a domotic
environment.
Keywords-video surveillance; smart home environments; am-
bient assisted living;
I. I NTRODUCTION
The smart home concept [1] is understood as an inte−
gration system that deliver a range of innovative services
to homeowners using a variety of intelligent, connected
devices.
The research in the field of vision surveillance meets with
the research in several smart home techniques, especially
in two important domotic aspects: home health, and home
security. We identified two distinct directions where video
surveillance techniques can be used in smart home environ−
ments: (a) ambient assisted living, whose goal is to improve
the quality of life and to maintain independence of older
and vulnerable people, and (b) vision-based fire detection,
where video processing techniques are used to develop fire
monitoring systems for smart home environments. In this
paper, we focus attention only on the ambient assisted living.
An indoor surveillance system attempts to detect and
recognize objects of interest from video obtained by one
or more cameras along, eventually by fusion information
obtained from cameras and other sensors installed in the
monitored area. The aim of an automated video surveillance
system is to understand what is happening in a monitored
area and to take appropriate actions like alerting appropriate
services if an undesirable occurred [2].
Ambient assisted living (AAL) can be described as in−
formation and communication technology based services
and systems to provide older and vulnerable people with
a secure environment, in order to improve their quality of
life and reduce the costs of health and social care [3]. Video
surveillance in smart home environments, attempts to detect,
recognize and track persons from image sequences, and
more importantly to understand and recognize their actions
and activities.
Video surveillance systems in smart home environments
can be classified as: (a) centralized systems, where human
activity analysis is performed on a centralized server, and
(b) distributed systems, where analysis is performed on a
distributed cameras network.
In general, an in−house video surveillance system in−
cludes, as presented in Figure 1, the following modules: (a)
motion detection, (b) object tracking, and (c) human motion
analysis, in order to detect simple events, or recognize com−
plex human (or group oh humans) activities. The first two
modules represent a syntactic low−level processing phase,
while the last module represents a semantic high−level phase,
which is able to detect and recognize human activities.
The rest of this paper is organized as follows. Section
II covers approaches related to low−level video processing
techniques, such as motion detection and object recognition,
while Section III covers current computer vision approaches
for human motion analysis. In Section IV privacy issues in
video surveillance systems are discussed. Finally, conclu−
sions are given in Section IV.
II. M OTION E STIMATION AND O BJECT R ECOGNITION
The low−level processing task of an indoor video surveil−
lance system contains two distinct components, as presented
in Figure 1: motion detection and object recognition. The
input for these modules is a video sequence, each element
from this sequence representing a video frame.
A. Motion detection
Motion detection methods attempt to locate connected
regions of pixels that represent the moving objects within
the scene. Conventional approaches for motion detection
methods use background subtraction, temporal differencing
[4], and optical flow [5]. The first approach consists in
subtraction of a background or reference model from the
current image followed by a labeling process. The second
technique is based on the the subtraction of two or more
consecutive frames followed by thresholding. The optical
flow approach uses the velocity field that warps one image
into another image.

978-0-7695-4980-4/13 $26.00 © 2013 IEEE 471

DOI 10.1109/CSCS.2013.30
 Input cameras
Motion detection
Object tracking
Human motion analysis
Activity recognition Event detection
Control and visualization Alarm generation
Figure 1. Traditional flow of processing in a in−house video surveillance
system
Background subtraction method is simple, but extremely
sensitive to changes in dynamic scenes derived from lighting
and extraneous events. Recent background subtraction algo−
rithms focused on adapting to varying illumination condi−
tions, geometry reconfiguration of background structure, and
repetitive motion from clutter. Among others may include
methods such as: (a) background subtraction methods for
modeling a multiple modal background distribution [6],
which use a Gaussian−based approach for real−time applica−
tions, (b) statistical background modeling [7], where an edge
segment−based statistical background modeling is used, and
(c) universal background subtraction algorithm for video
sequences [8], which stores a set of values taken in the past
in the same location or in the neighborhood.
Temporal differencing is robust to dynamic changes of the
environment, but generally this technique gives poor results
in extracting all the relevant pixels, leaving holes inside
moving objects. For this reason, background subtraction
and temporal differencing techniques are used together in
many approaches. Optical−flow−based methods can be used
to detect independently moving objects even in the presence
of camera motion, but the flow computation methods are
computationally complex and very sensitive to noise, and
cannot be applied to video streams in real time without using
specialized hardware.
B. Object Tracking
The object tracking module is responsible for detecting
and tracking of moving objects by using information from
the motion detection module, object locations being subse−
quently transformed into 3D coordinates.
There are several approaches to classify object tracking
methods. According to [9], object tracking can be classified
472
into (i) region-based tracking, (ii) active contour-based
tracking, (iii) feature-based tracking, and (iv) model-based
tracking. We will use this classification because it is more
appropriate with the in−house video surveillance methods.
Region-based tracking algorithms track objects accord−
ing to variations of the image regions corresponding to
the moving objects. In this case the background image is
maintained dynamically, and motion regions are usually
detected by subtracting the background from the current
image. Feature-based tracking methods perform the tracking
of objects by extracting first some elements from video
frames, and then clustering them into higher level features,
and finally by matching the features between frames. Model-
based tracking algorithms track objects by matching object
models, produced with prior knowledge, to image data.
The models are usually constructed off−line with manual
measurement, or computer vision techniques.
We focus on model-based human body tracking be−
cause this method is related to in−house vision surveillance
systems. Model−based human body tracking is known as
analysis−by−synthesis, and it is used in a predict−match−
update style. In a first step, the pose of the model for the
next frame is predicted according to prior knowledge and
tracking history, then the predicted model is synthesized
and projected into the image plane for comparison with the
image data.
Model−based human body tracking techniques are based
on three components: (i) human body models, (ii) motion
models, and (iii) search strategies.
Human body models can be represented in several styles:
(a) a stick figure representation, which can be used to build
a hierarchical model of human dynamics encoded using
Hidden Markov models [10], (b) 2D contour, which rep−
resents the human body projections in an image plane (the
human body segments can be modeled by 2D ribbons [11],
or blobs [12]), (c) volumetric models that use 3D models
such as elliptical cylinders, cones, spheres, super−quadrics,
etc [13], and (d) hierarchical model [14] that include several
levels (skeleton, ellipsoid meatballs, polygonal surface) for
achieving more accurate results.
Motion models of human limbs and joints are widely used
in tracking, because the movements of the limbs are strongly
constrained. These motion models serve as prior knowledge
to predict motion parameters [15], to interpret and recognize
human behaviors [16], or to constrain the estimation of low−
level image measurements [17].
Search strategies are used to reduce the solution space,
because pose estimation in a high−dimensional body con−
figuration space is intrinsically difficult. Generally, there
are four main classes of search strategies: dynamics, Taylor
models, Kalman filtering, and stochastic sampling. Dynam-
ical strategies use physical forces applied to each rigid
part of the 3D model of the tracked object that guide the
minimization of the difference between the pose of the 3D
model and the pose of the real object [13]. Taylor models use
an incremental approach to improve an existing estimation,
using differentials of motion parameters with respect to the
observation to predict better search directions [18]. The
Kalman filter is a recursive linear estimator used for tracking
the shape and position over time in which the density
of the motion parameters can be modeled as Gaussian
[19]. Stochastic sampling strategies, such as Markov Chain
Monte Carlo [20], and condensation [21], are used to handle
clutter that causes the probability density function for motion
parameters to be multimodal and non−Gaussian.
Compared with other tracking algorithms, model−based
tracking algorithms have several advantages such as:
• These algorithms are robust (by using the prior knowl−
edge of the 3−D contours or surfaces of objects), and
they can obtain better results even under occlusion.
• The structure of human body, the constraint of human
motion, and other prior knowledge can be fused in a
single information structure.
• The 3−D model−based tracking algorithms can be ap−
plied even when objects greatly change their orienta−
tions during the motion.
However model−based tracking algorithms have two main
disadvantages: the necessity of constructing the models, and
the high computational cost.
III. H UMAN M OTION A NALYSIS
After the of motion detection step, human actions can be
viewed as a series of detected motions. In [22] an action
taxonomy is defined, based on the degree of abstraction:
(a) basic motion recognition, or action primitives, which
represent the atomic entities out of which actions are built,
(b) a set of different or repetitive action primitives that make
up an action, and (c) activities, which represent complex
sequence of actions performed by several humans who could
be interacting with each other in a constrained manner. In
the following we use the term of event instead of action.
Various approaches for categorizing recognition methods
for events and activities have been proposed [2], [23], [24],
based on the approaches used for event modeling.
Figure 2 presents an hierarchy that is similar to the
approach proposed in [24], where the notion of single-
layered approach is replaced with the notion of event, and
hierarchical approach is replaced with the notion of activity.
Single−layered approaches from [24] represent methods that
recognize human motion directly based on sequences of
images, being suitable for recognition of events, while
hierarchical approaches represent high−level human activities
that can be described in term of sub−events.
A. Modeling and Recognition of Events
Methods for event recognition can be again classified into
two types, as presented in Figure 2, depending on the model
used to describe human motion: (i) space-time approaches,
473
Events
Space−time Sequential
approaches approaches
Space−time Space−time
Trajectories Exemplar−based State−based
volume features
Activities
Statistical Syntactic Graphical−based Declarative
Figure 2. Overview of approaches for event and activity recognition
where the input video is considered as a 3D volume, and
(ii) sequential approaches, where the input is considered as
a sequence of frames.
1) Space-time approaches: The aim of these approaches
is to recognize human activities by analyzing space−time
volumes from the video frames. They are divided into several
categories based on the type of features considered in the
3D space−time volumes: (a) volumes, (b) trajectories, and
(c) local features.
Volumes are viewed themselves as features, and the recog−
nition is performed by measuring the similarity between two
volumes. In [25] a template matching method is applied to
a pair of (MEI, MHI), where MEI represents the motion−
energy of an image, and MHI represents the motion−history
of the image. This system is able to recognize simple
actions like sitting, arm waving, and crouching. In [26]
a segmented spatio−temporal volumes method is used to
model human activities, and then a hierarchical meanshift
method is used to cluster similarly colored voxels, while
SVM method is applied to recognize human actions. Authors
of [27] introduce a method that uses background modeling
and spatio−temporal template matching based technique. The
motion history images are used to construct object shape
information for recognizing different human activities, such
as walking, standing, bending, sleeping and jumping.
The space−time volume approaches have difficulties in
recognizing actions when multiple persons are present in the
scene, or when the actions cannot be spatially segmented.
Trajectories are methods, where features are represented
as a sequence of 2D or 3D points corresponding to positions
of the moving objects, and human body part estimation
methodologies are then used to extract the joint positions of
a person at each image frame. In [28] an action is represented
as a set of 13 joint trajectories in a 4D XYZT space,
and an affine projection is used to obtain normalized XYT
trajectories, in order to measure the view−invariant similarity
between two sets of trajectories. In [29] a methodology that
extracts meaningful curvature patterns from the trajectories
is proposed. The system extracts the positions of peaks of
trajectory curves, representing an action as a set of peaks and
intervals between them. By analyzing peaks of trajectories,
the proposed method is able to recognize human actions such
as ’opening a cabinet’ and ’picking up an object’.
One major advantage of the trajectory−based approaches is
the ability to analyze detailed levels of human movements.
However, the problem of the 3−D body−part detection and
tracking remains an unsolved and an open research problem.
Local features are extracted from 3D space−time vol−
umes, and they are used to represent and recognize human
motion. Several approaches extract these local features at
every frame and concatenate them temporally to describe
the human activities [30], while other approaches extract
sparse spatio−temporal local interest points from 3D volumes
[31], [32]. In [33] an approach using local spatio−temporal
features at multiple temporal scales is proposed, which can
handle execution speed variations of an action. In [32]
a spatio−temporal relationship matching is introduced in
order to recognize complex activities. The method measures
structural similarity between two videos, which enables the
detection and localization of complex−structured activities.
In [34] a new model, called context space model, is pro−
posed for detecting anomalous behavior in video sequence.
Context space is defined as an n−dimensional information
space formed by parameters selected from the contextual
information. The proposed method provides guidelines for
the system designers to select information that can be used
to describe context, and enables a system to distinguish
between different contexts.
Methods using local descriptors have some advantages,
because background subtraction or other low−level compo−
nents are not required, and the local features are affine
invariant in most cases. They can be used for recognizing
simple periodic actions such as ’walking’.
2) Sequential approaches: These approaches consider as
input a sequence of video frames, and determine if an
activity has occurred in the video when a particular sequence
of features characterizing the activity is observed. Depending
on the method used to recognize human motion, they are
classified into (i) exemplar-based, and (ii) model-based.
Exemplar-based approaches describe classes of human
actions using training samples, and represent human activi−
ties by maintaining a template sequence or a set of sample
sequences of actions. The dynamic time warping (DTW)
algorithm has been adopted for matching two sequences
with variations [35]. In [36] human activities are recognized
by modeling them as linear time invariant (LTI) systems.
The system converts a sequence of images into a sequence
of silhouettes, extracts contour information, and then uses
SVMs for classifying a new video input. In this way some
simple actions such as ’slow walk’ and ’fast walk’ can be
recognized. In [37] a method for the analysis of human
motion has been proposed that uses joint estimation of
human behavioral information, such as head and body pose.
474
In the first stage a head localization method is used from a
human detection bounding box, and a head pose classifier
is estimated. The second stage is a framework for the joint
estimation of body position, body pose and head pose.
In model-based approaches the human motion is repre−
sented as a model composed of a set of states. The model is
statistically trained, and one statistical model is constructed
for each activity. Hidden Markov models (HMMs) and
dynamic Bayesian networks (DBNs) have been widely used
for state model−based approaches. In [38] a DBN is used to
recognize gestures of two interacting persons. Some gestures
such as ’stretching an arm’ and ’turning a head left’ can
be recognized by constructing a tree−structured DBN. In
[39] an efficient recognition algorithm using coupled hidden
semi−Markov models (CHSMMs) has been proposed, which
extends the coupled HMMs by modeling the duration of
an activity staying in each state. In [40] a method for
object detection and action recognition is presented that
uses a Histogram of Oriented Gradients (HOG) method for
object detection, and a Hidden Markov Model (HMM) for
capturing the temporal structure of the features.
Exemplar−based approaches provide more flexibility for
recognition of human activities than the model−based ap−
proaches (e.g. such systems can maintain multiple and
different sample sequences). In addition, the amount of
necessary training data can be less than in the case of state
model−based approaches. On the other hand, state−based
approaches are able to perform probabilistic inference for
activity determination.
B. Modeling and Recognition of Activities
Higher−level representation and reasoning methods are
necessary for modeling complex activities having inherent
structure and semantics. Accordingly to this assumption, in
approaches for human activity recognition (or hierarchical
approaches [24]) a high−level activity is considered as com−
posed of several simpler activities, denoted by sub-activities
(or actions, or events).
As presented in Figure 2, approaches for modeling and
recognition of activities are divided into four categories:
(i) statistical, (ii) graphical-based, (iii) syntactic, and (iv)
declarative.
1) Statistical approaches: In the case of statistical ap-
proaches, multiple layers (usually two) of state−based mod−
els such as HMMs are used to recognize activities with
sequential structures. At the bottom layer, atomic actions
are recognized from sequences of feature vectors, while
the second−level treats this sequence of atomic actions as
observations generated by the first−level. For each model, a
classifier is constructed by using the maximum likelihood
estimation (MLE), or the maximum a posteriori probability
(MAP). The method of multi−layered HMMs has been
explored by various researchers. In [41] hierarchical HMMs
of two layers are constructed to recognize human activities
such as ’a person having a meal’, or ’a person having
a snack’. In [42] a multi−layered HMM is constructed to
recognize group activities occurring in a meeting room. The
system recognized atomic actions of speaking’, ’writing’,
and group activities such as ’monologue’, ’discussion’, and
’presentation’.
2) Graphical-based approaches: These approaches con−
tain a graphical representation of some state−based models.
Among others we can mention belief networks and Petri
nets.
Belief networks represent Bayesian networks that specify
complex conditional dependencies between a set of random
variables that are encoded as local conditional probability
densities. In addition, Dynamic Belief networks (DBNs)
represent a generalization of the Bayesian networks by
incorporating temporal dependencies between random vari−
ables, and approaches using DBNs may contain multiple
levels of hidden states. In [43] DBNs are constructed to
recognize group activities in a conference room, such as
’break’, ’presentation’, and ’discussion’, based on atomic
actions such as ’talking’, or ’asking’. In [44] a method for
interpretation of human−object interactions is presented, that
integrates information from perceptual tasks such as human
motion analysis, and object detection.
The Petri net (PN) formalism allows a graphical represen−
tation of activities that can be used to model semantic rela−
tions that occur in video events including temporal relations,
spatial and logical composition, hierarchy, and concurrency.
As specified in [45], PN event model approaches can be
divided into two categories: object PNs and plan PNs.
Tokens in the object PN model correspond to objects and
their properties in video sequences, places represent object
states, while transitions represent changes in an object state.
In [46] an enhanced PN model constructed on the object
PN model was used for people surveillance, which replaces
transitions with stochastic timed transitions for dealing with
uncertainty. In plan PN approaches each event is viewed as
a ’plan’ of sub−events, each sub−event being represented by
a place. An event is recognized when the ’sink’ transition of
the plan fires. In this case a separate model for each event
is required. In [47] an enhanced PN model constructed on
the plan PN model is used for people surveillance, which
associates probabilities with tokens. Though PNs represent
an intuitive tool for expressing complex activities, they suffer
from the disadvantage of having to manually create the
model structure. The problem of learning the PN structure
from training−data has not yet been formally addressed.
3) Syntactic approaches: These approaches are based
on grammars that express the structure of a process using
a set of production rules. In video motion understanding
approaches, terminals symbols correspond to abstraction
primitives, nonterminal symbols correspond to semantic
concepts (i.e. sub−events), and production rules correspond
to the semantic structure of the activities. The recognition
475
of an activity represents a parsing process. There are several
approaches for using grammars in in video activity under−
standing, which use different type of grammars: context-free
grammars, stochastic grammars, and attribute grammars.
Context-free grammars (CFG) are one of the earliest
used type of grammars for video activity recognition [48].
In [49] a method that use the CFG formalism to model
and recognize composite human activities and multi−person
interactions is proposed. This method represents a hierarchi−
cal approach, having the lower−levels composed of HMMs
and BNs, while the higher−level interactions are modeled
by CFGs. In complex scenarios involving several persons,
and requiring temporal relations, it is difficult to formulate
the grammatical rules manually. Learning the rules of the
grammar from training data is a promising alternative, but
it has proved to be extremely difficult in the general case
[50].
Stochastic grammars allow probabilities to be associ−
ated with each production rule. This extension provides a
mechanism to deal with the uncertainty inherent in video
surveillance systems. In [51] Stochastic context−free gram−
mars (SCFG) were used to model the semantics of activities
whose structure was assumed to be known, where low−
level primitive detection is performed by using HMMs. In
[52] SCFGs are used to model multi−tasked activities (i.e.
activities that have several independent threads of execution
with intermittent dependent interactions). As in the case of
CFGs, approaches for learning the structure of SCFGs have
been proposed. In [53] a method for automatically learning
a Probabilistic Context−free grammar for recognizing human
actions from sequences of human silhouettes is presented.
Attribute grammars associate conditions with production
rules. In video−surveillance systems, attributes can be at−
tached to primitive events. In [54] Probabilistic Attribute
Grammars have been used for multi−agent activities in video−
surveillance. The primitive events used in this approach are
’appear’, ’disappear’, ’stop’, and ’start’. The primitive events
are associated with attributes such as id (identity of the entity
involved, loc (location where the primitive event occurs), and
class (object classification label).
4) Declarative approaches: Declarative, or Knowledge-
based approaches represent activities in terms of primi−
tives and constraints on them. These methods can express
more complex constraints than grammar−based approaches.
Declarative approaches can be divided in two categories:
logic-based approaches, and ontology-based approaches.
Logic-based approaches use logical rules to describe
common−sense domain knowledge that is used to describe
human activities. In [55] a method for representing activities
using declarative models is presented, recognition being per−
formed by using a constraint−satisfaction algorithm. In [56]
a hierarchical representation to recognize actions performed
by a single person is presented. The first level realizes
detection and tracking of moving objects from the video
stream, while the second level takes the inferred trajectory
of each object, and the contextual information, to recognize
the behavior of the moving objects among a large number
of potential scenarios. In [57] this representation is extended
by considering an activity to be composed of several action
threads, each action thread being modeled as a stochastic
finite−state automaton.
Ontology-based approaches represent taxonomy−based
methods that attempt to categorize human activities accord−
ing to some predefined criteria. Some methods decompose
human activities into a sequence of behaviors to obtain a
flexible description. In [58] a multi−level context hierarchy
ontology is proposed. The ontology is based on knowledge
gained from video recorded in the public spaces, and it
is constructed and implemented using a dynamic Bayesian
network. A formal language, called ”The Video Event Rep−
resentation Language” (VERL) [59] was developed, which
provides an ontological representation of complex events
in terms of simpler sub−events. In addition to annotating
specific events and defining composite properties, the lan−
guage allows to specify inference rules that can be used to
recognize complex human activities.
The main advantage of the statistical and syntactic ap−
proaches is the fact that they allow reliable recognition
with noisy inputs, while the main drawback is the difficulty
for representing and recognizing activities with concurrently
organized sub−events. The main advantage of the graphical−
based and declarative approaches is the possibility to repre−
sent and recognize human activities with complex temporal
structures, while the major drawback is the deterministic
structure at the high−level component.
IV. P RIVACY AND V IDEO S URVEILLANCE S YSTEMS FOR
A SSISTED L IVING
Despite of the variety of the approaches for video surveil−
lance in smart home environments, and of advances in
camera and computing equipment hardware in recent years,
there is a real barrier to introduce the video surveillance
system at home. The most relevant problem is the total
lack of privacy. Actually relatively few surveillance systems
addressing privacy issues have been published.
The majority of work on image sequences applies simple
distortion methods such as pixelation (image subsampling)
or blurring (smoothing the image with a Gaussian filter with
large variance) to obfuscate parts or all of the image [60].
The PrivacyCam architecture proposed in [61] suppresses
automatically segmented foreground objects in the scene and
cryptographically secures access to the altered video stream
produced by the system. In [62] it is proposed a method
for face de−identification by using the k−Same algorithm,
which offers formal privacy protection guarantees. In [63]
an interesting approach is proposed, the respectful camera,
where the problem of automatically obscuring faces in real
time to assist in video privacy enforcement is considered.
476
This approach targets surveillance applications where an
alarm need to be detected, and persons are required to
wear colored hats or vests. Authors from [64] present
a privacy−preserving surveillance video system where the
privacy information can be stored and retrieved in a secure
and reliable manner. A digital signature is inserted into the
resulting video for authentication.
V. C ONCLUSION
In this paper, we have presented an overview of the current
approaches on vision surveillance techniques in smart home
environments. In this review, we have summarized the
methodologies used in several stages of an in−house video
surveillance system: motion detection, object tracking, and
human activity recognition. An taxonomy−based approach
has been presented and applied to current research. In
addition privacy issues in video surveillance systems for
smart home environments have been discussed.
R EFERENCES
[1] V. Ricquebourg, D. Menga, D. Durand, B. Marhic, L. Dela−
hoche, and C. Loge, “The smart home concept: our immediate
future,” in Proc. IEEE Int. Conf. on E-Learning in Industrial
Electronics, dec 2006, pp. 23–28.
[2] G. Lavee, E. Rivlin, and M. Rudzsky, “Understanding video
events: a survey of methods for automatic interpretation of
semantic occurrences in video,” Trans. Sys. Man Cyber Part
C, vol. 39, no. 5, pp. 489–504, sep 2009.
[3] F. Cardinaux, D. Bhowmik, C. Abhayaratne, and M. S.
Hawley, “Video based technology for ambient assisted living:
A review of the literature,” Journal of Ambient Intelligence
and Smart Environments, vol. 3, no. 3, pp. 253–269, 2011.
[4] A. J. Lipton, H. Fujiyoshi, and R. S. Patil, “Moving target
classification and tracking from real−time video,” in Proc.
IEEE Workshop Applications of Computer Vision, 1998, pp.
8–14.
[5] J. Barron, D. Fleet, and S. Beauchemin, “Performance of
optical flow techniques,” Intl. Journal of Computer Vision,
vol. 12, no. 1, pp. 42–77, 1994.
[6] M. Hedayati, W. Zaki, and A. Hussain, “Real−time back−
ground subtraction for video surveillance: From research to
reality,” in Proc. Int. Colloquium on Signal Processing and
Its Applications, 2010, pp. 1–6.
[7] M. Murshed, A. Ramirez, and O. Chae, “Statistical back−
ground modeling: An edge segment based moving object
detection approach,” in Proc. IEEE Int. Conf. on Advanced
Video and Signal Based Surveillance, 2010, pp. 300–306.
[8] O. Barnich and M. V. Droogenbroeck, “Vibe: A universal
background subtraction algorithm for video sequences,” IEEE
Trans. on Image Processing, vol. 20, no. 6, pp. 1709–1724,
2011.
 [9] W. Hu, T. Tan, L. Wang, and S. Maybank, “A survey on visual
surveillance of object motion and behaviors,” IEEE Trans. on
Systems, Man, and Cybernetics, Part C, vol. 34, no. 3, pp.
334–352, 2004.
[10] I. A. Karaulova, P. M. Hall, and A. D. Marshall, “A hierar−
chical model of dynamics for tracking people with a single
video camera,” in Proc. British Machine Vision Conf., 2000,
pp. 261–352.
[11] S. Ju, M. Black, and Y. Yaccob, “Cardboard people: a
parameterized model of articulated image motion,” in Proc.
IEEE Int. Conf. Automatic Face and Gesture Recognition,
1996, pp. 38–44.
[12] S. A. Niyogi and E. H. Adelson, “Analyzing and recognizing
walking figures in XYT,” in Proc. IEEE Int. Conf. Computer
Vision and Pattern Recognition, 1994, pp. 496–474.
[13] Q. Delamarre and O. Faugeras, “3D articulated models and
multi−view tracking with physical forces,” Comput. Vis. Image
Understanding, vol. 81, no. 3, pp. 328–357, 2001.
[14] R. Plankers and P. Fua, “Articulated soft objects for video−
based body modeling,” in Proc. Int. Conf. Computer Vision,
Vancouver, BC, Canada, 2001, pp. 394–401.
[15] T. Zhao, T. S. Wang, and H. Y. Shum, “Learning a highly
structured motion model for 3D human tracking,” in Proc.
Asian Conf. Computer Vision, Melbourne, Australia, 2002,
pp. 144–149.
[16] C. Bregler, “Learning and recognizing human dynamics in
video sequences,” in Proc. IEEE Conf. Computer Vision and
Pattern Recognition, San Juan, Puerto Rico, 1997, pp. 568–
576.
[17] H. Sidenbladh and M. Black, “tochastic tracking of 3D human
figures using 2D image motion,” in Proc. European Conf.
Computer Vision, Dublin, Ireland, 2000, pp. 702–716.
[18] D. G. Lowe, “Fitting parameterized 3−D models to images,”
IEEE Trans. Pattern Anal. Machine Intell., vol. 13, pp. 441–
450, 1991.
[19] J. Hoshino, H. Saito, and M. Yamamoto, “A match moving
technique for merging CG cloth and human video,” J. Visu-
aliz. Comput. Animation, vol. 12, no. 1, pp. 23–29, 2001.
[20] J. E. Bennett, A. Racine−Poon, and J. C. Wakefield, “Mcmc
for nonlinear hierarchical models,” in Markov Chain Monte
Carlo in Practice, W. R. Gilks, S. Richardson, and D. J.
Spiegelhalter, Eds. U.K.: Chapman and Hall, 1996, pp. 339–
357.
[21] M. Isard and A. Blake, “CONDENSATIONconditional den−
sity propagation for visual tracking,” Int. J. Comput. Vis.,
vol. 29, no. 1, pp. 5–28, 1998.
[22] T. B. Moeslund, A. Hilton, and V. Krger, “A survey of
advances in vision−based human motion capture and analysis,”
Comput. Vis. Image Understanding, vol. 104, pp. 96–126,
2006.
477
[23] P. Turaga, R. Chellappa, V. Subrahmanian, and O. Udrea,
“Machine recognition of human activities: A survey,” IEEE
Trans. on Circuits and Systems for Video Technology, vol. 18,
pp. 1473–1488, 2008.
[24] J. Aggarwal and M. Ryoo, “Human activity analysis: A
reviewmachine recognition of human activities: A survey,”
ACM Computing Surveys, vol. 13, no. 3, 2011. [Online].
Available: doi:10.1145/1922649.1922653
[25] A. Bobick and J. Davis, “The recognition of human move−
ment using temporal templates,” IEEE Trans. Pattern Anal.
Machine Intell., vol. 23, no. 3, pp. 257–267, 2001.
[26] Y. Ke, R. Sukthankar, and M. Hebert, “Spatio−temporal shape
and ow correlation for action recognition,” in Proc. IEEE
Conf. on Computer Vision and Pattern Recognition, 2007,
pp. 1–8.
[27] C. M. Sharma, A. K. S. Kushwaha, S. Nigam, and A. Khar,
“Automatic human activity recognition in video using back−
ground modeling and spatio−temporal template matching
based technique,” in Proc. of the Int. Conf. on Advances in
Computing and Artificial Intelligence, 2011, pp. 97–101.
[28] Y. Sheikh, M. Sheikh, and M. Shah, “Exploring the space
of a human actione,” in Proc. IEEE Int. Conf. on Comput.
Vision, vol. 1, 2005, pp. 144–149.
[29] C. Rao and M. Shah, “View−invariance in action recognition,”
in Proc. IEEE Conf. on Computer Vision and Pattern Recog-
nition, vol. 2, 2001, pp. 316–322.
[30] M. Blank, L. Gorelick, E. Shechtman, M. Irani, R., and Basri,
“Actions as space−time shapes,” in Proc. IEEE Int. Conf. on
Comput. Vision, vol. 2, 2005, pp. 1395–1402.
[31] J. C. Niebles, H. Wang, and L. Fei−Fei, “Unsupervised
learning of human action categories using spatial−temporal
words,” Int. J. Comp. Vis., vol. 79, no. 3, pp. 299–318, 2009.
[32] M. S. Ryoo and J. K. Aggarwal, “Spatio−temporal relationship
match: Video structure comparison for recognition of complex
human activities,” in Proc. IEEE Int. Conf. on Comp. Vision,
2009, pp. 1593–1600.
[33] L. Zelnik−Manor and M. Irani, “Event−based analysis of
video,” in Proc. IEEE Conf. on Comp. Vision and Pattern
Recognition, vol. 2, 2001, pp. 123–130.
[34] A. Wiliem, V. Madasu, W. Boles, and P. Yarlagadda, “Context
space model for detecting anomalous behaviour in video
surveillance,” in Proc. IEEE Int. Conf. on Information Tech-
nology: New Generations, 2012, pp. 18–24.
[35] A. Veeraraghavan, R. Chellappa, and A. Roy−Chowdhury,
“The function space of an activity,” in Proc. IEEE Conf. on
Comp. Vision and Pattern Recognition, vol. 1, 2006, pp. 959–
968.
[36] R. Lublinerman, N. Ozay, D. Zarpalas, and O. Camps, “Pa−
rameterized modeling and recognition of activities,” in Proc.
Int. Conf. on Pattern Recognition, 2006, pp. 347–350.
[37] C. Chen, A. Heili, and J. M. Odobez, “A joint estimation
of head and body orientation cues in surveillance video,” in
Proc. IEEE Int. Conf. on Comp. Vision Workshops, 2011, pp.
860–867.
[38] S. Park and J. K. Aggarwal, “A hierarchical bayesian network
for event recognition of human actions and interactions,”
Multimedia Systems, vol. 10, no. 2, pp. 164–179, 2004.
[39] P. Natarajan and R. Nevatia, “Coupled hidden semi markov
models for activity recognition,” in Proc. IEEE Workshop on
Motion and Video Computing, 2007.
[40] C. hao Wang, Y. Wang, and L. Guan, “Event detection and
recognition using histogram of oriented gradients and hidden
markov models,” in Proc. Int. Conf. on Image Analysis and
Recognition, 2011, pp. 436–445.
[41] N. T. Nguyen, D. Q. Phung, S. Venkatesh, and H. H. Bui,
“Learning and detecting activities from movement trajectories
using the hierarchical hidden markov models,” in Proc. IEEE
Conf. on Comp. Vision and Pattern Recognition, vol. 2, 2005,
pp. 955–960.
[42] D. Zhang, D. Gatica−Perez, S. Bengio, and I. McCowan,
“Modeling individual and group actions in meetings with
layered hmms,” IEEE Trans. on Multimedia, vol. 8, no. 3,
pp. 509–520, 2006.
[43] P. Dai, H. Di, L. Dong, L. Tao, and G. Xu, “Group interaction
analysis in dynamic context,” IEEE Trans. on Systems, Man,
and Cybernetics, Part B, vol. 38, no. 1, pp. 275–282, 2008.
[44] A. Gupta and L. S. Davis, “Objects in action: An approach
for combining action understanding and object perception,” in
Proc. IEEE Conf. on Comp. Vision and Pattern Recognition,
2007, pp. 1–8.
[45] G. Lavee, A. Borzin, E. Rivlin, and M. Rudzsky, “Building
petri nets from video event ontologies,” in Proc. Int. Symp.
Vis. Comput., 2007, pp. 442–451.
[46] A. Borzin, E. Rivlin, and M. Rudzsky, “Surveillance inter−
pretation using generalized stochastic petri nets,” in Proc. Int.
Workshop Image Anal. Multimedia Interactive Serv., 2007.
[47] M. Albanese, V.Moscato, R. Chellappa, A. Picariello, P. T.
V. S. Subrahmanian, and O. Udrea, “A constrained proba−
bilistic petri−net framework for human activity detection in
video,” IEEE Trans. Multimedia, vol. 6, pp. 982–996, 2008.
[48] M. Brand, “Understanding manipulation in video,” in Proc.
Int. Conf. on Automatic Face and Gesture Recognition, 1996,
pp. 94–99.
[49] M. S. Ryoo and J. K. Aggarwal, “Recognition of composite
human activities through context−free grammar based repre−
sentation,” in Proc. IEEE Conf. on Comp. Vision and Pattern
Recognition, 2006, pp. 1709–1718.
[50] C. D. L. Higuera, “Current trends in grammatical inference,”
in Proc. Joint IAPR Int. Workshops on Adv. in Pattern
Recognition, 2000, pp. 28–31.
478
[51] Y. A. Ivanov and A. F. Bobick, “Recognition of visual
activities and interactions by stochastic parsing,” IEEE Trans.
Pattern Anal. Machine Intell., vol. 22, no. 8, pp. 852–872,
2001.
[52] D. Moore and I. Essa, “Recognizing multitasked activities
from video using stochastic context−free grammar,” in Proc.
Nat. Conf. on Artificial intelligence, 2002, pp. 770–776.
[53] A. S. Ogale, A. Karapurkar, and Y. Aloimonos, “View−
invariant modeling and recognition of human actions using
grammars,” in Proc. ECCV Workshop on Dynamical Vision,
2006, pp. 115–126.
[54] S. W. Joo and R. Chellappa, “Recognition of multi−object
events using attribute grammars,” in Proc. Int. Conf. on Image
Processing, 2006, pp. 2897–2900.
[55] N. Rota and M. Thonnat, “Activity recognition from video
sequences using declarative models,” in Proc. European Conf.
on Artificial Intelligence, 2000, pp. 673–680.
[56] G. Medioni, I. Cohen, F. Bremond, S. Hongeng, , and
R. Nevatia, “Event detection and analysis from video
streams,” IEEE Trans. Pattern Anal. Machine Intell., vol. 23,
no. 8, pp. 873–889, 2001.
[57] S. Hongeng, R. Nevatia, and F. Bremond, “Video−based event
recognition: activity representation and probabilistic recog−
nition methods,” Comp. Vis. Image Understanding, vol. 96,
no. 2, pp. 129–162, 2004.
[58] D. Chen, J. Yang, and H. D. Wactlar, “Towards automatic
analysis of social interaction patterns in a nursing home en−
vironment from video,” in Proc. ACM SIGMM Int. workshop
on Multimedia information retrieval, 2004, pp. 283–290.
[59] A. Francois, R. Nevatia, J. Hobbs, and R. Bolles, “Verl: An
ontology framework for representing and annotating video
events,” IEEE Trans. on MultiMedia, vol. 12, no. 4, pp. 76–
86, 2005.
[60] C. Neustaedter, S. Greenberg, and M. Boyle, “Blur filtration
fails to preserve privacy for home−based video conferencing,”
ACM Trans. on on Computer-Human Interaction, vol. 13,
no. 1, pp. 1–36, 2005.
[61] A. Senior, S. Pankati, A. Hampapur, L. Brown, Y. Tian, and
A. Ekin, “Blinkering surveillance: enabling video surveillance
privacy through computer vision,” IEEE Security and Privacy,
vol. 3, no. 5, pp. 50–57, 2005.
[62] E. Newton, L. Sweeney, and B. Malin, “Preserving privacy
by de−identifying facial images,” IEEE Trans. on Knowledge
and Data Engineering, vol. 17, no. 2, pp. 232–243, 2005.
[63] J. Schiff, M. Meingast, D. Mulligan, S. Sastry, and K. Gold−
berg, “Respectful cameras: Detecting visualmarkers in real−
time to address privacy concerns,” in Proc. IEEE/RSJ Inter-
national Conference on Intelligent Robots and Systems, 2007,
pp. 971–978.
[64] W. Zhang, S. ching S. Cheung, and M. Chen, “Hiding privacy
information in video surveillance system,” in Proc. IEEE Intl.
Conf. on Image Processing, 2005, pp. 868–871.
 2014 28th International Conference on Advanced Information Networking and Applications Workshops
Domotic evolution towards the IoT
Vittorio Miori
Institute of Information Science and Technology (ISTI)
National Research Council of Italy (CNR)
Pisa, Italy
vittorio.miori@isti.cnr.it
Abstract— The number of smart devices around us grows more
and more every day, and with it the need to interface them in
order to share data and activate functions. Each day, new
scenarios and new applications emerge to make our lives easier
in many different contexts. The race towards realizing a true
Internet of Things (IoT) paradigm has already begun, and by
now such reality is at hand. The work presented herein aims to
offer a practicable, scalable solution for fulfilling many of the
promises of the Internet of Things, even in contexts rendered
problematic by the continuing presence of closed proprietary
systems, lacking any compatibility with Internet protocols,
such as the home automation industry. Starting with a major
contribution by our laboratory to the field of interoperability
among natively incompatible domotic technologies, a software
module has been developed to enable any and all home
automation devices to interface and interact via the IPv6
network protocol. Each and every home automation device can
thereby interact actively with the surrounding world, as it has
been made reachable through its own IPv6 address that
identifies it uniquely on the Internet. The proposed system
thereby advances users’ ability to take full advantage of the
benefits offered by the new IoT vision of the world.
Keywords- IPv6; Interoperability; Web services; Internet of
Things, Ambient Intelligence, Digital Ecosystem
I. INTRODUCTION
Although the Internet has already fundamentally changed
society [1], the greatest transformation still lies ahead of us.
Several new technologies are now converging in a way that
sets the Internet on the brink of a true revolution, as billions
of large and small objects are connected and take on their
own Web identity.
Following on from the Internet of computers, the next
phase of development is the Internet of Things [2], when
more or less everything will be connected and managed in
the virtual world. This transformation will be the Net’s
largest expansion ever and will have sweeping effects on
every industry, and all of our everyday lives.
In fact, in the near future, more and more devices and
systems will be capable of sending and receiving data
automatically via the Internet. This new scenario involves
new developments with enormous potential, for example, in
business markets. Indeed, the Internet of Things (IoT) will
enable connecting market participants and sectors that
previously had no business dealings with one another. This
will generate new products and services, which will in turn
978-1-4799-2652-7/14 $31.00 © 2014 IEEE
DOI 10.1109/WAINA.2014.128
Dario Russo
Institute of Information Science and Technology (ISTI)
National Research Council of Italy (CNR)
Pisa, Italy
dario.russo@isti.cnr.it
lead to the creation of new business models as well. In such a
scenario, companies must get used to the idea of sitting down
and cooperating at a “virtual table”. Web-based platforms
can create the basis for partners to extend or supplement
what they offer in completely new ways.
The Internet of Things is however not just a distant vision
of the future – it’s already here and is having an impact on
more than just technological developments.
Every device that connects to the Internet requires an IP
address, and it has been predicted that by the year 2020 there
will be 50-100 billion Internet-enabled devices in a world [3]
with an expected global population of 7.6 billion people.
Considering that, according to a survey of urban
environments, each human being is surrounded by 1000 to
5000 trackable objects [4], the move to IPv6 [5] is necessary,
as it provides a almost unimaginable number of IP addresses
— 18 quintillion blocks of 18 quintillion possible addresses.
Domotics, or home automation in a so-called “Smart
Home” involves the controlling and monitoring of home
appliances in a unified system. Such control systems include
lighting, climate control (HVAC: Heating, Ventilation, and
Air Conditioning), security systems and even home
electronics. Home automation is closely related to
(industrial) building automation, which focuses on the
automation of large commercial buildings.
There are many different types of home automation
systems available. These systems are typically designed and
purchased for different purposes. In fact, one of the major
problems in the area is that these different systems are
neither interoperable nor interconnected. These systems
range from simple remote-controlled light switches to fully
integrated, networked devices controlling all appliances in an
entire building.
Home automation is an extremely appealing application
of the Internet of Things. It envisions a future home
environment where embedded sensors and actuators (e.g., in
consumer electronic products and systems) are self-
configuring and can be controlled remotely through the
Internet, enabling a variety of monitoring and control
applications. Such communication capabilities are often
offered by manufacturers of domotic systems, though
without Internet compatibility. In fact, each manufacturer
produces its own special device called an IP gateway that
enables physically interfacing a proprietary domotic bus with
an IPv4-enabled Ethernet socket. By connecting the IP
gateway to the Internet, either directly or through a home /
809
residential gateway [6], the domotic system can be managed
remotely using a PC, Smartphone or Tablet through the use
of the proper software.
In contrast to the true IoT paradigm, such solutions
provide the home (but not each device) with a unique
Internet access point (and hence, a unique public IP address
that can be assigned to the IP gateway or the home /
residential gateway according to the home network
configuration) for controlling all the devices connected to a
certain domotic bus. In this scenario, the assigned public IP
address identifies not a single device or function, but the
entire domotic network. For this reason, using common
Internet applications (e.g. Web browsers) is often not
sufficient to interact directly with a single home device
through the Internet: in addition to the IP gateway, a
customized software manager application is required to
locate devices and activate their functions within the domotic
network. In this case, the software manager application may
be run within the IP gateway of the home / residential
gateway, but not within the domotic devices themselves,
which are lacking a public IP address. One example of a
software manager application would be a Web server that
translates Web browser user interactions into specific
domotic commands, and can hence display and enable
interaction with the available devices belonging to a certain
domotic network.
However, by exploiting the functionalities of these IP
gateways, it is possible to develop a system for controlling
home electrical devices via the Internet using the IPv6
addressing system to enable direct control. Thus, the aim of
this work consists in developing software able to interface
directly with domotic devices following the principles of the
IoT paradigm.
The solution presented here is a natural extension of an
existing project carried out at our laboratory called DomoNet
[7], which provides a framework for implementing
interoperability among different proprietary domotic systems
from different manufacturers.
II. RELATED WORKS
Current domotic systems differ widely in characteristics,
operation, functionality, device management and so on. For
these reasons, in general they are not natively interoperable
and moreover use different proprietary media to transmit
messages across their own networks. This is because most
domotic systems use physically different wired or wireless
proprietary buses, and protocols that are incompatible with
Internet and IPv6 technologies. To overcome the current lack
of direct Internet connectivity, many home automation
manufacturers still provide special interfaces called IP
gateways that interface the domotics system buses with the
Internet using the IPv4 protocol. As mentioned, this results
in the ability to interconnect only the domotic bus and not
each single device. Thus, although domotic devices can be
piloted remotely through the Internet, it is still impossible to
interact directly with them using standard protocols.
Many works have addressed the IoT paradigm in some
early attempts to make domotic devices compliant with the
IPv6 protocol. Two main approaches to assigning IPv6
810
addresses to domotic devices lacking IPv6-compatible
interfaces have been followed in the literature:
• hardware: using a NIC (Network Interface Card) for each
domotic device. The NIC acts as a hardware gateway
able to interface the device with the network. This
solution is poorly scalable because it requires physically
modifying and adding hardware to each domotic device;
• software: can be implemented without making hardware
modifications. It is potentially quick and easy to apply to
a virtually infinite number of devices without additional
single hardware costs.
Tin-Yu Wu et al. [8] has proposed an interesting
approach to intelligent appliance auto-configuration in a
networked domain. It implements three functions: (i)
assisting the information appliance in acquiring a regular
domain name without manual configuration; (ii) providing a
session initialization protocol, uniform resource identifier,
auto-configuration and seeing to device registration; (iii)
initiating communications between devices in order to
manage the residential gateway and configure the user
management system interface. Unfortunately, this solution
requires adding a software application that must be executed
during the device system boot, which involves modifying the
original device design by adding different embedded
routines.
Another work in this regard has been presented by van
Moergestel and Meyer [9], who propose a multi-agent based
architecture to implement home automation device
interoperability. The architecture described provides each
device with an independent agent to which an IPv6 address
can then be assigned. However, the solution requires
installing small computer equipment to execute the
corresponding agent on each device, thus making the system
poorly scalable.
Jung et al. [10] propose an approach using a gateway that
allows the integration of a building’s automation system into
constrained RESTful environments by means of a per-device
oBIX-based IPv6 interface. This solution does not require
any direct manipulation or adjustment of the devices. In
another work, Jung et al. [11] propose a solution for adding
IPv6 and illustrate it using the BACNet system as an
example. In the example, however, significant modifications
are made to the BACNet protocol functioning.
Jeong et al. [12] also address the problem of IPv6 and the
Internet of Things, proposing a solution that permits users to
discover, identify and communicate with things
independently of their underlying addresses and network
protocol stacks. The solution exploits the EPC (Electronic
Product Code), a worldwide standard that provides a unique
identity for every physical object anywhere in the world via
RFID or optical data carriers. The solution proposed does not
modify either standard protocols or devices, but implements
an ad hoc network infrastructure.
The solution described in this paper takes the advantages
of the true software approach where no hardware device
modifications are required and of a software middleware
able to flatten out technologic differences among different
domotic devices. The result is a scalable solution that is able
of interfacing on a IPv6 network any home device regardless
its belonging technology.
III. DOMONET FRAMEWORK
Nowadays, the many domotic systems crowding the
market are rarely interoperable and thus do not permit
consumers to choose devices according to their requirements
or other relevant criteria, such as cost, performance, trends
and confidence, instead of being constrained by issues of
compatibility with their pre-existing systems. The current
lack of interoperability is due to the fact that current market
practice effectively binds consumers to proprietary
technologies, thereby forcing them to purchase only devices
conforming to a specific manufacturer’s system to enjoy full
interoperability. To date, no domotic technology has
emerged as a de facto standard in the industry.
To tackle this issue, our laboratory has created a digital
“ecosystem” called DomoNet [7]. DomoNet is an open-
source software application released under the GPL license
that takes advantage of W3C-recommended standard Web
technologies such as Web Services, SOA and XML. The
advantage to using W3C standard solutions is that it ensures
that applications are fully compatible with other standards-
based software and are not tied to any particular software
system, programming language or computer architecture.
DomoNet has been coded using the Java language and open-
source libraries and tools. It offers significant benefits in
terms of interoperability by means of a middleware
infrastructure offering a high level of abstraction and a
comprehensive approach to addressing technology
mismatches directly through the use of ad hoc mappings of
different proprietary standards.
The core of DomoNet consists of middleware based on
the Web Services and Service Oriented Architecture (SOA)
[13] paradigms, in which the services correspond to the
functionalities offered by the devices.
The core of the DomoNet framework is represented by
domoNetWS  a WebServices-based engine whose task is to
enable true cooperation between nodes. It constructs a
unique view of the system, including all the devices
belonging to all the different domotic systems available
through a set of modules that act as gateways, called
TechManagers, to deal with specific domotic systems.
Figure 1 shows a schematic representation of the DomoNet
architecture.
To implement interoperability, DomoNet defines a
standard language, called DomoML, for the semantic
abstraction of heterogeneous systems in order to describe
device functions, data types, messages and models of the
interactions and communications among framework entities.
It represents a sort of universal domotic language to be
applied in any domotic context.
DomoML consists of two main formalisms:
• domoDevice: defines devices and their functions. In
particular, it describes the characteristics of a device, its
location, functions (services) and the processes by which
interactions with other domoDevices must take place.
• domoMessage: formally describes events, commands
and responses.
811
By exploiting the DomoML language, DomoNet
constructs a technologically uniform view of all the devices
available on the network and their functions. In this context,
all differences between domotic systems are leveled, making
DomoNet able to interact with any and all devices using this
single high-level language alone. In this way, DomoNet
mediates the interactions between two or more different
devices belonging to different domotic systems in order to
render them interoperable. DomoML in fact defines and
constitutes a new control layer, which can be viewed as a
meta-infrastructure of high-level services. This logical
infrastructure binds several single domotic systems together
to provide them with common information exchange and
control mechanisms.
Figure 1. DomoNet architecture
At the time of system configuration, DomoNet assigns to
each device detected by the TechManagers a unique id and
the URL of its managing Web service, so that it can be
addressed from both within and outside the framework. By
exploiting the DomoNetWS Web services mechanism in a
standard fashion, it is possible to remotely interact with
devices regardless of the various different underlying
domotic technologies. In fact, the Web services can provide a
list of all the devices belonging to a DomoNet network,
recognize their available functions, and invoke them.
The TechManagers represent the connecting links
interfacing the domotic systems with the DomoNet core.
Each TechManager implements all the functions necessary
for DomoNetWS to manage a domotic system and provide
customized services. One important service permits
interactions with devices by implementing the functions of
an out-and-out gateway using, on the one hand, DomoML,
when the communication is with DomoNet, and on the other,
the language of the specific domotic system, when the
communication is with the domotic bus. A translation service
is moreover provided for sharing information between these
two languages. Other important TechManager services
include discovering devices and their functions, submitting
commands, receiving notifications regarding system states,
and so on. The implementations of these various
TechManager services differ from one to the next, as they
are strictly dependent on the underlying domotic technology.
Extending DomoNet to support a new domotic system
requires simply adding a new TechManager. DomoNet
provides well-documented class interfaces and APIs to
facilitate this process.
 IV. THE IPV6 GATEWAY
Exploiting the peculiar feature of the DomoNet
framework, that is, its ability to provide a uniform system
view of networked devices implementing different
technologies, the aim of this work is to develop a module to
make domotic devices compliant with IoT objectives. This is
made possible by DomoNet’s inherent provisions for
interoperability.
To this end, IPv6 protocol support is a sine qua non. The
software solution developed is perfectly scalable and
immediately adoptable without the need for hardware or
hybrid solutions that may require direct device alterations,
which can in general be risky and difficult for non-
specialized users. Moreover, modifying the hardware of a
large number of devices can be very demanding, especially
when some are not physically accessible.
The proposed software solution provides the DomoNet
framework with IPv6 protocol support, in particular it aims
to:
• link together each DomoNet device via an IPv6 address
using a mapping scheme. This function creates a
correspondence between the DomoNet and IPv6
addressing systems, which enables translating the
address from one representation to other bi-
directionally;
• make each domotic device managed by the DomoNet
framework reachable anywhere and any way through an
IPv6 address. Obviously, all IPv6 addresses associated
to domotic devices must be globally valid, unique and
fully compliant with IPv6 rules;
• implement a dedicated MVC (Model View Controller)
[14] Web interface for each domotic device. This
interface, which must be reachable using the device’s
IPv6 address, displays each device’s status and available
functions.
In general, a set of different instances of DomoNet can
co-exist in the same or different environments. When two or
more DomoNet instances co-exist, they can share the same
devices. By way of example, it is possible to have one
instance of DomoNet at home and another at work. These
two instances can cooperate and share values and functions.
In this way, DomoNet enables, for example, switching a light
off at the office using a push button at home, even if the two
domotic systems implement different technologies from
different manufacturers.
As shown in Figure 1, each DomoNet instance is made
up of a server at the core of the architecture, and a set of
TechManagers, which interface the heterogeneous
technologies.
The solution presented requires assigning a set of global
IPv6 addresses to each machine running an instance of the
DomoNet server. Each IP address in the set, created by the
DomoNet server machine itself, must include two main fields
in order to be valid:
• a prefix that it is used for routing purposes. This can be
achieved by exploiting OS functions and apis. On a
812
Linux machine, for instance, the ip command line is
invoked to obtain the network prefix field and assign an
address to the network interface;
• an interface identifier, which distinguishes the host
network interface. This can be created randomly by the
server machine itself. If combining the prefix with the
interface identifier leads to the generation of an already
existing IPv6 address, a Duplicate Address Detection
error of the NDP protocol results.
Figure 2. IPv6 address assignment
When a new device signals its entry into the DomoNet
network (Figure 2) its associated TechManager creates the
corresponding DomoDevice. The DomoDevice formal
representation of the device is sent to the DomoNet server,
which assigns it both a DomoNet and an IPv6 address,
thereby providing dual identification. In doing so, the
DomoNet server compiles a bi-directional map in order to
enable identification of address correspondences. The choice
of providing this dual representation ensures backward
compatibility with the applications and services previously
created for the DomoNet ecosystem.
Figure 2 illustrates a scenario in which the DomoNet
server receives an IPv6 request from outside its network.
When an IPv6 request is forwarded by a resource belonging
to the Internet of Things, the DomoNet server responsible for
the requester’s address responds. The mapping scheme is
then used to find the correspondence between the IPv6
address and the DomoNet address and identify the correct
device involved. To process the request, the DomoNet server
forwards it to the proper TechManager, which then translates
the request to a formalism that the device can process and
queries the device involved. The device’s response is
delivered to the TechManager and, after the DomoML
translation process, is forwarded to the DomoNet server,
which finally sends it to the requester.
V. THE PROTOTYPE
To test the prototype developed, an instance of DomoNet
equipped with the IPv6 gateway has been set up and running
in a simulated home environment in our demo lab.
The home automation technologies involved in the test
are KNX, UPnP, ByMe and MyHome. Although these
technologies are different and cannot therefore interact
natively, DomoNet provides a unique view of the entire
system and is able to make them interoperate.
The DomoNet server with IPv6 gateway is executed on a
common PC with two network cards to enable it to connect
simultaneously to (figure 3):
end, JavaBean, JSP and Servlet technologies [16] have been
adopted in the test and applied under the constraints of the
MVC [14] paradigm. In this way, the Web server responds to
requests with Web interfaces customized to each device,
which are invoked using the device’s IPv6 address directly.
When a Web request originates from the Internet, Tomcat
responds because it shares the same set of IPv6 addresses as
DomoNet. The request is received by a servlet, which reads
the address of the device involved in the communication
from the requester URL. Using the IPv6DomoNet mapping,
DomoNet then identifies the device and queries it in order to
obtain the information needed to satisfy the request. To
display the results on a Web page, the DomoNet server
creates a JavaBean to represent the device involved and fills
it with the needed data. Tomcat takes the completed
JavaBean as input and shows the result through a JSP.

Figure 3. Architecture of the test

• the local network (DomoNet), where local

communications occur via the IPv4 protocol through a
hardware network switch used to connect the different
domotic systems and the DomoNet server. The
DomoNet server is thereby able to interact with all
devices of all the domotic systems;
• the public network that interfaces the DomoNet server
Figure 4. Device callable functions
with the Internet using the IPv6 protocol.
A dynamic DNS service cooperates with the IPv6 To test the platform’s functioning, we created some test
gateway and DomoNet server. In this way, accessing a Web pages for controlling a device. Using a Web browser, a
network resource does not require specifying long, difficult request was sent to load the main page of the device, which
IPv6 addresses. A Bind9 DNS server [15] is used for this in this example, was an electric oven (Figure 4). This
purpose. To automatically and dynamically assign names to resulting page shows the functions that can be activated, in
the entries in the DNS database, each time a new device joins particular: request the device state, power it on or off, check
the DomoNet network and requests a new IPv6 address, a the state of the electrical socket and enable or disable it. For
DNS entry is created using the device name. instance, the oven power on or off function can be activated
by specifying the needed parameters (Figure 5).
VI. THE WEB INTERFACE
One of the main objectives of the Internet of Things is to
enable direct interaction with devices. A simple way to
achieve this is through a Web interface. However,
unfortunately domotic devices cannot in general interact
directly with Web browsers because they lack standard
Internet protocols, such as http, ldap, imap, pop, and so on.
Moreover, implementing such protocols directly on domotic
devices is not possible due to their hardware limitations. For
these reasons, the Internet protocols must be implemented
elsewhere. Our current implementation includes the use of a
Web server running on the same computer as the DomoNet Figure 5. Device function call
server. This Web server can respond to http requests as if
they were direct Web interactions with a device identified by When the function has been activated, the response
its IPv6 address. In our test, the Tomcat Web server was used shows the updated state of the oven (Figure 6).
to display all the necessary Web pages. VII. CONCLUSIONS AND FUTURE WORK
Due to the potentially extremely different characteristics
of the various devices in the network, in order to avoid The work presented represents an extension of the
generating many distinct Web pages for each device, the DomoNet interoperability framework, consisting of adding
Web server must rely on a dynamic page generator. To this

813
IPv6 capabilities even to domotic systems unable to interact
natively via IP protocols.
To such aim, the software solution developed enables a
unique IPv6 address to be assigned to each domotic device
on the DomoNet network, thereby making all remotely
accessible directly via the Web. A newly implemented Web
server mechanism handles the Internet-based information
flow, allowing for direct interaction with each device.
Figure 6. Response of the device function call
The results obtained represent a first step in achieving
full integration of IPv6-based communications in domotic
systems, and hence for realizing the promise of the Internet
of Things.
Thanks to the flexibility of the DomoNet system, it can
be applied not only within homes, but also to all other
emerging fields where advanced automation is required but
the necessary IPv6 support is lacking, such as Smart Cities,
Smart Grid, Smart Lighting and transportation, in which
new and innovative services will be made possible.
It is nevertheless to be hoped that in the near future
domotic manufacturers offer solutions that enable native
interaction with their with devices using standard Web
protocols based on IPv6 in order to offer ever-more
advanced services and possibilities. The marketing
considerations that limit the development of new, open
technologies only for business reasons should be overcome
and be replaced by the adoption of open standards allowing
for fair competition based on the quality of services offered.
Important future work regards the creation of useful
applications able to exploit all the benefits of adopting IPv6
and the IoT paradigm. To this end, one important goal to
pursue would be to assign each domotic device its own
personalized WSDL [17], which must be created
dynamically, in order to export its functionality external to
the DomoNet framework and thereby decentralize the current
DomoNet Web service support.
A further possible development is to decentralize the
entire DomoNet architecture in such a way as to create
virtual independent devices that act as agents able to
cooperate with each other according to the Digital Ecosystem
[18] architecture paradigm. Such an approach would further
the realization of the concepts underlying the IoT paradigm
and promote a new model for thinking about the
environment surrounding us and the objects contained
therein.
814
REFERENCES
[1] C. Fuchs, "Internet and society: Social theory in the information age.
Routledge", 2013.
[2] L. Atzori, A. Iera and G. Morabito, "The internet of things: A survey"
Computer Networks, 54(15), pp. 2787-2805, 2010.
[3] B. Emmerson, “M2M: the Internet of 50 billion devices”, WinWin
Magazine, pp. 19-22, 2010.
[4] J. B. Waldner, “Nanoinformatique et intelligence ambiante. Inventer
l'Ordinateur du XXIeme Siècle”, London: Hermes Science. pp. p254,
2007, ISBN 2-7462-1516-0.
[5] A. J. Jara, P. Moreno-Sanchez., A. F. Skarmeta, S. Varakliotis, and P.
Kirstein, “IPv6 Addressing Proxy: Mapping Native Addressing from
Legacy Technologies and Devices to the Internet of Things (IPv6)”
Sensors, 13(5), 6687-6712, 2013.
[6] Z. Wei, J. Li, Y. Yang, D. Jia, “A residential gateway architecture
based on Cloud computing”, Software Engineering and Service
Sciences (ICSESS), 2010 IEEE International Conference on, vol., no.,
pp.245,248, 16-18 July 2010, doi: 10.1109/ICSESS.2010.5552422
[7] V. Miori, D. Russo, and M. Aliberti. “Domotic technologies
incompatibility becomes user transparent”, Commun. ACM 53, 1
January 2010, 153-157. DOI=10.1145/1629175.1629211Y.
[8] T.Y. Wu, C.C. Hsu, and H.C. Chao, “IPv6 Home Network Domain
Name Auto-configuration for Intelligent Appliances”, IEEE
Transactions on Consumer Electronics, Vol. 50, No. 2, pp. 491-497,
May 2004.
[9] L. van Moergestel, W. Langerak and J-J. Meyer, "Agents in Domestic
Environments," Control Systems and Computer Science (CSCS), 19th
International Conference on , vol., no., pp.487,494, 29-31 May 2013,
doi: 10.1109/CSCS.2013.57
[10] M. Jung, J. Weidinger, W. Kastner, and A. Olivieri. “Heterogeneous
device interaction using an IPv6 enabled service-oriented architecture
for building automation systems”, In Proceedings of the 28th Annual
ACM Symposium on Applied Computing (SAC '13). ACM, New
York, NY, USA, 1939-1941, 2013, DOI=10.1145/2480362.2480722
[11] M. Jung, C. Reinisch, W. Kastner, “Integrating Building Automation
Systems and IPv6 in the Internet of Things”, Innovative Mobile and
Internet Services in Ubiquitous Computing (IMIS), 2012 Sixth
International Conference on , vol., no., pp.683,688, 4-6 July 2012
doi: 10.1109/IMIS.2012.134
[12] S. Jeong, S. H. Kim; M. Ha; T. Kim; J. Yang; N. Giang; D. Kim,
“Enabling Transparent Communication with Global ID for the
Internet of Things” Innovative Mobile and Internet Services in
Ubiquitous Computing (IMIS), 2012 Sixth International Conference
on , vol., no., pp.695,701, 4-6 July 2012
doi: 10.1109/IMIS.2012.91
[13] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, D. Savio, "Interacting
with the SOA-Based Internet of Things: Discovery, Query, Selection,
and On-Demand Provisioning of Web Services," Services
Computing, IEEE Transactions on , vol.3, no.3, pp.223,235, July-
Sept. 2010, doi: 10.1109/TSC.2010.3
[14] T. Reenskaug, “Thing-Model-View-Editor–an Example from a
planning system”, Technical note, Xerox PARC, 1979.
[15] S. Nathan, S. S. Mohan, A. R., Harudas and K. Nisar, “BERKELEY
INTERNET NAME DOMAIN (BIND).”
[16] D. Alur, D. Malks, J. Crupi, G. Booch and M. Fowler, “Core J2EE
Patterns (Core Design Series): Best Practices and Design Strategies.
Sun Microsystem, Inc., 2003.
[17] E. Christensen, F. Curbera, G. Meredith and S. Weerawarana, “Web
services description language (WSDL) 1.1”, 2001.
[18] G. Briscoe, “Complex adaptive digital EcoSystems”, In Proceedings
of the International Conference on Management of Emergent Digital
EcoSystems (MEDES '10). ACM, New York, NY, USA, 39-46, 2010,
DOI=10.1145/1936254.193
 Simulation Platform for Domotic Systems
Mauricio A. Coral Lozada, Fernando De la Rosa R.
Departamento de Ingeniería de Sistemas y Computación
Universidad de los Andes
Bogotá, Colombia
{ma.coral126, fde}@uniandes.edu.co
Abstract - The lack of a standard in the area of Automation has
led to all manufacturers and researchers to work in parallel on
new technologies which have increased the heterogeneity of
devices and drivers on the market. As a result, each
manufacturer must provide the tools needed for the installation,
configuration and implementation of its technology. As a
consequence, different components of different brands have low
compatibility. This paper presents a simulation platform which
allows automated systems to evaluate a design without the need of
physical implementation, regardless of the component
manufacturer. Furthermore, it increases the number of
components (software and hardware) that could be used as a
controller, it supports multiple communication protocols, it
provides 2D/3D views of simulated scenarios, and it is built using
free software.
Keywords: Automation, simulation, virtual instrumentation, home
automation, smart home, pervasive computing, domotic.
I. INTRODUCTION
Domotic is a set of elements that are installed,
interconnected and controlled by a central system for home
automation, providing energy management services, safety,
welfare and communication. The main objective is to improve
quality of life for residential users by providing most daily
activities like turning on lights, open doors and windows.
Another goal is household resource management, for example
water and gas, to make more efficient use of them.
Pervasive computing is defined as the integration of
computers in the environment of people, so that computers or
controllers are not perceived as distinct objects. Domotic is
included as an area of pervasive computing.
The first problem associated with automated systems is the
lack of a standard to coordinate the efforts of the main
manufacturers towards common goals. As a consequence of
that, there are multiple parallel developments increasing the
diversity of elements in automation based systems. This
increases the complexity of testing because a system can be
composed of different elements which use different protocols
of different brands or suppliers. Another of the problems
associated with automation is the lack of means to evaluate the
system performance without the need of physical
implementation, which increases costs and does not identify
problems in the design stage. For these reasons it is very
common to find statements like: Test and verify the
performance of services in pervasive computing systems is
highly expensive and prone to errors, also demands a lot of
978-1-4799-4340-1/14/$31.00 ©2014 IEEE
time [1]. In [2] Lazovik et al. claim that one of the greatest
difficulties in the development of home automation
applications is that these systems are extremely difficult to test,
because appropriate tests require a physical home dedicated just
for this purpose. In [3] Mateos et al. mention that a common
problem in automation and control is presented in the practice
or testing stage, because developers have to implement and test
their designs using specialized devices control (such as micro
controllers or PLC) and in many cases, the use of scale models
or actual components is not possible, forcing to have to deal
with a large number of switches, leds, etc, which can lead to
confusion or reduce designer motivation. In [4] Lazovik et al.
mention that one of the biggest challenges in home automation
is the verification of the proposed solutions due to the high cost
of the components involved. This shows the need for generic
tools to simulate and evaluate the designs without the need for
any implementation.
This paper is divided as follows. Section II provides a
description of the state of the art. Section III describes our
simulation platform for domotic systems. Section IV describes
the tests done to this work and the last section presents the
conclusion and the future work.
II. STATE OF THE ART
One of the first works to address the issue of simulation of
domotic design is VISIR [5]. VISIR is a software application
for Microsoft Windows that allow designing home automation
installations and carrying out the simulation of the same in
direct connection with the series PLCs SIMATIC S5 and
SIMATIC S7-200 from Siemens, responsible for inspection of
the facility given. This paper focuses on the states of
programming and debugging the system and notes that most of
this work is done in a laboratory at a stage prior to the physical
system installation. Although there are several tools for this
purpose, they have several limitations about aspects such as
their cost, the proximity to the real systems, the development
time, the flexibility to build different systems, the connectivity
between devices, and the maintenance. These limitations make
necessary to develop an application for such tasks. The VISIR
system allows using objects which are grouped into nine
categories according to their characteristics: flat objects (leak
sensor, water solenoid), gas, irrigation, fire, intrusion, lights,
connect (switches, washing machines), 'sunshade' (rain sensors,
anemometers), other (displays).
In [4] is done a description of one of the most common
problem of Automation, the heterogeneity of all products on the
market and the need for interoperability between them. The
authors propose a method of cost reduction in testing
automated systems using virtual "stubs" which behave like if
you have actually installed automation system hardware
somewhere in the house, and further the system displays the
behavior of the home. The developed software is ViSi (Smart
Home Visualization and Simulation) which is based on a SOC
(Services Oriented Computing) architecture and the
visualization is performed using Google SketchUp. The system
has the advantage of being easily extensible, however it
presents problems of performance with increasing the number
of connected components.
The GENIA group at the University of Oviedo presented in
[6] developed two software systems that simplify the design,
installation and maintenance of building automation. The first
one is SIMATICA which sets up all the home automation
features and automatically generates the information required
for the deployment of the system (architecture, components,
wiring diagrams, control routines, manuals, etc). The second
system is SIMAWEB which obtains the information generated
by the SIMATICA automated system and automatically
generates web pages for remote operation and monitoring
automation system.
In [7], Mateos et al. present the design and development
features of an automatic small scale house. The project is called
“Villa domótica” and contains most of the elements present in a
real house. Among the elements under the control system are:
alarms, lights, temperature, presence detectors, irrigation,
communications, etc. The controller used by this work is the
Siemens SIMATIC S7-200. For the development of the home
automation system two software applications are used:
SIMATICA [6] as well as VISIR [5] as a simulation tool. The
main purpose of this project is to develop educational tools that
simplify the learning process of Automation.
In [8], Lopez et al. describe a software that reduces training
costs of implementing automation projects. The main objective
of this work is to increase interest and motivation in the area of
home automation, simplifying the testing process of automation
systems. To describe the work performed, the authors show an
automation project to fill a cart with some liquid made up of
two different components ‘A’ and ‘B’, and transport it from
one place to another. The first step is to design the environment
by the selection, parameterization and interconnection of
different dynamic objects (valves, pipes, tanks, cylinders, etc.)
using GUIs (Graphic user interfaces). Later in the connection
stage, the device´s signals are connected to the controller. The
final stage is the simulation phase. In this phase after the
connection of the PC (Personal Computer) with the PLC, the
process will evolve “as if it were the real one”. User
interactions with the process are also allowed. These user
interactions can simulate operator parameterizations or can
introduce mal-functions in order to test the response of the
control program against anomalous situations. With the purpose
of monitoring the simulation process, the authors developed a
SCADA software denominated Scalibur.
The work of Conde et al. [9] is about smart homes that help
improve the quality of life of patients with physical difficulties
or patients who need to be monitored to events such as falls,
emergency buttons and detection of disease-specific needs.
This work proposes a laboratory specifically aimed to assess
the accessibility and usability for a smart home products and
specialized services. Two parameters are mainly analyzed:
Accessibility and Usability. Accessibility is about the analysis
of identification/localization, reach, access, perceptibility and
comprehensibility levels of system messages, information input
and navigation components of the user interface. Usability
concerns the analysis of effectiveness, efficiency and
satisfaction parameters of user-system interaction.
The platform uses a set of evaluation tools to assess the
accessibility and usability levels of the domotic products, a
context analysis and an expert evaluation. The context analysis
is a formal description of services/products under evaluation,
according to the target user group, and the tasks that the users
can perform. The expert evaluation is a based context analysis
accomplished by a group of experts who have not participated
in the design of the assessed product.
In [10] it is mentioned that one of the main problems in this
area is that most of the problems are identified by the end user,
which decreases customer satisfaction. To mitigate this
problem, this paper examines how to create and deploy virtual
space using virtual reality techniques as a platform to simulate
the configuration of services in smart homes. It proposes a
series of smart homes platform which allows users to
experience virtual places households smart online. Unlike
conventional 3D space, this paper includes information on the
context (spatial relationship between entities, activities and
users). Users can control avatars and thus navigate and operate
in virtual space.
III. SIMULATION PLATFORM DESCRIPTION
The main objective of our work is to develop a
computational platform to simulate the operation of a home
automation system without the need of its physical
implementation. To achieve this, the platform simulates the
behavior of each of the devices configured and through serial
connection delivers this information to a PLC or controller as if
it had the physical devices connected. The purpose to use
simulated elements connected with an external controller is to
separate the behavior of the domotic devices from the
component that manages their inputs/outputs. This component
can be a real controller (hardware component), a virtual
controller (software component), or a hybrid controller
(hardware/software controller). To increase the number of
elements supported by the platform, the developer can add new
models that specify the behavior and functionality of the device
to add.
The simulation platform is composed of four components or
layers and an external controller (Figure 1). The ‘Interaction’
layer allows the user to interact with the platform by defining
the system configuration, and controlling the avatar. The
‘Views’ layer contains components which support 2D and 3D
viewing to see the environment and the simulation results.
Additionally, it contains the graphical interfaces that allow the
user to have visual feedback of system properties, events,
configuration, interconnection of the elements and
communication with external devices. The ‘Simulator’ layer
contains the software components that implement business
logic, such as controlling the avatar, controllers between the
views and the persistence layer, the timer that controls the
system simulation and the interfacing with external controllers.
The ‘Persistence’ layer is responsible for saving the settings
defined by the user, the system log and the historical events
simulated by the platform.
  Activators: Dummy elements that are used to indicate the
User value of a physical variable of the environment (e.g.
temperature).

User Interfaces
Interaction

Avatar Device Controller

Views

2D View Properties Events

3D View Interconnection Communication

Simulator

External Controller Manager Figure 2. Final interface of the Simulation Platform.

SW/HW
Controller
Avatar Controllers Timer
Persistence
System
Configuration
Configuration of
Environments
Configuration
of Devices
Figure 1. Component diagram of the simulation platform.
The domotic simulation platform is built over Sweet Home
3D [11] which is a free interior design application that helps to
place furniture on a house 2D plan, with a 3D preview. This
application was extended by adding the domotic characteristics,
and by implementing the communication interface with the
controller through RS-232 and sockets. Figure 2 shows the
interface of the simulation platform based on Sweet Home 3D.
This graphical interface is composed of the catalog of physical
components available to define domotic environments (top
left), the physical, furniture and domotic objects which define
an environment to be simulated (bottom left), the 2D view (top
right) and the 3D view (bottom right) of the domotic
environment. The 2D visualization view enables the user to
locate the sensors, actuators and devices that will be part of the
environment. The 3D visualization view enables the user to
load the physical model of the place in which to perform the
simulation. The platform has the tools necessary to enable the
user to set the physical environment (stage) by adding doors,
walls, furniture objects, and domotic devices. The 2D and 3D
views include the graphical representation of the user avatar
inside the environment.
Devices that can be added within the simulation are
grouped into four categories according to their characteristics:
 Sensors: Temperature, humidity, fire (smoke), gas, light,
proximity, noise.
 Actuators: Lights, alarms, motors to open/close doors and
windows.
 Controllers: Components of software or hardware that
store the settings programmed by the user. They are
responsible for attending the events generated in the scene
and respond to them.
Every element in the environment simulated is modeled in
the system which must satisfy the properties of its category,
which defines its functionality, and which defines its
constraints. This allows to easily extending the system by
adding new elements to be simulated.
The user can add dummy elements to the simulation in
order to activate the sensors. For example when approaching a
3D cone to a temperature sensor, it will generate an alarm
signal.
To bring realism to the simulation, the final user can control
an avatar inside the simulation environment as if he/she were in
the domotic home and can move freely while activating
sensors, actuators, open doors and windows. In this way the
system will respond to real stimulus. To achieve this task a
VRPN server was added to the project. The Virtual-Reality
Peripheral Network (VRPN) is a network-transparent interface
between application programs and the set of physical devices
(tracker, etc.) used in a virtual-reality (VR) system.
Once the user has configured the environment to simulate,
the simulation platform will generate all the signals and
delivers them via RS-232 or Socket to the system controller.
Simultaneously the platform receives the outputs of the
controller which may define changes in its elements and in the
same way they change the current state of the simulated
environment. These changes are updated in the visual feedback
to the user.
When the application starts all sensor properties are loaded
from a XML configuration file, simplifying the configuration
process. The user can change these properties later using the
Configuration panel shown in figure 3.
When all elements are in place, the user can use the
Connection panel shown in Figure 4, to configure the
connections between them. This panel checks the connection
constraints like voltage levels, and communication protocols.
Additionally, the platform allows defining actions to be
executed when one or more of the sensors detect activity, such
as turn on alarms and open doors and/or windows when a fire is
detected within the home.
The system has several additional interfaces where the user
can easily define system synchronous events (activation of
domotic elements at specific times).
 IV. TESTING
To test the platform, an external controller is needed that is
responsible for receiving and responding to each of the signals
and events that are generated in the simulation environment.
To simplify this step, the platform was extended so it can work
with RS-232 controllers and external hardware devices but
additionally using sockets to use any computer (including the
one in which the simulation is being performed) as a controller
(Figure 5).

Figure 3. Configuration panel with properties of elements.

Figure 5. Available options as external controller to test the platform.

Two additional applications were developed to test the
platform. The first creates a RS-232 link with another PC,
using 8 data bits, no flow control, stop bit and 9600 baud. The
purpose is to use a second PC as a controller and to allow
seeing the data sent and received as in Figure 6. In this case for
each of the inputs, the controller returns the value multiplied
by 2. The second application allows the same as the first but
the communication is done through sockets (Figure 7).
Figure 4. Connection panel.
Additionally the platform supports asynchronous events,
each event activates actions to handle it such as:
 Action(s) related with changes in temperature.
 Action(s) related with detection of fire (smoke).
 Action(s) related with changes in illumination.
 Action(s) related with detection of objects inside a region
of interest.
To mitigate the heterogeneity problems in domotic systems, Figure 6. RS-232 test application.
the platform is capable of supporting the behavior of each of its
elements individually. Technically this means that each
component is represented by an instance of a model that
contains its input parameters, its outputs, its functional logic,
and its communication protocol. To connect two different
functional elements it is necessary to accomplish the electrical
and communication protocol restrictions, so the same bus or
data line can be used to connect these two elements with
different functionality. For example with two proximity
sensors; one returns its handle at the time of an event while the
other returns the distance to the detected object, while both use
the same bus for sending an integer reporting the event. For the
first case, one can detect the sensor area or identify the
presence of an intruder, while the second returns its distance
Figure 7. Socket test application.
from the sensor, not the user location. This model
representation helps for extending the system. For each new For the third option shown in Figure 5 (microcontroller)
element is only necessary to add a model that describes its the pic 18f2550 was chosen which has sixteen free pin for
functionality and its inputs/outputs. At run time, for each digital signals and has a UART for serial communication.
element added to the simulation, the platform creates a new
instance of the model that describes its operation. Three scenarios were constructed to test the platform. The
first of them includes sensors, actuators and it uses a second
PC (through RS-232) as a controller (Figure 8). The scene
contains a proximity sensor, a smoke sensor, a lamp, an alarm,
an avatar and a generating element of smoke. The system must
activate the lamp at the time the avatar is within the coverage
area of the proximity sensor and the alarm must be activated
when the event smoke generator is within the coverage area of
the respective sensor. The aim is to prove that the sensors
detect events of the environment, that they report to the
controller and that the controller sends the response or
activates the action(s) to perform in the environment.
Figure 8. First scene. Comprising a Smoke and proximity
sensor, an avatar, a smoke event generator, a lamp and an
alarm.
The following scenario will show the platform's
capabilities to support the programming of synchronous and
asynchronous events (Figure 9). An example of connection of
heterogeneous devices is shown and a microcontroller will be
used as controller. The connection between the platform and
the microcontroller is by RS-232.
Figure 9. Second test scene. It has four lamps, an alarm, two
proximity sensor (with different functions), a temperature
sensor and an avatar.
The final scenario contains an example with all the
capabilities of the platform. It includes eight proximity sensors,
eight lamps, a smoke sensor, an activator of smoke, an avatar
and, four doors (Figure 10). The controller in this case is a
second computer connected through socket. At the beginning
of the application the house´s lights will turn on automatically
and sequentially in order to simulate that the home is occupied.
Later when a resident comes, the door of the main entrance is
opened and the lights are turned on. As the user moves through
the interior of the house, the lights and the doors open and
close automatically. It generates an event of fire in the house
so the controller activates the alarm and opens the door to
facilitate the evacuation. Finally, in the back of the house an
intruder is detected so the outside lights are turned on, if the
intruder is still approaching, the interior lights are turned on. If
the intruder is too close of the house, the controller turns on
the alarms.
Figure 10. Complete test scene. It includes eight proximity
sensors, eight lamps, a smoke sensor, an activator of smoke,
an avatar and four doors.
V. CONCLUSION AND FUTURE WORK
In this work a simulation platform is designed and
implemented to solve or alleviate the major problems
encountered during the design, implementation and testing of
automation systems. This simulation platform is proposed for
creating a three dimensional environment of a house or
building in which the user can add domotic devices such as
sensors, and actuators. The platform’s external controller is
responsible for controlling the inputs/outputs of the simulated
domotic devices. This controller can be either a hardware
component or a software component. Additionally, the
connection between elements is restricted by the protocol and
electrical rules of the devices. The implemented system is able
to create predefined events that are activated during the course
of the simulation and execute actions when environment
conditions are modified like the temperature or fire detection.
Once created and configured the environment, the user or
designer is able to interact with the platform through an avatar
controlled by a joystick, control (Xbox) or a PC keyboard
during the simulation. The main purpose of the avatar is to
represent a user within the environment so that when moving
within the scene will activate the sensors and actuators. The
platform supports and solves the problems of heterogeneity
present in this field that difficult to simulate environments with
elements of different brands and/or functionality.
The platform developed is able to display a 3D world in
which the user can zoom, rotate or move in order to observe
the scenario from different viewpoints. It is possible to create
interfaces to communicate via RS-232 or Ethernet to the
platform with external controllers both software and hardware
to be appointed to receive events created in the system and
respond accurately and timely. We created a graphical user
interface that simplifies the process of creating the
environment by reducing the time involved in activities that
are not related with the simulation.
The software implementation allows prospective
developers or people responsible for extending the application,
to quickly understand the distribution of models/entities
through the Model-View-Controller (MVC) pattern that was
followed for the construction of the platform.
Functional tests are defined to validate each of the main
features provided by the platform.
For future work we plan to implement more sophisticated
physical models to assess aspects such as temperature of the
place considering the existing heat sources, open windows,
internal temperature. To achieve this goal, one must extend or
modify the way in which the sensors read the environment
variables. It means not to read only a specific value but to
consider all aspects of the environment that affect the value.
It is desirable to extend the number of elements
characterized and included in the platform to expand the
number of supported elements and offer more complex and
extensive simulations.
The editing options of the environment should be extended
and improved. For example adding new ways to select elements
of the environment: by families, by common characteristics,
generally edit the attributes, etc.
The platform can be extended by adding new capabilities to
facilitate the physical implementation of the design. For
example, to generate electric planes or to indicate the amount of
wiring needed to connect the elements.
For a web version of the developed platform Java Web Start
will be used. The Java Web Start software allows downloading
and running Java applications from the web in a browser. With
this choice we will have an online version that allows using all
the features of the simulation platform. However, in this case it
could not control the avatar by the security restrictions of the
web browser.
REFERENCES
[1] Eirini Kaldeli, Ehsan Ullah Warriach, Jaap Bresser, Alexander Lazovik,
and Marco Aiello. Interoperation, Composition and Simulation of
Services at Home. International Conference on Service Oriented
Computing, pp. 167–181, 2010
[2] Alexander Lazovik, Eirini Kaldeli, Elena Lazovik, and Marco Aiello.
Planning in a Smart Home: Visualization and Simulation. In 19th
International Conference on Automated Planning and Scheduling
(ICAPS 2009), pp. 13-16, 2009.
[3] Felipe Mateos, José M. Enguita, Antonio M. López, and Víctor M.
González. Improving laboratory training for automation and process
control courses with a specifically designed testing software application.
IEEE Transactions on Education, vol 44, No 2, pp. 214 – 227, May
2001.
[4] Elena Lazovik, Piet Den Dulk, Martijn de Groote, Alexander Lazovik,
and Marco Aiello. Services inside the smart home: A simulation and
visualization tool. International Conference on Service Oriented
Computing (ICSOC), pp. 651–652, 2009.
[5] Victor Gonzalez, Felipe Mateos, Antonio Lopez, Jose Enguita, Marta
Garcia, and Rosana Olaiz. VISIR, a simulation software for domotics
installations to improve laboratory training. ASEE/IEEE Frontienrs in
education conference, 31st Annual Vol 3, October 2001.
[6] Felipe Mateos, Marta Garcia, Ricardo Mayo, Reyes Poo, Victor
Gonzalez. Software tools for PLC programing and internet HMI in
domotics. International Federation of Automatic Control (IFAC) World
Congress, pp. 905, 2002.
[7] Felipe Mateos, Victor Gonzalez, Reyes Poo, Marta Garcia, Rosana
Olaiz. Design and development of an automatic small-scale house for
teaching domotics. 31st ASEE/IEEE Frontiers in Education Conference
(FIE), vol. 1, October 2001.
[8] Antonio Lopez, Victor Gonzalez, Jose Enguita, Felipe Mateos, Antonio
Robles. Software tools for helping with the design and implementation
of automation projects. 31st ASEE/IEEE Frontiers in Education
Conference (FIE), vol. 3, October 2001.
[9] E. Conde, A. Rodriguez, J. Montalva, M.. Arredondo. Laboratory for
domotic usability evaluations. I Workshop on Technologies for
Healthcare and Healthy Lifesyle, April 2006.
[10] Jumphon Lertlakkhanakul, Jinwon Choi. Virtual Place Framework for
User-centered Smart Home Applications, pp. 177–194, InTech, February
2010.
[11] Sweet Home 3D. [Online]: http://www.sweethome3d.com/. February
20th 2014.
 1569952859
FPGA Implementation of a Smart Home Lighting
Control System
Jesús García-Guzmán, Edgar O. Moctezuma-Monge and Farah H. Villa-López
Facultad de Ingeniería Mecánica y Eléctrica
Universidad Veracruzana
Xalapa, Veracruz, México
jesusgarcia@ieee.org
Abstract—Intelligent homes are nowadays equipped with all
sort of smart devices for the control of appliances and domotic
applications. One of the main aims of these devices is, apart from
the comfort of having automated systems, the efficient use of
energy. This paper reports on the design and FPGA
implementation of a smart lighting system for application in
small smart homes. Unlike those systems using pervasive remote
controls, the proposed system is based on automatic detection of
application conditions, and it requires minimum programming
by the end user.
Index Terms—FPGA, smart home, lighting automated control.
I. INTRODUCTION
Usage of electricity is one of the most important issues in
the global concern about energy. At the domestic level, apart
from electrical appliances such as fridges, cookers and washing
machines, lighting is perhaps the main factor in power
consumption and there have been a lot of research efforts
towards the reduction of its costs by means of smart devices
and systems.
Although there are many proposals for the automation of
lighting in smart homes, it is clear that a balance must be made
between the prices of energy, the costs of smart devices and the
actual comfort of users. Missaoui, Joumaa, Ploix & Bacha [1]
report a recent study on a model that considers simultaneously
these perspectives. Also, it is always important to think about
the real needs and living conditions of users before proposing a
smart home solution, i.e., a system that works well for a given
application might not result suitable for other uses.
Context-aware systems have been proposed both for the
control of lighting [2] and for inference of family needs in
residential environments [3]. In effect, in order to have a real
“smart” system, it is desirable that the proposed system is able
to “learn” from the context or environment and from the usage
patterns of the inhabitants of a house or a building. This is one
of the ideas behind the system proposed in this paper.
Different attempts to reduce the costs of electricity have
been made, such as the sophisticated model proposed by
Zhang, Liu & Papageorgiou [4] for the distribution of costs
among sets of smart homes with microgrids, and other more
conventional studies about energy efficiency of different types
419
of lamps [5]. Also, methods have been proposed in order to
calculate the costs instead of directly metering [6].
In this paper, we present a smart lighting system that can be
applied in smart homes, implemented experimentally on a
FPGA board and being capable of automatically adapting to
user needs and conditions, while requiring minimal field
programming.
II. DESCRIPTION OF THE PROPOSED SYSTEM
Figure 1 shows the block structure of the system, which
was programmed using the Altera DE2 board, based on a
Cyclone II FPGA. A clock signal at 1Hz is generated in order
to regulate the operation of the entire system. Counters for
hours, minutes and seconds were synchronized and two buttons
of the board are used to set the time, which is shown in a group
of 7-segment displays.
Programming of the timing for switching the lights on/off is
accomplished by a second module on the system. Here, the
user sets the times of the day in which automatic detection of
people will be operating. When the system is on, signals
indicating the presence or traffic of people are used as inputs to
the control system, which in return will generate the outputs
controlling the state of the lamps.
Intelligence of the system is provided by another logic
module, in which counters, adders and subtractors keep a count
of people in every room, and this condition is evaluated
together with the timing programmed in the previous module.
This way, light in a room is on only when it is required by
people. Furthermore, deriving information from the sequence
of activation of flip-flops in the counters, the system is capable
to detect the direction of movements between rooms, which is
particularly critical in small houses, where rooms often share
areas for communication between them.
PROGRAMMABLE INTELLIGENT INPUT – OUTPUT
DIGITAL CLOCK TIMER FOR DETECTION
GENERATOR SYSTEM OF LIGHTING
ASSIGNMENTS
AND CONTROL
ENABLING NEEDS
Fig. 1. Logic structure of the lighting control system.
 1569952859
Fig. 2. Circuit for detection of required state of a lamp.
Figure 2 shows the schematic of a circuit detecting the
conditions for the use of a lamp, depending on the counts of
people entering and leaving the room, the time at which
movement occurs, and the direction of traffic.
The last block in the system diagram corresponds to the
inputs and outputs. Assignment of pins depends on the number
of rooms and lamps of a given application, which is limited in
this design to the availability of ports in the expansion headers
of the Altera DE2 board.
III. EXPERIMENTAL FPGA IMPLEMENTATION
The developed system has been programmed in the
Cyclone II FPGA included in the DE2 board, for the simulation
of lighting control in small homes. Signals from sensors
detecting the presence and movement of people were simulated
through a set of input switches available in the board. To
complement the system in an actual application, a wireless
sensor network can be used, giving additional intelligence to
the arrangement. Output signals are sent to an array of LEDs,
replicating the actual lights in the home. For a particular set of
real lamps, output signals should be sent to the expansion
parallel ports and additional circuitry may be required,
depending on the type of lamps and power switches installed,
although the logical performance will remain the same.
Several tests were performed, programming operation of
the system from say 7 am to 11 pm, and considering the usual
movements for a five people family. The rooms (a lounge, a
kitchen, one bathroom, and two bedrooms), had common areas
for communication and there was also a corridor which was not
controlled by counting people but only by timing. The system
performed as expected in all the situations tested, which
included every combination of the corresponding look-up table
prepared for the experiments.
IV. CONCLUSIONS
A lighting control system for smart homes has been
developed and implemented experimentally on an FPGA
420
board. The system proved to be functional when adapted to the
needs of a family in a small home. Programming required by
the end users is minimal and the operation of the system is
adjusted automatically depending on the conditions of use.
Practical implementation for actual smart home operation
would require a small PCB with the FPGA, a few
programming buttons, 7-segment displays and additional
interfaces for inputs (sensor signals) and outputs (light
switching signals).
REFERENCES
[1] Rim Missaoui, Hussein Joumaa, Stephane Ploix, Seddik Bacha,
“Managing energy smart homes according to energy prices:
analysis of a building energy management system”, Energy and
Buildings, vol. 71, pp. 155-167, March 2014.
[2] Chao Li, Lijun Suna, Xiangpei Hua, “A context-aware lighting
control system for smart meeting rooms”, Systems Engineering
Procedia, vol. 4, pp. 314-323, 2012.
[3] Ju Hyun Lee, Hyunsoo Lee, Mi Jeong Kim, Xiangyu Wang,
Peter E.D. Love, “Context-aware inference in ubiquitous
residential environments”, Computers in Industry, vol. 65(1),
pp. 148-157, January 2014.
[4] Di Zhang, Songsong Liu, Lazaros G. Papageorgiou, “Fair cost
distribution among smart homes with microgrid”, Energy
Conversion and Management, vol. 80, pp. 498-508, April 2014.
[5] Tobias Welz, Roland Hischier, Lorenz M. Hilty,
“Environmental impacts of lighting technologies — Life cycle
assessment and sensitivity analysis”, Environmental Impact
Assessment Review, vol. 31(3), pp. 334-343, April 2011.
[6] Eva Rosenberg, “Calculation method for electricity end-use for
residential lighting”, Energy, vol. 66(1), pp. 295-304, March
2014.
[7] Edgar O. Moctezuma-Monge, “Programación en FPGA de la
etapa digital de un sistema de iluminación en edificios
inteligentes”, BEng Thesis, Universidad Veracruzana, 2010.
 A ZigBee Wireless Domotic System
with Bluetooth Interface
Eurico Leite, Luis Varela, V. Fernão A. J. Pires
Pires, and Filipe D. Cardoso ESTSetúbal, IPS and CTS-UNINOVA
ESTSetúbal, IPS Portugal
Estefanilha, Portugal
Abstract— In this paper a wireless home automation system is
presented. The proposed system allows controlling devices in a
home environment by using a simple Bluetooth equipped mobile
phone. The mobile phone communicates with a main
Bluetooth/ZigBee module that communicates with the different
ZigBee modules acting as the coordinator of the ZigBee network
established between all nodes where electrical devices are
connected. The identification of each device is made through
DomoML strings by using the KNX home automation standard
protocol.
Keywords—Home automation; Smart homes; Low-power
electronics; Zigbee; Bluetooth
I. INTRODUCTION
In recent years home automation has became an important
issue with increasing dissemination degrees in the future. This
technology allows tenants to manage the internal home
environment. Home automation is nowadays a key concept
regarding home energy efficiency improvement [1].
The evolution of low-power electronics and wireless based
systems has given mankind the possibility of being more
demanding regarding his well-being without no significant
need for expensive investments. In the area of home
automation there are three basic features that need to be
addressed: comfort, efficiency and safety. These basic
requirements of home automation are commonly known as
building intelligence control. Following this evolution, homes
have been improving in order to satisfy these needs. With the
recent interest in low-cost wireless networks it is now possible
to have small, energy-efficient electronic devices that can
monitor and control heating, air conditioning, lights, food
preparation, entrance gates, security systems and appliances
without any special wiring.
Home automation, specifically wireless home automation,
presents several applications and advantages to home tenants.
Amongst the several applications one can consider light and
HVAC control, surveillance, smart door lock and automated
security system, electrical appliances control, water supply and
irrigation, smart metering and energy management. Users will
benefit from wireless home automation systems, particular in
energy savings, improved security and occupant safety, better
comfort and living conditions, reduced equipment maintenance
and operational costs, increased equipment’s lifetime and
environmental gains.
k,((( 
João F. Martins
FCT/UNL and CTS-UNINOVA
Monte de Caparica
Portugal
As the number of devices grows, there is a possibility that
inefficient management may occur. This is viewable in
appliances that are always on, regardless of having a standby
mode or not, wasting power. Besides this, there is also the
matter of knowing which remote controller is associated with
each device. Regarding compatibility it’s important that all
devices are interoperable preventing spending time controlling
each one of them.
Thus, for appropriate monitoring and control all the devices
could be linked to a central automatic system that will handle
events activating devices, as they are needed. With this system,
power consumption can be reduced whereas resources are more
efficiently used. Moreover, the tenant can check all the data
about the devices in a single place locally or remotely through
a mobile device like a laptop, a mobile phone or a Personal
Digital Assistant (PDA).
On the other hand, safety is also an important factor. The
system must be protected against unauthorized accesses and at
the same time, allow monitoring the status of every device in
the house therefore improving security and allowing to identify
possible malfunctioning of given equipments.
From the business point of view wireless sensors networks
are not yet too much developed. The large variety of protocols,
standards and solutions makes them confusing for potential
investors [12]. In the literature one can find a considerable
number of research papers that discuss the existing wireless
home automation technologies [13][14]. Amongst those
technologies one can consider, ZigBee [16], Z-Wave,
Bluetooth, 6LoWPAN, Insteon, Wavenis, UWB, Wi-Fi, X10,
KNX, LON, Powerelink or EnOcean, just to name a few.
Several ZigBee based home automation systems have been
presented just recently [3][4][5][17]. This technology usually
implies the use of WiFi if the tenant wants to have wireless
access to the system. Likewise, technologies like Bluetooth
were also applied to the home automation [2][6][18]. From a
scalability point of view, there is a strict limitation of number
of home equipments attachable to the Bluetooth master device
due to the characteristics of the protocol. However the
Bluetooth protocol could be a good solution in the absence of a
WiFi network. On the other hand, the power consumption of
Zigbee or Bluetooth devices is almost ten times lower than
WiFi devices. Some solutions integrate traditional wired
solutions with wireless ones, being [7] a good example on
using a KNX-ZigBee gateway for home automation. However,
future home automation systems should discard intrusive
cabling throughout home. This paper puts together Bluetooth,
ZigBee and KNX in order to get the best of each technology
for the tenant’s well being.
In this paper, a wireless home automation system is
proposed. The system allows controlling and monitoring
electrical equipment by using a simple Bluetooth equipped
mobile phone. The wireless home network is implemented with
wireless ZigBee modules that communicate centrally with a
Bluetooth ZigBee Central Module. The standard used for
communication between the different equipments using the
ZigBee network is Konnex (KNX), a worldwide standard for
home and building control applications. The proposed system
allows easy Plug-and-Use addition and removal of devices.
Integrating the proposed system into other home automation
networks is also considered since Domotics Markup Language
(DomoML) strings are used to ensure interoperability.
DomoML is a mark-up language aimed at the definition of
interoperability standard for domestic use. DomoML is the
glue which allows different home automaton systems to be
interfaced since a semantic layer is defined on which novel
value-added services (agents) can easily be built.
One last remark regarding available commercial home
automation solutions. There is an increasing number of home
automation and smart home control devices and systems (a
quick internet query reports a huge number of commercial
solutions). However, those solutions are becoming more and
more sophisticated, using WiFi protocols and considering
PDAs, tablets or smartphones as preferred human-machine
interfaces. Regular Bluetooth mobile phones are no longer
considered. Thus it is important to consider wireless home
automation systems that not depend exclusively on WiFi
protocols and/or smartphone like devices.
This paper is structured as follows. The system’s adopted
technologies are briefly described in Section II. The proposed
system architecture and its operation are detailed in section III.
In Section IV, different network devices are described in detail.
Implementation results and tests are presented in Section V.
Finally, in section VI, conclusion and final remarks are
presented.
II. ADOPTED TECHNOLOGIES
The proposed system incorporates different technologies
that are based on already well known standards, used in
numerous consumer electronics devices and products.
A. Wireless Standards
Two different technologies are adopted, IEEE 802.15.1 [8]
and 802.15.4 [9], commonly known as Bluetooth and ZigBee
respectively. The ten years old Bluetooth standard is already
widely supported in most mobile devices and computers
whereas ZigBee is best suited for sensor and monitoring
applications, thanks to its low power consumption, improved
coverage range, low datarates (on the order of a few hundreds
of kbps) and low equipment cost. There are a lot of home
automation Zigbee applications, raging from security to light or
HVAC control [19][20][15].

Bluetooth devices are categorized in three power classes:
class 1 (100 mW), class 2 (2.5 mW), which is the most
common, and class 3 (1 mW) being rarely used. Datarates,
depending on the standard version, can go up to a few Mbps,
which is enough for most voice and low datarate applications.
The main drawback of Bluetooth is its low energy efficiency
and the maximum number of devices that it can support
simultaneously – a maximum of 7 devices is allowed.
Instead, ZigBee devices are intended to be energy-efficient
while providing datarates from several tenths to a few hundreds
of kbps while allowing connecting 65000 devices
simultaneously. Typical coverage range varies from a few
meters to several kilometers depending on the transmitting
power, antennas and frequency band. Additionally, different
sleeping modes are possible therefore allowing energy
efficiency improvement. However, the structure of the
established network limits the number of nodes, as well the
amount of traffic [21]. This makes Zigbee more suitable for
home automation applications.
B. Konnex Standard
There are more than 15 standard protocols related with
building’s communication. Some standards covering the
buildings communication issues are: BACNet (CEN EN ISO
16484-5), LonWorks (CEN EN 14908, ISO/IEC 14908-1),
KNX (CENELEC EN 50090, CEN EN 13321-1 ISO/IEC
14543-3) or ModBus, just to name a few.
Konnex (KNX) [10] resulted from the convergence of three
entities in the European market, which emerged in the early
90s. These are the European Installation Bus Association
(EIBA), who has achieved great success in Germany and
northern Europe, the Batibus Club International (BCI), which
is well established in Italy and Spain and the European Home
System Association (EHSA).
In order to unify these systems on the market for intelligent
homes the Konnex Association was created, in 1999. Given
that those different systems had their own manufacturing
partners, the need arose to create a single system encompassing
the areas of operation. Thus, to achieve interoperability of
equipment from various manufacturers, the KNX becomes part
of the control features in a widely varied set of devices for
various fields.
Due to the fact that KNX is considered one of the most
promising standards in home automation systems, several
researchers proposed security mechanisms [22] and the
introduction of ambient intelligence mechanisms [22].
C. DomoML
Presently, there are a variety of different systems in a home
such as the water system or the media system. Each of them
controls their own devices and specifications. However, most
of these systems are heterogeneous which means that they
can’t “speak the same language”. It could be interesting if all
the systems could understand one another in order to provide a
real home system.
In order to solve the interoperability between devices from
heterogeneous systems, reference [11] proposes a new service
orientated architecture named DomoNet (Domotic Network). It
works based on the functionalities offered by the different
devices and consists in different network servers (WebServices
based) that identify a device and forwards the messages to a set
of modules known as TechManagers which are interfaced to
the different home automation systems.
The process of identifying the device and its function is
made by a universal language (DomoML) based on XML and
is used to describe messages and devices in the network. It
consists of two essential parts: domoDevice, which identifies
the network device through four levels of identification
(device, service, input or linkedService, allowed or
linkedInput), and domoMessage, which describes the
interactions between devices with two levels of identification
(message and input).
In the proposed system, DomoML is intended to describe
devices in a homogeneous and universal way, as presented in
Figure 1. This enables the user to update a database of devices
without any substantial changes to the source code.
Fig. 1. DomoML device description.
The identification of each device or set of devices in the
proposed network is specified by a KNX address, as stated
before, and presented in Table I.
TABLE I. EXAMPLE OF DEVICE ADDRESSES FOLLOWING THE KNX
STANDARD.
Device Address Group Address
Mobile 0.1.1
Coupling Unit 0.0.1
Switching Unit #1 0.0.2 1.0.0
Switching Unit #2 0.0.3 1.0.0
Dimming Unit 0.0.4 1.0.0
Remote Unit 0.0.5
III. SYSTEM ARCHITECTURE
The proposed system was designed to be easy to install,
flexible to use and modular. This means that is possible to
add/remove units while the system is operating without any
required user action. Four distinct units were considered:
Coupler Unit (CU), Switching Unit (SU), Dimming Unit (DU)
and Remote Control Unit (RCU), each of them with specific
features as it will be described in Section IV. These units,
altogether made up the ZigBee home wireless network, which
is presented in Figure 2.

Fig. 2. System architecture.
In order to access the system, a mobile device with a Java
application is used to interact with the network, allowing the
tenant to properly access and monitor different equipments.
However, there is still the possibility of gaining limited access
to the units through a portable standalone Remote Control Unit
(RCU).
The RCU allow controlling SU and DU, therefore, serving
as a backup solution for controlling different devices when the
mobile device is not available. Its use is limited since it can
only send control actions to SU and DU, monitoring is not
possible.
It should be underlined that any mobile phone with the
required Java application can be used, therefore improving the
flexibility of the developed system.
The SU is an interface that allows ON/OFF switching of a
set of given devices. The DU has the possibility of changing
the device’s applied voltage, therefore being particularly suited
for lighting control, amongst any others possible applications.
As an alternative, a RCU can be used to access the ZigBee
network if a mobile device is not available.
The mobile device communicates with the Bluetooth CU
interface allowing control and monitoring actions that are sent
and received from the SU or the DU. Information received
from the mobile terminal are processed by the CU. In the case
of an unrecognized address (not in use by any active SU or
DU), the CU forwards the commands to a default gateway
(computer) via an RS-232 interface, making it available to
other network, if other active networks are available.
Valid addresses, the ones associated to active SUs and/or
DUs, are accepted. The CU broadcasts the ZigBee network and
waits for reply from the SU or DU with the given specified
address. Once the data is received by a SU or DU, it is checked
for validity and the corresponding switching or dimming
command is activated.
IV. NETWORK ELEMENTS
A. Coupler Unit
The CU, presented in Figure 3, is the brain of the proposed
system. As referred, it is responsible for interfacing the
ZigBee network with the mobile device, being equipped with
a Bluetooth and a ZigBee module, and a PIC16F684
microcontroller.
The Bluetooth module is a 2.5mW, class 2, 2.4 GHz
module, with a sensitivity of -80 dBm, providing about 10 m
coverage range in Line-of-Sight (LoS) environments. The
maximum datarate is imposed by the ZigBee network being
115.2 kbps.
The Zigbee module is a 1 mW XBee 2.4 GHz module with
a sensitivity of -92 dBm. Typical coverage range being in the
order of a few tenths of meters depending on the operating
conditions.
Fig. 3. Coupler Unit prototype.
The communication between the Bluetooth and ZigBee
modules and the microcontroller is performed through a SPI
bus by the UART/SPI adapter. This is mandatory since the RF
has a UART interface. Other possible solutions to
communicate with the different modules could be UART by
software or multiplexing the ports. However, in the first case
there would be a burden on the microcontroller with I/O
operations while in the second, only one channel could be
used each time. When there is no active transmission, the
microcontroller will enable sleep mode on both modules, in
order to provide greater energy efficiency.
B. Switching Unit
The SU, presented in Figures 4 and 5, receives commands
from the ZigBee network and acts directly on the control
element, for example some lighting equipment. It consists of a
ZigBee module, a microcontroller, a power source and a DC-
DC converter.
Fig. 4. Switching Unit prototype.

Fig. 5. SU architecture.
SU operation starts with a KNX command received from
the CU via the ZigBee interface. The received command is
interpreted by the microcontroller and if this is a valid
command, and the destination address correspond to the one
of the given SU then the microcontroller operates the lighting
control circuit. If for some reason a command is not
recognized a NACK command is sent back to the CU.
C. Dimming Unit
This unit differs from the switching unit mainly because it
has a PWM generator enabling not only on/off control but also
modifying the RMS voltage applied to the lamp.
Recognizes DPT_Control_Dimming based messages and as
such is capable of generating up to eight different levels.
D. Remote Control Unit
In order to access the home network without the need for a
mobile phone, a wireless switch module was developed and
presented in Figures 6 and 7. It presents low energy
consumption, allowing the remote control of the switching
unit.
This unit has a button that allows sending a KNX message
(DPT_SWITCH, reading mode) to the switching unit. Upon
receiving the result of the reading, the microcontroller sends a
command message (DPT_SWITCH writing mode) that
contains the command to change the state of the lamp.
The module is able to hibernate when not in use. This
allows the module to work with only a residual current of less
than 10 ȝA.

Fig. 6. Remote Control Unit prototype.
Fig. 7. RU architecture.
E. Mobile Terminal
In order to control the entire network a cell phone was
used. This choice was based on the fact that these devices are
quite common and flexible. Thus, a relatively inexpensive and
personal universal controller can be achieved. Figure 8
presents a snapshot of the developed interface. For security
purposes each user must register using a personal password.
Fig. 8. Mobile phone interface.
The main interface is provided by a Java application
installed on a mobile terminal. This choice was made because
of its versatility; it can work almost on every mobile phone.
This application communicates directly, via Bluetooth, with
the Coupler Module that in turn has access to the remaining

network. The application is flexible enough to allow easy
inclusion of devices from a remote or local database, for
which DomoML was used. Both the GUI and the KNX
messages were computed from the devices in the database
(interpreting the DomoML).
Figure 9 presents the block architecture of the developed
mobile application. It has five main classes: DisplayManager,
KnxManager, XmlManager, Menu e InterfaceIO. The Menu
class is a generic class; it has some pre-defined values and
allows menus’ polymorphism. DisplayManager is the class
responsible for managing the menus holding until 10 menus’
layers. The KnxManager class is responsible for managing the
input/output datagrams coming from/to the InterfaceIO class,
which manages the I/O communication. The XmlManager
class is responsible for processing XML data, as the ones
coming from the DomoML language.
Fig. 9. Mobile phone interface block architecture
V. TESTS AND RESULTS
In this Section some results of tests and trials conducted on
the developed system are presented. Parameters like maximum
range, line of sight viability and power consumption are
analyzed.
For the Bluetooth module was observed that this module
can keep a link in the line of sight, up to 17.5 meters.
Regarding the ZigBee module, it communicates within 100
meters line of sight conditions.
In order to measure the ratio attenuation / distance several
tests were made in line of sight, making four measurements at
four meters. Measurements were obtained using the X-
CTU. To this end, the command ATDB was used in the
ZigBee module to establish the power of the last received
message (RSSI), as presented in Table II.
VI. CONCLUSIONS AND REMARKS
The work presented in this paper refers to a ZigBee wireless
domotic system with a Bluetooth interface. It allows tenants to
connect a single mobile device to a ZigBee based wireless
home automation network. To assure a line of communication
between the mobile device and the network units, a main
module device is equipped with low-cost WPAN technology,
widely used in mobile applications and sensor monitoring.
 TABLE II. AVERAGE RSSI VALUE [4] Maoheng Sun, Qian Liu, Min Jiang, "An Implementation of Remote
Lighting Control System Based on ZigBee Technology and Soc
Distance (meters) RSSI Value (dBm) Solution", International Conference on Audio, Language and Image
4 -63,25 Processing, 2008.
8 -61,25 [5] Michal Varchola, Miloš Druarovsky, "Zigbee Based Home Automation
Wireless Sensor Network", Acta Electrotechnica Et Informatica No. 4,
12 -73,75 Vol. 7, 2007.
16 -72 [6] R. Shepherd "Bluetooth Wireless Technology in the Home", Electronics
20 -67,75 & Communication Engineering Journal, Vol. 13 Issue.5, pp. 195 -203,
October 2001.
24 -72
[7] Woo Suk Lee and Seung Ho Hong, "Implementation of a KNXZigBee
28 -73 Gateway for Home Automation", The 13th IEEE International
32 -75 Symposium on Consumer Electronics (ISCE2009), 2009.
36 -82 [8] "IEEE IEEE 802.15 WPAN Task Group 1 (TG1)", official web site,
40 -80,25 http://www.ieee802.org/15/pub/TG1.html
44 -82,25 [9] "IEEE IEEE 802.15 WPAN Task Group 4 (TG4)", official web site,
http://www.ieee802.org/15/pub/TG4.html
48 -79,5 [10] Konnex Association, Handbook for Home and Building Control:
52 -80,5 Application Layer, 1st ed., 2001, vol. 3, ch. 3.7.
56 -79,75 [11] Miori, V.; Tarrini, L.; Manca, M.; Tolomei, G., "DomoNet: a framework
60 -78,25 and a prototype for interoperability of domotic middlewares based on
XML and Web Services," Consumer Electronics, 2006. ICCE '06. 2006
54 -81,75 Digest of Technical Papers. International Conference on , vol., no.,
68 -83,75 pp.117,118, 7-11 Jan. 2006
[12] Dietrich, D.; Bruckner, D.; Zucker, G.; Palensky, P., "Communication
The proposed system tries to implement the four pilars of a and Computation in Buildings: A Short Introduction and Overview,"
domotic system: comfort, safety, resources and Industrial Electronics, IEEE Transactions on , vol.57, no.11,
pp.3577,3584, Nov. 2010
communication; in order to improve the tenant’s quality of life
[13] Sauter, T., "The Three Generations of Field-Level Networks—Evolution
at home. and Compatibility Issues," Industrial Electronics, IEEE Transactions on ,
The system is built in order to be flexible, meaning that is vol.57, no.11, pp.3585,3595, Nov. 2010
possible to add devices to the network, such as a GSM or [14] Gomez, C.; Paradells, J., "Wireless home automation networks: A
modem modules or even connect another mixed network, with survey of architectures and technologies," Communications Magazine,
IEEE , vol.48, no.6, pp.92,101, June 2010
quick and easy programming, without interrupting the network
[15] Spadacini, M.; Savazzi, S.; Nicoli, M., " Wireless home automation
already working. Besides, it is also possible to swap the RF networks for indoor surveillance: technologies and experiments,"
chips with new chips and take advantage of other new features EURASIP Journal on Wireless Communications and Networking, vol. 6,
such as AES encryption for extra security and higher 2014
transmission rates. [16] Ramya, C.M.; Shanmugaraj, M.; Prabakaran, R., "Study on ZigBee
The number of devices in the network is only limited by the technology," Electronics Computer Technology (ICECT), 2011 3rd
International Conference on , vol.6, no., pp.297,301, 8-10 April 2011
number that the KNX standard allows and the number of
[17] Hwajeong Seo; Howon Kim, "Zigbee security for visitors in home
ZigBee devices used in the PAN network. automation using attribute based proxy re-encryption," Consumer
The Java application, installed on the mobile phone, can be Electronics (ISCE), 2011 IEEE 15th International Symposium on , vol.,
updated with more IO interfaces for the KNX Manager giving no., pp.304,307, 14-17 June 2011
the network more features such as text messaging commands [18] Piyare, R.; Tazil, M., "Bluetooth based home automation system using
cell phone," Consumer Electronics (ISCE), 2011 IEEE 15th
or internet access. International Symposium on , vol., no., pp.192,195, 14-17 June 2011
VII. ACKNOWLEDGEMENT [19] Shuai Yao; Mingguang Wu; Yanpeng Liu; Pinan Yang, "Research on
EIB and Development of Switch Module," Industrial Informatics, 2006
This work was supported by international funds through IEEE International Conference on , vol., no., pp.1241,1244, 16-18 Aug.
SOE3/P1/E508 - programa de Cooperação Territorial 2006
Europeia INTERREG IV B SUDOE and supported by [20] Collotta, M.; Nicolosi, G.; Toscano, E.; Mirabella, O., "A ZigBee-based
network for home heating control," Industrial Electronics, 2008. IECON
national funds through FCT Fundação para a Ciência e a 2008. 34th Annual Conference of IEEE , vol., no., pp.2724,2729, 10-13
Tecnologia, under project PEst- OE/EEI/UI0066/2014. Nov. 2008
[21] Bunyai, D.; Krammer, L.; Kastner, W., "Limiting constraints for ZigBee
REFERENCES networks," IECON 2012 - 38th Annual Conference on IEEE Industrial
[1] K. Bromley, M. Perry and G. Webb, Trends in Smart Home Systems, Electronics Society , vol., no., pp.4840,4846, 25-28 Oct. 2012
Connectivity and Services, 2003, [online] Available: [22] Cavalieri, S.; Cutuli, G.; Malgeri, M., "A study on security mechanisms
www.nextwave.org.uk in KNX-based home/building automation networks," Emerging
[2] N. Sriskanthan, F. Tan and A. Karande, “Bluetooth based home Technologies and Factory Automation (ETFA), 2010 IEEE Conference
automation system”, Microprocessors and Microsystems, vol. 26, no. 6, on , vol., no., pp.1,4, 13-16 Sept. 2010
pp. 281-289, 2002 [23] Ruta, M.; Scioscia, F.; Di Sciascio, E.; Loseto, G., "Semantic-Based
[3] Gill, K.; Shuang-Hua Yang; Fang Yao; Xin Lu, "A zigbee-based home Enhancement of ISO/IEC 14543-3 EIB/KNX Standard for Building
automation system," Consumer Electronics, IEEE Transactions on , Automation," Industrial Informatics, IEEE Transactions on , vol.7, no.4,
vol.55, no.2, pp.422,430, May 2009 pp.731,739, Nov. 2011




 

  


  


  
   ()


! " 
 
! " 


##! 
##!


$
% &'
$
' 


 
 
  
 
  (  

  " 
'(
(
(   
 

 

       "  
       
  7 

                
   
 ( 
 
 (  "(  (


  


  
 ( 
3
 (
2 "
 


    
 
  ( " (     (
(  '=

        
                3 (
  >

  
    
   
   

   * (
    ( 

 
 

   
               0
1 ( (

 2 




" 
    
      

      
  !   
   2 (!
          

'  (    
     (   

      
       
   
    7     
 

    (    

  #
                          

#
  
 " 
  

     
           
 ( (

   2'*( 


#(
      &

 & 
  8)

 
(  ( (       
 #  
 *     ! #

   

 " 
 (  "  
 ( (

        
5  (  



'
"
 
(  (     (

   
*' *+!*+ 
  


 2    (     2   (  ( 

* " 
 
,-#-./   
   
 #(  3

  
 (

 


(   

 
  


(
(  '  "

(



  ( &  0(

 1  01  
  
 


 ( (
 

   "
'      (  

      
" 

( 

 (   (    
 " 
 (
 ( 2
  

   " 


' " # ( 
(


 
 7  #

        ( (   

  (  
 ( 


  
 " *   ?  
(      (
 "    
 (  (       
  "( 

   2 (

 

  

 





   "  
 <  9 (  ( 
   (  (

( (


" 


3 

 (  '

 ( (
:
( 
( 
 (  
4

2     
  




 
    ( (
   (
 '
 

  
 

   ( (
( # ( "  
     " 

(    (
(" 

  
  
 5  

  

'  6

  
 
(
 
  ,@/#( " (
 "   
   "       (    
      2  
   


 

(

2 
    ( (
 7   (  " 
          (  (  
    (    2#
 
 ' (    ( 




 
  
 6      

   
'  =(   (      (   
 

  

 (        
#    
   
 
 " 
(  
 2(
(
 
  (



" 

 
# 2  (  7 

(
( 
' "  (     (  &
  

# 
(

  " 
 (   2
 " 

    (  

 
 ( 

 
   (   '  *  ,A/   
   
 
  (
  


          
    0 "      
   
 & 
 "  
(   1
58)



(   " 
   2(   (
 
 '
       # (!

  *
(

 


(
 
  ,B/
       '( 

(  (     & 
  
 " 

(

*  

 ( ( 
2 

(  
 2 
 
'
" (      

 " 

  
  
 
    ( 
 
  

 ,C/(   
   (
  '( 
 (

  

   (
 
'



     (
 " 
   
    (  " (  
 
    (
    
     ,D/'  (  ( (
     9*      ( 
:  0*1  (   (   "  " ( " 


   (( "  

   
4
(
 (
         ( (  7  (



 "    

" 4
  2<( 
 
( (
(" 
=    '

   (
*   

" 
  
"  ( "    ! 0*!1(
 
  ,E/FG ( 

U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright
(  "  
   
 &

   "  3 

 +  2   

(*!'= 
 2 
   ((    #  (   


    "   

  * 0*1    
 
        " 
    *!'  (        

F 

(   



 " 

2     "    
  



       ( 

    (  "  '(

  " ((
    ,H/# (  ,I/   " 

   (  *'(


 

    
    (         (
 
  -@A( 
(
   
!)
 (  (  
 (
' M       " ' M  &
    "  " 


 *J
 

 

(

(
(  
 % 

J*
 @" " 8)     (  "      ( 
J
  ( 


 (   
 
     ( 
 
 

 


     


 
( 


   <
 C( ( (

 

 


   (   
(    
( 

   (  
 E '

2
  ( 
   " ""   (  
 



'  * 
   H  (       
       M  
8)  
  (  "  # 2 





   
     (     
 (  ( 
     "    
 #         

#

  
 2'  7 

#    (   
   ( 
   3 



     (   "  '  M  &
      "  
**' GK*K!K 

  ( 




 " (   (
 
         7    '  =(  
 

    

   (   

     "   "  "  #( 
 (#

  (
 (
  
          
 
 
       (       '  M
  (   " 
   
  "         
  "  
       M   
   
   
    (


     " 
<    "    
(
 (
 "  

 
   
 "  

  ( 
'6

( (


   
 

2
'M
( 
  (    
 " 
( 
#( 


 
 
   "  "  


 
 0@HH13 


   
 
  2  
 *     !   0*!1#     

   .+3 
'
*  ?  

 " 
 
 K(3 


*   (
    M   

  (   ( 


'    (  M  '( *      M  0*M1

( 8)     ( 



 

5
 " 3 #(  (  

  
"  
(
(  " 
(  
(
'(
*           
 
    (   "    
 
     ( 
3 (
(

( 
  "   '*



  (       "  
      (  

*    !  
 " 
 '
K( "  (
 "   F  ( (

( 
 ( 

F  (  
  "  (  "  '
    (             "  

  2  (
 "   F  
!*# ( (

 


 "   
 N M*
( (  "    ( 
'
 
 " 


   ( " 



     (    (   2         (  (   


(   (
  
'



2
        E?6   
%  0
3     5 " 



 
1

     " 
' 



  
 2 
'
2 



 !
" ( )+'2 



   
   "  ( #(  ( 2
 "  
(    
  
    " ( 






  2'* 
   "   2 
  ( '


  ( 
( 


  ( 

   ("   K(      " #   
    
     "  '  (             
 
 "  
 2 
" )*   


J+   
  


'+   


   "        
           
 


 
       "       "     
 


 ( 
  2' 
      " 
 (   

             (
6 (    L 6    
       
   

    

'        

 
       

   (  '(   2

    

  
3 # "  
   

(

 
 
   
 +
'  
 (   3            "  '  6


 "  
    (  "  ! 7 *0!*1 ( (
  


2  

(
(  
@.
(
 
 
 

 " 
2 
 "  
" #  #  

  
   7 

 
 " 
 5  (

'
    '(      ( 2 



U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright
OO  2  ((

"  (    ( ?   



  
 (
 ' "  

     '
P  "  


" 
"  (  (  

  
 "  (" ( 
(    " 
"   


+   
'  
 
   (
'M &
   
*           (  

   
"   (  P    ("      


 " 
 ("    2   *4
        
"  (  
 (  
 & 
 " 
  
 -    BBB    ( (    P    " 
     
( (
(
  
  
(      

 '  ( 

    
 
 " 
 (  
  '( P  "  

    (
 
(   
+'  -  ("  (  3   Q.  
   
 (     (   
 
 " 
''
 "   *      (    " 
   
  (
     " 
   (   3 
      &   !  "

     (
'  (  

 " 
 3 


 
 " 
2 
  
(   
 
'  (  

 " 
 
    " 
( " 
.0 (  %  F 1


 (
   



 "  (


    
5

     
      
     F*
    
   (    (  "   "  F '  (

*    ! 0*!1

   "   



 

  
 

   (   

     
# 

    
    
 
 &

   
2
    
    " 
 
  

 
'
***' !+**+

 
(    
(

   "
 


 
    " 
   

   (  (  (  




    "   (  
 '  (     "

2 
#" 
( (   # 
 
 
 

#



(  



  " 

(
( 
   "  ' =(    "  



# # $
 %  
(    
  "
 ((
 " 
# 

 " 
   
( 

 "     "  
       
  
    (  

  
  " 
'
  )  
  
    0@@E'IA'-@'A    -AA-1

  

  


 (
 9+ 66:2    R
!*# 

 "  " 
( 
 
 (   2 (  * " 

 ? " +
 '(
  & 5   
 (


 (
(
( 
 0 
1 
( "  3 
   &
"   
     %"

" #    (  
  2 
9  :2 
   
 " 

"  ( ( 
 (   2(      .@HH'( (

(
2 ((
'(
  


     ( (
   
  (  "  3 
 
" 
  

  
   
 (     
  9+  2S : 2 ' (       "   


#     
 
    ( (  ((   
(    S   2  ( (   
 (   " 
 
 2   (        P     
    ( ( (  

*    

  F '  (         S   2
    3
     

   
' (  

  
   
 
    
    
   
(  "    
  (    

2

   ( "   
 ( 
        "  (

  

  
 
("   

 (  " 
' (  "

    (  "   M  'M (
3     (     "   (    7     (  3 
( 
  (      
   (
    
 
 (  "   
 (3 *2'

      2 
 '  *      "  
  
&
"   "    *    ?   ( ( 

 (  ( 3 
("    ( 



    2  
 (  '  (  *    ?    
  2  ( (
(
(  "  
" 
  

   (( 
     

 'M
(


(  "  

 7  (   ( 

 7  

'( 



   ((  " 
" +   
  

 
 
 " 

)

  &   


'" 

F   " (  "  


(  
  '  *         
 


  
    2 
   " 
 ( 
      
 " 
#  (  *    ?   " 

    
2 
'
    
     *  

'  
#     

U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright
 "   (
 "   F 
2 (  ( 2 6

    2  
'
  "    ( .'  "   
 2 
%  

**
 #(  .
         (  "    .'   "      7  (  ( 
 '
   &  (


 " 
 
( ?!*
 "  ( 
%     
 "   (    (   ( 
   
(
( 
  



 
  


'


  
" (    


( 


 
 


3 ( (
 " .


 " 
  &      
   
   
   
<    &
  
 R
 F     (( 
4
   
' ( 




( 
   
 F " 2 
(?!*
   ( 

 
   
     C@     ( ( 
 (      
( ( !*5F    "  (  
    (    K(  (   
 
  (
   (   2' (

   
'

  F    
 "  



  
  
  
7        
  


  (  
   
  
      


 6  
 2 
'K(2  
( 

 (
'(

( 
# &
 # ( 
 

   2     (    


 '  2 
  "   
  (     "
  
&    F  (  2  "

( 
 " ( 
'  (    
( (  ( 


 
F   (
 F

    &(
  ( !P( 
2 ' " #2  &     

7 
#( ( "   (( 4
   ( (
  "  F      (  &   
7  '  (  
  

 2 ( " (  4
('(

  "  ( 


 F   (
   
   (     J  (     "  


      "  (       '*

   ( " 
.( 

( 



       (  (      "     F    
 " 
    (  "   2 
( 


 

((   "  '#(
 7

(     ( "    'M 


 
   " 
 7  #( 
 



       "      ( 

#  (   " 
*  



 ( 


  " '

     F ( 


  
(4
 2 
  ((  "  4
 "
2 ' (
  ( " 
    " 
*P' K!*G+*PG+*K*+
("  " 
  
   ""



  



  ( 
!  
"  2 ('(  " 
( 

    (  
  
 '  *   

  (
#  
(

   ( 
   " 
   
'   2 2  ( (

 


 
     (  ((    &
  " #  ( (  " 
#   "     (


     (  " (  
    2    ( ( 
 
'*
 
( " ("  (

     (       " 
'   " #  (  "    "   ( *   


 
   "  

     
   #    
 


'  (
( 2 ( 

( 2 (  "  " (  (  (
   2   (              (

  " '  (
    "        
 
  



 " ( *  ? 
(  

  
"  
 (( " (  ( 2
(
  "( 
 
' " #

(

2
    



( 


(


 2 ' (
   2  
   "  #  (  (        
& '    ( (   
 2 

  '
( 
 


 
(
 
  #   

2 
 
 !
' 2   "    


   "  
  


 (   
K(2  
(   "   
 
( 
'

 '( 2 *
  (  (
2 '*


.2 
(
("  

  " 
* 2 + 66  ' 



 & '(%$ 
     (  * 
    (  

    "   *'  2      (
 

( 



 
 7 "  
  " 
2 # 
F (
   
( (   "   (

 
  "   
(   2
2  &(    "   ( 

 "      2
'      
    (  
   (    
(  
  

  (     
 (
 
 
  (  2 '  + 
 T.#  - 01'( 
  (( 
J
T-#  @HI  T@'  K    
  
( (      (

 
    (  2 J  .+ )*+,-)*.)*.,,
 #  -8#  @K-@A#  CK@HI      (  
( 
( 
#F
( 

F 
   '  ( 
  " 
        ( 

 ( 


 '  (     U 
     
 

 #
 (  (
% # ' '( 2    '( 

 
3 (
( 







   (    'M-
 (   
   (  2       0 (  (  &      (

( 
 
@.
@HI 
C@    
1(  
( 2 6'* 

'  +
   "
   2       2     ' '     "  2
# ( ( ( (
2 +
 (
 
' 
       2 

 (   (  " 

#(  "  
( 
+  2S 2 ( 

U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright
  ( 

F 
(  
2 +
  

( 32 "  #(


 

  


 .' 6 
2  
  (  (  
   02 +
 # (  3 


    2 


F 1
 7   2 +
 
( 
*    ! '
  7((  " 
  "  #( 




   
 2
' ! (%$ 
 


2  "  

2     2
     
  


      

     
 IE 

  " 
 

+  2 
      (    2    
    (    

S 2  ( '(       

      " 
'  =     "        (  

 IE 

  
( 

F  

#

(
"  #    

( 
( F  
J  "   
      
    
  
   
(
" 
   '
(



%*-$)/. *./, ("         (       
 
    
'
( 

(  (  "   (( =(   

   ( 

 

 2  ( S   2 '(  &
    " ( "   (

(  " 
#
(

 
 
 (( F 
 7  "  (     "  
     (  (
    

 ( 
(
 " 
 2 


 2 


 
   

(

  (   

 ( 
7  
 
 "
'
        % '  (    (  (  F 
  7  
 ( *        M 

     ( 


  (


 " 

  " 
(("      ) " '   " . 



 ( ( "  
  
( (8'  (   

F 

  
 "  ("   

 ( 



  (
  " 
    ( 



    "   C 

     
       (
(" 
%  7 ((  -(
(#
 (   ( %  


 

'  
     
F 
2 (  2 ( 

 8 ((



# " .

( 
  



 7  F  
  &
      
  
   ( # (   " @C
 ' 
  " 

((
   
 

 2 
 
  * 
 

     "       
       "       ( %    " 
 
  
   3 

    " 
 "  

 "  

 
  " '  
#     " 
(    2#  (  (  ""
    (       ( 


(
(" 

   " 



    

'  (    ( "  
 ""   

.C'(  " 
.

#


 

   ( 
  2 
   ( 



'         " 
( (  ( (("  
   (     
    
   (  2 
  F        (  '  6
  4
 



 
   
  "  '=(  

 " 
"   " 
# #  &    " 

  
*  (

  ( 
 .



' =(  "  -




 ( 
 (("  'M &
  2   "  @# ( -


 7
 

  

( 

 
  #(  
(    
 @( 


 5 7
 


 
( 
(  
 
 
' " # (   J


( 

 

  ( 5 ( &-
) 0(%+()+#,,


(" 
 
 

  
'*(2 


5      2  ( (  
   (   (  (

  (  )0-#@1
  


)

  (      "  "    "  
       
    4

'*VT  ) " ( 
    

( 
  
  (  7

 ( 
 2 

2
(( 
'  (   #          
  (   7
   (    

        '  (  )


  " (    

*  
 

  "   "  

#(   

( ( 

 '  "  
(    
    (     

    ( 

 " 
         

 (   


  (
  
 7 
   
#

 &   '
2 #
(  "   "  2   ( ( 


 ( 2 '*
(
 (       (  
 
   )4
      (



   (  ((  
    "  #(   
 (   
 
 #
 7 


  (" 

(   "   F    (     "   (   
   

   
    (
  ( '*(  

3
( 


(   
  


 (  " 


7  
2 ((  
 
(  
 M  '( W V 


"  (  " 
( (   " ( 2 

  7      (   "  #       (
  ( 

(2 (  "  ' " #
   
(   (  "    &
(
2 
 


    
 7 
(( 
      (   
  (  (
 


  7  '  (
+  2 S   2 #      (  

   (   
   

  "    
   3  # 
 
6
  ( 
        
   
(     2 ( 

 '*
 7 
(  (
'*    

 ( 
   #
( +  2S  " 
   "
 )   &
(  (  


( 
*    ! (  ( ( ( 

  

 (   ) " 
    2   

(   3    (  (  ( 
  .'

(

 
 (  M 
2   (

 '(
# 3
( 

  " 
  

#(  

U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright
(  
    
J(
'*
 7  ( ( "    (   8)     
      
  



 (

    
(( 


   %   K&   "   M  '  (
   
 
    (


(  


(
9 
  

% (  " 
 &
 ( 
2   
( 
   
 ( (
:'*
( ( 
   
       "  ( 
   

'  6




 

2 (   
(  
2   "  )    & 
   (   
 (  & 
( 
   ( '
#   
(
"    
        "    
 
   (
 
     (       (      "  "   0"     
 (       1      
 ( 
(   
  
   (   8)      (    
((  "  ( 
 '
 % K& "  '(  
  
 (  
(
  (  &  
 


     
 (  F*     
   & 
 (  "    " 
   

(    "    "
'  (
 &    "
     

2 
  
 

 (  
( 

 

 8) 
 ( "  ((
    "  ' 

*    
 
! 
 "   

  " )4
*    ?     
        
     (  & 
((
 ( &  ( "

  "   
'

"   (  
(

      '
( 
   
 
   "      (   
 "    8)   
 ( (   
   


      (   "
   
  (  (
   F   ('  =    & 
    
    (    "       
 
    ( (  9??   
: 

       

 



  "5    (         
2 '


 8) 
  

       (  =C  8) 
( K& "  M 
 
 
 ( 
  &   "  'K" 

  

   "    
   (   " 
  
 &  
  
F*   

(
'(
   2(" (   
2  (    
   
" 
   &   "    
(
 
( " 

  "
 
' 7  (
 "   '

! 2%% 324

P' **+)KP*K
(  
 *     !   0*!1 
  
     " 

 (
  
   
#
 (" 
  
(  ((  ( ( (
( 


    

  " 
 (  
"  ( 
'*!


 ( 
  2 ((      
( 
 &    
( 
    '(
( 
 
 7  
 


  
" 

 ( "      
    

  
    *!  

    '( (
 7 



      

     " 
  " 
#    ( 
     
      
" 
  

      
 

 
( (   

 ( 
(

  " 
'   (   
   
  
  '       (  
 
  ( *!
 "  #( 
 
 1(%  (             
 ( (
(  "      

  
#    "  
  ( *!'6




    
          "
#   2
     
#*!("  
 

 (
 
 & (  "  0

" 1  


 (  "  0 
 1'
  


   
    
 "  +
#

(
   2!)
(
 "  

 <  
    
   (   "   


  ?!*
 '     
    
    ( 52%% " 
 
%

(   
 
(  "  #( "  
 






(  & " 

"
 "
(
'M &
   
(
 "  '


    (      

              *( 

  &
 
(   " #*!

 

   
 
 
 @E(
   (   
        
     (  
( 

"    '(
 "   

   (  
(  '6
(   # ( E




M   (                B.... 

     
(    

  
  *!  

( 
( 

   -.


      &     (  (   
        &J  9=
( 
 "     
               
    C
(   
  :(" (  &  (

 "  
'*      M 
    
     (      &  
 (      
    (
(   "           
 
   (  


  
( 
(  '  *! 
 

 2 
 
     

 
         

  
    ?!*  
   " 
   (  (
#  (  
 
 
       "  
   3   
    (   "  (
2              (  
(      


 '*  (
#( *  M  
  
   (   ( ( "  
( ( 

P'
(  (      


      "    
    
"  
  (
'( *          6 
     " 
       " 
   
 
 


*  
  (

   
 
#*! 
( 
 




 
    

   (  (   "   0&1      

 "
  
"  



  ( 
    
"       0
1'
    (  (
    "              &
 

!* 

 (  '


  ( 


 ( (    ( 
 (
   


  ( 

2   (  



U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright


 
  
 "  
' 
 *! ( M
  (
 ( ) &0 


 ( (
  " ( 
 #7 (  ( 
" 
 1'
(  
 (  
    (
   (  # '
6)K*' M*)K+MKKM+K
*!

(  
    
 
 "  (2 #
  ! %&
 (    ( 

( 
 
 (  !" # $
  



( 
 "  ( 32 
   

 "  ( 32  "  
(
' --EI- .'B- +5

(  *    ?  
 (        

 

 ( CDAHIH@ -'EA -'BB

   ( 
 


'( (

  DDHBEI@E -'EA @'-.
  2    

 "  
       (
 (

 
 


 (     ' " #
(  (
    
(        (  (

"  ( 




(
(
% 9


 (  
    & 


 
  "    :

 
   (  
 


(        2          
  (  ( 
 #  ( (  
%   M 
     ) &
      "   


   (
 (    
  
  ( (( M 
  
   (
  (
    ' (
   
"  (   
( 



 (
 
  

  ( 
"  
( 

 7 

 (  *    ?            

  
 '* 

 ( (M 






  " 
 
 ( (

   #"  9*(   :
  2'  (  

   
 2     "    0 1  2  (    
  2 
  
   (

   2  (       -"   ( 

2 
(2

  
 



3    


 #  
 (    

   (      
 ( %   ( 
  "  (  '
 "  (




'
(   ( %   (   

 *

     
    #  *!    *  
 " 
 

  (   2   ?  
   2
(



'
  

F  


 ( ( 
(  0( 
  "   "  1'(   (
 
   ( 

   

(       

    (  (  


  



(   '( 
 (
 
?   ( (  ((   

 
   "     
(       
    
   
&(
 "  
    

'  
F (    ((   (
 2  (  #      
#   
   

 
 

     (   "  '    (    
     ( 
 
 (
  J
 "  
    ( 
   "     
 (  2  
 "  
( (J55 '
% &'
5
'(

  2'
KMKK+K
P*' +)!*++M!!K=F ,-/   
       (  )#  9  
    


= 


  

   ( 

      (      P
  6
  

     +"  :#  @.-C
 " 
 2  
  ( 

   
      *     
 
#

  



#
F '
!  0@  F6      C@  F6  
 M
(1   =H-..
,@/ (
    3#     
#  9
   
 J   
 
9K(  ( :#-.@*@
  

)K

   (
 
 :#  K
" #  
 
 X      C-

 ( 

'(


 " ( 0@.-@1BE.BHH'
( 
   

  (    

 

 ,C/ (  
#''
#( G ) #9*    
 " 

 
(   2  (  
 2 
M
2




:#..BAC.IC5--@.--*KKK'
(     (  -  '  (   " 


  ,E/ G= F#( G#9!
  

 (

    ( 
   


 
( ?!* 
 :#
 
X* 
CE0@.-@1-D--AA'
(   " 
 


  " '( ,H/  ( % '#9
2 "  (

 
    


   
 (  (  
    
 



J  M
  7 

    :#  (  S    


 
F " 
( 
 ( ( 
 
#      AE0@.--1-..A-.@-'
( 
 
C)K4
'( 


 
( ?!* ,I/   K3  "
    '#  9      ( 2    
 
 
   
 (  
 ( (
  (
:#S? K   C.CC@D@.--'
( )K4
  (  
'( 

   ,D/ P         '#  9            
 

(
     (     ( 

 
 "     ( *    :#..BAC.IC5.I@..I*KKK'

  
 ' ,A/ S   '#9( 
*

 ) 



 

  :#..BAC.IC5.I@..I*KKK
( 


( 
  
 



,B/   L   2    '#  9*  6
  
 
   


:#  ..BA
 
  
 
"    ( (  C.CI5-.@.-A*KKK'

    
  
     
 



  ,-./   
       (  )#  9    
 3 

 (  
 ( " 
 
 2 +"  


 K& 
 P
:#
@.-E'

U.S. Government work not protected

978-1-4799-8757-3/15/$31.00 ©2015byIEEE
U.S. copyright
 By Natalia M. López, Sergio Ponce, David Piccinini,
From Hospital
to Home Care
Creating a domotic environment for elderly and disabled people.
For people without disabilities, technology makes things easier.
For people with disabilities, technology makes things possible.
A
dvances in medicine have led to a significant increase
in human life expectancy and, therefore, to a growing
number of disabled elderly people who need chronic
care and assistance [1]. The World Health Organiza-
tion reports that the world’s population over 60 years
old will double between 2000 and 2050 and qua-
druple for seniors older than 80 years, reaching 400 million
[2]. In addition, strokes, traffic-related and other accidents, and
seemingly endless wars and acts of terrorism contribute to an
increasing number of disabled younger people.
These and other causes have increased the population of dis-
abled patients, who mostly end up in clinics and hospitals—places
that are already overcrowded. Consequently, alternatives for care
and rehabilitation need exploration. Rehab interventions involving
virtual reality technology [3], Microsoft Kinect-based exercise and
“serious” games [4], and other similar proposals have been devel-
oped around the world with encouraging results, especially in the
case of stroke survivors, for whom age is a significant risk factor.
Domestic care is a novel and promising area, supported by
the use of biomedical sensors and physiological monitoring
through ECG portable devices, inertial sensors, video record-
ing, alarms for fall detection, and so on [5]. Patients can be
monitored using wearable sensors that provide early warn-
ing of health deterioration. The demand for technologically
advanced methods of home-based care may easily expand,
so that expectations for wide-scale adoption are not merely
well intentioned dreams. Moreover, almost daily, new smart
home products appear that can be adapted to special needs,
Digital Object Identifier 10.1109/MPUL.2016.2539105
Date of publication: 13 May 2016
38 ieee pulse ▼ may/june 2016 2154-2287/16©2016 IEEE
Elisa Perez, and Martín Roberti
even when the companies don’t specifi-
cally market them to disabled patients.
Assistive technologies have emerged as
a useful aid to people with disabilities. They
aim at improving residual functions or ca-
pabilities, allowing the command of several
devices. The main goal of these technologies
is to support the independence of people
with chronic or degenerative limitations in
motor or cognitive skills and to aid in care
of the elderly. The most cited needs for this
population are those related to the activi-
ties of ­daily ­living and communication.
In this article, we present an assistive
home care system specially designed for
people with severe brain or spinal inju-
ries and for poststroke survivors who are
immobilized or face mobility difficulties.
The main objective is to create the easy,
low-cost automation of a room or house
to provide a friendly environment that
enhances the psychological condition
of immobilized users (Figure 1).
System Overview
At the system’s core is a personal computer (PC) and ichno-
graphic software (referred to as SICAA, for the Spanish Sistema
Integrado de Control y Automatización Asistida) that allow the pa-
tient to interact with the environment and peripheral devices,
such as a webcam, intercom, lights, and electrical blinds. Sev-
eral human–computer interfaces (HCIs) were developed and
adapted for this system, according to the residual capability of
different users. The SICAA software has three main elements:
environment control (operating blinds, lights, an orthope-
dic bed, an air conditioner, a television, and an ­intercom),

c­ommunication (nurse call and voice syn-
thesizer), and computer access (to the Internet, for chat and
games, and to text processors). Preliminary tests were well re-
ceived by the patients and their families, as well as by healthy
volunteers who tried this system. The entire system is a low-
cost solution for people with disabilities, and the project is in-
tended for implementation in the patient’s house.
Human–Computer Interface
Regarding the HCI, the major requirements are noninvasive-
ness, low cost, robustness, and adaptability for users with s­imilar
disabilities. For many years, we have de-
veloped HCIs that were essayed as control
input with acceptable results, such as a con-
ventional mouse, an adapted keypad, a Nin-
tendo Wii console, a vision-based interface
(VBI) using hand detection, and an electro-
oculogram (EOG)-based interface.
The conventional mouse-keypad is the
simplest and most e­ ssential piece of the whole
system; however, some patients cannot oper-
ate it due to spasticity, abnormal movements,
or tremor, among other causes. Hence, a VBI
was adapted to the overall arrangement using
the image of the user’s hand captured by a web-
cam. The image-processing algorithm detects
the presence and orientation of the hand and
uses this information to obtain the reference
angles for generating the input commands to the
mouse tracker. The first step in the processing al-
gorithm is the lighting compensation. The second
step involves the transformation and detection of
the skin by segmentation in the color space YCb-
Cr, because this color space is more flexible and
stable for the system due to their specificity against
the skin detection. Segmentation was performed
by thresholding, and the image obtained is binary,
with white representing the detected skin.
After that, it is necessary to determine the
characteristics that represent the position and
orientation of the hand. The characteristics cho-
sen are the coordinates of the center of mass and
the axes (minor L1 and major L2) of the hand,
using the moments of the image. These axes are
good descriptors of the hand orientation, and
they allow the click action of the cursor to be per-
formed by closing the hand, as computed with the
axes relation. The movement of the cursor is gen-
erated by the coordinates of the center mass and
ing
filtered to obtain a smooth, precise movement. A
ingram publish
work plane fits the area focused on the webcam,
which is located at a fixed distance. The HCI was
tested with several volunteers and under various
d by
image license
experimental conditions, essaying the robustness
against different skin tones and colors, all with good
results. The behavior was identical for all users be-
cause segmentation isolates only the skin. Some vari-
ations appear when there are changes in the ambient
light conditions. To avoid this problem, we decided to
incorporate a light source. More details about this interface
can be found in [6].
Other alternative command devices are achieved through
inertial sensors like those on a Nintendo Wii or other com-
mercial console, such as the HP Swing. This is a plug-and-
play solution, robust and ergonomic. Both HCIs were tested
with healthy volunteers and one patient with tremors who
cannot use a conventional mouse. Both commercial con-
soles are adequate, due to their easy connection, ergonomic
may/june 2016 ▼ ieee pulse 39
FIGURE 1 An overview of the SICAA system. The user can access the SICAA through different HCIs (from top to bottom: electro-­oculogram/
electromyogram, a Nintendo Wii console, and a vision-based interface) and control some home devices and communication tools.
shape, big buttons, and low price. The inertial sensor-based
console is easy to use and does not require training, but its
use is only possible for patients who maintain the ability to
move their hand.
Interface Adapted for the Severely Disabled
For severely disabled people (for example, those with quad-
riplegia), we have developed a hybrid HCI based on the EOG
and the electromyogram (EMG), as it allows mouse control us-
ing eye movement and the voluntary contraction of any facial
muscle [7]. The bioelectrical signals are sensed with adhesive
electrodes and are acquired by a custom-designed portable
wireless system. The mouse can be moved in any direction—
vertically, horizontally, and diagonally—by two EOG chan-
nels, and the EMG signal is used to perform the mouse-click
action. Blinks are avoided by a decision algorithm, and the
natural reading of the screen is p­ ossible with the designed
software without interrupting the mouse ­tracker.
The device was tested with satisfactory results in terms of ac-
ceptance, performance, size, portability, and data transmission.
Users can select a threshold between five levels of sensitivity to
suit their requirements and also load, modify, and save their
profiles. This choice allows users to make smooth eye move-
ments, such as those involved in reading or looking beyond the
screen, that will not be considered a control signal. A training
40 ieee pulse ▼ may/june 2016
stage is necessary for a complete HMI domain, especially for
patients with severe diseases.
The choice of the HCI will depend on the user capabilities and
other interfaces can also be used with the system.
System Specifics
The SICAA constitutes the main imple-mentation of the
­system, allowing integration of the commands of the HCI with
control of the peripheral devices. The software design must
meet several constraints related to user accessibility and ease
of operation [8].
An iconographic interface, big buttons, and vibrant ­colors
were chosen for the software, developed with Microsoft ­Visual
Studio 2008 and Basic .NET Express. The software has a princi-
pal panel (Figure 2) that includes the date, the hour, a control
menu showing the output states, and icons representing the
television control, home control, Internet access, voice synthe-
sizer, nurse call, bed control, and diary. The menu’s icons are
easy to interpret and relatively large on the screen, enabling po-
sitioning by patients with some degree of spasticity or tremors.
In addition, a button for turning off lights provides a ­d irect
access and a configuration entry to the program’s mainte-
nance and recalibration, if necessary. Each icon allows access
to another window, with a specific menu related to the task
group selected.

• Internet
Home Control
Communication
• Text Processor
• Voice
Synthetizer
• Diary Planner
• Nurse Call
FIGURE 2 The principal panel of the SICAA system and its functionalities.
A QWERTY keyboard was designed, which appears in the
front panel when necessary for writing in the selected ap-
plication (such as the Internet browser, text processor, chat,
diary, or voice synthesizer). The keyboard is predictive and
has two modes, basic and advanced. These two modes were
implemented for users with different capabilities and train-
ing. The voice synthesizer panel shows preselected phrases,
and it allows the addition of other expressions, defined by
individual users. Configuration parameters are accessible by
the programmer or authorized personnel to prevent mistakes
and system failures. This menu allows the control of cursor
sensitivity and language (Spanish, Portuguese, and English),
among other functions.
The peripheral devices are controlled through a customized
and isolated control board, with eight digital outputs by relays,
three analogical and six digital inputs, and an ATMega 8-16PU
microcontroller of 1 MHz. To avoid incompatibilities with previ-
ously installed home appliances and devices, a generic infrared
transducer was used to control the air conditioning and televi-
sion. The intercom must be adapted to a webcam, thereby pro-
viding visual information to the patient. The door opens with
an electrical lock. The nurse call is a luminous sounding alarm,
interrupted only by a physical button pressed by the caregiver,
assuring the presence of the caregiver. Other devices such as the
bed, home appliances, and lights only need a minimal electri-
cal connection to be controlled by the SICAA. The peripheral
devices used are objects whose operation is not affected by the
type of control input and that require no structural modifica-
tions. The panel control shows the output state, offering a direct
visual view of the entire system.
The costs, calculated for a 32-in television, a PC, and all the
electronics components, comes to a total of US$5,000. This is
a low-cost solution if we consider the psychological and physi-
cal benefits of the independence and ability to communicate
the system allows for its potential users. There are commercial
domotic systems available on the market and a lot of “smart
homes” projects in research groups, but our objective was a de-
sign specifically for disabled people that provides a wide variety
of plug-and-play HCIs, while also considering the economic con-
dition of the potential users.
The use of this assistive technol-
ogy helps in patients’ recovery, im-
proving their relationship with those
• Lights in attendance, as well as their com-
• Television fort, self-esteem, and overall psycho-
• Blinds logical condition.
• Bed
• Intercom
• Air Conditionning Acknowledgments
• Door Opening The authors thank the Universidad
Tecnológica Nacional, the Universidad
Nacional de San Juan, and the Na-
tional Council of Scientific Research of
Argentina (CONICET) for supporting
this research.
Natalia M. López (nlopez@gateme.unsj.
edu.ar) is with the Gabinete de Tecnología
Médica, Facultad de Ingeniería, Universidad Nacional de San Juan,
Argentina. Sergio Ponce (sponce@rec.utn.edu.ar) and David
­Piccinini (davidp13@gmail.com) are with the Grupo de Análisis,
Desarrollos e Investigaciones Biomédicas, Facultad R
­ egional San Nico-
lás, Universidad Tecnológica Nacional, Argentina. Elisa Perez (eperez
@gateme.unsj.edu.ar) is with the Gabinete de Tecnología Médica,
Facultad de Ingeniería, Universidad Nacional de San Juan, Argentina.
Martín Roberti (martinroberti@gmail.com) is with the Grupo de
Análisis, Desarrollos e Investigaciones Biomédicas, Facultad Regional
San Nicolás, Universidad Tecnológica Nacional, Argentina.
References
[1] D. Webster and O. Celik, “Systematic review of Kinect applica-
tions in elderly care and stroke rehabilitation,” J. Neuroeng. Reha-
bil., vol. 11, p. 108, July 2014.
[2] Organización Mundial de la Salud. (2014). Desafios sanitarios
planteados por el envejecimiento de la población. [Online]. Avail-
able: http://www.who.int/ageing/publications/es
[3] A. Darekar, B. J. McFadyen, A. Lamontagne, and J. Fung, “Effi-
cacy of virtual reality-based intervention on balance and mobility
disorders post-stroke: A scoping review,” J. Neuroeng. Rehabil., vol.
12, p. 46, May 2015.
[4] C. Loconsole, F. Banno, A. Frisoli, and M. Bergamasco, “A new
Kinect-based guidance mode for upper limb robot-aided neurore-
habilitation,” in Proc. 2012 IEEE/RSJ Int. Conf. Intelligent Robots and
Systems (IROS), Vilamoura, Portugal, pp. 1037–1042.
[5] L. Mertz, “Convergence revolution comes to wearables: Multiple
advances are taking biosensor networks to the next level in health
care,” IEEE Pulse, vol. 7, no. 1, pp. 13–17, Jan. 2016.
[6] E. Perez, C. Soria, N. M. López, O. Nasisi, and V. Mut, “Vision-
based interfaces applied to assistive robots,” Int. J. Adv. Robot. Syst.,
vol. 10, pp. 116, 2013.
[7] N. M. Lopez, E. Orosco, E. Perez, S. Bajinay, R. Zanetti, and M. E.
Valentinuzzi, “Hybrid human-machine interface to mouse control
for severely disabled people,” Int. J. Eng. Innovative Technol., vol. 4,
no. 11, pp. 164–171, May 2015.
[8] D. Piccinini, N. M. López, E. Pérez, S. Ponce, and M. Valentinuzzi,
“Assistive home care system for people with severe disabilities,”
presented in Proc. 4th IEEE Biosignals and Biorobotics Conf. (ISSNIP),
Feb. 2013. 
may/june 2016 ▼ ieee pulse 41