Remote and Mobile Control in Domotics

F. Sandu
*1
, M. Romanca
*1
, A. Nedelcu
1
, P. Borza
*1
, R. Dimova
*2

1
Transilvania University / Department of Electronics and Computers, Brasov, Romania
2
Technical University of Varna / Department of Communication Engineering, Varna, Bulgaria
sandu@unitbv.ro, romanca@unitbv.ro, nedelcu3@vega.unitbv.ro, borzapn@unitbv.ro, rdim@abv.bg
*
IEEE Members



Abstract - The paper presents a system for remote control of
distributed and networked drives and data acquisition
devices. The system goal is to be integrated in monitoring
systems for Intelligent Buildings. The authors developed
and tested a wireless acquisition & distribution architecture
(IEEE 802.11 "WiFi" compliant) based on embedded web-
servers (with Ethernet-serial-Ethernet tunneling) at the
drives' side and PDA/Communicators (Pocket PC
Smartphones running MS Windows Mobile CE6) at the
remote and mobile control side.
Keywords - Intelligent Buildings, Remote control systems,
Mobile control
I. INTRODUCTION
Nowadays in domotic systems, there is a main trend
of spreading the TCP/IP communication protocols and
wireless technology. They simplify the process of
remotely monitoring devices, sensors, actuators and
controllers already integrated in local systems e.g.
controlling indoor climate, provide comfort and
entertainment, energy conservation, security systems etc.
This trend leads to many advantages in implementation,
upgrading, or sustenance of Intelligent Building systems.
Many authors analyze this important trend pursuant to the
fact that the Internet has become not only an important
information source but also a center of the development
of new markets and service sources.
Paper [1] describes a domotic system (VESTA)
oriented to low to medium rate domotic wireless
applications, multi-interface communication gateway,
using embedded micro Web-servers and a distributed
intelligence between its two types of components:
Antares - the processing platform, and Mercurios - the
remote modules. In [2] a prototype domotic system is
described; this system integrates web servers to home and
office existing intelligent devices, in order to control
them over the Internet and also to create effective user
interfaces in the form of web pages. There are also onsets
that take into account combination of hybrid wired and
wireless technologies for the networked home of
tomorrow to deliver the seemingly endless amount of
content craved by end users today [3]. Furthermore paper
[4] presents a domotic house gateway capable of
seamlessly interacting with different devices from
heterogeneous domotic systems and appliances. The
authors note that smart portable devices or information
appliances (like PDAs, set top boxes, etc.) are not usually
produced by domotic system vendors, and are only
recently facing the intercommunication and
standardization issues related to domotic systems.
The use of mobile computing equipments (PDA,
and/or smart phones) in Building Automation has
rarely been adopted. There are research approaches that
use PDAs in medical mobile monitoring systems [5,6].
Remote and mobile control of an intelligent building
was considered in the generic architecture of fig.1.
Remote and mobile control can be done from PDA
Smartphones. The authors used a HTC P3600 - PDA / 3G
HSDPA WiFi GPS with Microsoft Windows
Mobile 5.0. The mobile Smartphone can be a Client
terminal for Internet or Intranet access to the centralized
control of sub-systems like "HVAC" (heating, ventilation
and air conditioning), lighting, irrigation, elevators,
security (alarms and intrusion detection) etc.
There are multiple data acquisition (DAQ) and drive
sub-systems with local intelligence (we implemented
microcontroller-based embedded systems) and/or local
"network enablement" (we implemented embedded web-
servers for "device networking").
A fixed computer could play the role of central
communication server as well as of instrumentation
server (running specialized instrumentation software
like National Instruments LabVIEW that was used in our
implementation). The server can publish measured data
by means of shared variables which can be accessed by
clients (also called shared variables subscribers).
Network enablement solutions should connect to
Internet or to an Intranet, almost any peripheral electronic
device, enabling it to be remotely accessed, monitored
and controlled. This integration extends the life of
existing equipment and can "introduce distance" in many
existing control architectures. Server capability can be
brought to machines - by device server technology and
working out distance, by device networking technology
with "machine to machine" communication in distributed
client-server architectures [1-4]. There are many
companies which provide embedded web-servers:
Lantronix, Tibbo, Digi, Moxa, Patton, Perle etc.
Embedded web-servers are miniature specialized
computers that contain a CPU (central processing unit), a
RTOS (real-time operating system), a TCP/IP stack and
an Ethernet connection to provide a bridge to different
devices with serial interfaces (RS-232, RS-422, or RS-
485), CAN (Controller Area Network) interfaces, GPIB
(General Purpose Interface Bus) interfaces etc; embedded
web servers which offer a WiFi wireless interface have
also been developed. They are available as chips, boards,
and boxes and they bring a great deal of intelligence to
devices that need to be monitored and controlled
remotely.

Figure 1. Generic architecture of the remote and mobile control of an intelligent building

II. DEVICE NETWORKING
The authors used the Lantronix "XPort"
embedded web-server. XPort is an integrated and
compact solution (see the natural view in fig.2) to web-
enable any device with serial capability [5]. It removes
the difficulty to introduce network connectivity into a
product by incorporating all of the required hardware and
software inside a single embedded solution.
The XPort is built around the DSTni LX "System on
Chip" (SOC) that integrates a x86 compatible 48Mhz 16
bit processor, 256K bytes SRAM on-chip (with
addressability of 16M bytes external memory), a
10/100M Ethernet controller, two 230K baud High
performance RS232/422/485 Serial Channels, two 1M
baud CAN channels, a SPI controller, 8K dual port
memory, 4 DMA channels, 3 timers, an interrupt
controller and a watchdog timer.
III. THE SERIAL TUNNELING CONCEPT
By encapsulating serial data in network packets and
transporting them over an Ethernet network, device

Figure 2. Lantronix XPort Webserver
servers enable virtual serial links to be established over
extended distances. The process of transporting serial
data over Ethernet is often referred to as "Serial
Tunneling". By design, serial tunneling is transparent to
both applications' software and the connected devices,
often requiring no software or device configuration
changes (see fig.3).
The same tunneling can be done for CAN or GPIB
interfacing etc. as Ethernet supports multiple protocols
over a common medium.
This gives the equipment designer the freedom to
choose the protocols to be used and the opportunity to use
the same infrastructure for new protocols as they become
available. Where local-area networks (LANs) or wide-
area networks (WANs) are established, device servers
enable equipment to use this infrastructure to form
connections with remote serial devices.


Figure 3. The Serial Tunneling Concept
If sensitive information needs to be passed between the
serial devices across the network, then data encryption is
required.
Protocols such as SSH (Secure Shell or Secure Socket
Shell ) using encryption techniques such as AES, 3DES,
Blowfish, ARCFOUR and CAST prevent this data from
being captured (sniffed) and viewed during their transit
across the network. Modern terminal servers now have
the capability to encrypt the data from the serial device
before sending across the network. The information is
then decrypted at the destination terminal server before
being passed to the target serial device.
For Intelligent Buildings, remote switching can be used
almost everywhere, activate/inactivate alarm systems, to
open or to close gates, garage and apartment doors,
granting access form a surveillance desk, to start/stop
HVAC, lighting, irrigation etc [6].
Fig. 4 and 5 show a web-server hardware completed
by the authors and a relay assembly (with Meder DIP05-
1C90-51L Reed-Relays, driven by transistors having their
base connected to XPort pins.
Java programming for remote switching by XPort was
done using JBuilder.
The communication between the software and XPort is
using socket technology.
IV. THE INTELLIGENT BUILDING SERVER
The intelligent building server could be a PC. They are
even miniature solutions like, for instance, ALIX1C from
PC Engines ( http://www.pcengines.ch/alix1c.htm ) with
a CPU of 433 or 500 MHz (AMD Geode LX), DRAM:
128 or 256 MB SDRAM on board, Storage on
CompactFlash socket, 44 pin IDE, Power: 12V DC, DC-
DC converter on board (no bulky ATX PSU needed!),


Figure 4. Web-server hardware completed by the authors


Figure 5. The Reed Relays assembly
Expansion: miniPCI + PCI + LPC + optional I2C,
Connectivity: 1 Ethernet channel (Via VT6105M 10/100)
I/O: 2 COM, 4 USB, 1 LPT, audio, VGA, Board size: 6.7
x 6.7" (miniITX), low profile, Firmware: Award BIOS.
V. THE INSTRUMENTATION SOFTWARE
For the instrumentation software we have chosen
LabVIEW from National Instruments (NI), one of the
most well-known specialized software packages world-
wide. For our purpose, it has the advantage of a special
version running on Pocket PC, then available for the
Smartphones like those used by the authors for remote
and mobile domotic control.
VI. NETWORK-ENABLED DAQ CHANNEL FOR
TEMPERATURE MONITORING
For this example of implementation, the authors used a
configuration consisting of two main building blocks (see
Fig.6).
1) An acquisition and processing board, based on an
AT Mega 32 microcontroller and on a LM35-DZ
temperature sensor.
The AT Mega 32 is a low-power CMOS 8-bit
microcontroller based on the AVR enhanced RISC
architecture, which offers facilities such as:
32K Bytes of In-System Self-Programmable Flash
Two 8-bit Timer/Counters with Separate
Prescalers and Compare Modes
8-channel, 10-bit ADC
The LM35 series are precision integrated-circuit
temperature sensors, whose output voltage is
linearly proportional to the Celsius (Centigrade)
temperature( + 10.0 mV/C scale factor)
The DAQ from the LM35 temperature sensor is
performed by the ADC integrated in the AT Mega 32
microcontroller. The AT Mega 32 analyzes the data,
converts it into a format suitable for publishing (ASCII
format) and then sends it to the XPort through the serial
interface.
The source code for the firmware running on the AT
Mega 32 has been written in assembler language using
AVR Studio 4, an IDE offered by Atmel. The
applications begins with a module initiation phase:
initialize_USART , for the initiation of the USART
serial interface, initialize_ADC , for the initiation of the
ADC converter.

Figure 6. The acquisition & processing board (above) and the
Lantronix XPort (in its SDK)
The program then enters the main waiting loop, which
is interrupted by each successful ADC conversion. As
mentioned before, at the end of every ADC conversion an
interrupt service routine, ADC_ISR is called. The data
from the ADCL and ADCH is analyzed and converted
into ASCII format, through the convert_ASCII
procedure and then sent through the serial interface
(send_character procedure). The delay between two
successive ADC conversions (temperature measurement)
is of 3 minutes and is obtained by calling the delay
procedure.

2) The Lantronix XPort, which is used to transmit data
remotely. The XPort performs the serial-to-Ethernet
conversion, thus allowing the temperature data to be sent
over the Internet to a remote user. The temperature data is
published by a Java Applet running on the XPort and can
be accessed from a PDA device running a Java-
compatible web browser.
VII. NI DATA-LOGGING AND SUPERVISORY CONTROL
The Datalogging and Supervisory Control module of
National Instruments LabVIEW [7] is dedicated to
remote monitoring and control, by networking of devices
for the transfer of acquisition (output) / or (input) control
data to / from distributed databases.
The LabVIEW Shared Variables enable efficient
programming of distributed applications. Data can be
shared between VIs running in different nodes of a an
Ethernet network in an optimized way compared with
other data sharing methods usable in LabVIEW (e.g.
UDP/TCP, queues and Real-Time FIFOs) [8].
Shared variables are configured at project's edit time
(using property dialogs) and do not necessarily require
configuration codes included in the applications. In order
to optimize the applications the shared variables can be
deployed programmatically using specialized functions.
There are three types of shared variables: single-process,
time-triggered and network-published (the latter are used
in our application).
The creation of shared variables in our project tree,
was done by right-click on the main computing node of
our configuration (hosting the server) hereby called My
Computer (see fig.7); by selecting New > Variable, it is
displayed the shared variable properties dialog where the
new variable can be configured. The shared variables
parameters that can be configured using this dialog box
are as follows: type of shared variable, type of data,
buffer size, initial value, scaling and security
(permissions).
The target to which the shared variable belongs is the
node from which LabVIEW deploys and hosts the shared
variable (in our case, the above-mentioned My
Computer.
After shared variables are added to the LabVIEW
project, they can be simply dragged into the block
diagram of the VI (that reads or writes these shared
variables or part of them), thus creating the "Shared
Variable" read or write nodes (see the following Server
VI and Client VI diagrams).
The NI Publish and Subscribe Protocol (NI-PSP) is a
simplified networking protocol optimized to be the
transport for network-published shared variables.

Figure 7. Remote and mobile control project tree
The underlying layer of NI-PSP has been written to be
more efficient by optimized architecture of TCP/IP use.
This requires LabVIEW to run on all the nodes involved
in the communication. The Shared Variable Network
Stack is presented in fig.8. LogosXT is the layer that is
optimizing the throughput for the shared variable by an 8
KB transmit buffer (unique for all the connections
between two distinct endpoints) and a 10 ms timer thread
(so every network operation has a fixed overhead both in
packet size and in latency time, for target stream of data).
Deployment of network-published shared variables is
done towards a shared variable engine (SVE) that hosts
the shared variable values on the network (see fig.9).
When writing to a shared variable node, LabVIEW
sends the new value to the SVE that deployed and hosts
the variable (in our case the "My Computer" server with
the WLAN Intranet address 192.168.1.3). The SVE
processing loop publishes the value so that any
subscriber (e.g. our Client Smartphone Pocket PC) gets
the updated value.

LabVIEW
Shared Variable Engine
NI-PSP
LogosXT
TCP/IP
Ethernet
Figure 8. The NI Shared Variable Network Stack


Figure 9. Deployment of network-published shared variables
VIII. THE SERVER VI
The Server VI takes over data from the serial interface
- see the VISA ("VXI (plug&play) Systems Alliance")
read (R) control in the diagram of fig.10 ; as shown
above, these data are acquired and processed by the board
with AT Mega 32. The VI converts these data in decimal
format and will publish the Measured temperature values
in the shared Variable1. As for the Input temperature
(that is sent from the client terminal to the HVAC
automated control system) their values are read from the
shared Variable3, converted from decimal and sent (via
the VISA write (W) control) to the serial interface.
IX. THE CLIENT VI
The VI (with the diagram of fig.11.a and the panel of
fig.11.b) reads the shared Variable1 (representing the
Measured temperature) and displays it on the front panel.
It writes into the shared Variable3 the value of the desired
Input temperature (taken over by the remote HVAC
automated control system).



Figure 10. The Server VI LabVIEW diagram




Figure 11. (a) the Client VI LabVIEW diagram; (b) Client VI
LabVIEW panel, running on HTC P3600 PDA
X. TECHNICAL ASPECTS OF THE REMOTE AND
MOBILE CONTROL IMPLEMENTATION
The pilot configuration (see fig.12) was built around a
PC server (running the Server VI and thus hosting the
shared variables through the Shared Variables Engine),
connected in the Intranet of a "Linksys Wireless-G"
router.
In order to check its status and configuration, the HTC
P3600 - PDA run a " vxUtil " tool [9] from Cambridge
Computer Corp. (see fig.13) that enables DNS Audit /
DNS Lookup / Finger / Get HTML / Info / IP Subnet
Calculator / Password Generator / Ping / Ping Sweep /
Port Scanner / Quote / Time Service / Trace Route /
Wake On LAN / Whois.


Figure 12. Pilot test configuration for Remote and Mobile Control
based on NI Shared Variables


Figure 13. " vxUtil " status screen on HTC P3600 - PDA run
In the PocketPC PDA Build Specification, Deploy
aliases file must be selected (see fig.14).

Figure 14. The PocketPC PDA Build Specification Properties screen
XI. CONCLUSIONS
Remote and mobile control (from a PDA multimodal
Smartphone) of distributed and networked drives and
DAQ in domotics was presented in a pilot configuration
using modern data socket technologies from National
Instruments, based on LabVIEW Shared Variables.
Normal Run-Time Engines that are plugged-in PC
Internet Explorer (allowing to grant remote control of
LabVIEW panels) are not a solution for PDA browsers.
The authors successfully tested new instrumental
measurement and control data streaming by NI
Datalogging and Supervisory Control, very efficient for
device networking in intelligent buildings.
REFERENCES
[1] Araujo, D. Fraga, J.M. Moya, O. Nieto-Taladriz, Domotic platform
based on multipurpose wireless technology with distributed
processing capabilities, 15th IEEE International Symposium on
Personal, Indoor and Mobile Radio Communications, Volume 4,
Issue 5-8 Sept. 2004, p. 3003 3007
[2] C. Filibelia, O. Ozkasap, R. Civanlara, Embedded web server-based
home appliance networks, Journal of Network and Computer
Applications, Volume 30, Issue 2, April 2007, p. 499-514
[3] C. Hintze, Reconnecting the connected home. Electronic Design,
55(2), 2007, pp.36-39, online:
http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=1
4611
[4] P. Pellegrino, D. Bonino, F. Corno, Domotic House Gateway, 21st
Annual Symposium on Applied Computing, Dijon, France, 2006,
http://www.cad.polito.it/FullDB/exact/sac2006.html
[5] Y.H. Lin; I.C. Jan, P.C. Ko, Y. Chen, J.M. Wong, G.J. Jan, A
wireless PDA-based physiological monitoring system for patient
transport, IEEE Transactions on Information Technology in
Biomedicine, Vol. 8, Dec. 2004, p. 439 447
[6] R. Hurling, M. Catt, M. De Boni, B.W. Fairley, T. Hurst, P. Murray,
A. Richardson, J.S. Sodhi, Using Internet and Mobile Phone
Technology to Deliver an Automated Physical Activity Program:
Randomized Controlled Trial, J Med Internet Res. 2007 Apr
27;9(2), http://www.jmir.org/2007/1
[7] http://www.lantronix.com/device-networking/embedded-device-
servers/xport.html
[8] http://www.beyondlogic.org/etherip/ip.htm
[9] J. Axelson, Embedded Ethernet and Internet Complete, Lakeview
Research, 2003, ISBN 978-1931448000
[10] J. Catsoulis, Designing Embedded Hardware, O'Reilly; 2005,
ISBN 978-0596007553
[11] T. Kissell, Electricity, Electronics, and Control Systems for
HVAC, Prentice Hall, 2004, ISBN 978-0130096623
[12] National Instruments, LabVIEW DSC Tutorial,
http://www.ni.com/swf/presentation/us/labview/newdsc/
[13] National Instruments, Using Shared Variables
http://zone.ni.com/devzone/cda/tut/p/id/4679
[14] Cambridge Computer Corp, vxUtil (Personal) for Windows CE,
http://cam.com/vxutil_pers.html