Research Article High Performance Web of Things ...downloads.hindawi.com/journals/ijdsn/2015/347413.pdf · Research Article High Performance Web of Things Architecture for the Smart

Research ArticleHigh Performance Web of Things Architecture forthe Smart Grid Domain

David Vernet, Agustín Zaballos, Ramon Martin de Pozuelo, and Víctor Caballero

Engineering Department, Universitat Ramon Llull (URL), La Salle, 08022 Barcelona, Spain

Correspondence should be addressed to Agustın Zaballos; [email protected]

Received 3 July 2015; Revised 26 November 2015; Accepted 29 November 2015

Academic Editor: Salvatore Distefano

Copyright © 2015 David Vernet et al. This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

The increasing complexity in the management of Smart Grids is an essential factor in the creation of new technologicalinfrastructures capable ofmanaging the different devices involved in the network.This network has been converted into an exampleof the Internet of Things. In this regard, the Web of Things enables an improvement in the processing of these data. Besides, thelarge amount of data in the Smart Grid domain means that a high performance architectural design is able to manage concurrentlythe entire information processing ability.This paper presents an initial approach for a new architecture and the first results after thesystem implementation.

1. Introduction

The recent growth of the Internet has fostered the inter-action of many heterogeneous technologies under a com-mon environment (i.e., the Internet of Things, IoT). SmartGrids entail a sound example of this situation where severaldevices from different vendors, running different protocolsand policies, are integrated in order to reach a commongoal: bringing together energy delivery and smart services.This proposal deploys an IoT-based infrastructure thatenables machine-to-machine interactions between small andresource-constrained devices on the Smart Grid domainbased on HTTP. It extends the IoT concept by providing abidirectional human-to-machine interface, inspired by theWeb of Things (WoT), which results in a ubiquitous energycontrol and management system (i.e., uniform access to alldevices of the Smart Grid) coined as Web of Energy (WoE)[1].

The recent advances on this domain have led to effec-tive architectures that support this idea from a technicalperspective but fail to provide powerful tools to assist thisnew environment. Hence, the purpose of our technologicalproposal is to research a novel unified and ubiquitous sensormanagement interface that uses the advantages featured bythe Web of Things to manage the Smart Grid. Therefore,this work opens a new path from the Internet of Things to

the WoT and results in a new concept coined as the WoE [1].Overall, the Web of Energy links all domains and permits abidirectional communication between electricity domain andthe application domain. More concretely, the main objectiveis to carry out a proof of concept of an open web-basedinterface that isolates the electricity grid domain from itsutility functions. (1) It relies on a distributed storage layer tosupport themassive amount of data generated by the grid.Thedatabase proposed is an open-source document database thatprovides high performance, high availability, and automaticscaling [2]. (2) It also relies on a Southbound RESTfulAPI that permits an easy and seamless management of thedistributed storage layer and the smart objects connected tothe system.

2. The Smart Grid as an IoT

Recent advances on Smart Grids have explored the feasibilityof considering the power electrical distribution network asa particular case of the IoT [3, 4]. Certainly, this specificdomain poses appealing challenges in terms of integration,since several distinct smart devices (also referred to as Intel-ligent Electronic Devices or IEDs) from different vendors,often using proprietary protocols and running at differentlayers, must interact to effectively deliver energy and providea set of enhanced services and features (also referred to as

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2015, Article ID 347413, 13 pageshttp://dx.doi.org/10.1155/2015/347413

2 International Journal of Distributed Sensor Networks

smart functions) to both consumers and producers (pro-sumers) such as network self-healing, real-time consumptionmonitoring, and asset management [5]. Although the latestdevelopments on the IoT field have definitely contributed tothe physical connection of such an overwhelming amount ofsmart devices [6], several issues have arisen when attemptingto provide a commonmanagement and monitoring interfacefor the whole Smart Grid [5, 7].

Indeed, integrating the heterogeneous data generated byevery device on the Smart Grid (e.g., wired and wireless sen-sors, smart meters, distributed generators, dispersed loads,synchrophasors, wind turbines, solar panels, and communi-cation network devices) into a single interface has emerged asa hot research topic [4, 8]. So far, some experimental propos-als [3] have been presented to face this issue by using theWebofThings (WoT) concept to access a mashup of smart devicesand directly retrieve their information using reasonably thinprotocols (e.g., HTTP and SOAP) [9]. However, the specificapplication of these approaches into real-world environmentsis fairly dubious due to the following reasons: (1) they mayopen new security breaches [10, 11] (i.e., end-users could gainaccess to critical equipment), (2) there are no mature electricdevices implementing WoT-compliant standards available inthe market [5], and (3) industry is averse to include foreignmodules (i.e., web servers) on their historically tested andestablished, but poorly evolved, proprietary systems [12].

Therefore, the authors of this paper explore a new way toovercome these issues through the European project INTel-ligent Electrical GRId Sensor Communications (INTEGRIS)[5] and Future INtErnet Smart Utility ServiCEs (FINESCE)project [13]. This work provides a management interface forthe Smart Grid inspired by the WoT. Continuing the workdone in these projects, the aim is to implement an ICTinfrastructure, based on the IoT paradigm, to handle theSmart Grid storage and communications requirements [14]to manage the whole Smart Grid and link it with end-usersusing a WoT-based approach, which results in a new bridgebetween the IoT and WoT. This proposal, which takes thepioneering new form of the WoT, is targeted at providinga context-aware and uniform web-based novel environmentto effectively manage, monitor, and configure the wholeSmart Grid. Moreover, conducted developments prove thefeasibility and reliability of our approach and encouragepractitioners to further research in this direction and toenvisage new business models [15, 16].

The open IoT-based infrastructure presented in our Webof Energy proposal will provide new tools to manage energyinfrastructures at different levels from IoT-based infrastruc-ture enabledmachine-to-machine interactions between smalland resource-constrained devices on the Smart Grid domain.Thus, we have extended the IoT concept by providing abidirectional human-to-machine interface, inspired by theWoT, which results in a ubiquitous energy control and man-agement system coined as Web of Energy [1]. This proposalwill combine the web-based visualization and tracking toolswith the Internet protocols, which enables a uniform accessto all devices of the Smart Grid. In order to provide suchan effective and reliable management interface to address theheterogeneous nature of devices residing on the grid, we will

continue the deployment of an intelligent subsystem devotedto (1) learn from the real-world events, (2) predict futuresituations, and (3) assist in the decision-making process.

The tools developed can be provided in an open formatavailable to anyone in the research community and are ableto contribute to and enhance the platform building newmod-ules formanaging other resources. As a first step, the platformwill be demonstrated through the management of SmartMetering resources, based on the formats of DLMS COSEMand IEC 61850, but the whole system will be designed for amuch wider scope where every utility, enterprise, and publicadministration or any organization or single prosumer canbuild their own sensor application on top of it (Figure 1).

2.1. WoE Presentation and Specified Functions. The conceptof Smart Grids has been considered in recent years as anappropriate answer to address new challenges in the energydomain. However, additional resources are still needed inchallenges such as the proactive operation of the grid, efficientintegration of demand into grid operation, integration ofrenewable generation, or maximum network reliability toobtain applicable solutions. The WoE will combine energydomains and ICT technologies with the objective of buildingan interoperable platform for the coordinated planning,operation, and settlement of future distribution and access tonetworks by integrating demonstrable solutions in real userenvironments based on Web of Things technologies.

The current control of electricity distribution networks,including the Advanced Distribution Automation (ADA)and Demand Side Management (DSM), is (1) centralized,(2) silo-oriented, (3) fragmented by applications that usespecific communication technologies for each purpose butwith a lack of integration among them, and (4) generallybased on proprietary ICT systems owned by the DSO[18]. So, in practice, the situation is still centralized andfragmented but with existing solutions and trials allowingthe integrated management and the distribution of selectedgranular functions. This contrasts with the distributed andfractal nature of the future Smart Grids, which can only bebased on standardization, flexibility, distributed systems, andcommunication among all the actors [12, 13].

Furthermore, the increased use of renewable and dis-tributed generation means the operation and management ofthe electric power system must change radically. Increasedlevels of automation, distributed intelligence, and on-linedata mining and management are required to deliver thenetwork control functions, reducing reconfiguration and therestoration times. Reconfiguration of smart grids addressesnew challenges during normal operation and also for restora-tion and management of crisis situations [10, 19]. The con-nection of end-users (prosumers) to the energy market willfacilitate the installation and connection of devices that offergrid services that will help mitigate capital and operationalcosts of the gridmodernization required for energy transitionand minimize environmental impact, thus ensuring lowerelectricity prices for everything involved. New benefits willbe generated and shared in a fair way between all actors, fromaggregators to industrial end-users and citizens.

International Journal of Distributed Sensor Networks 3

Publicsubscription

model

RSS

Ope

nda

ta

Ope

ratio

nal

big

data

rt-n

rt

CoAP (ICT-IoT)

ICT NET

CAC

ONTOL.

Sensingand

acting

FractalSWoT

Net

wor

kG

IS/C

ISon

tolo

gy

Contributortransversal

Consultingtransversal

AMI

1

N

Virtual SubE

Vpp-AMP

IED

FIDEV

SDU

Google ALG

EV

ONTOa

ONTOb

ONTOc

ONTOd

Network

mLVL TRANS CAC

DLMS 61850 FINESCE MIB(CMI)

1 2 3 4 5

AAAGEO

REST

ful m

appi

ngC

oAP

JSO

N-X

ML

S3

S3

S2

S2 S2S3

S3

S3

S2S1

Datafunctionheat map

Hybrid cloud

Processing

SD

TSOVPP

DSOuSCADA

PROSUMERuDER

U-USERSnoop

SMCTSit. room

SM_Ho

SM_Bu

SM_Ci

SM_ReN× N× N

N× N

Figure 1: WoE interactions.

A coordinated vision of the grid will providemechanismsto tackle the challenges mentioned above showcasing themthrough real and modern applications. WoE will providesynergies at different levels: Smart Grids and other smartnetworks, individuals, and communities as a first approachto a Software Defining Utility (SDU). The potential benefitsof the WoE are framed by (a) innovative communications,acquisition, and processing platform based on the extensiveuse of the “Real-Time Services” concept providing openand interoperable access, (b) metering integration platformbased on multiplatform web technologies, (c) advancedmedium/low voltage control centre integrating real-time gridinformation coming from devices to provide a clear view ofthe current and the near-future status of the grid thanks toa high performance environment, and (d) energy servicesmarket platform. The performance quantification of thatWoE concept will be the key to accelerate the implementationof new policies, market rules, and emerging Smart Gridprograms [15, 16].

WoE outlines some of the challenges in improving theresiliency of the electrical grid and proposes an approach thatmakes use of advanced sensor technology (advanced sensorsare needed to improve the knowledge of state), analytics, andagile control in a Smart Grid [20, 21]. Furthermore, WoEproposes a Smart Grid supervision infrastructure, whichcan deliver real-time and high performance notifications ona global scale for transferring measurements from differ-ent distributed sensors and take actions over the grid viadifferent communication protocols, informing the different

stakeholders (e.g., producers, consumers, aggregators, andsystem operators) within the adequate time frame [8, 18]. Wepropose to use a distributed infrastructure based on Web ofThings and implement a novel service platform for facilitatingdistributed control, autohealing, and power grid control.

In addition, WoE technology will tackle the implemen-tation of smart real-time distributed monitoring platformsenabling the data fusion and knowledge extraction for thedifferent faults detection and prevention schemes. IntelligentHTTP based sensors will provide a new source of relevantdistribution status information, including loadings, voltageprofiles, harmonics, and outage conditions which, combinedwith equipment condition data, such as power frequencyinterference signatures, will provide predictive perspectivesof potential equipment failures. This platform requires largestorage technologies that can hold the massive amountsof information that will be generated by the millions ofsensors implemented in the Smart Grids and will make theinformation available in negligible times to the system orsystems demanding it (Figure 2).

Smart Grids need monitoring strategies based on decen-tralized and uncoupled architectures (service oriented andmultiagent), supported by real-time middleware (DDS)capable of dealing with huge amounts of information atdifferent time scales, process events (complex event pro-cessing), and discover sequences of them (sequence eventdiscovery) working together with OLAP and data miningsolutions. A multiagent conception of the grid is necessaryto deal with coordination and optimization requirements for


USN middleware

Distributed generation monitoring

Substation monitoringHome and building monitoring

Distributed generation control

application

Substation control and maintenance application

Customer monitoring application

Integrated control centreGIS

BBDD

Security manager Open API Sensor network

directory service

Query processor

Sensing data mining processor

Context-awarerule engine processor

Event

Securitymanager

Sensor network common interface

Sensor network monitor

Figure 2: Open API architecture.

an efficient and safe network. Pervasive web monitoringdevices with communication capabilities increase securityof the network as a whole but imply new cyber-securityissues and make optimal restoration and reconfigurationmore complicated [22]. Currently, heuristics, metaheuristics,and learning methods are mature and available. Restorationand reconfiguration techniques including autohealing willbenefit from these reasoning engines.

3. The Web of Things

Day by day, the number of connected Things is growingexponentially. The latest data shared by Gartner finds that4.9 Billion of Things will be accessible during 2015 and thisfigure will increase to 25 Billion in 2020 [23]. The way toaccess these devices from a single platform is undoubtedlyone of the biggest headaches for researchers. In this regard,standardized solutions provided by the rapid evolution ofthe Internet have laid the foundation of what we call theWeb ofThings.Therefore,WoT architectures aim to integrateeveryday objectswithweb technologies.Those devices shouldbe able to communicate with each other using existingweb standards. Prerequisites for those Things are minimalprocessing and communication capabilities.WoT researcherstry to define and delimit concepts (e.g., what is aThing? [24])implied on those envisioned architectures and solve someproblems that arise when every Thing may sense or actuateon every Thing.

Applications

Composition

Sharing

Findability

Accessibility

WoT architecture proposedby Guinard

Figure 3: Layered architecture [17].

The architecture presented by Guinard in his thesis [17]proposes a good basis to start other WoT designs. Guinarddefines WoT general prerequisites; he also defines what aThing is and a virtual object is in aWoT architecture and findssolutions to problems like how to discover and find Thingsand how those Things can connect and push informationto a server. In [17], a layered architecture (see Figure 3) thatconsists of four layers that address four main problems isproposed:


(i) Device Accessibility Layer: how to enable consistentaccess to all kinds of connected objects?

(ii) Findability Layer: how do we find their services tointegrate them into composite applications?

(iii) Sharing Layer: how we preserve privacy?(iv) Composition Layer: how do we get closer to end-

users?

One of the main problems of the WoT architecture isto standardize communication protocols between differentThings. Indeed, there is still no clear standard defined for thispurpose and there are different options available. In the nextsection, we present the best placed and supported protocolsby researchers and which protocols are also valid/eligiblealternatives.

4. WoT Protocols

It would be easy for WoT to use only one protocol, butthe heterogeneity of devices composing the WoT makes itunfeasible. Thus, different communication protocols shouldbe considered. The use of each one depends on the finalproposed solution.

4.1. Preferred Candidates by the Community

4.1.1. MQTT. As stated in its official webpage [25], MQTTstands for MQ Telemetry Transport. It is a publish/subscribe(pub/sub), extremely simple, and lightweight messaging pro-tocol, designed for constrained devices and low-bandwidth,high-latency, or unreliable networks. The design principlesare to minimize network bandwidth and device resourcerequirements while attempting to ensure reliability and somedegree of assurance of delivery. These principles also con-tribute to the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet ofThings” world of connecteddevices and to mobile applications where bandwidth andbattery power are at a premium. MQTT was introduced byIBM and Eurotech companies.

MQTT is a protocol that uses a pub/sub model, con-necting publishers and subscribers via a broker (server). Itsheaders are small and therefore their overhead is minimum.MQTT can also work over SSL for security reasons, but SSLadds an extra overhead to the communication. As publishersand subscribers connect via a broker, the use of a centralizedserver leads to a SPF (Single Point of Failure).

4.1.2. CoAP. CoAP [26] was specified and standardized bythe CoRE (Constrained RESTful Environments) group inIETF; the Constrained Application Protocol (CoAP) is aspecialized web transfer protocol for use with constrainednodes and constrained networks, such as those that will formthe Web of Things. This protocol shares several similaritieswith HTTP like its REST architectural style but instead ofusing TCP it uses UDP to achieve its goals.

As it is a request/response protocol like HTTP, bothWoTservers and constrained devices or gateways should act asservers and clients at the same time to ensure bidirectional

communication at any time. For example, a constraineddevice using this protocol may fire an event to the WoTserver and the WoT server may request something to theconstrained device. Proxies between HTTP and CoAP willachieve interoperability between HTTP and CoAP clients.Translation betweenCoAP andHTTP is easy and straightfor-ward as equivalences of response codes, options, andmethodsare present in both protocols. Security is achievable usingDTLS and a variety of key management methods.

4.2. Other Candidates

4.2.1. DDS. From [27], “DDS (Data Distributed Service) is anAPI specification and an interoperability wire-protocol thatdefines a data-centric publish-subscribe architecture for con-necting anonymous information providers with informationconsumers.” DDS follows a decentralized pub/sub model. Itdiffers fromMQTT model in the following two key points:

(i) DDS protocol starts to operate on top of the linklevel layer of the OSI model creating a CommonDataBus where every device can connect in a decentral-ized manner. This protocol also defines several QoSoptions.

(ii) As a decentralized protocol, it does not have SPF likethe broker in MQTT.

DDS has only implementations for C, C++, and Java and hasa higher learning curve compared to MQTT. On the otherhand, MQTT clients are implemented for several languages.

4.2.2. XMPP. XMPP [28] (originally named Jabber) is aprotocol for person-to-person communication based onXML. Its main use is for chat communication but since thegrowth of the IoT concept theXMPPStandards Foundation isworking ondefining extensions (XEPs) for use in the IoT [29].These extensions aim to specify standards for awide variety ofcommunication types between IoT devices such as Control,Discovery,Multicast, or pub/submessage types.They use EXI[30] (compressed XML) to reduce the size of messages, asXML is known to produce larger file/message sizes than othertext based formats. Even though XEPs for the IoT are not asmuch as popular asMQTT or CoAP, it is worth keeping trackof them as they are growing fast andmay be used as a basis tomodel WoT message formats.

4.2.3. AMQP. AMQP [31] is a message-centric binary wireprotocol that uses a centralized broker. AMQP is built ontop of the TCP layer (at least, it is assumed to work on topof TCP). Authentication and encryption are made availablethrough SASL and TLS, respectively. As AMQP was createdby businesses-to-businesses, it provides transactional modesof operation that allow it to take part in a multiphase commitsequence.The key feature of AMQP is that it was designed forinteroperability between vendors. It mandates the behaviourof the messaging provider and client to the extent thatimplementations from different vendors are interoperable.

Third party implementations of AMQP clients exist forseveral languages. Although AMQP is a great opponent for


MQTT, the latter seems more suitable to build a proof ofconcept for theWoT architecture we have been talking aboutin this section.

5. Some WoT Implementations(Related Work)

This section is going to review someWoT implementations ofthis architecture. Guinard joined the EVRYTHNG platformand engine [32]. This engine allows Things (they call them“thngs”) to be connected to this platform through a RESTfulAPI. They describe two types of thngs:

(i) Unconnected/tagged: they are encoded in 1D/2D barcode or NFC/RFID tag and users can interact withthem by scanning the tag.

(ii) Connected: those thngs can interact with the RESTfulAPI of the EVRYTHING engine; they can be sensedand/or actuated.

This engine offers the creation of applications that repre-sent remote client applications (like those used in socialnetworks like Twitter or Facebook). Thanks to its THNG-Push technology (currently in beta), the engine provides apublish/subscribe MQTT M2M broker where WebSocketswrapping MQTT are used to allow communication withbrowsers. They are also working on adding CoAP support tothis technology. Node.js and JavaScript libraries are availableto facilitate the use of their API.

In [33], the authors propose and implement holistic webarchitecture for the Internet of Things. They point out keyfeatures and capabilities of holistic architecture and they usea layered model with an abstraction layer for communicationamong devices.

Node-RED [34] is a visual tool for wiring hardwaredevices, APIs, and services. From the Node-RED front page,“Node-RED provides a browser-based flow editor that makesit easy to wire together flows using the wide range nodesin the palette. Flows can be then deployed to the runtimein a single-click.” Also in beta, this tool aims to provideusers with a visual manner connecting things. Node-RED isbuilt on Node.js and customized functions between nodescan be created within the editor using JavaScript. There isan EVRYTHNG Node-RED integration library to add somefunctionality of the EVRYTHING platform to this tool.

Octoblu [35] is an open-source cloud platform (public,private, or hybrid) built to connect people, devices, andsystems through a great variety of protocols like MQTT,CoAP, HTTP(S), and WebSockets using a RESTful API. Italso offers a very powerful visual tool for connecting things(nodes). This tool also allows developers to program theirown nodes as JavaScript functions. Node.js and JavaScriptlibraries are also available to facilitate the use of their API.

Neura [36] and TempoIQ [37] are platforms for collect-ing sensor data through a RESTful API. While Neura ismore person-oriented, TempoIQ is a general-purpose datacollector. TempoIQ (former TempoDB) also offers tools formonitoring and analyzing this sensor data.

Finally, in [38], the concept of storage registration isintroduced for the WoT. In this storage approach a webclient announces its interest of storing some sensor datato the server. The server will store the data until the webclient requests removal or an expiration time is reached. Thisprevents the server from reaching its storage limit.

6. Proposed Architecture

The purpose of this section is to present the architecture andannounce the key parameters used to link the layers. Fromour real-world experiences collected during the INTEGRISand FINESCE [13] projects, we have found that dividingthe Smart Grid into these logical layers poses some criticaldifficulties arising from the fact that typically IEDs are closeddevices that do not allow implementing custom develop-ments (e.g., security or information-exchange protocols) asnovel experimental devices do. Therefore, we proposed anew device coined as I-Dev [14, 18, 22] which behavesas a frontier between these two layers and implements(1) a communications subsystem that allows heterogeneousnetwork coexistence, (2) a security subsystem that provides areliable and secure low layer communications infrastructure,(3) a distributed storage subsystem that smartly stores all datagenerated by IEDs, and (4) a cognitive subsystem that is awareof all events arising from any subsystem of the network.

In Figure 4, an architecture is proposed in order toallow Things to communicate with each other. The proposalexplanation will be divided into the following sections:specifications, used protocols, and software design.

6.1. Specifications. In this proposal, a Thing can be under-stood as every device that has minimum communication,processing, and storage capabilities so it is able to be sensed oractuated and can communicate with another device to sendor receive data. The proposed architecture has those goals tosatisfy:

(i) As standard Web protocols such as HTTP or Web-Sockets use resources that may not be availableon some constrained Things, this architecture willconnect them using a variety of protocols (but ideallyone) like CoAP or MQTT that are more suitable forconstrained devices.

(ii) EveryThingmust be using an open standard protocoland must be understandable by the architecture toconnect to the WoT. Gateways serving as a proxy forthose Things that use proprietary or nonunderstand-able protocols should be used.

(iii) Things that cannot connect to theWoT infrastructuredirectly should connect to a gateway instead and letthat gateway do the connection for them.

(iv) This architecturewill allowdevelopers to interactwithThings without knowing the protocol they are reallyusing to communicate; hence, there is a need to pro-vide developers with a communication abstractionlayer.


International

Country

Region

City

Neighbourhood

Building

Home

ActingSensing Processing

Prosumers

Utilityadministrators

TSOs DSOs

Publicadministrations

Secu

ret—

scal

able

-con

text

-aw

are-

Zero

Con

f

Multiutility SCADA: electricity, water, gas, . . .

Figure 4: Functional architecture.

(v) It must allow on-demand deployment due to the factthat the number ofThings will increase and thereforemore resources will be needed to connect them.

(vi) This architecture should be able to balance the load onits servers. Load balancers will prevent or minimizebottlenecks.

(vii) Things will become virtual objects for the architectureand those virtual objects could be aggregated andlinked to form other virtual objects.

(viii) Eventually, every virtual object will be accessible byRESTful URI.

(ix) The architecture must have authorization ofThings tointeract with them to preserve owner’s privacy.

(x) Third-party applications must have the architectureauthorization to interact withThings.

(xi) Every Thing must have an owner.(xii) Things can be queried and discovered.

In Figure 5, we can see how Things are connected toservers directly or via a gateway/aggregator being part of theWoT.

6.2. Protocols. While the use of one protocol like HTTP forall the Web of Things would be desirable, it is obvious thatit is not achievable due to the heterogeneity of devices. So, aWoT architecture would need interoperability with a varietyof protocols to interconnect devices.


P

CD CD

P P

P

PWS

CoAP

CoAP

CoAPCoAP

CoAP

CoAP

CoAPMQTT MQTT

MQTT

MQTT

MQTT

CD-P

CD-PCD-P

HTTP

HTTPS

HTTPS

HTTP + WS

HTTP + WS

HTTP + WS

Thing CD: constrained device

P: proprietary protocol

WS: WebSockets protocol

Aggregator

Server

Figure 5: The proposed WoT architecture.

6.2.1. HTTP and WS. As the Web uses HTTP to commu-nicate, it is mandatory for the architecture to support thisprotocol. It will also provide a RESTful communication usingURIs to identify resources and methods to actuate or senseon them.

With IPv4 still in use and incapable of addressing allInternet connected devices, Internet connection to personalcomputers, for example, is available through port transla-tion mechanisms. This translation makes them incapable ofreceiving data asynchronously from a server; hence, the useof some sort ofmechanism to allow them to receive data in anasynchronousmanner is required. In addition, as proposed in[2],WebSockets [12] protocol can overcome this constraint byproviding a mechanism for browser-based applications thatneed two-way communication with servers.

6.2.2. MQTT and CoAP. As described in the previous sec-tion, MQTT and CoAP seem to be very suitable protocolsfor the WoT world. We propose to use these protocols butthe architecture should be capable of understanding moreprotocols (e.g., DDS).

6.3. Layered and Modular Design. To be able to seam-lessly intercommunicate these protocols and help develop-ers implement and provide different implementations offunctional units (e.g., how a protocol is handled, adding anew protocol to the framework, and how VO is accessed),

the architecture relies on a layered and modular design.It is composed of five main layers (Figure 6); they are thefollowing:

(i) WoT Protocol Abstraction Layer: the purpose of thislayer is to provide an abstraction mechanism fordevelopers to interact withThings.

(ii) REST to VO/Query: the goal of this layer is to mapdynamically generated URIs to virtual objects (VOs).It is an interface to gather information or actuate onVOs, that is,Things. It is also an endpoint for queryingThings like the temperature on a specific location.

(iii) Auth: this layer is responsible for requesting andgranting access between Things. As mentioned inSection 4, everyThingmust have an owner; therefore,WoT servers must request access to Things and VOsmust request access to other VOs.

(iv) Virtual Object Space: this is the space for virtualobjects. Things will become virtual objects in thevirtual world. Those VOs could be then sensed,actuated, and aggregated.

(v) Proxy layer: this abstraction layer will serve as aproxy for servers to communicate. A protocol for thiscommunication must be defined for the architecture.

Those layers will be backed up by the database and thereasoner [39] modules. As theWoT architecture will generate


WoT protocolabstraction layer

REST to VO/query

Auth

VO space

Proxylayer

Server 0

· · ·


REST to VO/query

Auth

VO space

Proxylayer

Server 2


REST to VO/query

Auth

VO space

Proxylayer

Server 1

Figure 6: Layered and modular design.

URIs to addressThings, a distributed database will be suitablefor routing request based on their URI. Given a query, serverscan first search in this database if this resource has beendiscovered beforehand. If this were the case, no discoveryprotocols would be needed; otherwise, a discovery protocolwould start a search to find the resource and once discoveredthe resource URI would be stored in the distributed database.Servers may also have local storage to implement the storageregistration mechanism.

TheWoT architecture presented in this paper is based onthe architecture proposed by Guinard.This section is focusedon the architecture but we will highlight main similaritiesbetween two architectures.

As Guinard stated in his thesis, the upper layers presentedin Figure 7 do not hide lower layers and instead they aredevelopment layers where users with different technicalknowledge can develop applications on top of them.

On the other hand, the definition of each of the layersof the proposed architecture and its correspondence withGuinard’s proposal would be as follows.

6.3.1. Virtual Object Space. The layer that shares more sim-ilarities in Guinard’s architecture is the Composition Layer,but in his approach this layer is a Physical Mashup whereweb services and enabled smart devices can create compositeapplications. In the proposed system and as in [24], this layerserves the purpose of digitally enabling smart devices for theiruse by the architecture and by WoT users. Then, applicationsbuilt on the upper layer of the architecture (e.g., PhysicalMashups) could use these digitally enabled smart devices.

6.3.2. Auth. This layer shares the same purpose as the SharingLayer exposed in Guinard’s thesis. The goal is to preserve theprivacy of each Thing, allowing Things to have owners thatshare the capabilities of theirThings. A great approach to thisauthentication and authorization layer would be the same asthe one proposed in [17].

6.3.3. REST to VO/Query. The goal of this layer is to dynam-ically generate meaningful, RESTful URIs for VOs as they arequeried for the first time. Once the device has a meaningfulbase URI, its capabilities can be exposed through expandingits URI and the common HTTP verbs. Querying Things will

Virtua

l obje

ctsp

ace

Auth

REST to

VO/qu

ery

WoT

abstr

actio

n lay

er

Applications

Proxy layer

Figure 7: Applications can be developed over the upper layers.

involve complex semantic processing and a process such asthe one described in [32].

6.3.4. WoT Protocol Abstraction Layer and Proxy Layer. Asseveral protocols can join the WoT architecture, there is aneed to unify those protocols at the entrance of the proposedarchitecture (WoT Protocol Abstraction Layer), translatingthose protocols to an internal language. This will allow thedevelopment of the inner layers of the architecture regardlessof the protocolThings are using to connect to the architecture.This layer would accomplish the functions of the AccessibilityLayer proposed by Guinard. In Figure 8, the correspondencebetween the layers defined by Guinard and the layers of theproposal is presented.

As the inner architecture should be agnostic from theoutside protocols (those used by Things and the architectureto exchange information), there is a need to develop an inter-nal format and mechanism (proxy layer) to pass messagesbetween different nodes of the architecture. The next sectionshows a proof of concept of this idea. Firstly, the used datasetfor testing is described and, secondly, the discovery algorithmis depicted. Finally, two implementation approaches arepresented and the results obtained are discussed.

7. Proof of Concept

7.1. Dataset. The data used for performing the tests of thisproof of concept come from public data from the NationalStatistics Institute of Spain (http://www.ine.es) concerning


Applications

Composition

Proxylayer

Sharing

Findability

Accessibility

WoT architecture proposedby Guinard Our architecture

Applications

Virtual object space

Auth

REST to VO/query

WoT protocol abstractionlayer

Figure 8: Comparison between the proposed architecture andGuinard’s one.

Figure 9: Snapshot of the representation of the devices response.

cities/towns and inhabitants of Spain’s municipality. Specif-ically, all the inhabitants of Catalonia region have beenaccounted (about 7.5 million), taking into account the follow-ing two assumptions:

(i) In each house live an average of three people.

(ii) Only 1% of households have some functional andInternet-controllable device.

Each house has been assigned to a city, and then a device israndomly assigned to each house. Different types of sensorsare chosen, including temperature sensors and electricitymeters.

For each city, it has been possible to obtain geolocationdata (longitude and latitude) and it has been geographicallyrepresented on the map. In Figure 9, a snapshot (from thecreated application, called Semantic Web of Energy) can beobserved.The control of these devices is displayed, indicatingin color the answer to a request for consultation (Discoveryof Thing).

7.2. Algorithm. Based on the assumptions outlined above,a first version of the architecture presented in this paperis implemented. In this sense, we have implemented thefirst “Discovery of Things” functionality. It is simulated by

the example of how to access a temperature sensor using thesteps described in the following algorithm:

(1) User A sends a request R1 to its local dispatcher nodeD1 (located in Madrid).P1 = {"action": "GET", "what":"temperature", "loc": "Carrer de Sants"}

(2) D1 processes de address (“Carrer de Sants”), searchesfor the Barcelona IP address and send a response touser A.R1 = {"request": {"what": "ws-conn", "to":"@IP-BarcelonaNode"}}

(3) User A sends a request P2 to the node with the IPaddress @IP-Barcelona.P2 = {"request": {"what": "ws-conn"}}

(4) Barcelona’s D2 dispatcher rececives P2 and sends aresponse R2.R2 = {"uri": {"method": "GET", "uri": "/ws/id/1"}}

(5) User A connects to @IP-Barcelona/ws/id/1 via Web-Sockets (WS1 connection) and resends P1 throughthis connection. This connection will be managed byN1 node (server).

(6) N1 processes the requests and searches for an addressto forward the request and receive the temperatureof Carrer de Sants. N1 has the private address of anaggregator/gateway (A1) that can provide the result ofthe query. N1 sends a CoAP request P2 to A1.P2 = {"action": "GET", "what":"temperature"}

(7) A1 processes the request and sends a response R3to N1. R3 = {"uri": {"method": "GET", "uri":"/temperature"}, "data": {"value": 15,"unit":"Celsius"}}.A1 also saves an URI map to its local database:saveUriMap: "(GET)/temperature" ->(function to get data)

(8) N1 receives R3 response and saves to its local database:saveUriMap: "/carrer-de-sants/" ->(GET)@IP-A1/temperature.N1 also saves a query map to the distributeddatabase: saveQueryMap: "Carrer de Sants,temperature" -> "(GET)@IP-N1/carrer-de-sants/temperature".N1 sends a R4 response to user A.R3 = {"uri": {"method": "GET", "uri":"/carrer-de-sants/temperature"}, "data":{"value": 15, "unit": "celsius"}}.Moreover, if N1 has users that need the same data,sends R4 to these users too.

(9) User A receives the requested data and a URI toidentify the resource and made future requests to it.


If the same user A wants to request the same dataagain, he will send a URI request ((GET)@IP-N1/carrer-de-sants/temperature) directly to N1 and as query and URImaps are now present the response will return faster as lessprocessing time will be needed.

If user B sends the same request P1 to D1, D1 will respondsaying that user B must request a WebSocket connection toN1 and send a request to this URI “(GET)@IP-N1/carrer-de-sants/temperature.”

As shown, the framework is capable of handling thediscovery of the new object and further processing andstorage in the system for future reference.

7.3. Implementation. In this section two implementationapproaches are compared.

7.3.1. First Approach. As a lot of services found inWeb 2.0 areimplemented using the PHP language (http://trends.built-with.com/framework) and in order to ease Web of Thingsapplications at every layer for experienced PHP developers,we have developed a prototype implementing the algorithmpresented in this section using the PHP language. Althoughwe have succeeded in developing basic functionalities usingPHP, several problems have arisen during the implementa-tion.

PHP was born to serve CGIs, for example, to serve HTTPrequests with dynamic content. The main workflow wherePHP has been used consists in three steps: load, execute,and die. For this reason, few efforts have been made to solveproblems such asmemory leaks or the fact that executing onePHP statement requires more low-level instructions than theactually needed ones.

In recent years, PHP has undergone some changes in itsusages and performance:

(i) With the arrival of Node.js [40], some PHP develop-ers started to implement libraries with the objective ofallowing PHP users to create servers in this languageas in React PHP [41] instead of relying on web serverslike Apache HTTP.

(ii) Compiled PHP frameworks such as the PhalconFramework [42] with a high performance boost onexecution time have motivated the release of PHP7, solving memory leaks and decreasing the numberof low-level instructions needed to execute a PHPstatement.

In order to build the prototype, we have used the PhalconFramework and React PHP to boost performance. ThePhalcon Framework presents high speed in performing oper-ations and React PHP presents a novel manner for buildingPHP applications using the reactor pattern and asynchronousprogramming. However, the immaturity of React PHP andthe lack of asynchronous libraries in PHP present an obstaclefor developers to use even basic technologies such as Mon-goDB.

In this way, PHP has succeeded in building and fast-prototypingWeb applications thanks to its low learning curveand its dynamic typing. However, its use at low-level/core

Table 1: Benchmarking PHP versus Scala languages.

Feature PHP Scala

Natural workflow Load, execute,die

Always running ona JVM

Speed 1 28 times fasterBacked by research No Yes

Libraries PHP, Cextensions

JVM compliantlibraries

Distributed libraries As C extensions Akka and otherJVM libraries

Async. libraries/constructs ReactPHP Akka and FuturesTyping Dynamic Static

layers in a WoT/IoT architecture where program correctnessis crucial facilitates the appearance of execution time errors.

7.3.2. Second Approach. After evaluating other solutionsin the market, the Scala [43] language has been selectedfor reimplementation of the prototype. Although this lan-guage usage is not wider than PHP, Scala is experiencingan adoption growth (http://www.indeed.com/jobtrends?q=scala&l=).

Moreover, this language presents key characteristics thatmake it suitable for building a future WoT prototype archi-tecture. Scala has also been chosen due to its researchcommunity. In fact, Scala was born at the EPFL (Ecole Poly-technique Federale de Lausanne) thanks to Martin Odersky[43]. Therefore, continuous investigation is being made inorder to optimize speed and provide better APIs.

7.3.3. Comparison Table. A comparison between PHP andScala is presented in Table 1. Data presented in this compar-ison table have been extracted from the authors’ experimen-tation. Speed has been extracted from benchmarks done in[44].

8. Conclusions and Further Lines

A new framework approach and a proof of concept havebeen presented in this paper. It has been shown that theproposed architecture is feasible and that the implementationof successive parts can be made using this design.

Although the results exposed are promising, we have real-ized that PHP lacks libraries and implementation for themostrelevant WoT protocols. If there is a valid implementation, itonly covers basic features of the protocol.

Moreover, the reactor approach was performed to proto-type the architecture using ReactPHP and it was found thatthere are no libraries to connect the most commonly useddatabases in distributed systems like Redis or MongoDB orthe WoT protocols.

For the reasons exposed, it seems that PHP is notmature enough for the purpose, that is, to develop holisticarchitecture for the Web of Things. Reimplementation ofthe architecture using the Scala language has been made,speeding up its performance and opening up the possibility


to take advantage of robust libraries and frameworks built ontop of JVM compliant languages.

Heterogeneity, parallelization, and distribution asexplained in [45] are also key characteristics of a WoT archi-tecture. More work has to be done to fully achieve these char-acteristics. The Actor Model [46] seems to be well suitedto build an architecture with such characteristics asasynchronous messaging, location transparency, distribu-tion, and concurrency as its core principles.

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper.

Acknowledgment

This work received funding from the European Union’s 7thFramework Program under FI.ICT-2011 Grant no. 604677-FINESCE (Future INtErnet Smart Utility ServiCEs).

References

[1] J. Navarro, A. Sancho, A. Zaballos, V. Jimenez, D. Vernet, and E.Armendariz-Inigo, “The management system of INTEGRIS—extending the smart grid to the web of energy,” in Proceedingsof the 4th International Conference on Cloud Computing andServices Science (CLOSER ’14), pp. 329–336, Barcelona, Spain,2014.

[2] MongoDB Database, https://www.mongodb.org/.[3] D. Guinard, V. Trifa, F. Mattern, and E. Wilde, “From the

internet of things to the web of things: resource-orientedarchitecture and best practices,” in Architecting the Internet ofThings, pp. 97–129, Springer, Berlin, Germany, 2011.

[4] A. Zaballos, A. Vallejo, and J. M. Selga, “Heterogeneous com-munication architecture for the smart grid,” IEEE Network, vol.25, no. 5, pp. 30–37, 2011.

[5] INTEGRIS, INTEGRIS FP7 Project INTelligent ElectricalGrid Sensor communications, ICT-Energy-2009 call (number247938), http://fp7integris.eu.

[6] C. Bo, C. Xin, Z. Zhongyi, Z. Chengwen, and C. Junliang,“Web of things-based remote monitoring system for coal minesafety using wireless sensor network,” International Journal ofDistributed Sensor Networks, vol. 2014, Article ID 323127, 14pages, 2014.

[7] S. Aman, Y. Simmhan, and V. K. Prasanna, “Energy man-agement systems: state of the art and emerging trends,” IEEECommunications Magazine, vol. 51, no. 1, pp. 114–119, 2013.

[8] A. Zaballos, D. Vernet, and J. M. Selga, “A genetic QoS-aware routing protocol for the smart electricity networks,”International Journal of Distributed Sensor Networks, vol. 2013,Article ID 135056, 12 pages, 2013.

[9] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio,“Interacting with the SOA-based internet of things: discovery,query, selection, and on-demand provisioning of web services,”IEEE Transactions on Services Computing, vol. 3, no. 3, pp. 223–235, 2010.

[10] D. Zeng, S. Guo, and Z. Cheng, “The web of things: a survey(invited paper),” Journal of Communications, vol. 6, no. 6, pp.424–438, 2011.

[11] E. Bou-Harb, C. Fachkha, M. Pourzandi, M. Debbabi, andC. Assi, “Communication security for smart grid distributionnetworks,” IEEE Communications Magazine, vol. 51, no. 1, pp.42–49, 2013.

[12] V. C. Gungor, D. Sahin, T. Kocak et al., “A survey on smart gridpotential applications and communication requirements,” IEEETransactions on Industrial Informatics, vol. 9, no. 1, pp. 28–42,2013.

[13] FINESCE, European Union’s 7th Framework Program underthe FI.ICT-2011 Grant number 604677, http://www.finesce.eu/.

[14] J. Navarro, A. Zaballos, A. Sancho-Asensio, G. Ravera, and J.E. Armendariz-Inigo, “The information system of INTEGRIS:Intelligent electrical grid sensor communications,” IEEE Trans-actions on Industrial Informatics, vol. 9, no. 3, pp. 1548–1560,2013.

[15] A. Bari, J. Jiang, W. Saad, and A. Jaekel, “Challenges in thesmart grid applications: an overview,” International Journal ofDistributed Sensor Networks, vol. 2014, Article ID 974682, 11pages, 2014.

[16] J. Rodrıguez-Molina, M. Martınez-Nunez, J.-F. Martınez, andW. Perez-Aguiar, “Business models in the smart grid: chal-lenges, opportunities and proposals for prosumer profitability,”Energies, vol. 7, no. 9, pp. 6142–6171, 2014.

[17] D. Guinard, A web of things application architecture [Doctoraldissertation], Eidgenossische Technische Hochschule ETH,Zurich, Switzerland, 2011, Nr. 19891.

[18] J. M. Selga, G. Corral, A. Zaballos, and R. Martın de Pozuelo,“Smart grid ICT research lines out of the European projectINTEGRIS,” Network Protocols and Algorithms, vol. 6, no. 2,2014.

[19] Y. Oualmakran, J. Melendez, S. Herraiz, M. Lopez-Perea, and E.Gonzalez, “Survey on knowledge based methods to assist faultrestoration in power distribution networks,” in Proceedings ofthe International Conference on Renewable Energies and PowerQuality (ICREPQ ’11), Las Palmas, Spain, April 2011.

[20] C. Miller, The Fractal Grid: Achieving Grid Security, Reliabil-ity, and Resiliency through Advanced Analytics and Control,National Rural Electric Cooperative Association, 2013.

[21] C. Miller, M. Martin, D. Pinney, and G. Walker, Achieving aResilient and Agile Grid, National Rural Electric CooperativeAssociation, Arlington, Va, USA, 2014.

[22] A. Sancho-Asensio, J. Navarro, I. Arrieta-Salinas et al., “Improv-ing data partition schemes in Smart Grids via clustering datastreams,” Expert Systems with Applications, vol. 41, no. 13, pp.5832–5842, 2014.

[23] Gartner Says the Internet of Things Installed Base Will Growto 26 Billion Units By 2020, Stamford, Conn, USA, December2013, http://www.gartner.com/newsroom/id/2636073.

[24] E. Oriwoh and M. Conrad, “Things’ in the internet of things:towards a definition,” International Journal of Internet ofThings,vol. 4, no. 1, pp. 1–5, 2015.

[25] MQTT, Retrieved March 27, 2015, http://mqtt.org/.[26] C. Bormann, A. P. Castellani, and Z. Shelby, “Coap: an applica-

tion protocol for billions of tiny internet nodes,” IEEE InternetComputing, vol. 16, no. 2, pp. 62–67, 2012.

[27] Data Distribution Service Portal, April 2015, http://portals.omg.org/dds/what-is-dds-3/.

[28] TheXMPP Standards Foundation (n.d.), June 2015, http://xmpp.org.

[29] Tech pages/IoT Xeps Explained, June 2015, http://wiki.xmpp.org/web/Tech pages/IoT XepsExplained.


[30] Efficient XML Interchange Working Group. (n.d.), June 2015,http://www.w3.org/XML/EXI/.

[31] AMQP, April 2015, https://www.amqp.org/.[32] EVRYTHNG—Every Thing Connected, April 2015, https://

evrythng.com.[33] D. Tracey and C. Sreenan, “A holistic architecture for the

internet of things, sensing services and big data,” in Proceedingsof the 13th IEEE/ACM International Symposium on Cluster,Cloud, and Grid Computing (CCGrid ’13), pp. 546–553, Delft,The Netherlands, May 2013.

[34] Node-RED, April 2015, http://nodered.org/.[35] Octoblu, “Wemake all APIs, Platforms and Devices talk to each

other. Easily,” April 2015, http://octoblu.com/.[36] Neura, April 2015, http://www.theneura.com/.[37] TempoIQ, April 2015, https://www.tempoiq.com.[38] G. Bovet and J. Hennebert, “A web-of-things gateway for KNX

networks,” in Proceedings of the European Conference on SmartObjects, Systems and Technologies (SmartSysTech ’13), pp. 1–8,VDE, Erlangen, Germany, June 2013.

[39] B. Christophe, V. Verdot, and V. Toubiana, “Searching the‘web of things’,” in Proceedings of the 5th IEEE InternationalConference on Semantic Computing (ICSC ’11), pp. 308–315,IEEE, Palo Alto, Calif, USA, September 2011.

[40] Node.js, June 2015, https://nodejs.org/.[41] ReactPHP, June 2015, http://reactphp.org/.[42] A Full-stack PHP Framework Delivered as a C-extension,

Phalcon PHP, June 2015, https://phalconphp.com/.[43] Scala, “The Scala Programming Language,” June 2015, http://

www.scala-lang.org.[44] The Computer Language Benchmarks Game, 2015, http://

benchmarksgame.alioth.debian.org.[45] M. Odersky, P. Altherr, V. Cremet et al., “An overview of the

Scala programming language,” Tech. Rep. LAMP-REPORT-2004-006, 2004.

[46] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Inter-net of things: vision, applications and research challenges,” AdHoc Networks, vol. 10, no. 7, pp. 1497–1516, 2012.

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation http://www.hindawi.com

Journal ofEngineeringVolume 2014

Submit your manuscripts athttp://www.hindawi.com

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawi Publishing Corporation http://www.hindawi.com

Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014

SensorsJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks


Documents

Research Article High Performance Web of Things ...downloads.hindawi.com/journals/ijdsn/2015/347413.pdf · Research Article High Performance Web of Things Architecture for the Smart