Demo Abstract: Plug&Play Site Managementor, Why Your Solar Panel Should Be Like Your Webcam

Ettore Ferranti, Alessandro Montanari, Yvonne-Anne Pignolet, Igor ZablotchiABB Corporate Research

Segelhofstrasse 1K, 5405 Baden, Switzerland

1 Motivation and IntroductionAutomation and monitoring systems for industrial and

commercial sites (short: Site Management Systems) oftengrow organically, hence they need to be able to integratelarge numbers of heterogeneous devices, based on bothlegacy and novel tools and systems. Currently, many stan-dards are used in the site management field for both con-trol (e.g., KNX, BACNet, LON) and communication (e.g.,WiFi, Ethernet). Different systems are responsible for dif-ferent tasks and parts of the site. Since they are usually notdesigned to interoperate, the site manager is forced to chooseone that suits most of her needs, forgoing features offered byalternative solutions. I.e, the flexibility of the site manageris limited. Moreover, site management systems often requiretechnical personnel for installation, calibration and config-uration, and are not designed to be modified frequently toadapt to changes. Because of this, the site manager is dis-couraged from changing the settings of the system or fromadding or updating devices, by lack of technical knowledgeand by high costs. In other words, a site management systemthat makes adding new devices, e.g., solar panels, as easy asplugging in and using a webcam is needed.

A first step in this direction is presented in [3] showcasinga Zeroconf system for building automation. Our approachgoes beyond [3] by integrating a large variety of devices andprotocols. Other improvements include i) the fact that in-stead of using HTTP and TCP we rely on the more efficientpair CoAP and UDP, ii) that our DNS-SD implementation al-lows devices not only to periodically advertise their servicesbut also to answer queries, iii) the solution proposed in [3]does not make use of a routing protocol specifically tailoredfor sensor networks such as RPL described below and iv)our system features a domain specific language to write ap-plications easily and offering greater flexibility than the webapplication to write rules implemented for [3].

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. To copy otherwise, to republish, to post on servers or to redistributeto lists, requires prior specific permission and/or a fee.

SenSys’13, November 11–15, 2013, Rome, Italy.Copyright c© 2013 ACM 978-1-4503-1169-4 ...$10.00

2 Self-configuring Site Management SystemTo tackle these problems we propose a multi-agent archi-

tecture [1, 7] integrating different technologies to offer flex-ible interfaces to the system. Our solution is based on stan-dard IP protocols and reduces the cost of deployment whileimproving flexibility. Hence we can take advantage of exist-ing infrastructures and devices (e.g. a LAN inside a build-ing). Below we discuss our recent extensions to increase theuser-friendliness and flexibility of our system.

Figure 1. Extensions for more flexible site management.

Intuitive Interaction: Our approach provides the userwith an innovative and simple way of controlling the system,called SmartScript [1]. SmartScript is a domain-specific lan-guage tailored for site management. It allows users to inputintuitive, high-level commands to set or query the state of anappliance or groups of appliances. By design, SmartScriptdoes not rely on the assumption that the user has in-depthknowledge of the technical details of the system. To thisend, the syntax and keywords used by SmartScript, as wellas device names and states were made as close as possible tonatural speech. Moreover, the language features flow controlthrough conditional statements and loops. Below, we presentimprovements made since the original implementation [1].

SmartScript, as well as the agent infrastructure it interactswith, were revised to add more flexibility. First, they adaptquickly to the dynamic addition or removal of devices. Whensuch a change occurs, an agent is notified and the infrastruc-ture related to the language is automatically re-generated andre-deployed. Thus, the user is supported by auto-suggestionsfor newly added devices. Second, SmartScript now has amodular grammar: the main grammar defining core func-tionality and a dictionary module for terminals such as key-words or device names. Therefore, it can be easily adaptedto accommodate languages other than English (the currentdefault) by implementing dictionary modules for those lan-guages, without changing the core grammar.

Another focus of SmartScript is ease of use. Therefore,users can now control devices by spoken commands in ad-dition to the original version, where commands are given inwritten form. For this purpose, the previously strict syntaxhas been replaced by a less constrained one allowing for ex-tra (non-essential) words (abundant in natural speech), arbi-trary word order and approximative matching of the input toterminals. For instance, the command to lower the blindsin an office was previously set G0147 shutter to ’DOWN’,it can now have a more natural form: Could you lower theshutter in g147 please?

Auto-Device Discovery and Interoperability: For auto-configuration we use the mDNS and DNS-SD [2] protocols(Zeroconf) and apply a REST architecture over Coap[5].These lightweight protocols are perfectly suited for con-strained devices and allow us to keep the resource usage low.

Each device is able to answer mDNS/DNS-SD queriesand exposes a RESTful API for its sensors and actuators.To discover a new device, each node publishes a service(node._coap._udp) identifying the IPv6 address and portof its RESTful interface. In the agent system, a specificagent browses the network for the service type _coap._udpand as soon as it detects a new device it performs a GET op-eration as described in [4]. This returns a list of links ofthe resources hosted by that device. This way, the systemknows what the device can do, obsoleting manual configu-ration. After the discovery phase, the system can interactwith any device using standard HTTP-based methods GET,POST, PUT and DELETE. Disappearing devices are handled bythe DNS-SD protocol automatically as well. Moreover, theRESTful interface guarantees a homogeneous access to thesensors and actuators hosted by the devices and facilitatesinteroperation with other web technologies.

Heterogeneous Communication: Often the high costfor the installation of cables and the configuration of thecommunication infrastructure is an obstacle for brown fieldsite management. Furthermore, adaptable links betweencomponents are an essential feature of a flexible distributedsystem. As a consequence, we extended the networkingstack of the embedded Contiki OS, in order to offer flexi-bility regarding the communication technologies used and tosatisfy the constraints of Low Power and Lossy Networks.More precisely we modified the stack to allow the IPv6 rout-ing protocol RPL [6] to use more than one communicationinterface, e.g., wireless and Ethernet. RPL is a self-healingDistance Vector protocol that can be optimized for variousapplications by changing the objective function it uses tocompute suitable paths to border routers. It ensures that newdevices join an existing network automatically and discovercommunication paths to and from any node in the network.

3 Demonstration DescriptionFor the demonstration, we set up a mini office-like en-

vironment, complete with various sensors (e.g., brightness,movement, temperature) and actuators (e.g., light switch,shutter motor) and showcase the main features of our system.In particular, we show how the system can be controlled byissuing voice commands, how plugging devices in and outis automatically recognized, and how communication seam-

a) b)Figure 2. a) Setup for service discovery and REST demo,with two Arduinos equipped with sensors b) Schema ofRPL demo with four Arduinos with 802.15.4 and Ether-net shields, two cables, sending a message from A to Bover one of the two paths

lessly switches between wireless and wired links.Part 1 - SmartScript + Voice Recognition We showcase

the voice command capability. Users can control the appli-ances in the miniature office environment by issuing com-mands with a headset connected to a computer. Users areencouraged to experiment with different wordings to illus-trate the flexibility of the interface.

Part 2 - Service Discovery + REST We show how torealize a flexible and auto-configurable system with standardprotocols and technologies. New sensor and actuator deviceswill be turned on and their presence will be detected auto-matically by the system. The new devices will appear in theWeb user interface along with all the information they carry.Moreover, the newly added devices become addressable inSmartScript commands, therefore it is possible to use themin the language without any manual intervention.

Part 3 - Reliability over Heterogeneous Links Wedemonstrate how RPL switches paths depending on theavailability of reliable links. Our setup (Figure 2.b) con-sists of four nodes, equipped with an 802.15.4 shield and anENC28J60 Ethernet shield, forming a ring connection (usingMAC address filtering to ensure that no other messages arereceived). When transmitting a message from node A to anode B connected by Ethernet, RPL chooses this direct path,as can be seen by a blinking LED on node B. If the cable be-tween them is unplugged, the LED on the other nodes startblinking, signaling that they are forwarding packets.

4 References[1] D. Adolf, E. Ferranti, S. Koch. SmartScript-A Domain-Specific

Language for Appliance Control in Smart Grids. IEEE SmartGrid-Comm’12.

[2] S. Cheshire, M. Krochmal. Multicast DNS (IETF RFC 6773), DNS-Based Service Discovery (IETF RFC 6762), ’11.

[3] L. Schor, P. Sommer, R. Wattenhofer. Towards a zero-configurationwireless sensor network architecture for smart buildings. BuildSys’09.

[4] Z. Shelby. Constrained RESTful Environments (CoRE) Link Format,IETF RFC 6690, ’12.

[5] Z. Shelby, K. Hartke, C. Bormann. Constrained application protocol(coap), draft-ietf-core-coap-18, ’13.

[6] T. Winter, P. Thubert, A. Brandt, T. H. Clausen, J. W. Hui, R. Kelsey,P. Levis, K. Pister, R. Struik, J. Vasseur. RPL: IPv6 Routing Protocolfor Low power and Lossy Networks. IETF RFC 6550, ’12.

[7] D.-Y. Yu, E. Ferranti, H. Hadeli. An intelligent building that listens toyour needs. ACM SAC ’13.

Demo Description: Plug&Play Site Management

The aim of this document is to give more in-depth infor-mation about precisely what is happening during each partof our demo. This document has three sections, to reflect thethree parts of the demo described in the main demo paper.

SmartScript + Voice RecognitionIn the first part, users will give spoken commands to the

system and will see them being executed in the mini-officeenvironment. Figure 3 shows the execution path. The en-coded command is sent to the web interface, where it is trans-formed to text via Google’s Web Speech API. The text ver-sion of the command is then translated from SmartScript for-mat to Python code by a SmartScript processor module. ThisPython code is executed in the agent infrastructure, whichfinally triggers execution at the target appliance via device-specific commands.

A short video preview of SmartScript’s featuresis available at: https://www.youtube.com/watch?v=1HQKxQ0DBdc

User with headset

Web interface

Web Speech API

SmartScript Processor

Agent infrastructureExecution at device

Speech data Text from speech data

Text from speech dataSpeech data

Commands as Python code

Device-specific commands

Figure 3. Executing a voice command.

Service Discovery + RESTWhen a device is turned on, in the mini-office envi-

ronment, its service node1._coap._udp is advertised andsince the agent infrastructure is listening for the same ser-vice type, the new device is automatically detected. Atthis point the infrastructure performs a GET operation on thelink /.well-known/core which is a predefined link used topreform resource discovery (see Figure 4). The list of re-sources returned is used to trigger the re-generation and re-deployment of the infrastructure related to the Smart Scriptlanguage allowing the use of the new device. The subsequentinteractions with the device will be performed using standardmethods (GET, PUT, . . . ) on the previously discovered links.

CoAP / UDP

6LowPan + RPL

GET - node-1/.well-known/core

/brightnessREST

mDNS-SD node1._coap._udp

/blinds

node-2/motion

REST

mDNS-SD node2._coap._udp

/lights

node-1

QUERY - _coap._udpSRV - node1._coap._udp

RES - /brightness /blinds

GET - node-1/brightness

CONTENT - 70

Figure 4. Device discovery and Interaction.

Reliability over Heterogeneous LinksThe visitor can observe that messages are sent regularly

every 2 seconds from node A to node B as long as node Bkeeps turning its green LED on and off, as depicted in Fig-ure 5. If the red LEDs of the other nodes remain dark, thedirect Ethernet path is chosen by RPL. When the visitor un-plugs the Ethernet cable between node A and B, RPL tries tofind another paths via the remaining nodes. Every time oneof them forwards a data message, it will blink its red LEDand node B will start blinking the green LED again as soonas it receives messages over the longer path. If the Ethernetcable on this path is unplugged as well then no LEDs will belit, until at least one of them is plugged in again.

Figure 5. Testbed for heterogeneous communication.

To achieve this behaviour, node B is a RPL DODAG rootnode, i.e., all nodes maintain paths to it proactively. NodeA sends unicast UDP Messages to B, using B’s global IPv6address it receives from the routing protocol.