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

sensors Article

A Web Service Protocol Realizing Interoperable Internet of Things Tasking Capability Chih-Yuan Huang 1, * and Cheng-Hung Wu 2 1 2

*

Center for Space and Remote Sensing Research, National Central University, Taoyuan 320, Taiwan 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 Figure 1, 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 Sensors 2016, 16, 1395

3 of 23 3 of 23

Figure 1. 1. Architecture Architecture of of Internet Internet of of Things. Things. Figure

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. Problems Problems and and Objectives Objectives 1.3. While the the IoT IoT isis attracting attracting much much attention, attention, companies companies are are defining defining different different proprietary proprietary web web While service protocols, and only their own IoT devices support those protocols. Either with the intention service protocols, and only their own IoT devices support those protocols. Either with the intention or without, without, these which wewe callcall thethe IoTIoT silos. EachEach silo may or these companies companiesconstruct constructclosed closedecosystems, ecosystems, which silos. silo have its complete IoT architecture and components including devices, gateways, services, and may have its complete IoT architecture and components including devices, gateways, services, and applications. However, the components in one silo cannot connect to the components in another applications. However, the components in one silo cannot connect to the components in another silo silo as support they support different communication protocols. For example, users usually to use as they different communication protocols. For example, users usually need to need use specific specific software or applications provided by different companies to access different IoT devices, software or applications provided by different companies to access different IoT devices, such as such as theHue Philips Hue or the Belkin WeMoasSwitch, as these devices usecommunication different communication the Philips or the Belkin WeMo Switch, these devices use different protocols. protocols. Hence, the IoT is currently suffering from a lackand of faces interoperability faces Hence, the IoT is currently suffering from a lack of interoperability heterogeneityand problem. heterogeneity problem. This heterogeneity problem seriously damages the development of the IoT This heterogeneity problem seriously damages the development of the IoT as users and applications as users and applications cannotIoT communicate every IoT[5,8]. devices in a uniform way [5,8]. cannot communicate with every devices in a with uniform way Moreover, the heterogeneity Moreover, the heterogeneity problem impedes the design of a unifying framework the problem impedes the design of a unifying framework and the communication protocol [9]. As and a result, communication protocol [9]. As a result, since IoT devices cannot be easily connected, extra costs since IoT devices cannot be easily connected, extra costs are required to achieve automatic and efficient are required to achieve automatic and efficient physical mashup applications. 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 Section 3, 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 Section 4, we apply the proposed solution on some existing IoT products and demonstrate the contributions by constructing some applications. Finally, this paper concludes in Section 5. 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 Figure 2, 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 standards establishes the connection between the SID SWEseems web service and theprotocols sensors. sensors. Inand terms of the tasking capability, although able to standards describe device In terms of the tasking capability, although SID seems able to describe device protocols with OSI with the OSI model (Open Systems Interconnection model), clear description and examples the of how model (Open Systems Interconnection model), clear description and examples of how to automatically to automatically compose device requests based on SID seems to be missing from the references compose device requests based on SIDa seems to be missing from the references [20].verbose In addition, [20]. In addition, while SID presents complete but complicated data model and XML while SID presents a complete but complicated data model and verbose XML schema, to understand schema, to understand and adapt the SID may be costly for IoT device manufacturers. Therefore, and theproposes SID may an be costly for IoT devicethat manufacturers. Therefore, this research an this adapt research alternative solution uses a relatively simple data modelproposes to describe alternative solution that uses a relatively simple data model to describe IoT device protocols. IoT device protocols.

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

In general, we argue that the existing solutions cannot fully fully address address the the IoT IoT heterogeneity heterogeneity issue. issue. developing a uniform uniform service service description for the IoT IoT tasking tasking capabilities capabilities This research focuses on developing that is flexible enough to describe describe different HTTP HTTP protocols protocols for for controlling controlling IoT IoT devices. devices. Also, while most of the existing service description solutions are based on the XML format, the documents are usually large largeininsize size[21] [21] and suitable for resource-constrained IoT devices. web usually and notnot suitable for resource-constrained IoT devices. Hence,Hence, the webthe service service description this research is based on the JSONOverall, format.by Overall, by describing device description this research proposesproposes is based on the JSON format. describing device protocols protocols inmanner, a uniform manner, a web service cantobe constructed to connect automatically to in a uniform a web service can be constructed connect automatically to different IoT devices, different IoT devices, and consequently, users can control different devices using a single service and consequently, users can control different devices using a single service protocol. protocol. 3. Methodology 3. Methodology This study aims to define an interoperable solution for the IoT tasking capability. The proposed solution twoaims main we definesolution a JSON-based webtasking servicecapability. description toproposed describe Thishas study to parts. define Firstly, an interoperable for the IoT The device tasking capabilities including communication protocols. Secondly, users solution has two main parts. Firstly,the wemetadata define a and JSON-based web service description to for describe to remotely connect with different IoT devices with a uniform interface, we propose a web service that device tasking capabilities including the metadata and communication protocols. Secondly, for users can understand the proposed serviceIoT description and automatically transform tasks intoservice device to remotely connect with different devices with a uniform interface, we users’ propose a web requests. We also specifically design the web service as an automatically extension of the OGC SensorThings that can understand the proposed service description and transform users’ tasks API into based the idea that SensorThings APIweb couldservice provideasaccess to both IoTofsensing and deviceonrequests. We the alsoExtended specifically design the an extension the OGC tasking capabilities. In thisonsection, wethat firstthe introduce theSensorThings overall workflow the proposed solution SensorThings API based the idea Extended API of could provide access to and the connection with the SensorThings API. Then we present the details of the proposed tasking both IoT sensing and tasking capabilities. In this section, we first introduce the overall workflow of capability service description. we explain proposed solution withwe anpresent example. the proposed solution and the Finally, connection with thethe SensorThings API. Then the details of the proposed tasking capability service description. Finally, we explain the proposed solution with an example.

Sensors 2016, 2016, 16, 16, 1395 1395 Sensors

of 23 23 77 of

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 To propose a complete interoperable solution for the thisSensorThings study integrates proposed proposed solution with theand OGC SensorThings API [10]. TheIoT, OGC APIthe provides an solution with the OGC SensorThings API [10]. The OGC SensorThings API provides an open and open and flexible web service protocol to host “things” and manage observations [10]. This flexible web serviceon protocol to host “things” and manage observations [10]. This standard is based on standard is based the JSON format and mainly follows the OGC Observation and Measurement the JSON format andasmainly follows the OGCmodel Observation Measurement O&M) model (OGC O&M) model the sensor observation (Figureand 3) [11]. In general,(OGC the first and current as the sensor observation model (Figure 3) [11]. In general, the first and current version of the version of the SensorThings API is mainly designed for the IoT sensing capability and did not SensorThings API is mainly designed for thetoIoT sensing include theresearch tasking include the tasking capability. Therefore, provide a capability complete and IoT did webnot service, this capability. Therefore, to provide a complete IoT web service, research proposes an interoperable proposes an interoperable solution as an extension to the this SensorThings API, where the general solution as an extension to the SensorThings API, where the general operations (e.g., the Create, Read, operations (e.g., the Create, Read, Update, and Delete of entities) directly follow the SensorThings Update, and Delete of entities) directly follow the SensorThings standard. For the of API standard. For the remainder of this paper, this extended API service is referred to remainder as Extended this paper, thisAPI. extended service is referred to as Extended SensorThings API. SensorThings

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

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 Figure 4, 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 with the parameter “on” as true in a Task. room, a user can set an Input with the parameter “on” as true in a Task.

Sensors 2016, 16, 1395 Sensors 2016, 16, 1395

8 of 23 8 of 23

Figure 4. 4. An An example example of of the the Extended Extended SensorThings SensorThings API. API. Figure

One thing thing to model, users/providers have the One to note note is is that thatsimilar similartotothe theSensorThings SensorThingsAPI APIdata data model, users/providers have flexibility to model their their scenario. For example, a user could model air conditioner as a Thing the flexibility to model scenario. For example, a useralso could alsothe model the air conditioner instead of an Actuator providing TaskingCapability for the room. This decision is for as a Thing instead of an Actuator providing TaskingCapability for the room. This decision is left left for users/applications to to decide. decide.InIngeneral, general,the the Extended SensorThings handle sensing users/applications Extended SensorThings APIAPI cancan handle bothboth sensing and and tasking capabilities so that users can access complete IoT capabilities in a single service and tasking capabilities so that users can access complete IoT capabilities in a single service and integrate integrate the capabilities for different applications. For example, an environment control application the capabilities for different applications. For example, an environment control application can retrieve can retrievereadings temperature readings SensorThings from Extended API the periodically. When the temperature from Extended APISensorThings periodically. When temperature exceeds temperature exceeds predefined maximum or minimum thresholds, the application will predefined maximum or minimum thresholds, the application will automatically turn on or off the air automatically on ora off air conditioner by creating a Task entity. conditioner by turn creating Taskthe entity. After introducing introducing the the overall overall high-level high-level model model of of Extended Extended SensorThings SensorThings API, API, one one of of the the main main After objectives of this study is to design an IoT tasking capability solution so that users can control IoT objectives of this study is to design an IoT tasking capability solution so that users can control IoT deviceswith witha uniform a uniform interface allowing manufacturers toproprietary define proprietary device devices interface whilewhile allowing manufacturers to define device protocols. protocols. Before presenting the details, we first describe the key ideas and the overall workflow: Before presenting the details, we first describe the key ideas and the overall workflow: (1). Describe the IoT device tasking capability: To connect IoT devices while allowing (1). manufacturers Describe the IoTto device tasking capability: To connect IoT devices whileaallowing define different protocols, this study proposes uniformmanufacturers web service to define different protocols, this study proposes a uniform web service description format description format (presented in Section 3.2). By following the service description, users or (presented in Section 3.2).write By following the to service description, userscapabilities or manufacturers first manufacturers can first documents describe the tasking of IoT can devices, write describe the taskingprotocols. capabilities of IoT devices, which include the templates whichdocuments include thetotemplates of device of device protocols. (2). Register the IoT tasking capability to an Extended SensorThings API service: After preparing (2). the Register thecapability IoT tasking capability users, to an Extended SensorThings API service: After preparing tasking description, manufacturers or devices themselves can register the the tasking capability description, users, manufacturers or devices themselves can register descriptions to a web service following the Extended SensorThings API. The web service the can descriptions to a web service following Extended SensorThings API. The web service can then automatically understand the devicethe protocols of different IoT devices. then automatically understand the device protocols of different IoT devices. (3). Retrieve the tasking capability from the Extended SensorThings API service: Before users or (3). applications Retrieve the control taskingthe capability fromthey the Extended SensorThings service: Before from usersthe or IoT devices, can retrieve the availableAPI tasking capabilities applications control the IoT devices, they can retrieve the available tasking capabilities from the Extended SensorThings API to understand the allowed input parameters. While the Extended SensorThings API to understand the allowed inputfor parameters. the resources, SensorThings SensorThings API provides a simple and RESTful interface the user toWhile retrieve the API provides a simple and RESTful interface for the user to retrieve resources, the Extended Extended SensorThings API follows the same procedure. Based on the information in the SensorThings API follows the same Based can on the information in entities the tasking capability tasking capability document users procedure. retrieved, users create valid task (presented 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, 1395different tasking capabilities. 9 of 23 (4). Control IoT devices via the Extended SensorThings API service: Finally, users create task entities the input parameters and values,API retrieve the corresponding capability description in the Extended SensorThings service. The Extendedtasking SensorThings API will parsefrom the the database, and and automatically compose a device request based on the protocol template in input parameters values, retrieve the corresponding tasking capability description from the the taskingand capability description. Finally, the request service based sends on thethe request to control the database, automatically compose a device protocol template in IoT the devices. tasking capability description. Finally, the service sends the request to control the IoT devices. 3.2. The The Data Data Model Model of of the the Tasking Tasking Capability Description 3.2. As we mentioned and products areare similar to web services, which should have As mentionedearlier, earlier,IoT IoTdevices devices and products similar to web services, which should documents to advertise their capabilities and communication protocols. While XML format not have documents to advertise their capabilities and communication protocols. While XMLmay format be suitable resource-constraint IoT devices, this research tries to propose a JSON-based tasking may not be for suitable for resource-constraint IoT devices, this research tries to propose a JSON-based capability document standard,standard, which is which called “tasking description”. In general, In thegeneral, tasking tasking capability document is calledcapability “tasking capability description”. capability is a JSON-based descriptiondescription that mainlythat describes IoT tasking capability the taskingdescription capability description is a JSON-based mainlythe describes the IoT tasking including the communication protocols and metadata of IoT devices. 5 shows the data modelthe of capability including the communication protocols and metadata of Figure IoT devices. Figure 5 shows the tasking capability. To connect the proposed tasking capability with the SensorThings API, we can data model of the tasking capability. To connect the proposed tasking capability with the simply connectAPI, the we Thing from the SensorThings API with TaskingCapability entity, which SensorThings canentity simply connect the Thing entity fromthe the SensorThings API with the represents the controllable ability of the Thing. TaskingCapability entity, which represents the controllable ability of the Thing.

Figure Figure 5. 5. The The 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. Table 1 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

Description

A human-readable description for the Tasking Capability

CharacterString

One (Mandatory)

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 Table 2, 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


Description

A human-readable description for the Actuator

CharacterString

One (Mandatory)

EncodingType

Data type of the metadata

ValueCode (e.g., for SensorML, application/xml, application/json)

One (Mandatory)

Metadata

A metadata of the actuator

Any

One (Mandatory)

3.2.3. Parameter The Parameter mainly has four properties (Table 3) 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 Tables 4–7, respectively.

Sensors 2016, 16, 1395

11 of 23

Table 3. Properties of the Parameter. Name

Definition

Data Type


ParameterID

The unique identification for an allowed parameter

CharacterString

One (Mandatory)

Description

A human-readable description for the Parameter

CharacterString

One (Mandatory)

The necessity of the ParameterID

“Mandatory” or “Optional”

One (Mandatory)

The corresponding portion of template in the HTTPProtocol of an optional ParameterID

CharacterString

Zero to one (Optional)

Use

CorrespondingTemplate

Table 4. Properties of the Definition. Name

Definition

Data Type


InputType

The data type of the input value

“String”, “Double”, “Boolean”, “Integer”

One (Mandatory)

UnitOfMeasurement

Unit of measurement of the input value

JSON_Object

One (Mandatory)

Table 5. Properties of the AllowedValues. Name

Definition

Data Type


Value

An acceptable value for the Parameter

Value

Zero to many (at least one Value or one Range is required)

Range

An acceptable value range for the Parameter

Range

Zero to many (at least one Value or one Range is required)

Table 6. Properties of the Value. Name

Definition

Value Description

An acceptable value for the Parameter A human-readable description of the Value

Data Type Any CharacterString

Multiplicity and Use One (Mandatory) One (Mandatory)

Table 7. Properties of the Range. Name

Data Type


Min

The minimum value of a range

Double or Integer

One (Mandatory)

Max

The maximum value of a range

Double or Integer

One (Mandatory)

CharacterString

One (Mandatory)

Description

Definition

A human-readable description of the Range

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 Table 8. Table 8. Properties of the HTTPProtocol. Data Type


HTTP Method

One (Mandatory)

URL

One (Mandatory)

ValueCode (e.g., for application/xml, application/json)


The MessageBody of the device HTTP request

CharacterString


The QueryString of the device HTTP request

CharacterString


Headers

The Headers of the device HTTP request

CharacterString

Zero to many (Optional)

Fragment

The Fragment of the device HTTP request

CharacterString


Authentication information for accessing the IoT device

Authentication


Name

Definition

HTTPMethod

The HTTP method of the device HTTP request

AbsoluteResourcePath

Absolute resource path of the device HTTP request

MessageBodyDataType

The data type for the MessageBody, which can be used to verify the content in the MessageBody

MessageBody QueryString

Authentication

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 Table 9, 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

Type

Type of HTTP authentication

Value code (e.g., for HTTP Basic, HTTP Digest)

One (Mandatory)

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. Name

Definition

Data Type


Time

Time for executing the task. If the Time is not specified, the request will be sent immediately.

ISO 8601 Time String


Status

The task status automatically changed by the service

CharacterString

One (Mandatory)

ResponseDataType

The data type of the response from device

ValueCode (e.g., for application/xml, application/json)


Any


Response

The response message from device

Table 11. Properties of the Input. Name

Definition

Data Type


ParameterID

The unique identification of the Parameter

CharacterString

One (Mandatory)

Value

User’s input value

Any (but limited by the Parameter’s Definition and AllowedValue)

One (Mandatory)

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 (Figure 6) to an

Sensors 2016, 16, 1395

Sensors 2016, 16, 1395

14 of 23

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 Extended SensorThings API service.When Whenthis thisuser usersends sendsaaTask Taskwith withthe theInputs Inputsshown shown in in Figure Figure 7a 7a to Extended SensorThings API service. to turn onlight the light bulb, service will first parsethe theInputs. Inputs. The The service turn on the bulb, thethe service will first parse servicewill willfind findthe theParameterID ParameterID “on” and “bri” with Value true and 255, respectively. Then the service composes keywords “{on}” “on” and “bri” with Value true and 255, respectively. Then the service composes keywords “{on}” and and “{bri}” to find the placeholders in the HTTPProtocol template. In this case, the service will use the “{bri}” to find the placeholders in the HTTPProtocol template. In this case, the service will use the Value Value true and 255 to replace the “{on}” and “{bri}” in the MessageBody. As a result, the final device true and 255 to replace the “{on}” and “{bri}” in the MessageBody. As a result, the final device request request is shown in Figure 7c. is shown in Figure 7c. 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 Value false in the“bri” Task is asnot shown in Figure 7b,case. the portion template for ParameterID “bri” isinnot ParameterID required in this Hence, of wethe design the CorrespondingTemplate required in this case. Hence,6 we designthe thecorresponding CorrespondingTemplate Parameter shown in Figure Parameter shown in Figure to specify portion of theintemplate in HTTPProtocol. In 6 to this specify the corresponding portion of the template in HTTPProtocol. In this case, when the service case, when the service is composing a device request, Figure 7d shows the service removes the is composing a device request, Figure 7d shows the service removes the and CorrespondingTemplates CorrespondingTemplates of optional Parameters that are not required composes a device of request. optionalFinally, Parameters that arehas nota required and composes device Finally, if a requesttohas if a request MessageBody, the servicea will userequest. the MessageBodyDataType a MessageBody, the service will use the MessageBodyDataType toas verify and fix simple formatting verify and fix simple formatting issues in the MessageBody, such removing necessary commas issues the MessageBody, suchthe as service removing commas from a JSON String. As a result, fromin a JSON String. As a result, can necessary automatically compose a complete HTTP request for anautomatically IoT device. compose a complete HTTP request for controlling an IoT device. thecontrolling service can { “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.

“Input”: [

“Input”: [

{“ParameterID”: “bri”,”Value”: 255},

{“ParameterID”: “on”,”Value”: false}

{“ParameterID”: “on”,”Value”: true}

],

], Sensors 2016, 16, 1395 “Status”: “Waiting to be Sensors 2016, 16, 1395

“Status”: “Waiting to be sent”, sent”,

“Time”: “2016-02-26T15:42:00+0800”

“Time”: “2016-02-26T15:40:00+0800” { (a) {“ID”: 3}, “TaskingCapability”: HTTP PUT http://example.com/lightbulb1 “Input”: [ MessageBody {“ParameterID”: 255}, {“on”: true, “bri”:“bri”,”Value”: 255} {“ParameterID”:(c) “on”,”Value”: true} }

15 of 23 15 of 23

} {

(b) {“ID”: 3}, HTTP “TaskingCapability”: PUT http://example.com/lightbulb1 “Input”: [ MessageBody {“on”: false} {“ParameterID”: “on”,”Value”: false} (d) ],

], Figure 7. (a) A Task with two input parameters; (b) A Task“Status”: with one “Waiting input parameters; (c) The device to be sent”, request corresponds to be thesent”, two-input-parameters Task; (d) The device request corresponds to the “Status”: “Waiting to “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 defined tasking capability description and the keyword replacement procedure, input values can HTTP PUT http://example.com/lightbulb1 HTTP PUT http://example.com/lightbulb1 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 Figure A with Task with two input parameters; A with Taskcapability. with one input parameters; (c)device The device couldFigure consequently realize the of(b)IoT tasking 7. (a)7.A(a) Task two interoperability input parameters; A(b) Task one input parameters; (c) The request corresponds totwo-input-parameters the two-input-parameters (d) device The device request corresponds to the request corresponds to the Task;Task; (d) The request corresponds to the one-input-parameter 4. Results one-input-parameter Task. Task.

The The main focus of thisshows studythe is case to propose a input uniform service for However, describingwith above example of having values in thedescription MessageBody. 4. Results heterogeneous IoT device protocols and design a web service interface for users to control different the defined tasking capability description and the keyword replacement procedure, input values can IoT devices following a single protocol. To demonstrate the contribution of this study, we first apply or The main focus of this study is to propose a uniform service description for describing be automatically placed in other HTTP components (i.e., resource path, querystring, headers, the proposed tasking capability description on three existing IoT devices, which are the Philips Hue, heterogeneous IoT device protocols and design a web service interface for users to control different fragment). Users or manufacturers only need to put the placeholder in the correct place in the Belkin WeMo Switch, and a Panasonic IP camera. Secondly, we use the Extended SensorThings API IoT devices following single can protocol. To demonstrate theplaceholders contribution and of this study, we first apply template, and the aservice automatically locate the compose a complete HTTP to two physical mashup applications to demonstrate the potential usage of the proposed thecreate proposed tasking capability description on three existing IoT devices, which are the Philips Hue, request. This solution is intuitive and simple enough to accommodate various device protocols and solution. Belkin WeMo Switch, andrealize a Panasonic IP camera. Secondly, we use capability. the Extended SensorThings API to could consequently the interoperability of IoT tasking create two physical mashup applications to demonstrate the potential usage of the proposed solution. 4.1. The Tasking Capability Descriptions for Existing IoT Products 4. Results 4.1. The Tasking Capability Descriptions for Existing IoT Products As shown in Figure a smart device that service can be remotely controlled to The main focus 8,ofthe thisPhilips studyHue is tois propose a uniform description for describing As the shown in Figure 8, the Philips Hue is adesign smart thatWhile caninterface bethe remotely controlled to change change colors, brightness, and saturation of light bulbs. Philips Huetoiscontrol one ofdifferent the heterogeneous IoT device protocols and adevice web service for users the colors, brightness, and saturation of light bulbs. While the Philips Hue is one of the popular IoT popular IoT devices, users need to use their applications or follow their proprietary protocol IoT devices following a single protocol. To demonstrate the contribution of this study, we firstto apply devices, users needtasking useproposed their applications or follow their proprietary protocol toservice control thePhilips device. control device. Iftoour tasking capability description can the protocol toHue, thethe proposed capability description on three existing IoT describe devices, which are the If our proposed tasking description canwith describe the service to control Hue light control HueWeMo light bulbs,capability users control IP them the same protocol other describable IoT API Belkin Switch, and acan Panasonic camera. Secondly, we useprotocol theasExtended SensorThings bulbs, users can control them with the same protocol as other describable IoT devices. devices. to create two physical mashup applications to demonstrate the potential 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 Figure 8. Philips Hue. control Hue light bulbs, users can control them with the same protocol as other describable IoT Figure 8. The The Philips Hue. 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 Figure 9. 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 Figure 9, “on” can be used to turn on or off the Hue, “bri” is for adjusting the brightness, Figure 8. The Philips Hue.

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 users2016, that16,this Sensors 1395 tasking capability can be used to control Hue. Parameters record the acceptable 16 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” helpsthe users change “hue” the color of users Hue and “sat” be of used toand adjust thecan saturation of adjust Hue. adjusting brightness, helps change thecan color Hue “sat” be used to The AllowedValues can be represented with Range and/or Value. the saturation of Hue. The AllowedValues can be represented 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 In order describe the communication of different devices, record record the toHTTP protocol. According protocols to Figure 9, Hue IoT accepts theHTTPProtocol HTTP PUTcanrequests. the HTTP protocol. According to Figure 9, service Hue accepts AbsoluteResourcePath AbsoluteResourcePath records the web entrythe to HTTP controlPUT thisrequests. Philips Hue, and MessageBody records the web service entry to control this Philips Hue, and MessageBody records the template records the template that will be used to compose device requests. As mentioned in Section 3.3, this that will be used to compose device requests. As mentioned in Section 3.3, this research designs research designs the keyword “{ParameterID}” as the placeholder, such as the {on}, {bri}, {sat}, and the keyword “{ParameterID}” as the placeholder, such as the {on}, {bri}, {sat}, and {hue}, which will be replaced with users’ input values. Finally, the TaskingCapability links to an Actuator 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 Sensors 2016, 16, 1395 17 of 23 Actuator that enables this capability. As in Figure 10,10, thethe Belkin WeMo InsightSwitch is a smart plug connecting to the Internet As shown shown Figure Belkin WeMo a smart plug connecting {hue}, which in will be replaced with users’ inputInsightSwitch values. Finally,is the TaskingCapability links to to an the via WIFI. Users can connect some appliances like a dehumidifier and further remotely control this Internet via WIFI. Users can connect some appliances like a dehumidifier and further remotely Actuator that enables this capability. smart turnplug on/off those connected controlplug this smart to turn thoseappliances. connected appliances. As to shown in Figure 10,on/off the Belkin WeMo InsightSwitch 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 InsightSwitch. Figure 10. 10. The The Belkin Belkin WeMo 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. the WeMo API, there isBelkin only one acceptable parameter called AsAccording in to Figure 11, thisInsightSwitch description explains InsightSwitch tasking According toshown the WeMo InsightSwitch API, there is only onethe acceptableWeMo parameter called “BinaryState”, “BinaryState”, which allows turn on or off WeMo plug. Figure 11 shows capability. According to theusers WeMotoInsightSwitch API,this there is onlysmart one acceptable parameter calledthat which allows users to turn on or off this WeMo smart plug. Figure 11 shows that value “1” and value “1” and value “0”allows stand users for “turn on” “turn respectively. HTTPProtocol, “BinaryState”, which to turn onand or off this off”, WeMo smart plug. From Figurethe 11 shows that value “0” stand for “turn on” and “turn off”, respectively. From the HTTPProtocol, the Extended value “1” and value “0” stand for “turn on” andthe “turn off”, respectively. From the aHTTPProtocol, the Extended SensorThings API can understand components for composing device request. SensorThings API can understand theunderstand components composing acomposing device request. For example, the Extended API can thefor components for a device request. For example, the SensorThings WeMo InsightSwitch requires some information in HTTP headers. In addition, the the WeMo InsightSwitch requires some information ininformation HTTP headers. In addition, theaddition, MessageBody For example, the WeMo InsightSwitch some inrequests, HTTP headers. the MessageBody stores the template of the requires XML document for device whereInthe {BinaryState} stores the template of the document for device requests, where the {BinaryState} is the keyword MessageBody stores theXML template of input the XML document for device requests, where the {BinaryState} is the keyword placeholder for users’ values. placeholder for users’ input values. is the keyword placeholder 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”: parameter isis used usedto toturnturnon on {“ParameterID”:“BinaryState”,”Description”: “BinaryState”,”Description”: “This “This parameter or or off off the the WeMo”,”Use”: “Mandatory”, WeMo”,”Use”: “Mandatory”, “Definition”: { { “Definition”: “InputType”: “Integer”,”UnitOfMeasurement”: “Status”, “InputType”: “Integer”,”UnitOfMeasurement”: “Status”, “AllowedValues”: “AllowedValues”: [ [ {“Value”: 1, “Description”:“Value “Value11isis used used to turn {“Value”: 1, “Description”: turnWeMo WeMoon”}, on”}, {“Value”: 0, “Description”: “Value 0 is used to turn WeMo {“Value”: 0, “Description”: “Value 0 is used to turn WeMooff”}]}} off”}]}} ], ], “HTTPProtocol”: “HTTPProtocol”: [ [ { { “HTTPMethod”: “POST”, “HTTPMethod”: “Headers”: [ “POST”, “Headers”: [ “Content-Type”,”Value”: “text/xml; charset=\”utf-8\”“}, {“Key”: {“Key”: “Content-Type”,”Value”: {“Key”: “Accept”,”Value”: ““}, “text/xml; charset=\”utf-8\”“}, {“Key”: “Accept”,”Value”: ““}, {“Key”: “SOAPACTION”,”Value”: “\”urn:Belkin:service:basicevent:1#SetBinaryState\”“} {“Key”: “SOAPACTION”,”Value”: “\”urn:Belkin:service:basicevent:1#SetBinaryState\”“} ], ], “AbsoluteResourcePath”: “http://example.com/upnp/control/basicevent1”, “MessageDataType”: “application/xml”, “AbsoluteResourcePath”: “http://example.com/upnp/control/basicevent1”, “MessageBody”: “{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 Sensors 16, 1395 The2016, third IoT

18 of 23

18 of 23 IP product we examined is the Panasonic IP camera as shown in Figure 12. 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 the the proposed alsoshould supportalso IP camera capabilities. timeInternet. via the Therefore, Internet. Therefore, the solution proposedshould solution supporttasking IP camera tasking cameras are common IoT devices, which allow users to remotely monitor features of interest in real As shown in Figure 13, Description and Parameters provide information for users to understand how capabilities. As shown in Figure 13, Description and Parameters provide information for users to time via the Internet. Therefore, the proposed solution should also support IP camera tasking to task this IPhow camera. Whilethis the IP request template also request recordedtemplate in the HTTPProtocol, but different understand to task camera. Whileis the is also recorded in the capabilities. As shown in Figure 13, Description and Parameters provide information for users to from the previous IoT products, the request two is an HTTP GET request, and the are HTTPProtocol, but two different from previous products, the request is parameters an HTTP GET understand how to task this IP the camera. While theIoT request template is also recorded in the specified in query options (i.e., the {pan} and {tilt}). request, and the parameters specified in querytwo options (i.e., the {pan} and {tilt}). HTTPProtocol, but differentare from the previous IoT products, the request 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”}, “Thing”: {“_link”: “Description”: “This “/Thing”}, tasking capability can help users control the Panasonic IP camera”, “Description”: “Parameters”: [ “This tasking capability can help users control the Panasonic IP camera”, “Parameters”: [ “pan”,”Description”: “The pan is used on horizontal rotation”,”Use”: “Mandatory”, {“ParameterID”: {“ParameterID”: “pan”,”Description”: “The pan is used on horizontal rotation”,”Use”: “Mandatory”, “Definition”: { “Definition”: { “InputType”: “Integer”,”UnitOfMeasurement”: “none”, “InputType”: “Integer”,”UnitOfMeasurement”: “none”, “AllowedValues”: [ “AllowedValues”: [ {“Max”: numbermeans meansturn turnright righthorizontally horizontally negative {“Max”:5,5,“Min”: “Min”:-5, -5,“Description”: “Description”: “Positive “Positive number andand negative number means turn left horizontally.” }]}}, number means turn left horizontally.” }]}}, {“ParameterID”: used on on vertical verticalrotation”,”Use”: rotation”,”Use”:“Mandatory”, “Mandatory”, {“ParameterID”:“tilt”,”Description”: “tilt”,”Description”: “The “The tilt tilt is is used “Definition”: { “Definition”: { “InputType”: “none”, “InputType”:“Integer”,”UnitOfMeasurement”: “Integer”,”UnitOfMeasurement”: “none”, “AllowedValues”: [ “AllowedValues”: [ {“Max”: numbermeans meansvertical verticaldecline declineand and negative number {“Max”:4,4,“Min”: “Min”:-4, -4,“Description”: “Description”: “Positive “Positive number negative number means vertical rise.” means vertical rise.”}]}} }]}} ], ], “HTTPProtocol”:{ { “HTTPProtocol”: “HTTPMethod”:“GET”, “GET”, “HTTPMethod”: “AbsoluteResourcePath”:“http://example.com/cgi-bin/camctrl”, “http://example.com/cgi-bin/camctrl”, “AbsoluteResourcePath”: “QueryString”:“pan={pan}&tilt={tilt}”, “pan={pan}&tilt={tilt}”, “QueryString”: “Authentication”:{“Type”: {“Type”:“HTTP “HTTPBasic”,”Username”: Basic”,”Username”: “admin”,”Password”: “Authentication”: “admin”,”Password”:“12345”} “12345”} }, }, “Actuator”: {“_link”:“/Actuator”} “/Actuator”} “Actuator”: {“_link”: } } Figure 13. The tasking capability description of Panasonic IP camera. Figure Figure 13. 13. The The tasking tasking capability capability description description of of Panasonic Panasonic IP IP camera. camera.

In addition, the Panasonic IP camera supports authentication for privacy and security In addition, addition,thethe Panasonic IP camera supports authentication for and privacy andpurposes. security In IP camera supports authentication forauthentication privacy security purposes. In orderPanasonic to automatically compose device requests, the standard type, purposes. order to automatically compose device requests, the authentication standard type, In order to In automatically device the authentication standard username and username and passwordcompose are specified in requests, the HTTPProtocol as well. This use casetype, indicates that our username and password are specified in the HTTPProtocol as well. This use case indicates that our password aresolution specified the HTTPProtocol as well. This as use case indicates that proposed solution proposed caninrecord variable device protocols the manufacturers of our IoT devices wants. proposed solution can record variable device protocols as the manufacturers of IoT devices wants. can record variable device protocols as the manufacturers of IoT devices wants. 4.2. The Task for Controlling IoT Products 4.2. The The Task Taskfor forControlling ControllingIoT IoTProducts Products 4.2. According to these tasking capability descriptions, users can understand every detail of According these tasking capability descriptions, users canhow understand every of According totothese tasking capability descriptions, users canknow understand detail of detail different different tasking capabilities from different IoT devices and to every use those acceptable different tasking capabilities fromIoT IoT and howentities to useinthose acceptable parameters to create a Task entity todifferent control devices. Similar to those other SensorThings tasking capabilities from different devicesthese and devices know how toknow use acceptable parameters to parameters to create Task entity control these devices. Similar in to SensorThings other inget SensorThings API,aby creating tasking capability entities in an Extended API, entities users can a unique create Task entity to acontrol these to devices. Similar to otherSensorThings entities API, by creating API, by capability creating tasking capability entities in an Extended API, SensorThings can get a unique tasking entities in an Extended SensorThings users canAPI, get users a unique ID for 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 When an Extended thetime, Task entity, Extended and SensorThings API the will parse the taskSensorThings to retrieve API the receives executing input the parameters values, and will corresponding parse the task toTaskingCapability retrieve the executing time, input parameters and values, and the corresponding ID. Then the Extended SensorThings API will compose a device TaskingCapability ID. Then keyword the Extended SensorThings APItemplate will compose a device request by replacing request by replacing placeholders in the with user’s input values. Finally, the keyword placeholders in the template with user’s input values. Finally, the Extended SensorThings Extended SensorThings API service sends the device request at the specified time. While IoT devices APIreceive servicethe sends the requests, device request specified time. While IoT devices theIndevice device some at IoTthe devices would return responses to thereceive service. this case, requests, some IoT devices would return responses to therecord service. thistype case, optional properties ResponseDataType and Response theIn data ofoptional responseproperties and response ResponseDataType andUsers Response record this the data type of response and response itself, respectively. can retrieve information from the Task entity. 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, and16,actuators Sensors 2016, 1395 Sensors 2016, 16, 1395

and their tasking capabilities can be registered to a service. In this case, users 20 of or 23 20 of 23 physical mashup applications can retrieve observations from different sensors and control different and control different actuators through coherent This web paper service protocol. This paper uses two simple actuators through a coherent web serviceaa protocol. two simple use cases examples and control different actuators through coherent web serviceuses protocol. This paper usesas two simple usedemonstrate cases as examples to demonstrate the contributions of the Extended SensorThings API. to the contributions of thethe Extended SensorThings API. use cases as examples to demonstrate contributions of 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. 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. Peopletoturn on dehumidifiers when they feel uncomfortable because of high relative humidity. In order make the process more automatic and efficient, we can apply the Extended In order to make the process more automatic and efficient, we can apply the Extended In order to make the process more automatic and efficient, we can apply the Extended SensorThings SensorThings API to collect relative humidity data from a sensor and automatically control a SensorThings API to collect relative humidity data from a sensor and automatically control a API to collect relative humidity data fromSwitch a sensorwhen and automatically dehumidifier traditional dehumidifier via the WeMo the humidity control exceedsa traditional a predefined threshold. traditional dehumidifier via the WeMo Switch when the humidity exceeds a predefined threshold. via the WeMo Switch humidity exceeds a predefined threshold. Although there have been Although there have when been the similar products integrating a humidity sensor in a dehumidifier, we Although there have been similar products integrating a humidity sensor in a dehumidifier, we similar products integrating a humidity sensor in a dehumidifier, we simply want to demonstrate that simply want to demonstrate that without buying a more expensive product, similar functionality simply want to demonstrate that without buying a more expensive product, similar functionality without buying a more expensive product,sensing similar and functionality can be achieved simply connecting can be achieved by simply connecting tasking capabilities frombydifferent connected can be achieved by simply connecting sensing and tasking capabilities from different connected sensing devices.and tasking capabilities from different connected devices. devices. Figure of of an an automatic dehumidifier. For the capability, this study Figure 16 16shows showsthe theprototype prototype automatic dehumidifier. Forsensing the sensing capability, this Figure 16 shows the prototype of an automatic dehumidifier. For the sensing capability, this uses DHT11 as the humidity sensor to measure the relative humidity and connects the DHT11 studythe uses the DHT11 as the humidity sensor to measure the relative humidity and connects the study uses the DHT11 as the humidity sensor to measure the relative humidity and connects the with Arduino YUN to upload observations to an Extended SensorThings API service every 30 min. DHT11 with Arduino YUN to upload observations to an Extended SensorThings API service every DHT11 with Arduino YUN to upload observations to an Extended SensorThings API service every From theFrom data model perspective, we assigned “room” as“room” a Thing,as thea DHT11 as the Sensor, 30 min. the data model perspective, we the assigned the Thing, the DHT11 asand the 30 min. From the data model perspective, we assigned the “room” as a Thing, the DHT11 as the “relative air humidity” ashumidity” the ObservedProperty. Users and applications then retrieve time-series Sensor, and “relative air as the ObservedProperty. Users andcan applications canthe then retrieve Sensor, and “relative air humidity” as the ObservedProperty. Users and applications can then retrieve Observations from the service. the time-series Observations from the service. the time-series Observations from the service.

Figure 16. The prototype of an automatic dehumidifier. Figure Figure 16. 16. The The prototype prototype of of an an automatic automatic 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. While the integrated system is considered as another Thing, the WeMo Switch is the Actuator, and its Sensors 2016, 16, 1395 21 of 23 TaskingCapability is similar to the example shown in Figure 11. By connecting the WeMo Switch with the dehumidifier, usersboth can remotely turn on/off machine. to an Extended SensorThings API After registering the sensor node andthe dehumidifier After registering both the sensor node and dehumidifier to an Extended SensorThings service, service, an application can first periodically retrieve humidity readings from the service.API When the an application can first humidity readings from the service. the humidity humidity exceeds theperiodically predefinedretrieve maximum or minimum thresholds, theWhen application will exceeds the predefined minimum thresholds, thea application will automatically automatically turn on maximum or off the or dehumidifier by creating corresponding Task entity inturn the on or off the dehumidifier creating a corresponding Task entity in the Extended SensorThings Extended SensorThings APIby service. 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, In daily life,forget many to office consume energy no this one issue, is present, or people often turnlighting off the systems lights when they unnecessary leave the office. To when address this or people often forget to turn off the lights when they leave the office. To address this issue, this study study implements a simple application that uses an ultrasonic distance sensor to monitor the implements a simple application that uses an ultrasonic distance sensor to monitor the distance distance changing in a hallway and automatically adjusts the Philips Hue light bulbs, as shown in changing Figure 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 This YUN. study The deploys an ultrasonic distance sensoratona the and connects the readings sensor toper an Arduino sensor produces measurements highwall frequency (i.e., five Arduino YUN. The sensor produces measurements at a high frequency (i.e., five readings per second). second). Once the reading changes (e.g., when someone passes by), the Arduino YUN will upload an Once the reading (e.g., whenSensorThings someone passes by), the Arduino YUN upload Observation Observation entitychanges to an Extended API automatically. Then,will similar toan the previous entity to an Extended SensorThings API automatically. Then, similar to the previous application, application, an application can periodically retrieve readings from the service and automatically an application periodically turn on/off the can Philips Hue lightretrieve bulbs. readings from the service and automatically turn on/off the Philips Hue light bulbs. In general, this study modeled the “office” as a Thing, the “ultrasonic distance sensor” as the In general, this study modeled the “office” Then as a Thing, the “ultrasonic sensor” as the Sensor, and “distance” as the ObservedProperty. the Philips Hue was distance considered as another Sensor, andActuator, “distance” as the ObservedProperty. Thentothe Hue was considered as another Thing and whose TaskingCapability is similar thePhilips Figure 9. Thing and Actuator, whose TaskingCapability is similar to the Figure 9. 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Weiser, M. The computer for the 21st century. Sci. Am. 1991, 265, 94–104. [CrossRef] Atzori, L.; Iera, A.; Morabito, G. The Internet of Things: A survey. Comput. Netw. 2010, 54, 2787–2805. [CrossRef] Ashton, K. That ‘Internet of Things’ thing. RFiD J. 2009, 22, 97–114. ITU Telecommunication Standardization Sector. Overview of Internet of Things; ITU-T: Geneva, Switzerland, 2012. 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] 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. Bormann, C.; Ersue, M.; Keranen, A. Terminology for Constrained-Node Networks; Internet Engineering Task Force (IETF), RFC: Vijfhuizen, Holland, 2014; Volume 7228. 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] 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] Liang, S.; Huang, C.Y.; Khalafbeigi, T. OGC® SensorThings API; Open Geospatial Consortium: Wayland, MA, USA, 2016. Cox, S. Observations and measurements. In Open Geospatial Consortium Best Practices Document; Open Geospatial Consortium: Wayland, MA, USA, 2006. 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] 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). 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

15. 16. 17. 18.

19.

20. 21.

22.

23.

23 of 23

Bröring, A.; Stasch, C.; Echterhoff, J. OGC® Sensor Observation Service Interface Standard; Open Geospatial Consortium Interface Standard: Wayland, MA, USA, 2012. Simonis, I.; Echterhoff, J. OGC® Sensor Planning Service Implementation Standard; Open Geospatial Consortium Interface Standard: Wayland, MA, USA, 2011. Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S. Web Services Description Language (WSDL) 1.1; 2001. 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. 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. Broering, A.; Below, S. Opengis® Sensor Interface Descriptors; Open Geospatial Consortium: Wayland, MA, USA, 2010. 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. 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). 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/).

Implementation and Evaluation of Four Interoperable Open Standards for the Internet of Things.

A User-Centric Knowledge Creation Model in a Web of Object-Enabled Internet of Things Environment.

Integrated semantics service platform for the Internet of Things: a case study of a smart office.

Secure Service Proxy: A CoAP(s) Intermediary for a Securer and Smarter Web of Things.

Web-of-Objects (WoO)-based context aware emergency fire management systems for the Internet of Things.

Service-Aware Clustering: An Energy-Efficient Model for the Internet-of-Things.

Distributed Data Service for Data Management in Internet of Things Middleware.

Time-Aware Service Ranking Prediction in the Internet of Things Environment.

Service-Oriented Security Framework for Remote Medical Services in the Internet of Things Environment.

A new approach to integrate Internet-of-things and software-as-a-service model for logistic systems: a case study.

Recent advances on internet of things.

Sensing in the collaborative Internet of Things.

Educating for health service reform: clinical learning, governance and capability - a case study protocol.

Beyond accuracy: creating interoperable and scalable text-mining web services.

Processing biological literature with customizable Web services supporting interoperable formats.

Signal waveform detection with statistical automaton for internet and web service streaming.

Closed-Loop Lifecycle Management of Service and Product in the Internet of Things: Semantic Framework for Knowledge Integration.

The OAuth 2.0 Web Authorization Protocol for the Internet Addiction Bioinformatics (IABio) Database.

Radiochemistry, PET Imaging, and the Internet of Chemical Things.

CoAP-Based Mobility Management for the Internet of Things.

Medical Device Integration Model Based on the Internet of Things.

Postmarketing Safety Study Tool: A Web Based, Dynamic, and Interoperable System for Postmarketing Drug Surveillance Studies.

The Open Anatomy Browser: A Collaborative Web-Based Viewer for Interoperable Anatomy Atlases.

Biological Web Service Repositories Review.