sensors

Article A Web Service Protocol Realizing Interoperable Internet of Things Tasking Capability

Chih-Yuan Huang 1,* and Cheng-Hung Wu 2

1 Center for Space and Remote Sensing Research, National Central University, Taoyuan 320, Taiwan 2 Department of Civil Engineering, National Central University, Taoyuan 320, Taiwan; [email protected] * Correspondence: [email protected]; Tel.: +886-3-422-7151 (ext. 57692)

Academic Editors: Mihai Lazarescu and Luciano Lavagno Received: 8 June 2016; Accepted: 26 August 2016; Published: 31 August 2016

Abstract: The Internet of Things (IoT) is an infrastructure that interconnects uniquely-identifiable devices using the Internet. By interconnecting everyday appliances, various monitoring, and physical mashup applications can be constructed to improve human’s daily life. In general, IoT devices provide two main capabilities: sensing and tasking capabilities. While the sensing capability is similar to the World-Wide Sensor Web, this research focuses on the tasking capability. However, currently, IoT devices created by different manufacturers follow different proprietary protocols and are locked in many closed ecosystems. This heterogeneity issue impedes the interconnection between IoT devices and damages the potential of the IoT. To address this issue, this research aims at proposing an interoperable solution called tasking capability description that allows users to control different IoT devices using a uniform web service interface. This paper demonstrates the contribution of the proposed solution by interconnecting different IoT devices for different applications. In addition, the proposed solution is integrated with the OGC SensorThings API standard, which is a Web service standard defined for the IoT sensing capability. Consequently, the Extended SensorThings API can realize both IoT sensing and tasking capabilities in an integrated and interoperable manner.

Keywords: Internet of Things; tasking capability; interoperability; OGC SensorThings API

1. Introduction

1.1. Background The Internet of Things (IoT) is an infrastructure that interconnects uniquely-identifiable devices using the Internet. While the IoT is attracting attention from various fields, it is not a brand new concept. From the early stage of the 20th century, similar concepts were proposed, and some related communication technologies like the radio, barcodes, the Internet and radio frequency identification (RFID) were also invented [1,2]. At the early stage of the IoT, the main focus of IoT was to identify and track every physical thing, and many applications such as warehouse management and logistics applications applied RFID technology to prove the concept [1,3]. With the advances of communication and sensor technologies in recent years, the definition and scope of IoT have been extended. For instance, the International Telecommunication Union (ITU) defined the IoT as “a global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies [4]”. ITU shows that every physical thing can have a virtual identity in the information world. Through those virtual identities, every thing can interconnect and communicate with each other.

Sensors 2016, 16, 1395; doi:10.3390/s16091395 www.mdpi.com/journal/sensors Sensors 2016, 16, 1395 2 of 23

With the extended definition and scope, the IoT is no longer confined to object identification applications. Everyday appliances, such as TVs, ovens, heaters, lamps, door locks, could be connected to the Internet via different local communication technologies (e.g., Bluetooth and Zigbee, WiFi). By connecting devices to the Internet, users and applications can access device capabilities in a remote and real-time manner. Hence, the vision of the IoT started to attract the attention of various domains and applications. For example, Gubbi et al. [5] mentioned that IoT applications have four main categories: (1) Personal and Home; (2) Enterprise; (3) Utilities; and (4) Mobile. Atzori et al. [2] think that the IoT can be applied in: (1) Transportation and Logistics; (2) Healthcare; (3) Smart environment (home, office, plant); (4) Personal and social. Meanwhile, many predictions estimated that the number of IoT devices would reach 20 billion to 50 billion by 2020 (http://www.gartner.com/newsroom/id/3165317). As we can see from these predictions and envisioned applications, the IoT is one of the most popular developments in recent years. In general, the IoT has two main capabilities, which are sensing and tasking capabilities:

(1). Sensing capabilityThe sensing capability monitors devices’ statuses or the environmental properties of their surroundings. Users can remotely capture the properties for data analysis and application. People can use different sensors to collect not only the environmental properties like temperature, humidity, and location information, but also the status of devices such as “On” or “Off”. While sensors can monitor various properties, sensor owners or users can remotely access the sensor observations through the Internet. For example, users can understand if a device is “On”, or the battery status of each device. In general, the sensing capability allows users to remotely monitor device statuses and various properties, and consequently, users can utilize the sensor observations to support automatic and efficient applications. (2). Tasking capabilityThe tasking capability allows other devices or users to actuate devices via the Internet so the users can easily control the devices to execute feasible tasks remotely. For example, existing IoT products such as Philips Hue and Belkin WeMo provide tasking capabilities. The Philips Hue allows users to remotely turn on or off light bulbs as well as adjust brightness and saturation via the Internet. The Belkin WeMo is a smart switch. Users can connect their traditional appliances to the WeMo and remotely turn on or off these appliances by controlling the WeMo. Overall, while the sensing capability allows users to continuously monitor the statuses of devices and the environmental properties, the tasking capability can help users to make adjustments accordingly by controlling devices remotely.

In general, mashing-up the sensing and tasking capabilities of different IoT devices enables users to create various automatic and efficient applications. These kinds of applications are called “physical mashup” applications [6]. For instance, an application can use the GPS sensor in a mobile phone to monitor a user location. When the application senses that the user is heading back home, the application can automatically turn on air conditioners or heaters. In this case, the house will be at a comfortable temperature when the user arrives home. As a result, to facilitate the mashups of IoT capabilities, one of the key requirements is to provide a uniform interface for users or applications to access the capabilities in an interoperable manner.

1.2. The IoT Architecture To further define the scope of this research, here we introduce the IoT architecture. As shown in Figure1, there are four layers in the architecture which are Device Layer, Gateway Layer, Web service Layer and Application Layer [2]. The Device Layer contains the devices connecting to the Internet, such as appliances and smart sensors. With the ability to connect to the Internet, devices can upload sensor observations to a web service or be controlled by users via the Internet. However, devices can be divided into two types. The first type of device has enough computation resource to directly connect to the Internet. The second type of device is the device that is too resource-constrained to directly connect to the Internet by itself. Sensors 2016, 16, 1395 3 of 23 Sensors 2016, 16, 1395 3 of 23

FigureFigure 1.1. Architecture ofof InternetInternet ofof Things.Things.

Therefore, an additional layer called the Gateway Layer is required to serve as an intermediate Therefore, an additional layer called the Gateway Layer is required to serve as an intermediate layer to connect the resource-constrained devices on one end and connect to the Internet on the other layer to connect the resource-constrained devices on one end and connect to the Internet on the other end [7]. Usually, gateways act as a translator converting the device protocol to the web service end [7]. Usually, gateways act as a translator converting the device protocol to the web service protocol protocol and vice versa. After connecting to the gateways, the resource-constrained devices will be and vice versa. After connecting to the gateways, the resource-constrained devices will be able to able to connect to the Web Service Layer. connect to the Web Service Layer. The Web Service Layer contains services that may receive data from gateways or directly from The Web Service Layer contains services that may receive data from gateways or directly from devices. Different services may provide different functionalities, such as data processing, data devices. Different services may provide different functionalities, such as data processing, data storing, storing, data management and query. Finally, the Application Layer is where applications retrieve data management and query. Finally, the Application Layer is where applications retrieve the resources the resources from the Web services and usually provide graphical user interfaces for users to from the Web services and usually provide graphical user interfaces for users to operate and consume operate and consume the IoT data. the IoT data. In order to achieve an interoperable IoT infrastructure, standards are necessary for the In order to achieve an interoperable IoT infrastructure, standards are necessary for the communications communications between layers. When two layers follow the same standard, they can communicate between layers. When two layers follow the same standard, they can communicate and understand and understand each other based on the defined data model and protocol. In this case, the IoT can each other based on the defined data model and protocol. In this case, the IoT can achieve achieve interoperability [2,5]. With the increasing amount of Internet of Things devices, different interoperability [2,5]. With the increasing amount of Internet of Things devices, different and various and various IoT devices would cause heterogeneity issues. These heterogeneity issues could be IoT devices would cause heterogeneity issues. These heterogeneity issues could be solved by following solved by following certain standards to achieve the IoT interoperability [5,8]. certain standards to achieve the IoT interoperability [5,8]. In principle, two layers following the same standard can communicate with each other. While In principle, two layers following the same standard can communicate with each other. there have been some open standards proposed to support communication in the Gateway and While there have been some open standards proposed to support communication in the Gateway Device layers, e.g., Bluetooth Low Energy, Zigbee, 6LoWPAN, and WIFI, we argue that a and Device layers, e.g., Bluetooth Low Energy, Zigbee, 6LoWPAN, and WIFI, we argue that a comprehensive IoT Web service standard is currently missing. Hence, this research mainly focuses comprehensive IoT Web service standard is currently missing. Hence, this research mainly focuses on the communication between the Web Service layer and Internet-connected devices (including the on the communication between the Web Service layer and Internet-connected devices (including the resource-constrained devices connected to gateways). resource-constrained devices connected to gateways).

1.3.1.3. Problems andand ObjectivesObjectives WhileWhile thethe IoTIoT isis attractingattracting muchmuch attention,attention, companiescompanies are definingdefining differentdifferent proprietaryproprietary webweb serviceservice protocols,protocols, andand onlyonly theirtheir ownown IoTIoT devicesdevices supportsupport thosethose protocols.protocols. EitherEither withwith thethe intentionintention oror without, these these companies companies construct construct closed closed ecosys ecosystems,tems, which which we we call call the the IoT IoT silos. silos. Each Each silo may silo mayhave haveits complete its complete IoT IoTarchitecture architecture and and components components including including devices, devices, gateways, gateways, services, andand applications.applications. However,However, thethe components components in in one one silo silo cannot cannot connect connect to theto the components components in another in another silo assilo they as supportthey support different different communication communication protocols. protocols. For example, For example, users usually users usually need to need use specific to use softwarespecific software or applications or applications provided provided by different by di companiesfferent companies to access to different access different IoT devices, IoT devices, such as thesuch Philips as the Hue Philips or the Hue Belkin or the WeMo Belkin Switch, WeMo as Switch, these devices as these use devices different use communication different communication protocols. Hence,protocols. the IoTHence, is currently the IoT suffering is currently from a lacksufferi ofng interoperability from a lack and of facesinteroperability heterogeneity and problem. faces Thisheterogeneity heterogeneity problem. problem This seriously heterogeneity damages proble them development seriously damages of the IoT the as development users and applications of the IoT cannotas users communicate and applications with everycannot IoT communicate devices in a with uniform every way IoT [5 ,devices8]. Moreover, in a uniform the heterogeneity way [5,8]. problemMoreover, impedes the heterogeneity the design of aproblem unifying frameworkimpedes the and design the communication of a unifying protocol framework [9]. As and a result, the sincecommunication IoT devices protocol cannot be [9]. easily As connected,a result, since extra IoT costs devices are required cannot tobe achieve easily automaticconnected, and extra efficient costs physicalare required mashup to achieve applications. automatic and efficient physical mashup applications. We identify two main approaches to address this IoT heterogeneity issue. The first one is the hub approach. The hub approach mainly focuses on developing different connectors to

Sensors 2016, 16, 1395 4 of 23

We identify two main approaches to address this IoT heterogeneity issue. The first one is the hub approach. The hub approach mainly focuses on developing different connectors to communicate with different IoT devices and provides users/applications a uniform interface, such as the Apple HomeKit, Alphabet (Google) Nest ecosystem and If-This-Then-That (IFTTT). The connectors could be in the Gateway Layer, Web Service Layer, or Application Layer. However, as the devices or services in different IoT silos support different protocols, the hub approach needs to implement every kind of connector to communicate with all the IoT silos, which would result in a large development cost. The other approach is the open standard approach, which is usually the best approach to ultimately address heterogeneity issues [5,8]. There have also been some IoT standards proposed to address the IoT heterogeneity issue. Among which, the SensorThings API v1 standard [10] defined by the Open Geospatial Consortium (OGC). SensorThings API defines comprehensive query functionalities based on the OGC Observation & Measurements data model standard [11]. The SensorThings API provides a uniform service interface to host the virtual identities of IoT devices as well as the generated sensor observations. However, the IoT tasking capability is not supported by the first version of the SensorThings API, which means users/applications still cannot send requests to IoT devices with a uniform interface. Therefore, to fill the gap, the goal of this study is to propose a potential solution to realize the IoT tasking capability in an interoperable manner. While a naïve solution is to define an IoT device protocol for manufacturers to follow, from a previous study experience, we can understand that manufacturers prefer having the flexibility to define their proprietary protocols instead of following a defined standard [12]. Therefore, we choose to define a web service protocol and a description data model to communicate with different IoT devices. Overall, this study has three main objectives:

(1). Firstly, this research aims at defining a common and uniform description document standard that can describe the communication protocols of IoT devices. This description allows the web service layer to automatically understand the device protocols. Currently, we only focus on HTTP protocols. (2). Secondly, we propose a web service protocol that can automatically translate between users’ tasking requests and device protocol requests. Therefore, users/applications can use a uniform interface to control different IoT devices even if the devices follow different proprietary protocols. (3). Thirdly, this research aims at integrating the proposed solution with the OGC SensorThings API, which supports the IoT sensing capability [10]. The integrated web service protocol is named the Extended SensorThings API. In this case, the Extended SensorThings API could be the solution that manages the virtual identities of IoT devices and supports both IoT sensing and tasking capabilities in an interoperable manner.

In the next section, this paper reviews the existing solutions for solving the heterogeneity problem and then indicates the limitations of these solutions. In Section3, we first introduce the overall architecture of the Extended SensorThings API, as well as define the scope of this research, and then explain the proposed solution. In Section4, we apply the proposed solution on some existing IoT products and demonstrate the contributions by constructing some applications. Finally, this paper concludes in Section5.

2. Related Work Interoperability of IoT implementations is a critical issue to be solved to realize the IoT vision. After reviewing the existing approaches addressing this issue, we categorize them into two approaches, which are the hub approach and the open standard approach. The hub approach is an intuitive and common solution to solve the heterogeneity problem. A hub could connect with different IoT products by developing connectors following different communication protocols. Hubs could be in Gateway Layer, Web Service Layer, or Application Layer. Through the hubs, users can communicate with different IoT products. The hub approach can be effective, and many Sensors 2016, 16, 1395 5 of 23 industrial companies have applied this approach to interconnect IoT devices, such as the Apple HomeKit, Alphabet (Google) Nest ecosystem and IFTTT. The key of these hubs is to develop connectors to support different IoT device communication protocols. For example, IFTTT is a web platform supporting many connectors for various IoT products. Users can use IFTTT “recipes” to connect their IoT devices and online services (e.g., email, calendar) to realize automatic applications. However, although the hub approach is effective, connectors specifically developed for different IoT products is necessary. As the number of IoT products increases rapidly, the cost of developing every possible connector get higher. Therefore, we believe that the hub approach is not the ultimate solution for the IoT heterogeneity issue. On the other hand, the open standard approach defines standards to address the heterogeneity problem. In principle, with open standards, manufacturers and users can follow the same data model and communication protocol to create devices, gateways, web services and applications that can automatically understand each other. There have been some efforts defining IoT standards. For example, the HyperCat is a standard proposed by Flexeye and other companies [13]. HyperCat provides a hypermedia catalogue standard to index and shares IoT resources (e.g., products and data) online [13]. As a catalogue service standard, HyperCat mainly focuses on the resource discovery functionalities and the heterogeneity problem of connecting IoT devices is not the focus. In addition, the OpenIoT and OM2M (https://wiki. eclipse.org/OM2M/one) standards both define web service protocols to manage IoT products and data [14]. However, these two standards still need to build different connectors to communicate with different IoT devices. Furthermore, the OGC Sensor Web Enablement (SWE) standards such as the Sensor Observation Service (SOS) [15] and Sensor Planning Service (SPS) [16] are also relevant. The SOS focuses on the sensing capability and defines service interfaces to help users to share sensor observations and sensor metadata. The SPS focuses on the tasking capability and defines service interfaces to help users control their sensors. However, as the SPS and aforementioned standards mainly defines web service interfaces, connectors should be implemented to control devices. Therefore, similar to the hub approach, these existing standards still cannot solve the heterogeneity problem of connecting IoT devices. Although the intuitive approach to connect IoT devices is to define a uniform device communication protocol, previous experience tells us that manufacturers prefer having the flexibility to define their proprietary protocols instead of following a defined standard [12]. Therefore, we need a solution that allows users to communicate with IoT devices with a uniform interface while manufacturers can design their device protocols. In order to achieve this objective, we first consider the interaction between IoT devices and users. The interaction between users and IoT devices is similar to the interaction between client and server, in which, an IoT device can be regarded as a server that receives requests from clients. In tradition, before a client sends a request, the server needs a way to advertise its protocol. A web service description is a document describing the functionalities and communication protocols of the service [17]. With the web service description, a client could automatically understand how to communicate with the service. There have been some existing web service descriptions such as the Web Service Descriptions Language (WSDL) [17] and the HTML Microformat for Describing RESTful Web Services (hRESTS) [18]. WSDL is an XML-based service description standard, and it defines not only the functionalities and protocols of services but also the format and schema of data. In recent years, while RESTful web services become popular and the WSDL is not suitable to describe RESTful web services, Kopecky et al. [18] proposed the hRESTS based on XHTML format to describe RESTful service protocols. However, even with hRESTS, users still need to develop connectors to communicate with different IoT devices [19]. A similar work to our proposed solution is the Sensor Interface Descriptor (SID), which is a declarative model based on the OGC Sensor Model Language (Sensor ML) standard for describing device capabilities [20]. As shown in Figure2, the SID describes sensor metadata, sensor commands Sensors 2016, 16, 1395 6 of 23 and device protocols. With a SID Interpreter, a data acquisition system can retrieve data from sensors Sensors 2016, 16, 1395 6 of 23 and communicate with the SOS and SPS services [20]. SID provides a uniform interface for SWE standardssensors. In and terms establishes of the tasking the connection capability, between although the SID SWE seems web serviceable to standardsdescribe device and the protocols sensors. Inwith terms the ofOSI the model tasking (Open capability, Systems although Interconnection SID seems model), able to clear describe description device protocolsand examples with theof how OSI modelto automatically (Open Systems compose Interconnection device requests model), based clear on description SID seems and to examples be missing of howfrom to the automatically references compose[20]. In addition, device requests while SID based presents on SID a seemscomple tote bebut missing complicated from thedata references model and [20 ].verbose In addition, XML whileschema, SID to presents understand a complete and adapt but complicatedthe SID may data be co modelstly for and IoT verbose device XML manufacturers. schema, to understand Therefore, andthis adaptresearch the proposes SID may an be costlyalternative for IoT solution device that manufacturers. uses a relatively Therefore, simple this data research model proposes to describe an alternativeIoT device protocols. solution that uses a relatively simple data model to describe IoT device protocols.

Figure 2. The architecture of SID [[20].20].

In general, we argue that the existing solution solutionss cannot fully fully address address the the IoT IoT heterogeneity heterogeneity issue. issue. This research focuses on developingdeveloping a uniformuniform serviceservice description for the IoTIoT taskingtasking capabilitiescapabilities that is flexibleflexible enoughenough toto describedescribe differentdifferent HTTPHTTP protocolsprotocols forfor controllingcontrolling IoTIoT devices.devices. Also,Also, whilewhile most of the existing service description solutions are based on the XML format, the documents are usually largelarge inin size size [21 [21]] and and not not suitable suitable for resource-constrainedfor resource-constrained IoT devices. IoT devices. Hence, Hence, the web the service web descriptionservice description this research this research proposes proposes is based onis base the JSONd on the format. JSON Overall, format. byOver describingall, by describing device protocols device inprotocols a uniform in manner,a uniform a web manner, service cana web be constructedservice can to be connect constructed automatically to connect to different automatically IoT devices, to anddifferent consequently, IoT devices, users and can consequently, control different users devices can control using a different single service devices protocol. using a single service protocol. 3. Methodology 3. MethodologyThis study aims to define an interoperable solution for the IoT tasking capability. The proposed solutionThis hasstudy two aims main to parts.define Firstly,an interoperable we define soluti a JSON-basedon for the IoT web tasking service capability. description The to proposed describe devicesolution tasking has two capabilities main parts. including Firstly, the we metadata define a andJSON-based communication web service protocols. description Secondly, to fordescribe users todevice remotely tasking connect capabilities with different including IoT the devices metadata with and a uniform communication interface, weprotocols. propose Secondly, a web service for users that canto remotely understand connect the proposed with different service IoT description devices wi andth automaticallya uniform interface, transform we users’propose tasks a web into service device requests.that can understand We also specifically the proposed design service the web descriptio servicen as and an automatically extension of the transform OGC SensorThings users’ tasks APIinto baseddevice onrequests. the idea thatWe thealso Extended specifically SensorThings design the API web could service provide as access an extension to both IoT of sensing the OGC and taskingSensorThings capabilities. API based In this on section, the idea we that first the introduce Extended the SensorThings overall workflow API ofcould the proposedprovide access solution to andboth theIoT connection sensing and with tasking the SensorThings capabilities. In API. this Then section, we presentwe first theintroduce details ofthe the overall proposed workflow tasking of capabilitythe proposed service solution description. and the Finally,connection we explainwith the the SensorThings proposed solution API. Then with we an present example. the details of the proposed tasking capability service description. Finally, we explain the proposed solution with an example.

SensorsSensors 20162016,, 1616,, 13951395 7 of 23

3.1. The Overall Workflow of the Extended SensorThings API 3.1. The Overall Workflow of the Extended SensorThings API To propose a complete and interoperable solution for the IoT, this study integrates the proposedTo propose solution a complete with the andOGC interoperable SensorThings solution API [10]. for theThe IoT, OGC this SensorThings study integrates API the provides proposed an solutionopen and with flexible the OGC web SensorThings service protocol API [to10 ].host The “things” OGC SensorThings and manage API observations provides an [10]. open This and flexiblestandard web is based service on protocol the JSON to host format “things” and mainly and manage follows observations the OGC Observation [10]. This standard and Measurement is based on the(OGC JSON O&M) format model and as mainly the sensor follows observation the OGC model Observation (Figure and 3) [11]. Measurement In general, (OGCthe first O&M) and current model asversion the sensor of the observation SensorThings model API (Figureis mainly3)[ designed11]. In general, for the theIoT firstsensing and capability current version and did of thenot SensorThingsinclude the tasking API is mainlycapability. designed Therefore, for the to IoT provide sensing a capabilitycomplete andIoT didweb not service, include this the research tasking capability.proposes an Therefore, interoperable to provide solution a complete as an extens IoT webion service, to the thisSensorThings research proposes API, where an interoperable the general solutionoperations as an(e.g., extension the Create, to the Read, SensorThings Update, and API, Dele wherete of the entities) general directly operations follow (e.g., the the SensorThings Create, Read, Update,API standard. and Delete For the of entities) remainder directly of this follow paper, the SensorThingsthis extended APIservice standard. is referred For the to remainderas Extended of thisSensorThings paper, this API. extended service is referred to as Extended SensorThings API.

Figure 3. The data model of the OGC SensorThings API [[10].10].

While the details of the proposed tasking capability data model are presented in Section 3.2, While the details of the proposed tasking capability data model are presented in Section 3.2, here here we use an example to explain the conceptual model of the Extended SensorThings API. As we use an example to explain the conceptual model of the Extended SensorThings API. As shown in shown in Figure 4, regarding the sensing capability, a “room” can be regarded as a Thing, and the Figure4, regarding the sensing capability, a “room” can be regarded as a Thing, and the Location records Location records the position information of the room. In this room, a “thermometer” is modeled as the position information of the room. In this room, a “thermometer” is modeled as the Sensor measuring the Sensor measuring “air temperature” (i.e., ObservedProperty) of the room (i.e., FeatureOfInterest) “air temperature” (i.e., ObservedProperty) of the room (i.e., FeatureOfInterest) with the UnitOfMeasurement with the UnitOfMeasurement “degree Celsius”. In this example, the sensor performs an Observation at “degree Celsius”. In this example, the sensor performs an Observation at PhenomenonTime 9 May 2016 PhenomenonTime 9 May 2016 23:20 and receives a Result of 29. This information is modeled as a 23:20 and receives a Result of 29. This information is modeled as a Datastream of the Thing. Datastream of the Thing. Regarding the tasking capability, this room has a “smart air conditioner” which could be described Regarding the tasking capability, this room has a “smart air conditioner” which could be as an Actuator, which provides an ability for users to turn it on or off via HTTP requests. This ability is described as an Actuator, which provides an ability for users to turn it on or off via HTTP requests. modeled as a TaskingCapability of the room (i.e., Thing) as an ability to adjust the temperature of the This ability is modeled as a TaskingCapability of the room (i.e., Thing) as an ability to adjust the room. This TaskingCapability describes the acceptable parameters in Parameters and uses HTTPProtocol temperature of the room. This TaskingCapability describes the acceptable parameters in Parameters to record the device protocol template. With this information, users can create a Task to remotely and uses HTTPProtocol to record the device protocol template. With this information, users can control this TaskingCapability via the Internet. For example, to cool down the room, a user can set an create a Task to remotely control this TaskingCapability via the Internet. For example, to cool down the Input true Task room,with a user the can parameter set an Input “on” with as the inparameter a . “on” as true in a Task.

Sensors 2016, 16, 1395 8 of 23 Sensors 2016, 16, 1395 8 of 23

FigureFigure 4.4. AnAn exampleexample ofof thethe ExtendedExtended SensorThingsSensorThings API.API.

OneOne thing to note is is that that similar similar to to the the Sensor SensorThingsThings API API data data model, model, users/providers users/providers have have the theflexibility flexibility to model to model their theirscenario. scenario. For example, For example, a user could a user also could model also the model air conditioner the air conditioner as a Thing asinstead a Thing ofinstead an Actuator of an Actuator providingproviding TaskingCapabilityTaskingCapability for thefor theroom. room. This This decision decision is is left left forfor users/applicationsusers/applications toto decide.decide. InIn general, general, the the Extended Extended SensorThings SensorThings API API can can handle handle both both sensing sensing and taskingand tasking capabilities capabilities so that so users that canusers access can completeaccess complete IoT capabilities IoT capabilities in a single in servicea single and service integrate and theintegrate capabilities the capabilities for different for applications. different applications For example,. For an example, environment an environment control application control canapplication retrieve temperaturecan retrieve readingstemperature from Extendedreadings SensorThingsfrom Extended API SensorThings periodically. WhenAPI theperiodically. temperature When exceeds the predefinedtemperature maximum exceeds or predefined minimum thresholds, maximum the or application minimum will thresholds, automatically the turn application on or off the will air conditionerautomatically by turn creating on or a offTask theentity. air conditioner by creating a Task entity. AfterAfter introducingintroducing thethe overalloverall high-levelhigh-level modelmodel ofof ExtendedExtended SensorThingsSensorThings API,API, oneone ofof thethe mainmain objectivesobjectives ofof thisthis studystudy isis toto designdesign anan IoTIoT taskingtasking capabilitycapability solutionsolution soso thatthat usersusers cancan controlcontrol IoTIoT devicesdevices withwith a uniforma uniform interface interface while while allowing allowing manufacturers manufacturers to define to proprietary define proprietary device protocols. device Beforeprotocols. presenting Before presenting the details, the we details, first describe we firs thet describe key ideas the and key the ideas overall and workflow:the overall workflow: (1). Describe the IoT device tasking capability: To connect IoT devices while allowing (1). manufacturersDescribe the IoT to device define tasking differ capability:ent protocols, To connect this study IoT devices proposes while a allowing uniform manufacturers web service descriptionto define different format protocols,(presented thisin Section study proposes3.2). By following a uniform the web service service description, description users format or (presentedmanufacturers in Section can first 3.2 ).write By following documents the to service describe description, the tasking users capabilities or manufacturers of IoT candevices, first writewhich documents include the to templates describe theof device tasking protocols. capabilities of IoT devices, which include the templates (2). Registerof device the protocols. IoT tasking capability to an Extended SensorThings API service: After preparing (2). theRegister tasking the capability IoT tasking description, capability users, to an Extendedmanufacturers SensorThings or devices API themselves service: Aftercan register preparing the descriptionsthe tasking capability to a web description,service following users, the manufacturers Extended SensorThings or devices themselves API. The web can registerservice thecan thendescriptions automatically to a web understand service following the device the protocols Extended of different SensorThings IoT devices. API. The web service can (3). Retrievethen automatically the tasking understand capability thefrom device the Extended protocols ofSensorThings different IoT API devices. service: Before users or (3). applicationsRetrieve the control tasking the capability IoT devices, from they the Extendedcan retrieve SensorThings the available APItasking service: capabilities Before from users the or Extendedapplications SensorThings control the IoT API devices, to understand they can retrieve the theallowed available input tasking parameters. capabilities While from thethe SensorThingsExtended SensorThings API provides API toa simple understand and RESTful the allowed interface input for parameters. the user to While retrieve the resources, SensorThings the APIExtended provides SensorThings a simple and API RESTful follows interface the same for procedure. the user to Based retrieve on resources, the information the Extended in the taskingSensorThings capability API followsdocument the sameusers procedure.retrieved, users Based can on thecreate information valid task in entities the tasking (presented capability in Section 3.2) for controlling different tasking capabilities. (4). Control IoT devices via the Extended SensorThings API service: Finally, users create task entities in the Extended SensorThings API service. The Extended SensorThings API will parse

Sensors 2016, 16, 1395 9 of 23

document users retrieved, users can create valid task entities (presented in Section 3.2) for Sensorscontrolling 2016, 16, 1395 different tasking capabilities. 9 of 23 (4). Control IoT devices via the Extended SensorThings API service: Finally, users create task entities thein theinput Extended parameters SensorThings and values, API retrieve service. the co Therresponding Extended tasking SensorThings capability API description will parse from the theinput database, parameters and andautomatically values, retrieve compose the correspondinga device request tasking based capability on the protocol description template from thein thedatabase, tasking and capability automatically description. compose Finally, a device the requestservice basedsends onthe therequest protocol to control template the in IoT the devices.tasking capability description. Finally, the service sends the request to control the IoT devices.

3.2.3.2. The The Data Data Model Model of of the the Tasking Tasking Capability Description AsAs we mentionedmentioned earlier,earlier, IoT IoT devices devices and and products products are are similar similar to web to web services, services, which which should should have havedocuments documents to advertise to advertise their capabilities their capabilities and communication and communication protocols. protocols. While XML While format XML may format not maybe suitable not be forsuitable resource-constraint for resource-constraint IoT devices, IoT devi thisces, research this research tries to proposetries to propose a JSON-based a JSON-based tasking taskingcapability capability document document standard, standard, which is which called “taskingis called capability“tasking capability description”. description”. In general, In the general, tasking thecapability tasking description capability description is a JSON-based is a JSON-based description description that mainly that describes mainly thedescribes IoT tasking the IoT capability tasking capabilityincluding theincluding communication the communication protocols and protocols metadata an ofd IoTmetadata devices. of FigureIoT devices.5 shows Figure the data 5 shows model the of datathe tasking model capability. of the tasking To connect capability. the proposed To conne taskingct capabilitythe proposed with thetasking SensorThings capability API, with we canthe SensorThingssimply connect API, the weThing canentity simply from connect the SensorThings the Thing entity API with from the theTaskingCapability SensorThings APIentity, with which the TaskingCapabilityrepresents the controllable entity, which ability represents of the Thing the controllable. ability of the Thing.

FigureFigure 5. 5. TheThe data data model model of of tasking tasking capability. capability.

While the main purpose of the tasking capability description is to describe the protocol of IoT While the main purpose of the tasking capability description is to describe the protocol of IoT devices, a TaskingCapability entity uses the HTTPProtocol and zero-to-many Parameter entities to devices, a TaskingCapability entity uses the HTTPProtocol and zero-to-many Parameter entities to describe describe the protocol. The HTTPProtocol presents the template of the device request, which includes the protocol. The HTTPProtocol presents the template of the device request, which includes every every component of an HTTP request. The Parameter records not only the description of Parameter component of an HTTP request. The Parameter records not only the description of Parameter but also but also the Definition, which defines the data type, unit of measurement, and AllowedValues so that the Definition, which defines the data type, unit of measurement, and AllowedValues so that users can users can understand the feasibly allowed values to the specific Parameter. In this research, we understand the feasibly allowed values to the specific Parameter. In this research, we mainly focus on mainly focus on the HTTP-based protocol as most IoT devices are connected to the web. Tasks are the the HTTP-based protocol as most IoT devices are connected to the web. Tasks are the entities users send entities users send to the service to control IoT devices, which contain users’ input values in the to the service to control IoT devices, which contain users’ input values in the Inputs. In Section 3.2.1, Inputs. In Section 3.2.1, this paper introduces the details of each class. this paper introduces the details of each class. For addressing the heterogeneity issue the IoT devices facing, the proposed tasking capability data model should be able to describe possible IoT device protocols. In this section, we introduce the details of each defined class.

Sensors 2016, 16, 1395 10 of 23

For addressing the heterogeneity issue the IoT devices facing, the proposed tasking capability data model should be able to describe possible IoT device protocols. In this section, we introduce the details of each defined class.

3.2.1. TaskingCapability This research designs the TaskingCapability to be the controllable ability of a Thing. For example, a Thing can be an Internet smart light bulb, a smart lock or a smart plug. A smart light bulb could have tasking capabilities that can change its color, brightness, and saturation. In terms of the TaskingCapability class in the data model, TaskingCapability provides a uniform way to describe these controllable abilities of Thing so that users can understand the controllable abilities of the Thing. Moreover, one Thing can have multiple TaskingCapabilities to describe different controllable abilities. Table1 shows that Tasking Capability only has one Description property to explain what this TaskingCapability is. The detailed information of the TaskingCapability is shown in the linked Parameter, HTTPProtocol, and Actuator entities.

Table 1. Properties of the TaskingCapability.

Name Definition Data Type Multiplicity and Use A human-readable description Description CharacterString One (Mandatory) for the Tasking Capability

3.2.2. Actuator The Actuator is used to describe the specific actuator of a TaskingCapability. For example, an Internet camera (as a Thing) may have a motor actuator, which can support two tasking capabilities. One is for the pan and tilt movement. Another is for the zoom in and zoom out. So an Actuator may link to multiple TaskingCapabilities. As shown in Table2, Actuator has three properties. Description helps users understand the actuator. Metadata describes the detail of this actuator, which is usually based on a structured format. EncodingType presents the DataType of the Metadata. With the EncodingType, manufacturers can describe the Metadata of their IoT products in a standard format, e.g., the OGC SensorML, or in any data types such as plain-text, XML, and JSON.

Table 2. Properties of the Actuator.

Name Definition Data Type Multiplicity and Use A human-readable description Description CharacterString One (Mandatory) for the Actuator ValueCode (e.g., for SensorML, EncodingType Data type of the metadata One (Mandatory) application/xml, application/json) Metadata A metadata of the actuator Any One (Mandatory)

3.2.3. Parameter The Parameter mainly has four properties (Table3) for describing all of the acceptable parameters of the TaskingCapability. ParameterID shows the unique identification of an allowed parameter. Description can be used to describe the meaning of the parameter so that user could understand the use of it. Use is used to identify whether the parameter is “Optional” or “Mandatory”. CorrespondingTemplate records the corresponding portion of the template in the HTTPProtocol of a specific optional parameter. CorrespondingTemplate helps remove the unrequired portion from the template when composing a device request (details presented in Section 3.3). Also, the Parameter has a set of properties to describe the details, including the Definition, AllowedValues, Value and Range shown in Tables4–7, respectively. Sensors 2016, 16, 1395 11 of 23

Table 3. Properties of the Parameter.

Name Definition Data Type Multiplicity and Use The unique identification for ParameterID CharacterString One (Mandatory) an allowed parameter A human-readable description Description CharacterString One (Mandatory) for the Parameter The necessity of the “Mandatory” or Use One (Mandatory) ParameterID “Optional” The corresponding portion of CorrespondingTemplate template in the HTTPProtocol CharacterString Zero to one (Optional) of an optional ParameterID

Table 4. Properties of the Definition.

Name Definition Data Type Multiplicity and Use The data type of the “String”, “Double”, InputType One (Mandatory) input value “Boolean”, “Integer” Unit of measurement UnitOfMeasurement JSON_Object One (Mandatory) of the input value

Table 5. Properties of the AllowedValues.

Name Definition Data Type Multiplicity and Use An acceptable value for Zero to many (at least one Value or Value Value the Parameter one Range is required) An acceptable value Zero to many (at least one Value or Range Range range for the Parameter one Range is required)

Table 6. Properties of the Value.

Name Definition Data Type Multiplicity and Use Value An acceptable value for the Parameter Any One (Mandatory) Description A human-readable description of the Value CharacterString One (Mandatory)

Table 7. Properties of the Range.

Name Definition Data Type Multiplicity and Use Min The minimum value of a range Double or Integer One (Mandatory) Max The maximum value of a range Double or Integer One (Mandatory) Description A human-readable description of the Range CharacterString One (Mandatory)

One Parameter has one Definition that is used to describe the input data type and unit of measurement. Then one Definition may have multiple AllowedValues because a Parameter can have more than one acceptable value. For example, a smart light bulb may have a parameter “status”, and the allowed value of the “status” could be “On” or “Off”. Moreover, each allowed value should have one Description to describe the meanings of allowed values. Also, while allowed values could be in a specific range, our proposed solution defines the Range class for this scenario. Range records Max, Min. For example, because the brightness of the smart light bulb may have a range (e.g., from 1 to 254), the Range can represent the maximum and minimum values of the brightness. In general, through these properties, the acceptable parameters of a TaskingCapability can be modeled completely. Sensors 2016, 16, 1395 12 of 23

3.2.4. HTTPProtocol In order to automatically communicate with different IoT devices, this research designs a class to describe possible communication protocols of IoT devices. In this study, we mainly focus on HTTP-based protocol [22]. While manufacturers could design device protocols in different ways, such as using different HTTP methods (e.g., GET, POST, PUT, DELETE) and putting input values in the URL, in HTTP headers, or in message body, in order to describe every possible protocol, we design the HTTPProtocol as a request template according to the device communication protocol. In the template, we use the ParameterIDs in the Parameters as placeholders to indicate the location that input values should be. By simply replacing the placeholders in the template with input values, the Extended SensorThings API can automatically compose a request. We call this process “keyword replacement” and further explain it in Section 3.3. Therefore, to accommodate any possible device protocol, the HTTPProtocol contains properties for describing the common HTTP request components [22] as shown in Table8.

Table 8. Properties of the HTTPProtocol.

Multiplicity Name Definition Data Type and Use One HTTPMethod The HTTP method of the device HTTP request HTTP Method (Mandatory) One AbsoluteResourcePath Absolute resource path of the device HTTP request URL (Mandatory) ValueCode (e.g., for The data type for the MessageBody, which can be Zero to one MessageBodyDataType application/xml, used to verify the content in the MessageBody (Optional) application/json) Zero to one MessageBody The MessageBody of the device HTTP request CharacterString (Optional) Zero to one QueryString The QueryString of the device HTTP request CharacterString (Optional) Zero to many Headers The Headers of the device HTTP request CharacterString (Optional) Zero to one Fragment The Fragment of the device HTTP request CharacterString (Optional) Authentication information for accessing the Zero to one Authentication Authentication IoT device (Optional)

In addition, while the privacy and security requirements are critical for some IoT applications, some IoT products/services require users to provide authentication information (e.g., username and password) when connecting to IoT devices. Therefore, the proposed HTTPProtocol and web service implementation can describe and support authentication standards such as the HTTP Basic Authentication and Digest Authentication [23]. Users can first register their authentication information with the Authentication properties shown in Table9, and then the web service will automatically apply the specified authentication standard when sending device requests.

Table 9. Properties of the Authentication.

Name Definition Data Type MultIPLICITY and Use Value code (e.g., for HTTP Type Type of HTTP authentication One (Mandatory) Basic, HTTP Digest) Account User accounts for accessing IoT devices CharacterString One (Mandatory) Password Password for accessing IoT devices CharacterString One (Mandatory) Sensors 2016, 16, 1395 13 of 23

Through the above four classes in the tasking capability data model, the data model can completely describe the IoT device communication protocol. However, for users to control IoT devices in a uniform manner while following the general SensorThings API operation, this study designs the Task class as an entity type in the Extended SensorThings API.

3.2.5. Task While users can create entities in a general SensorThings API service by sending HTTP POST requests, we design our system so that users can send tasks by simply creating Task entities in an Extended SensorThings API service. In this case, users can control IoT devices in a uniform way. To be specific, the Task contains properties for a user to identify the TaskingCapability he/she wants to control, the time point for executing the Task (i.e., Time), and the input values for the Task (i.e., Inputs). For each Input, users should specify a ParameterID and a Value so that the Extended SensorThings API can use the ParameterID to find the placeholder in the HTTPProtocol template and replace the placeholder with the input Value. In addition, users can follow the SensorThings API Read operation to retrieve the created Task entities and find out their statuses (i.e., Status) and Responses from devices. The following Tables 10 and 11 present the properties of Task and Input, respectively.

Table 10. Properties of the Task.

Multiplicity Name Definition Data Type and Use Time for executing the task. If the Time is not Zero to one Time ISO 8601 Time String specified, the request will be sent immediately. (Optional) The task status automatically changed by One Status CharacterString the service (Mandatory) ValueCode (e.g., for Zero to one ResponseDataType The data type of the response from device application/xml, (Optional) application/json) Zero to one Response The response message from device Any (Optional)

Table 11. Properties of the Input.

Name Definition Data Type Multiplicity and Use The unique identification ParameterID CharacterString One (Mandatory) of the Parameter Any (but limited by the Parameter’s Value User’s input value One (Mandatory) Definition and AllowedValue)

3.3. Keyword Replacement To support any possible protocols that IoT devices could use, this study proposes an approach called “keyword replacement”. When users or manufacturers create a tasking capability description, the HTTPProtocol entity mainly presents the request template of device protocol. In the HTTPProtocol properties, manufacturers can place “keywords” at the locations where users’ input value should be. Then by simply replace the keywords with the Values in a Task, the service can automatically compose a device request. The designed style of the keyword is simple, which is using curly brackets (i.e., “{” and “}”) to encompass a ParameterID. For example, if a ParameterID is “On”, its keyword is “{On}”. We expect this approach could accommodate the heterogeneities in IoT device protocols and provide a uniform web service interface for users to access the IoT tasking capability. Here we use an example to explain the keyword replacement process, for a scenario that a user owns a smart light bulb, he/she registered the tasking capability of the light bulb (Figure6) to an Sensors 2016, 16, 1395 14 of 23

Sensors 2016, 16, 1395 14 of 23 Here we use an example to explain the keyword replacement process, for a scenario that a user owns a smart light bulb, he/she registered the tasking capability of the light bulb (Figure 6) to an ExtendedExtended SensorThings SensorThings API API service. service. When When this this user user sends sends a aTask Taskwith with the theInputs Inputs shownshown inin FigureFigure7 7aa to turnto turn on the on lightthe light bulb, bulb, the the service service will will first first parse parse the the Inputs. Inputs. The service will will find find the the ParameterID ParameterID “on”“on” and and “bri” “bri” with with Value Valuetrue trueand and 255, 255, respectively. respectively. Then Then the the service service composes composes keywords keywords “{on}” “{on}” and “{bri}”and “{bri}” to find to the find placeholders the placeholders in the inHTTPProtocol the HTTPProtocoltemplate. template. In this In case,this case, the service the service will will use use the Valuethe trueValueand true 255 toand replace 255 to thereplace “{on}” the and “{on}” “{bri}” and in“{bri}” the MessageBody. in the MessageBody. As a result, As a result, the final the device final device request request is shown in Figure 7c. is shown in Figure7c. In addition, while some Parameters are optional, and the HTTPProtocol records a complete In addition, while some Parameters are optional, and the HTTPProtocol records a complete template, template, the portion for those optional parameters should be removed from the final request if the portion for those optional parameters should be removed from the final request if unrequired. unrequired. For example, when users only want to turn off the light bulb by specifying the For example, when users only want to turn off the light bulb by specifying the ParameterID “on” and ParameterID “on” and Value false in the Task as shown in Figure 7b, the portion of the template for ValueParameterIDfalse in the “bri”Task isas not shown required in Figure in this7b, case the. portion Hence, ofwe the design template the CorrespondingTemplate for ParameterID “bri” is in not requiredParameter in thisshown case. in Figure Hence, 6 weto specify design the the corresponding CorrespondingTemplate portion of the in templateParameter in HTTPProtocolshown in Figure. In 6 tothis specify case, the when corresponding the service is portion composing of the a device template request, in HTTPProtocol Figure 7d shows. In this the case, service when removes the service the is composingCorrespondingTemplates a device request, of optional Figure7 dParameters shows the that service are not removes required the CorrespondingTemplatesand composes a device ofrequest. optional Finally,Parameters if a requestthat are has not a requiredMessageBody, and composes the service a will device use request. the MessageBodyDataType Finally, if a request to has a MessageBody,verify and fix simple the service formatting will use issues the MessageBodyDataTypein the MessageBody, such to as verify removing and fix necessary simple formattingcommas issuesfrom in a JSON the MessageBody, String. As a result such, the as service removing can necessaryautomatically commas compose from a complete a JSON String.HTTP request As a result for , thecontrolling service can an automatically IoT device. compose a complete HTTP request for controlling an IoT device.

{ “Thing”: {“_link”: “/Thing”}, “Description”: “This capability description can control a smart light bulb”, “Parameters”: [ {“ParameterID”: “on”, “Description”: “This parameter is used to turn on or off the smart light bulb”, “Use”: “Mandatory”, “Definition”: { “InputType”: “Boolean”, “UnitOfMeasurement”: “Status”, “AllowedValues”: [{“Value”: true, “Description”: “turn on”},{“Value”: false, “Description”: “turn off”}]}}, {“ParameterID”: “bri”,”Description”: “This parameter is used to adjust brightness of the smart light bulb”, “Use”: “Optional”,”CorrespondingTemplate”: “,\”bri\”: {bri}”, “Definition”: { “InputType”: “Integer”,”UnitOfMeasurement”: “brightness degrees”, “AllowedValues”: [{“Max”: 254, “Min”: 1, “Description”: “This is a scale from the minimum brightness the light is capable of, 1, to the maximum capable brightness, 254.” }]}} ], “HTTPProtocols”: { “HTTPMethod”: “PUT”, “AbsoluteResourcePath”: “http://example.com/lightbulb1”, “MessageDataType”: “application/json”, “MessageBody”: “{\”on\”: {on},\”bri\”: {bri}}” }, “Actuator”: {“_link”: “/Actuator”} }

Figure 6. An example of a tasking capability description for a smart light bulb. Figure 6. An example of a tasking capability description for a smart light bulb.

The above example shows the case of having input values in the MessageBody. However, with the defined tasking capability description and the keyword replacement procedure, input values can be automatically placed in other HTTP components (i.e., resource path, querystring, headers, or fragment). Users or manufacturers only need to put the placeholder in the correct place in the template, and the service can automatically locate the placeholders and compose a complete HTTP request. This solution is intuitive and simple enough to accommodate various device protocols and could consequently realize the interoperability of IoT tasking capability. Sensors 2016, 16, 1395 15 of 23

{ { “TaskingCapability”: {“ID”: 3}, “TaskingCapability”: {“ID”: 3}, “Input”: [ “Input”: [ {“ParameterID”: “bri”,”Value”: 255}, {“ParameterID”: “on”,”Value”: false} {“ParameterID”: “on”,”Value”: true} ], ], “Status”: “Waiting to be sent”, Sensors 2016, 16, 1395 15 of 23 “Status”: “Waiting to be sent”, Sensors 2016, 16, 1395 “Time”: “2016-02-26T15:42:00+0800” 15 of 23 “Time”: “2016-02-26T15:40:00+0800” } { } { “TaskingCapability”:(a) {“ID”: 3}, (b) HTTP PUT http://example.com/lightbulb1 HTTP “TaskingCapability”:PUT http://example.com/lightbulb1 {“ID”: 3}, “Input”: [ MessageBody MessageBody “Input”: [ {“ParameterID”: “bri”,”Value”: 255}, {“on”: true, “bri”: 255} {{“ParameterID”:“on”: false} “on”,”Value”: false} {“ParameterID”:( c“on”) ,”Value”: true} (d) ], ], Figure 7. (a) A Task with two input parameters; (b) A Task “Status”:with one “Waitinginput parameters; to be sent” (c), The device request “Status”: corresponds “Waiting toto bethe sent” two-input-parameters, Task; (d) The device request corresponds to the “Time”: “2016-02-26T15:42:00+0800” one-input-parameter Task. “Time”: “2016-02-26T15:40:00+0800” } } The above example shows the case of having input values in the MessageBody. However, with (a) (b) the definedHTTP PUT tasking http://example.com/lightbulb1 capability description and the keywordHTTP replacement PUT http://example.com/lightbulb1 procedure, input values can be automatically placed in other HTTP components (i.e., resource path, querystring, headers, or MessageBody MessageBody fragment). Users or manufacturers only need to put the placeholder in the correct place in the {“on”: true, “bri”: 255} {“on”: false} template, and the service can automatically locate the placeholders and compose a complete HTTP (c) (d) request. This solution is intuitive and simple enough to accommodate various device protocols and couldFigure consequentlyFigure 7. (a)A 7. (Taska )realize A withTask withthe two interoperability inputtwo input parameters; parameters; of (b IoT)A ( bTasktasking) A withTask capability. with one input one input parameters; parameters; (c) The (c) deviceThe device requestrequest corresponds corresponds to the to two-input-parametersthe two-input-parametersTask ;(Taskd); The (d) deviceThe device request request corresponds corresponds to the to the 4. Resultsone-input-parameterone-input-parameter Task. Task. The main focus of this study is to propose a uniform service description for describing 4. ResultsThe above example shows the case of having input values in the MessageBody. However, with heterogeneousthe defined IoT tasking device capability protocols description and design and a web the keywordservice interface replacement for users procedure, to control input different values can IoT devicesbeThe automatically main following focus aplaced of single this inprotocol. study other is HTTP To to demonstrate propose components a uniform the (i.e.,contribution resource service of descriptionpath, this study,querystring,for we describingfirst headers, apply or theheterogeneous proposedfragment). tasking IoTUsers device capabilityor manufacturers protocols description and designonly on needthree a web existingto serviceput the IoT interface placeholder devices, for which users in theare to controlthecorrect Philips differentplace Hue, in the BelkinIoT devicestemplate, WeMo following Switch,and the and aservice single a Panasonic can protocol. automatically IP To camera. demonstrate locate Secondly, the the placeholders contributionwe use the Extended and of this compose study, SensorThings wea complete first apply API HTTP tothe create proposedrequest. two This taskingphysical solution capability mashup is intuitive descriptionapplications and simple on to three demonstrate enough existing to accommodate IoT the devices, potential which various usage are ofdevice the the Philips proposedprotocols Hue, and solution.Belkincould WeMo consequently Switch, and realize a Panasonic the interoperability IP camera. Secondly, of IoT tasking we use capability. the Extended SensorThings API to create two physical mashup applications to demonstrate the potential usage of the proposed solution. 4.1. The4. Results Tasking Capability Descriptions for Existing IoT Products 4.1. The Tasking Capability Descriptions for Existing IoT Products As shownThe main in Figure focus 8,of the this Philips study Hue is to is proposea smart devicea uniform that servicecan be remotelydescription controlled for describing to changeheterogeneousAs the shown colors, in Figure brightness,IoT device8, the Philips protocolsand saturation Hue and is a design smart of light devicea web bulbs. thatservice While can interface be the remotely Philips for controlledusers Hue to is control one to change of different the popularthe colors,IoT devicesIoT brightness, devices, following users and a saturation singleneed toprotocol. use of lighttheir To bulbs. applicdemonstrate Whileations the orthe Philipsfollow contribution Huetheir isproprietary of one this of study, the popularprotocol we first IoT to apply controldevices,the theproposed users device. need tasking If to our use proposed capability their applications tasking description capability or follow on three description their existing proprietary canIoT describedevices, protocol thewhich to service control are the protocol the Philips device. to Hue, controlIf ourBelkin proposed Hue WeMo light tasking Switch,bulbs, capability users and a can Panasonic description control IPthem camera. can wi describeth Secondly, the same the service we protocol use protocol the as Extended other to control describable SensorThings Hue light IoT API devices.bulbs,to userscreate can two control physical them mashup with the applications same protocol to asdemonstrate other describable the potential IoT devices. usage of the proposed solution.

4.1. The Tasking Capability Descriptions for Existing IoT Products As shown in Figure 8, the Philips Hue is a smart device that can be remotely controlled to change the colors, brightness, and saturation of light bulbs. While the Philips Hue is one of the popular IoT devices, users need to use their applications or follow their proprietary protocol to

control the device. If our proposed tasking capability description can describe the service protocol to control Hue light bulbs, users canFigure control 8. The them Philips wi thHue. the same protocol as other describable IoT devices. Therefore, based on the Application Programming Interface (API) of Hue (http://www. developers.meethue.com/), we create the Hue tasking capability description as shown in Figure9. A TaskingCapability of Hue links to a Thing, which could be a lamp. Description shows users that this tasking capability can be used to control Hue. Parameters record the acceptable parameters and feasible values so that users can know how to control Hue through the Extended SensorThings API. As shown in Figure9, “on” can be used to turn on or off the Hue, “bri” is for adjusting the brightness,

Figure 8. The Philips Hue.

Sensors 2016, 16, 1395 16 of 23

Therefore, based on the Application Programming Interface (API) of Hue (http://www.developers.meethue.com/), we create the Hue tasking capability description as shown in Figure 9. A TaskingCapability of Hue links to a Thing, which could be a lamp. Description shows

Sensorsusers2016 that, 16 ,this 1395 tasking capability can be used to control Hue. Parameters record the acceptable16 of 23 parameters and feasible values so that users can know how to control Hue through the Extended SensorThings API. As shown in Figure 9, “on” can be used to turn on or off the Hue, “bri” is for “hue”adjusting helps the users brightness, change “hue” the color helps of users Hue andchange “sat” the can color be of used Hue to and adjust “sat” the can saturation be used to of adjust Hue. Thethe AllowedValuessaturation of Hue. can The be represented AllowedValues with canRange be and/orrepresentedValue with. Range and/or Value.

{ “Thing”: {“_link”: “/Thing”}, “Description”: “This capability description can control Philips Hue”, “Parameters”: [ {“ParameterID”: “on”,”Description”: “This parameter is used to turn on or off Philips Hue”,”Use”: “Mandatory”, “Definition”: { “InputType”: “Boolean”,”UnitOfMeasurement”: “Status”, “AllowedValues”: [ {“Value”: true, “Description”: “turn on”},{“Value”: false, “Description”: “turn off”}]}}, {“ParameterID”: “bri”,”Description”: “This parameter is used to adjust brightness of the Philips Hue”,”Use”: “Optional”,”CorrespondingTemplate”: “\”bri\”: {bri},”, “Definition”: { “InputType”: “Integer”,”UnitOfMeasurement”: “brightness degrees”, “AllowedValues”: [ {“Max”: 254, “Min”: 1, “Description”: “This is a scale from the minimum brightness the light is capable of, 1, to the maximum capable brightness, 254.” }]}}, {“ParameterID”: “hue”,”Description”: “This parameter is used to change the color of the Philips Hue”,”Use”: “Optional”,”CorrespondingTemplate”: “\”hue\”: {hue}”, “Definition”: { “InputType”: “Integer”,”UnitOfMeasurement”: “color”, “AllowedValues”: [ {“Max”: 65535, “Min”: 0, “Description”: “This is a wrapping value between 0 and 65535. Both 0 and 65535 are red, 25500 is green and 46920 is blue.” }]}}, {“ParameterID”: “sat”,”Description”: “This parameter is used to adjust the saturation of the Philips Hue”,”Use”: “Optional”,”CorrespondingTemplate”: “\”sat\”: {sat},”, “Definition”: { “InputType”: “Integer”,”UnitOfMeasurement”: “Saturation”, “AllowedValues”: [ {“Max”: 254, “Min”: 0, “Description”: “254 is the most saturated (colored) and 0 is the least saturated (white).” }]}} ], “HTTPProtocol”: { “HTTPMethod”: “PUT”, “AbsoluteResourcePath”: “http://example.com/api20a43e54177bba0f3bf9687c59cbb77/lights/2/state”, “MessageDataType”: “application/json”, “MessageBody”: “{\”on\”: {on},\”bri\”: {bri},\”sat\”: {sat},\”hue\”: {hue}}” }, “Actuator”: {“_link”: “/Actuator”} }

Figure 9. The tasking capability description of Philips Hue. Figure 9. The tasking capability description of Philips Hue.

In order to describe the communication protocols of different IoT devices, HTTPProtocol can recordIn order the toHTTP describe protocol. the communication According protocolsto Figure of different9, Hue IoTaccepts devices, theHTTPProtocol HTTP PUTcan requests. record theAbsoluteResourcePath HTTP protocol. According records to Figurethe web9, Hueservice accepts entry the to HTTPcontrol PUT this requests. Philips Hue, AbsoluteResourcePath and MessageBody recordsrecords the the web template service that entry will tobe controlused to thiscompose Philips device Hue, requests. and MessageBody As mentioned records in Section the template 3.3, this thatresearch will bedesigns used tothe compose keyword device “{ParameterID}” requests. As as mentionedthe placeholder, in Section such as3.3 the, this {on}, research {bri}, {sat}, designs and the keyword “{ParameterID}” as the placeholder, such as the {on}, {bri}, {sat}, and {hue}, which will TaskingCapability links to an Actuator be replaced with users’ input values. Finally, the that enables this capability. Sensors 2016, 16, 1395 17 of 23 Sensors 2016, 16, 1395 17 of 23 {hue}, which will be replaced with users’ input values. Finally, the TaskingCapability links to an ActuatorSensors that 2016 ,enables 16, 1395 this capability. 17 of 23 As shown in Figure 10, the Belkin WeMo InsightSwitch is a smart plug connecting to the Internet {hue},As shown which inwill Figure be replaced 10, the with Belkin users’ WeMo input InsightSwitch values. Finally, is thea smartTaskingCapability plug connecting links to toan the via WIFI. Users can connect some appliances like a dehumidifier and further remotely control this InternetActuator via thatWIFI. enables Users this can capability. connect some appliances like a dehumidifier and further remotely smartcontrol plug thisAs tosmartshown turn plug on/offin Figure to turn those 10, on/off connectedthe Belkin those appliances.WeMoconnected InsightSwitch appliances. is a smart plug connecting to the Internet via WIFI. Users can connect some appliances like a dehumidifier and further remotely control this smart plug to turn on/off those connected appliances.

Figure 10. The Belkin WeMo InsightSwitch. Figure 10. The Belkin WeMo InsightSwitch. As shown in Figure 11, this description explains the Belkin WeMo InsightSwitch tasking As shown in Figure 11, this description explains the Belkin WeMo InsightSwitch tasking capability. capability. According to the WeMo InsightSwitch API, there is only one acceptable parameter called AccordingAs to shown the WeMo in Figure InsightSwitch 11, this description API, there isex onlyplains one the acceptable Belkin WeMo parameter InsightSwitch called “BinaryState”, tasking “BinaryState”,capability. According which allows to the users WeMo to InsightSwitch turn on or offAP I,this there WeMo is only smart one acceptable plug. Figure parameter 11 shows called that which allows users to turn on or off this WeMo smart plug. Figure 11 shows that value “1” and value“BinaryState”, “1” and value which “0” allows stand usersfor “turn to turn on” on and or off“turn this off”,WeMo respectively. smart plug. FromFigure the 11 showsHTTPProtocol that , value “0” stand for “turn on” and “turn off”, respectively. From the HTTPProtocol, the Extended the Extendedvalue “1” andSensorThings value “0” stand API canfor “turn understand on” and the “turn components off”, respectively. for composing From the aHTTPProtocol device request., SensorThings API can understand the components for composing a device request. For example, For example,the Extended the SensorThingsWeMo InsightSwitch API can understandrequires some the informationcomponents forin HTTPcomposing headers. a device In addition, request. the the WeMo InsightSwitch requires some information in HTTP headers. In addition, the MessageBody MessageBodyFor example, stores the WeMo the template InsightSwitch of the requiresXML docu somement information for device in requests,HTTP headers. where In the addition, {BinaryState} the stores the template of the XML document for device requests, where the {BinaryState} is the keyword is theMessageBody keyword placeholder stores the template for users’ of inputthe XML values. docu ment for device requests, where the {BinaryState} placeholderis the keyword for users’ placeholder input values. for users’ input values. { “Thing”:{ {“/link”: “/Thing”}, “Thing”: {“/link”: “/Thing”}, “Description”: “The Belkin WeMo InsightSwitch is a smart plug that can help user turn on/off remotely “, “Description”: “The Belkin WeMo InsightSwitch is a smart plug that can help user turn on/off remotely “, “Parameters”: “Parameters”: [ [ { “ParameterID”: {“ParameterID”: “BinaryState” “BinaryState”,”Description”:,”Description”: “This“This parameterparameter isis usedused to toturn turn on onor oroff offthe the WeMo”WeMo”,”Use”:,”Use”: “Mandatory” “Mandatory”, , “Definition”: “Definition”: { { “InputType”: “InputType”: “Integer” “Integer”,”UnitOfMeasurement”:,”UnitOfMeasurement”: “Status”, , “AllowedValues”: “AllowedValues”: [ [ { “Value”: {“Value”: 1, “Description”:1, “Description”: “Value “Value 1 1 isis usedused to turnturn WeMo WeMo on” on”},} , { “Value”: {“Value”: 0, “Description”:0, “Description”: “Value “Value 0 0 isis usedused to turnturn WeMo WeMo off” off”}]}}}]}} ], ], “HTTPProtocol”: “HTTPProtocol”: [ [ { { “HTTPMethod”: “POST”, “HTTPMethod”: “Headers”: [ “POST”, “Headers”: {“Key”: [ “Content-Type”,”Value”: “text/xml; charset=\”utf-8\”“}, { “Key”: {“Key”: “Content-Type” “Accept”,”Value”:,”Value”: ““}, “text/xml; charset=\”utf-8\”“}, { “Key”: {“Key”: “Accept” “SOAPACTION”,”Value”: ““,”Value”:}, “\”urn:Belkin:service:basicevent:1#SetBinaryState\”“} { “Key”:], “SOAPACTION”,”Value”: “\”urn:Belkin:service:basicevent:1#SetBinaryState\”“} ] , “AbsoluteResourcePath”: “http://example.com/upnp/control/basicevent1”, “AbsoluteResourcePath”: “MessageDataType”: “application/xml”, “http://example.com/upnp/control/basicevent1” , “MessageDataType”: “MessageBody”: “{BinaryState}“} xmlns:u=\”urn:Belkin:service:basicevent:1\”>{BinaryState}“ “Actuator”: {“/link”: “/Actuator”} } ], } “Actuator”: {“/link”: “/Actuator”} Figure 11. The tasking capability description of Belkin WeMo. } Figure 11. The tasking capability description of Belkin WeMo. Figure 11. The tasking capability description of Belkin WeMo. The third IoT product we examined is the Panasonic IP camera as shown in Figure 12. IP cameras are common IoT devices, which allow users to remotely monitor features of interest in real time via

Sensors 2016, 16, 1395 18 of 23

Sensors 2016, 16, 1395 18 of 23 SensorsThe 2016 third, 16, 1395IoT product we examined is the Panasonic IP camera as shown in Figure18 of12. 23 IP cameras are common IoT devices, which allow users to remotely monitor features of interest in real The third IoT product we examined is the Panasonic IP camera as shown in Figure 12. IP thetime Internet. via the Therefore,Internet. Therefore, the proposed the solutionproposed should solution also should support also IP camerasupport tasking IP camera capabilities. tasking cameras are common IoT devices, which allow users to remotely monitor features of interest in real Ascapabilities. shown in FigureAs shown 13, Descriptionin Figure 13, and Description Parameters and provide Parameters information provide for usersinformation to understand for users how to time via the Internet. Therefore, the proposed solution should also support IP camera tasking tounderstand task this IP how camera. to task While this the IP request camera. template While is th alsoe request recorded template in the HTTPProtocol is also recorded, but different in the capabilities. As shown in Figure 13, Description and Parameters provide information for users to from the previous two IoT products, the request is an HTTP GET request, and the parameters are HTTPProtocolunderstand , howbut differentto task thisfrom IP thecamera. previous While two th eIoT request products, template the requestis also recordedis an HTTP in the GET specifiedrequest,HTTPProtocol and in query the, parametersbut options different (i.e., are from the specified {pan} the previous and in query {tilt}). two options IoT products,(i.e., the {pan} the request and {tilt}). is an HTTP GET request, and the parameters are specified in query options (i.e., the {pan} and {tilt}).

Figure 12. The Panasonic IP camera Figure 12. The Panasonic IP camera Figure 12. The Panasonic IP camera { “Thing”:{ {“_link”: “/Thing”}, “Description”: “Thing”: {“_link”: “This “/Thing”tasking capability}, can help users control the Panasonic IP camera”, “Parameters”: “Description”: [ “This tasking capability can help users control the Panasonic IP camera”, {“Parameters”:“ParameterID”: [ “pan”,”Description”: “The pan is used on horizontal rotation”,”Use”: “Mandatory”, “Definition”:{“ParameterID”: { “pan”,”Description”: “The pan is used on horizontal rotation”,”Use”: “Mandatory”, “Definition”: { “InputType”: “Integer”,”UnitOfMeasurement”: “none”, “InputType”: “Integer”,”UnitOfMeasurement”: “none”, “AllowedValues”: [ “AllowedValues”: [ { “Max”:{“Max”: 5 ,5 “Min”:, “Min”: -5 -5, ,“Description”: “Description”: “Positive numbernumber meansmeans turn turn right right horizontally horizontally and and negative negative numbernumber means means turn turn left left horizontally.” horizontally.” }]}} }]}},, { “ParameterID”: {“ParameterID”: “tilt” “tilt”,”Description”:,”Description”: “The“The tilt is used onon verticalvertical rotation” rotation”,”Use”:,”Use”: “Mandatory” “Mandatory”, , “Definition”: “Definition”: { { “InputType”: “InputType”: “Integer” “Integer”,”UnitOfMeasurement”:,”UnitOfMeasurement”: “none”,, “AllowedValues”: “AllowedValues”: [ [ { “Max”:{“Max”: 4 ,4 “Min”:, “Min”: -4 -4, ,“Description”: “Description”: “Positive numbernumber means means vertical vertical decline decline and and negative negative number number meansmeans vertical vertical rise.” rise.” }]}} }]}} ] , ], “HTTPProtocol”: “HTTPProtocol”: { { “HTTPMethod”: “HTTPMethod”: “GET” “GET”, , “AbsoluteResourcePath”: “AbsoluteResourcePath”: “http://example.com/cgi-bin/camctrl” “http://example.com/cgi-bin/camctrl”, , “QueryString”: “QueryString”: “pan={pan}&tilt={tilt}” “pan={pan}&tilt={tilt}”,, “Authentication”: “Authentication”: { “Type”:{“Type”: “HTTP “HTTP Basic” Basic”,”Username”:,”Username”: “admin”“admin”,”Password”:,”Password”: “12345” “12345”} } } , }, “Actuator”: “Actuator”: {“_link”: {“_link”: “/Actuator” “/Actuator”}} } } Figure 13. The tasking capability description of Panasonic IP camera. FigureFigure 13.13. TheThe taskingtasking capabilitycapability descriptiondescription ofof PanasonicPanasonic IPIP camera.camera. In addition, the Panasonic IP camera supports authentication for privacy and security In addition, the Panasonic IP camera supports authentication for privacy and security purposes.In addition, In order the Panasonic to automatically IP camera compose supports devic authenticatione requests, the for authentication privacy and security standard purposes. type, purposes. In order to automatically compose device requests, the authentication standard type, In orderusername to automatically and password compose are specified device in requests,the HTTPProtocol the authentication as well. This standard use casetype, indicates username that our and passwordusernameproposed areand solution specified password can in record theare HTTPProtocolspecified variable devicein theas well.HTTPProtocolprotoc Thisols as use the caseas manufacturers well. indicates This use that of case ourIoT devicesproposedindicates wants. solutionthat our canproposed record solution variable can device record protocols variable as device the manufacturers protocols as ofthe IoT manufacturers devices wants. of IoT devices wants. 4.2. The Task for Controlling IoT Products 4.2.4.2. TheThe TaskTask forfor ControllingControlling IoTIoT ProductsProducts According to these tasking capability descriptions, users can understand every detail of differentAccordingAccording tasking toto these capabilitiesthese tasking tasking from capability capability different descriptions, IoTdescrip devicestions, users and users can know understand can how understand to everyuse those detail every acceptable of detail different of taskingdifferentparameters capabilities tasking to create capabilities from a Task different entity from IoT todifferent control devices theseIoT and devices knowdevices. how andSimilar to know use to thoseother how entities acceptableto use in those SensorThings parameters acceptable to createparametersAPI, a by Task creating to entity create tasking to a control Task capability entity these to devices. entities control in Similar thesean Extended devices. to other SensorThings entitiesSimilar into SensorThingsother API, entitiesusers can API,in get SensorThings bya unique creating taskingAPI, by capabilitycreating tasking entities capability in an Extended entities in SensorThings an Extended API,SensorThings users can API, get users a unique can get ID fora unique each

Sensors 2016, 16, 1395 19 of 23 Sensors 2016, 16, 1395 19 of 23

TaskingCapability. A user can use the TaskingCapability ID to specify which tasking capability of which ID for each TaskingCapability. A user can use the TaskingCapability ID to specify which tasking devices in the Task entity. capability of which devices in the Task entity. In order to control those IoT devices, users can send a Task to the Extended SensorThings API by In order to control those IoT devices, users can send a Task to the Extended SensorThings API setting the acceptable input values. Figure 14 shows an example of a Task entity for controlling a Philips by setting the acceptable input values. Figure 14 shows an example of a Task entity for controlling a Hue. As shown in Figure 14, TaskingCapabilitiy records those IDs for controlling the specific IoT devices. Philips Hue. As shown in Figure 14, TaskingCapabilitiy records those IDs for controlling the specific Input records the user’s command values. The example task sets “on” is true to turn on the Philips Hue, IoT devices. Input records the user’s command values. The example task sets “on” is true to turn on change the color to red by “hue”, set the high brightness to with “bri” and 250 and adjust the lower the Philips Hue, change the color to red by “hue”, set the high brightness to with “bri” and 250 and saturation by “sat”. The Time is the time that the user wants to control the IoT device. According to the adjust the lower saturation by “sat”. The Time is the time that the user wants to control the IoT example, at 26 February 2016 15:40, the Extended SensorThings API will send the device request to the device. According to the example, at 26 February 2016 15:40, the Extended SensorThings API will IoT devices. Status describes the status of this Task, while the Task is sent successfully, status would send the device request to the IoT devices. Status describes the status of this Task, while the Task is tell us “Task is sent successfully”. sent successfully, status would tell us “Task is sent successfully”.

{ “TaskingCapability”:{“ID”:3}, “Input”:[ {“ParameterID”:”bri”,”Value”:250}, {“ParameterID”:”on”,”Value”:true}, {“ParameterID”:”hue”,”Value”:2000}, {“ParameterID”:”sat”,”Value”:100} ], “Status”:”Task is sent successfully.”, “Time”:”2016-02-26T15:40:00+0800”, “ResponseDataType”:”application/json”, “Response”: “[ {\”success\”: {\”/lights/2/state/on\”: true}}, {\”success\”: {\”/lights/2/state/hue\”: 2000}}, {\”success\”: {\”/lights/2/state/bri\”: 250}}, {\”success\”: {\”/lights/2/state/sat\”: 100}}]” }

Figure 14. A Task entity example for controlling Philips Hue. Figure 14. A Task entity example for controlling Philips Hue. When an Extended SensorThings API receives the Task entity, the Extended SensorThings API willWhen parse an Extended the task SensorThings to retrieve APIthe receivesexecutin theg time, Task entity,input theparameters Extended and SensorThings values, and API the willcorresponding parse the task toTaskingCapability retrieve the executing ID. Then time, the input Extended parameters SensorThings and values, API and will the compose corresponding a device TaskingCapabilityrequest by replacingID. Then keyword the Extended placeholders SensorThings in the API template will compose with user’s a device input request values. by replacing Finally, the keywordExtended placeholders SensorThings in the API template service with sends user’s the device input values.request Finally,at the specified the Extended time. While SensorThings IoT devices APIreceive service the sends device the requests, device request some atIoT the devices specified would time. return While responses IoT devices to the receive service. the In device this case, requests,optional some properties IoT devices ResponseDataType would return responses and Response to the record service. the In data this type case, of optionalresponse properties and response ResponseDataTypeitself, respectively. and Users Response can retrieve record this the datainformation type of responsefrom the Task and responseentity. itself, respectively. Users can retrieve this information from the Task entity. 4.3. Physical Mashup Applications 4.3. Physical Mashup Applications The previous section shows that the proposed tasking capability description can describe The previous section shows that the proposed tasking capability description can describe different different IoT device protocols. In order to further demonstrate that the Extended SensorThings API IoT device protocols. In order to further demonstrate that the Extended SensorThings API can handle can handle both IoT sensing and tasking capabilities, this study implements two physical mashup both IoT sensing and tasking capabilities, this study implements two physical mashup examples examples based on the Extended SensorThings API. To capture sensor observations, this study based on the Extended SensorThings API. To capture sensor observations, this study connects the connects the open-sourced Arduino microcontroller with sensors and communication modules. open-sourced Arduino microcontroller with sensors and communication modules. According to the According to the SensorThings API standard, Arduino sensor nodes can send observations of SensorThings API standard, Arduino sensor nodes can send observations of different environmental different environmental properties to an Extended SensorThings API service. properties to an Extended SensorThings API service. In general, Figure 15 shows the high-level IoT architecture using the Extended SensorThings In general, Figure 15 shows the high-level IoT architecture using the Extended SensorThings API. API. While IoT devices have sensors and actuators, the Extended SensorThings API has While IoT devices have sensors and actuators, the Extended SensorThings API has corresponding corresponding sensing and tasking capabilities to support them. Sensors can continuously upload sensing and tasking capabilities to support them. Sensors can continuously upload observations to a observations to a service, and actuators and their tasking capabilities can be registered to a service. In this case, users or physical mashup applications can retrieve observations from different sensors

Sensors 2016, 16, 1395 20 of 23

service,Sensors 2016 and, 16 actuators, 1395 and their tasking capabilities can be registered to a service. In this case, users20 of or23 Sensors 2016, 16, 1395 20 of 23 physical mashup applications can retrieve observations from different sensors and control different and control different actuators through a coherent web service protocol. This paper uses two simple andactuators control through different a coherent actuators web through service a protocol.coherent web This service paper uses protocol. two simple This paper use cases uses astwo examples simple use cases as examples to demonstrate the contributions of the Extended SensorThings API. useto demonstrate cases as examples the contributions to demonstrate of the the Extended contributions SensorThings of the Extended API. SensorThings API.

Figure 15. The high-level IoT architecture using the Extended SensorThings API. Figure 15. The high-level IoT architecture using the Extended SensorThings API. Figure 15. The high-level IoT architecture using the Extended SensorThings API. 4.3.1. Use Case 1—Automatic Dehumidifier 4.3.1. Use Case 1—Automatic Dehumidifier 4.3.1. Use Case 1—Automatic Dehumidifier People turn on dehumidifiers when they feel uncomfortable because of high relative humidity. People turn on dehumidifiers when they feel uncomfortable because of high relative humidity. In orderPeople to turn make on dehumidifiersthe process more when theyautomati feel uncomfortablec and efficient, because we can of highapply relative the Extended humidity. In order to make the process more automatic and efficient, we can apply the Extended InSensorThings order to make API the to process collect more relative automatic humidity and data efficient, from we a cansensor apply and the automatically Extended SensorThings control a SensorThings API to collect relative humidity data from a sensor and automatically control a APItraditional to collect dehumidifier relative humidity via the data WeMo from Switch a sensor when and automaticallythe humidity controlexceeds a traditionala predefined dehumidifier threshold. traditional dehumidifier via the WeMo Switch when the humidity exceeds a predefined threshold. viaAlthough the WeMo there Switch have whenbeen thesimila humidityr products exceeds integrating a predefined a humidity threshold. sensor Although in a dehumidifier, there have been we Although there have been similar products integrating a humidity sensor in a dehumidifier, we similarsimply productswant to demonstrate integrating a humiditythat without sensor buying in a dehumidifier,a more expensive we simply product, want similar to demonstrate functionality that simply want to demonstrate that without buying a more expensive product, similar functionality withoutcan be achieved buying a moreby simply expensive connecting product, sensing similar and functionality tasking capabilities can be achieved from by different simply connectingconnected can be achieved by simply connecting sensing and tasking capabilities from different connected sensingdevices. and tasking capabilities from different connected devices. devices. Figure 1616 shows shows the the prototype prototype of of an an automatic automatic dehumidifier. dehumidifier. For theFor sensingthe sensing capability, capability, this study this Figure 16 shows the prototype of an automatic dehumidifier. For the sensing capability, this usesstudy the uses DHT11 the DHT11 as the humidityas the humidity sensor tosensor measure to measure the relative the relative humidity humidity and connects and connects the DHT11 the study uses the DHT11 as the humidity sensor to measure the relative humidity and connects the withDHT11 Arduino with Arduino YUN to YUN upload to observationsupload observations to an Extended to an Extended SensorThings SensorThings API service API everyservice 30 every min. DHT11 with Arduino YUN to upload observations to an Extended SensorThings API service every From30 min. the From data modelthe data perspective, model perspective, we assigned we theassigned “room” the as “room” a Thing ,as the a DHT11Thing, the as theDHT11Sensor as, andthe 30 min. From the data model perspective, we assigned the “room” as a Thing, the DHT11 as the “relativeSensor, and air humidity”“relative air as humidity” the ObservedProperty as the ObservedProperty. Users and applications. Users and can applications then retrieve can the then time-series retrieve Sensor, and “relative air humidity” as the ObservedProperty. Users and applications can then retrieve Observationsthe time-seriesfrom Observations the service. from the service. the time-series Observations from the service.

Figure 16. The prototype of an automatic dehumidifier. FigureFigure 16. TheThe prototype prototype of of an automatic dehumidifier. dehumidifier. Regarding the tasking capability, we connected a traditional dehumidifier to the WeMo Switch. Regarding the tasking capability, we connected a traditional dehumidifier to the WeMo Switch. While the integrated system is considered as another Thing, the WeMo Switch is the Actuator, and While the integrated system is considered as another Thing, the WeMo Switch is the Actuator, and its TaskingCapability is similar to the example shown in Figure 11. By connecting the WeMo Switch its TaskingCapability is similar to the example shown in Figure 11. By connecting the WeMo Switch with the dehumidifier, users can remotely turn on/off the machine. with the dehumidifier, users can remotely turn on/off the machine.

Sensors 2016, 16, 1395 21 of 23

Regarding the tasking capability, we connected a traditional dehumidifier to the WeMo Switch. Thing Actuator WhileSensors 2016 the, integrated16, 1395 system is considered as another , the WeMo Switch is the , and21 of its23 TaskingCapability is similar to the example shown in Figure 11. By connecting the WeMo Switch with the dehumidifier,After registering users both can remotelythe sensor turn node on/off and the dehumidifier machine. to an Extended SensorThings API service,After an registering application both can the first sensor periodically node and retrie dehumidifierve humidity to an readings Extended from SensorThings the service. API When service, the anhumidity application exceeds can firstthe periodically predefined retrieve maximum humidity or minimum readings from thresholds, the service. the When application the humidity will exceedsautomatically the predefined turn on maximumor off the ordehu minimummidifier thresholds, by creating the a applicationcorresponding will automaticallyTask entity in turnthe onExtended or off theSensorThings dehumidifier API by service. creating a corresponding Task entity in the Extended SensorThings API service. 4.3.2. Use Case 2—A Smart Office Lighting System 4.3.2. Use Case 2—A Smart Office Lighting System In daily life, many office lighting systems consume unnecessary energy when no one is present, or peopleIn daily often life, forget many to office turn lighting off the systemslights when consume they unnecessaryleave the office. energy To whenaddress no this one issue, is present, this orstudy people implements often forget a tosimple turn offapplication the lights whenthat uses they an leave ultrasonic the office. distance To address sensor this issue,to monitor this study the implementsdistance changing a simple in a application hallway and that automatically uses an ultrasonic adjusts the distance Philips sensor Hue light to monitor bulbs, theas shown distance in changingFigure 17. in a hallway and automatically adjusts the Philips Hue light bulbs, as shown in Figure 17.

Figure 17. The prototype of a smart office light system. Figure 17. The prototype of a smart office light system.

This study deploys an ultrasonic distance sensor on the wall and connects the sensor to an ArduinoThis YUN. study The deploys sensor an ultrasonicproduces measurements distance sensor at on a thehigh wall frequency and connects (i.e., five the readings sensor to per an Arduinosecond). Once YUN. the The reading sensor produceschanges (e.g., measurements when some atone a high passes frequency by), the (i.e.,Arduino five readingsYUN will per upload second). an OnceObservation the reading entity changes to an Extended (e.g., when SensorThings someone passes API by), au thetomatically. Arduino YUNThen, will similar upload to antheObservation previous entityapplication, to an Extendedan application SensorThings can periodically API automatically. retrieve readings Then, from similar the to service the previous and automatically application, anturn application on/off the canPhilips periodically Hue light retrieve bulbs. readings from the service and automatically turn on/off the PhilipsIn Huegeneral, light this bulbs. study modeled the “office” as a Thing, the “ultrasonic distance sensor” as the SensorIn, general,and “distance” this study as the modeled ObservedProperty the “office”. Then as a Thing the Philips, the “ultrasonic Hue was distanceconsidered sensor” as another as the SensorThing and, and Actuator “distance”, whose as theTaskingCapabilityObservedProperty is similar. Then to the the PhilipsFigure 9. Hue was considered as another Thing and Actuator, whose TaskingCapability is similar to the Figure9. 5. Conclusions and Future Work 5. Conclusions and Future Work This paper proposes an interoperable solution for realizing the IoT tasking capability. While This paper proposes an interoperable solution for realizing the IoT tasking capability. While large large heterogeneities exist in the current IoT device communication protocols, to control different heterogeneities exist in the current IoT device communication protocols, to control different devices, devices, users/applications need to use or implement various customized connectors. To address this users/applications need to use or implement various customized connectors. To address this issue, issue, this research proposes a data model and JSON-based description of IoT tasking capability. this research proposes a data model and JSON-based description of IoT tasking capability. While the While the tasking capability can be used to describe the functionalities and communication protocols tasking capability can be used to describe the functionalities and communication protocols of IoT of IoT devices, we design and implement a web service that can understand the tasking capability devices, we design and implement a web service that can understand the tasking capability and and translate users’ input tasks into device requests. In this case, users can control heterogeneous translate users’ input tasks into device requests. In this case, users can control heterogeneous IoT IoT devices via a coherent web service interface. devices via a coherent web service interface. In addition, the proposed tasking capability was designed to integrate with the OGC SensorThings API to handle both IoT sensing and tasking capabilities in a single web service, which is called the Extended SensorThings API. To demonstrate the contribution of this study, we first applied the proposed tasking capability on three existing IoT products and successfully modeled their device protocols. Furthermore, this study implements two simple applications using the Extended SensorThings API. These applications retrieve sensor observations periodically from the

Sensors 2016, 16, 1395 22 of 23

In addition, the proposed tasking capability was designed to integrate with the OGC SensorThings API to handle both IoT sensing and tasking capabilities in a single web service, which is called the Extended SensorThings API. To demonstrate the contribution of this study, we first applied the proposed tasking capability on three existing IoT products and successfully modeled their device protocols. Furthermore, this study implements two simple applications using the Extended SensorThings API. These applications retrieve sensor observations periodically from the service and send tasks to control different IoT devices according to the observations. Overall, we believe that the proposed solution could address the heterogeneity problem of IoT devices, and consequently realize the Internet of Things vision. For future work, as this paper mainly focuses on the tasking capabilities served with HTTP, we will explore the feasibility of supporting different communication protocols such as Constrained Application Protocol (CoAP) and formerly MQ Telemetry Transport (MQTT). If those protocols can be described via the proposed tasking capability, the web service implementation could also be extended to support more possible IoT device protocols. Finally, as the proposed solution could be an extension to the OGC SensorThings API for handling the tasking capability, we plan to promote and introduce this solution to the OGC SensorThings API Standards Working Group.

Acknowledgments: We sincerely thank Ministry of Science and Technology in Taiwan for supporting and funding us to conduct this research. Author Contributions: Chih-Yuan Huang conceived the research direction; Chih-Yuan Huang and Cheng-Hung Wu designed the system; Cheng-Hung Wu develped and evaluated the system; Chih-Yuan Huang and Cheng-Hung Wu analyzed the result and wrote the paper. Conflicts of Interest: The authors declare no conflict of interest.

References

1. Weiser, M. The computer for the 21st century. Sci. Am. 1991, 265, 94–104. [CrossRef] 2. Atzori, L.; Iera, A.; Morabito, G. The Internet of Things: A survey. Comput. Netw. 2010, 54, 2787–2805. [CrossRef] 3. Ashton, K. That ‘Internet of Things’ thing. RFiD J. 2009, 22, 97–114. 4. ITU Telecommunication Standardization Sector. Overview of Internet of Things; ITU-T: Geneva, Switzerland, 2012. 5. Gubbi, J.; Buyya, R.; Marusic, S.; Palaniswami, M. Internet of Things (IOT): A vision, architectural elements, and future directions. Future Gener. Comput. Syst. 2013, 29, 1645–1660. [CrossRef] 6. Guinard, D.; Trifa, V.; Wilde, E. A resource oriented architecture for the web of things. In Proceedings of the Internet of Things (IOT), Tokyo, Japan, 29 November–1 December 2010; pp. 1–8. 7. Bormann, C.; Ersue, M.; Keranen, A. Terminology for Constrained-Node Networks; Internet Engineering Task Force (IETF), RFC: Vijfhuizen, Holland, 2014; Volume 7228. 8. Miorandi, D.; Sicari, S.; De Pellegrini, F.; Chlamtac, I. Internet of Things: Vision, applications and research challenges. Ad Hoc Netw. 2012, 10, 1497–1516. [CrossRef] 9. Zorzi, M.; Gluhak, A.; Lange, S.; Bassi, A. From today’s intranet of things to a future Internet of Things: A wireless-and mobility-related view. IEEE Wirel. Commun. 2010, 17, 44–51. [CrossRef] 10. Liang, S.; Huang, C.Y.; Khalafbeigi, T. OGC® SensorThings API; Open Geospatial Consortium: Wayland, MA, USA, 2016. 11. Cox, S. Observations and measurements. In Open Geospatial Consortium Best Practices Document; Open Geospatial Consortium: Wayland, MA, USA, 2006. 12. Bröring, A.; Maué, P.; Janowicz, K.; Nüst, D.; Malewski, C. Semantically-enabled sensor plug & play for the sensor web. Sensors 2011, 11, 7568–7605. [PubMed] 13. Lea, R. HyperCat: An IOT Interoperability Specification; 2013. Available online: http://eprints.lancs.ac.uk/ 69124/1/Interoperability_Action_Plan_1v1_spec_only.pdf (accessed on 30 August 2016). 14. Kim, J.; Lee, J.-W. Openiot: An open service framework for the Internet of Things. In Proceeedings of the IEEE World Forum on Internet of Things (WF-IOT), Seoul, Korea, 6–8 March 2014; pp. 89–93. Sensors 2016, 16, 1395 23 of 23

15. Bröring, A.; Stasch, C.; Echterhoff, J. OGC® Sensor Observation Service Interface Standard; Open Geospatial Consortium Interface Standard: Wayland, MA, USA, 2012. 16. Simonis, I.; Echterhoff, J. OGC® Sensor Planning Service Implementation Standard; Open Geospatial Consortium Interface Standard: Wayland, MA, USA, 2011. 17. Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S. Web Services Description Language (WSDL) 1.1; 2001. 18. Kopecky, J.; Gomadam, K.; Vitvar, T. Hrests: An html microformat for describing restful web services. In Proceedings of the IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT ’08), Sydney, Australia, 9–12 December 2008; pp. 619–625. 19. Mayer, S.; Guinard, D.; Trifa, V. Facilitating the integration and interaction of real-world services for the web of things. In Proceedings of Urban Internet of Things—Towards Programmable Real-Time Cities (UrbanIOT), Tokyo, Japan, 30 November–1 December, 2010. 20. Broering, A.; Below, S. Opengis® Sensor Interface Descriptors; Open Geospatial Consortium: Wayland, MA, USA, 2010. 21. Maeda, K. Performance evaluation of object serialization libraries in XML, JSON and binary formats. In Proceeedings of the Second International Conference on Digital Information and Communication Technology and it’s Applications (DICTAP), Bangkok, Thailand, 16–18 May 2012; pp. 177–182. 22. Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Masinter, L.; Leach, P.; Berners-Lee, T. Hypertext Transfer Protocol—http/1.1; RFC 2616; June 1999. Available online: https://www.rfc-editor.org/info/rfc2616 (accessed on 28 August 2016). 23. Franks, J.; Hallam-Baker, P.; Hostetler, J.; Lawrence, S.; Leach, P.; Luotonen, A.; Stewart, L. HTTP Authentication: Basic and Digest Access Authentication; RFC 2617; June 1999. Available online: https://tools.ietf.org/html/rfc2617 (accessed on 28 August 2016).

© 2016 by the authors; licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC-BY) license (http://creativecommons.org/licenses/by/4.0/).