Abstract
The Internet of Things (IoT) is neither science fiction nor industry hype; rather it is based on solid technological advances and visions of network ubiquity that are zealously being realized. The paper serves to provide guidance regarding the practical aspects of the IoT. Such guidance is largely missing in the current literature in which the focus has been more on research problems and less on issues describing how to set up an IoT system and what software toolkits are required. This paper aims to bridge this gap by providing guidance in terms of the software toolkits that can be utilized by IoT practitioners and research students to set up a practical IoT system. The IoT is the combination of multiple techniques; a onefold technology cannot become the IoT. This is conducted in a multilayer approach that covers node and operating systems, middleware, databases, IoT energy harvesting method, and so forth. We hope that this survey serves to be useful to researchers and practitioners in practical aspects of IoT.
1. Introduction
In 2005, the International Telecommunication Union in Tunisia formally identified the concept of the IoT at the World Summit on Information Society and released ITU internet reports. The report gave an in-depth introduction to the IoT and its effect on businesses and individuals around the world. It contained information on key emerging technologies, market opportunities, and policy implications. In the report, the IoT is described as follows: connections will multiply and create an entirely new dynamic network of networks—that is, the IoT.
Since its introduction, the IoT received considerable attention from around the world. IBM has been working with companies, cities, and communities around the world to build a smarter planet for over five years. The following three primary characteristics of the IoT were generalized by IBM in its smarter planet plan: instrumented, intelligent, and interconnected [1]. IoT is neither science fiction nor industry hype; rather it is based on solid technological advances and visions of network ubiquity that are zealously being realized.
The motivation of this paper is to provide guidance regarding the practical aspects of the IoT. This is a gap in the current literature. We therefore aim to bridge this gap by describing software toolkits that can be utilized by IoT practitioners and research students to help realize a practical IoT system. We employ a multilayer approach that covers node operating systems, middleware, database and IoT energy harvesting method, and so forth. In addition to this introductory section, the rest of our paper is organized as follows. From Section 2 to Section 5, we summarize the node and operating systems, IoT middleware, data storage of the IoT, and IoT energy harvesting. Finally we conclude our paper in Section 6.
2. Node and Operating System
Numerous heterogeneous devices comprise the IoT, including resource-constrained wireless sensors [2, 3], household appliances, automation equipment, mobile phones, and tablets. Below, we review several popular node and operating systems running on some of these heterogeneous devices.
TinyOS [4] is an open source, BSD-licensed OS designed for low-power and resource-constrained wireless devices. Unlike many other node operating systems, TinyOS is coded in nesC, a C dialect optimized for the memory limitations of sensor networks (SNs). TinyOS is component based and event-driven, providing a series of reusable components. Programs are built from software components that are connected to one another using interfaces. TinyOS is completely nonblocking and has one stack to accomplish split-phase operations for maintaining high concurrency. TinyOS is widely used in WSNs and can be ported to various kinds of sensor nodes. TinyOS employs nesC as its programming language. nesC, an event-driven programming language based on components, is designed for building applications that run on TinyOS. nesC is built as an extension to C. Extensions include the separation of construction and composition, specification of component behavior in terms of a set of interfaces, bidirectional interfaces, components statically linked to one another via their interfaces, and code generated by whole-program compilers. Alizai et al. [5] proposed the TinyWifi platform, built on nesC code, as a base for protocol testing and evaluation in multiple heterogeneous networks and discussed the requirements and challenges in such a solution.
Contiki [6] is a lightweight, open source node OS for networked, memory-constrained systems with a particular focus on low-power wireless IoT devices. Contiki was created by Adam Dunkels in 2002 and was further developed by a worldwide team of developers from Atmel, Cisco, Enea, ETH Zurich, and Oxford University. Contiki provides multitasking and a built-in TCP/IP stack, including IPv6 networking, as well as 6LoWPAN, RPL, and CoAP, but it only requires approximately 10 kilobytes of RAM and 30 kilobytes of ROM. ContikiMAC enables nodes to run in a low-power mode and still be able to receive and relay radio messages. Even wireless routers can be battery operated. Created specifically for the IoT, the 6LoWPAN of Contiki makes it possible to connect resource-constrained devices to the internet because there are plenty of available IP addresses.
Nut/OS [7] is a small open source real-time OS licensed under the BSD license. It is the OS for boards under the project Ethernut, an open source hardware and software embedded-Ethernet-system. All reference designs of the hardware share the same set of interfaces such as Ethernet connectors, RS-232 ports, and power connectors, and nearly all I/O pins of the microcontroller are available on an expansion port. The primary differences are the use of a microcontroller and available memory size. The Nut/OS supports cooperative multithreading and is most applicable to situations in which there are several concurrent tasks that must be simultaneously executed. Ethernut implements its own network stack called Nut/Net, which implements a number of protocols and socket APIs for use in Nut/OS. Nut/OS is in fact an embedded-Ethernet-system that controls and monitors embedded devices without a PC. Therefore, this OS may be used as part of an intelligent home system or many other such applications of the IoT.
IBM Zurich Research Laboratory developed Mote Runner, a high-performance, resource-efficient middleware platform with hardware-agnostic and language-independent features. It provides a viable solution to some of the cost-related and technological problems of large-scale applications in the IoT. As shown in Figure 1, using Mote Runner, applications that are dynamically distributed, loaded, updated, and deleted can be easily created and managed with a high-level object-oriented programming language by using an event-driven programming model. In this manner, a large amount of postdeployment and maintenance costs are reduced. In addition, with state-of-the-art back-end infrastructures, Mote Runner makes it possible for IoT applications to be seamlessly integrated.
IBM Mote Runner architecture.
The Raspberry Pi [8] is an open source hardware system with strong manipulability. There are several OSs that can be ported to Raspberry Pi, including GNU/Linux flavors (e.g., Debian, Fedora, Arch Linux ARM, and Android), RISC OS, FreeBSD, and Plan 9. The Raspbian, which is a Debian-based OS optimized for the Raspberry Pi, is the OS recommended by the Raspberry Pi Foundation. Although the Raspberry Pi is a credit-card-sized single-board computer, the computing and memory resources are more remarkable than the typical sensor nodes or boards.
Arduino [9] is another open source hardware system similar to the Raspberry Pi. Just as with the Raspberry Pi, we can also port various OSs to the Arduino, including the Free Real Time Operating System (FreeRTOS), Duin OS, Pyxis OS, ArduinoMacOS, TaOS, Contiki, and FemtoOS. Arduino's microcontroller is based on the 8-bit Atmel AVR or 32-bit Atmel ARM, while the software consists of a standard programming language compiler and a boot loader that executes on the microcontroller. OS programs are written either in C or in C++.
Android [10] is a Linux-based OS designed primarily for touchscreen mobile devices; however, Android can be ported to many other devices such as the Raspberry Pi. Android uses Java for creating interfaces and functions. Although Android has a Linux kernel, it does not have a native X Window System by default or the full set of standard GNU libraries, which makes it difficult to port existing Linux applications or libraries to Android. It runs on embedded devices that generally have sufficient computing and storage resources beyond that of the Raspberry Pi. Therefore, Android provides a much higher level and richer set of services in the IoT, but the consumption is inevitably much more than that of traditional sensor nodes.
Table 1 summarizes and compares the above OSs.
IoT node OSs comparison.
3. IoT Middleware
Middleware is a type of computer software that connects different software components and applications. It consists of a set of enabling services that allow multiple processes running on one or more machines to interact with one another across a network. For many new applications, middleware components are becoming more important than the underlying OS and networking services on which the applications formerly depended [11].
Various types of middleware exist, including message-oriented middleware, object middleware, Remote Procedure Call middleware, database middleware, transaction middleware, and portals. Atzori et al. [12] summarized the relation of IoT components as being things-oriented, semantic-oriented, and internet-oriented visions. As summarized in Figure 2, according to these characteristics, middleware in the IoT should be able to address things and internet-related issues, as well as issues related to the semantics gap, including interoperability across heterogeneous devices, context awareness, device discovery, management of resource-constrained embedded devices, scalability, management of large volumes of data, and privacy.
Specific functional areas of IoT middleware.
In [13], Wang et al. reviewed middleware for WSNs and provided a detailed analysis of the approaches and techniques offered by middleware to meet the requirements of WSNs. Wang et al. also discussed generic components of the middleware and a reference model of WSN-based middleware. In [14], middleware was surveyed from an adaptability perspective that presented a taxonomy for adaptive middleware and its application domains and provided details for each middleware category.
Context-aware middleware was also studied. The survey in [15] was based on the architectural aspects and provided a taxonomy of the features of a generic context-aware middleware. The survey reported in [16] evaluated several context-aware architectures based on relevant criteria from the ubiquitous and pervasive computing perspectives. Finally, the survey presented in [17] was a survey of middleware systems for the IoT.
Hydra [18] is a middleware that bridges a scientific workflow management system and high-performance computing to enable workflow parallelization with provenance gathering. Coutinho et al. [19] used it to support a data parallelism solution for a bioinformatics experiment. Anggorjati et al. [20] introduced ASPIRE, which focused on the design, development, and adoption of an innovative, programmable, royalty-free, lightweight, and private RFID middleware. Naumenko et al. [21] described their long-term vision for security and privacy management in complex multiagent systems, such as UBIWARE. UBISOAP is a service-oriented middleware for WSNs [22] with a two-layer architecture based on SOAP.
Terziyan et al. [23] proposed the requirements and architecture of a complex traffic management system and illustrated how such systems may benefit by using semantic and agent technologies with the UBIROAD middleware. Belmonte et al. [24] presented a real implementation of a coalition and incentive theoretical mechanism for content distribution that aimed to tackle the problems in user behavior by using SMEPP, a middleware that aims to ease the development of secure distributed applications.
Cannata et al. [25] proposed that the framework for addressing intelligent systems should adopt SOCRADES, a European research project exploiting the SOA paradigm at the device and application levels. Maló et al. [26] presented the SIMPLE self-organized and intelligent middleware platform, which focuses on data-dissemination using multilevel subscriptions processing and a tiered networking approach to cope with many disparate, widespread, and heterogeneous sensing networks.
Global sensor networks (GSNs) are designed to facilitate the deployment and programming of SNs and serve as middleware to connect the information from the IoT to the internet. GSN is a Java environment that collects live data from a set of wrappers, processing these data streams based on XML specification files, then releasing the processed data to the web. A GSN wrapper is a piece of Java code that performs data acquisition for various devices and different types of data sources, including local sensor nodes, remote sensor nodes, TinyOS nodes, CSV files, HTTP GET requests, serial ports, and USB cameras. Compared with existing middleware [27], GSN implements the feature of automatic process of generating wrappers. Given these characteristics, GSN has better connectivity and configurability to deploy embedded sensor devices. In 2014, an extended version of GSN was presented by [28]. XGSN is capable of enriching virtual sensor descriptions with semantically annotated content using standard vocabularies.
The Message Queuing Telemetry Transport (MQTT) protocol is a lightweight, real-time messaging protocol developed by IBM. Although MQTT is lightweight, it is powerful and robust enough to support smart devices in the IoT, including Arduino platform devices, smartphones, PDAs, and tablets, efficiently delivering messages between them. This makes it possible to link the IoT to the internet. The MQTT protocol has three types of service primitives: (a) at most one delivery; (b) at least one delivery; and (c) exactly one delivery. Different service primitives correspond to different QoS levels and flows. Lee et al. [29] analyzed the MQTT message transmission process through three levels of QoS with various payload sizes, and they also analyzed end-to-end delays and message loss. Using MQTT, IoT services can be fluently and safely transmitted between the internet and devices of the IoT.
Fuseki, a server providing access to the Simple Protocol and Resource Description Framework Query Language (SPARQL) 1.1 standard, uses it via HTTP and provides RESTful HTTP updating, querying, and updating. SPARQL is a querying language and data acquisition protocol developed for RDF by the W3C. It links two new web technologies, namely, Web 2.0 and the semantic web, together and might be the future querying language of mainstream network databases and data acquisition standards. After tagging heterogeneous data to form semantic data, Fuseki can be used to release such data to the web. Therefore, the IoT is connected to the traditional internet-based semantic data.
Operator [30], developed by Michael Kaply from IBM and arguably one of the important projects of the Mozilla labs, connects microformats and semantic data from many web pages, bringing us a new web service model. Microformats are a set of simple open data formats built upon existing and widely adopted standards designed for humans first and machines second. Operator makes it possible for us to integrate different data for different web services. An important issue is to study how the IoT should be linked to the internet for which the Operator middleware provides a possible solution.
ThingSpeak [31] is a decentralized, open source platform and API for the IoT. ThingSpeak provides a server that may be used to facilitate data storage and retrieval from IoT devices. One of the advantages of ThingSpeak is openness to different hardware profiles and provides visualization tools and enables the data in a more personified fashion.
FamiWare [32] is a middleware family for ambient intelligence that allows the customization and instantiation of a specific middleware platform taking into consideration the peculiarities of every device and application domain, with the goal of reducing the middleware size.
SIXTH [33] is a Java-based middleware for the Sensor Web. It allows sensor-driven applications and enables the dynamic tasking of sensor nodes to suit shifting application demands in near real time. AndroSIXTH [34] aims to improve network middleware SIXTH with discovery services and extend its abilities to mobile networks.
MOSDEN [35] captures and shares sensor data across multiple apps, smartphones, and users. MOSDEN supports the emerging trend of separating sensors from application-specific processing, storing, and sharing. MOSDEN promotes reuse and repurposing of sensor data hence reducing the efforts in developing novel opportunistic sensing applications. MOSDEN has been implemented on Android-based smartphones and tablets.
ManySense [36] is an Android-based middleware for heterogeneous consumer-oriented body sensor networks which allow sensors and context inferencing algorithms to be coupled with the middleware. And its accessibility allows third-party applications to access raw sensor data and inferred context data uniformly.
Table 2 shows a comparison of the existing middleware from the perspective of the IoT.
IoT middleware comparison.
4. Data Storage via RDF
In the IoT, as discussed above, the semantic vision is that the semantic meanings of objects are stored separately and effective tools exist for managing this information. As a key to the IoT, these data should be reconstructed using the RDF [38] model and published as Linked Data [39] on the web.
Information about resources is represented using the RDF, which provides a data model that is very simple but strictly tailored toward the architecture of the web. In RDF, a description of a resource is represented as a number of triples. The three parts of each triple are its subject, predicate, and object. RDF data can be accessed by HTTP URIs.
The main benefits of using the RDF data model in a Linked Data context are as follows:
users can look up every URI in an RDF graph over the web to retrieve additional information; information from different sources merges naturally; the data model enables the users to set RDF links between data from different sources; the data model allows users to represent information expressed using different schemata in a single model; combined with schema languages such as RDF-S or OWL, the data model allows users to use as much or as little structure as they need; that is, users can represent tightly structured and semistructured data.
There are data management and storage systems that can store raw sensing data and its corresponding semantics data, managing the relations between the two via a mapping.
The D2RQ Platform [40, 41] is a system for accessing relational databases as virtual read-only RDF graphs. It offers RDF-based access to the content of relational databases without having to replicate it in an RDF store. Database content is mapped to RDF by a declarative mapping that specifies how resources are identified and property values are generated from database content. Benefits of D2RQ are as follows:
it queries a non-RDF database using SPARQL; it accesses the content of the database as Linked Data over the web; it creates custom dumps of the database in RDF formats for loading into an RDF store; it accesses information in a non-RDF database using the Apache Jena API; it has rich interlink RDF and XHTML to enable browsers and crawlers to navigate database content.
As shown in Figure 3, the D2RQ Platform is composed of the following components:
the D2RQ Mapping Language, a declarative mapping language for describing relations between an ontology and a relational data model; the D2RQ Engine, a plug-in for the Jena Semantic Web toolkit, which uses the mappings to rewrite Jena API calls to SQL queries against the database and then passes query results to the higher layers of the framework; the D2R Server, a type of HTTP server that provides a Linked Data view, an HTML view for debugging, and a SPARQL Protocol endpoint over the database.
D2RQ Platform.
Supported databases currently include Oracle, MySQL, PostgreSQL, SQLServer, HSQLDB, and Interbase/Firebird.
There are other data storage systems worth reviewing. In [42], David et al. provide an overview of available triple stores, their technical implementations, support for the SPARQL W3C recommendations, and available APIs.
5. IoT Energy Harvesting
With the development of the IoT, an increasing number of resource-constrained wireless sensors are being applied in industrial, commercial, medical, consumer, and military fields. Minimizing power consumption is the key to extending the application life of wireless sensors and reducing costs. Energy harvesting is a technique for utilizing energy that is harvested from the environment. Energy collected from the environment is stored after conversion and then assigned to various parts of the wireless sensor, as shown in Figure 4.
Wireless sensor node energy supply.
The efficient use of energy in WSNs involves energy supply and energy consumption. These issues are core to successfully designing and deploying WSNs. Most research has focused on harvesting and using ambient energy. In [43], Gorlatova et al. proposed a kinetic energy collection method involving experiments with briefly moving objects that provided insights into the suitability of different scenarios for harvesting energy. To characterize the energy availability associated with specific human activities (e.g., relaxing, walking, and cycling), Gorlatova et al. analyzed a motion data set with more than 40 participants. Their observations provided insights into the design of networking algorithms and motion energy harvesters, which could then be embedded into mobile devices. If this technology is embedded into wireless sensors, moving wireless sensor nodes would achieve self-sufficiency in terms of energy.
In [44], Zhang et al. introduced an effective method for converting ambient energy to electrical energy. Their research enables wireless sensor nodes to power themselves by converting ambient energy into electrical energy. Among the various energy types, ambient vibration energy is particularly attractive owing to its abundance. In [45], Sudevalayam and Kulkarni compared the physical needs and energy requirements for processing and communication tasks conducted by sensor nodes. After demonstrating hard limits, Sudevalayam and Kulkarni compared relevant energy harvesting methods and determined the most likely candidates applicable to the IoT.
Table 3 shows various ambient energy harvesting methods, influencing productions, factors, and applications [46–50]. Methods for using natural energy are straightforward and cost is typically low, but there are many unsolved issues, including low energy efficiency and dependence on the environment. Other unnatural energy sources are easily controlled, but the process of generating energy is typically very complex and expensive. The limited battery power carried by wireless sensors is not suitable in the long run. Therefore, we must identify long-standing, low-power, easy-to-use energy harvesting methods for wireless sensors.
Comparison of energy harvesting methods.
6. Conclusions
The IoT is in the early development stages; the scalable and durable network will be deposited effectively in the future. The IoT is the combination of multiple techniques; a single technology cannot become the IoT. In this survey paper, we provided some guidance regarding the practical aspects of the IoT and give guidance of the practicality aspect of IoT which is largely missing in the current literature where the focus has been more on the research problems and less on issues such as how to set up an IoT system step by step and what software toolkits are needed.
We hope that this survey has served to be useful to researchers and practitioners in the field, helping them by providing some guidance in terms of the software toolkits that can be utilized to construct a practical IoT system. Predictably, the IoT will be information infrastructure in people's future lives and more efforts to tackle those challenging issues shall be made from both industry and academia to promote the progress of the IoT.
Footnotes
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work is funded by the European Framework Program (FP7) under Grant no. FP7-PEOPLE-2011-IRSES, National Natural Science Foundation of China under Grant nos. 61073009 and 61103197, National High Tech R&D Program 863 of China under Grant no. 2011AA010101, National Sci-Tech Support Plan of China under Grant no. 2014BAH02F03, National Sci-Tech Major Projects of China under Grant nos. SinoProbe-09-01-03 and 2012ZX01039-004-04-3, Key Sci-Tech Program of Jilin Province of China under Grant nos. 2011ZDGG007 and 20150204035GX, and Fundamental Research Funds for Central Universities of China under Grant nos. JCKY-QKJC46 and 2412015KJ005.