IoT limitations and WoT solutions
By Dominique Guinard and Vlad Trifa
In this article, excerpted from building WoT, we define IoT and its limitations, and describe how WoT can help IoT build an application layer.
Right now, it’s almost impossible to sum up the nature of IoT in one sentence. While the term itself is relatively new, the concept has been around for decades, so IoT has no clear boundaries. However, the widely accepted definition of IoT is no longer just a page connecting to a multimedia collection, but extends to the natural, real-time world through a large number of embedded devices. In short, the simplest definition we can provide for IoT is as follows:
IoT is a system of physical objects that can be discovered, monitored, controlled, or interoperated with electronic devices by communicating through their various network interfaces, and ultimately connected to the wider Internet
Twenty years ago, a world in which objects could sense the world through sensors every day and then analyze, store or exchange information was the stuff of science fiction. Today, these scenarios are increasingly becoming a reality thanks to huge advances in embedded devices that are bringing something new to the world: smart devices. A smart device is a physical object that is digitally enhanced in the following ways:
- Sensors (temperature, light, motion, etc.),
- Actuators (display, sound, motor, etc.),
- Computations (executable programs and logic),
- Communication interface (wired or wireless).
These devices expand the world we live in by enabling entirely new applications. A bunch of powerful, small, and cheap computers have been placed around us that can monitor and interact with the physical world with a higher spatio-temporal resolution than ever before.
Figure 1. – IoT application scenario. IoT is anything that can be connected to the Internet in any form. From a box of oranges with an electronic tag to a smart city, everything in between is digitally enhanced to make up IoT.
To be more specific, items in IoT can be very simple tagged products, such as: automatic identification tags (bar codes, QR codes or NFC and RFID tags) on delivery packages that can be tracked from shipping centers to homes; It could be a more elaborate, complex wireless product, device or machine, like a security system, your car or factory assembly line; Or even a building or a city. The network part simply means that the device’s services or data can be accessed and processed by other applications over the existing network infrastructure, but it does not mean that the device must be connected to the Internet. The communication networks used can be automatic identification technology in buildings, short-range radios (such as Bluetooth, wireless sensor networks, etc.) or local Wi-Fi networks.
Unfortunately, today it is almost impossible to build a single seamless global iot communication system. IoT has no unique and generic application protocol that can be used across many network interfaces today. To put it bluntly, today’s IoT is inherently isolated and cannot really communicate with each other.
To make IoT a reality, we need a common application-layer protocol (think of it as a “language”) so that devices and applications can communicate with each other regardless of how they are physically connected. Instead of creating another protocol from scratch (although many IoT projects have already started and are under way), why not just reuse what is already widely used to build scalable and interactive applications, such as the Web itself? This is what WoT is all about: reusing and leveraging readily available and widely popular Web protocols, standards, and blueprints to make data and services provided by objects accessible to more (Web) developers.
Talk about WoT
Once people want to integrate devices from different manufacturers into a single application or system, the limitations of the Internet of Things are exposed. To illustrate how the Internet of Things can handle these limitations, take a look at global hotel chain owner Johnny B. In the life. Johnny wants to digitally connect all the appliances in all the hotel rooms so he can monitor, control and improve his hotel using the Web-based “Hotel Control Center” application from the deck of his yacht in the Bahamas. At the same time, the system can also provide a more enjoyable and personalized experience for every guest in his hotel, as shown in Figure 2.
WoT application scenario: Hotel Interconnection
Building this smart hotel system may require Alpha’s electronic door locks, Beta’s security cameras and a Gamma’s control application to manage all of these devices. Connecting and collaborating with these devices and systems will require a great deal of custom system integration. Johnny will also hire a professional firm and spend a lot of money on a huge project for several months. Such a complex project is as stable as a building block: bugs and hacks can cripple it, and maintenance and expansion can be a nightmare. No doubt Johnny will run out of money before he gets the system he wants.
Figure 2 – Johnny wants to digitally connect devices in all of his hotel rooms. First, guests can use various services by controlling the room (lighting, air conditioning, entertainment, etc.), booking hotel facilities, ordering food and drinks (all done on their phones). Second, the system will allow Johnny to coordinate and optimize all aspects of his hotel in a centralized and efficient manner without having to use a variety of separate applications and tools.
If Johnny is into DIY (” do it yourself “), he could decide to build the whole system himself. He can buy a complete set of products from the same company because they are designed to work together. Unfortunately, no solution on the market will have all the sensors and devices it wants to control. Even if he could find the perfect system, the user interface is unlikely to be balanced, especially when it comes to custom access controls and configurability. If he also wants the system to be scalable, reliable, and secure, you can easily double or triple the time it takes to build the system. Should we also develop apps for hotel guests? So you know…
Johnny’s life may seem surreal. Unfortunately, that’s the case with IoT today. We know this because we’ve had the opportunity to work with many Johnnies over the last decade. We’ve seen it all, from store managers who want to combine their existing security cameras with access systems to create smarter security systems, to LED manufacturers who want to control their lights via the Web.
Figure 3 – Hundreds of incompatible protocols coexist in today’s IoT. This makes the integration of data and services from a variety of devices complex and expensive. In the Internet of Things, any device can be accessed using standard Web protocols. Connecting various devices to the Web makes integration across systems and applications much easier.
Wouldn’t it be great if any device could be easily integrated and used by any application, regardless of network protocols? As figure 3 shows, this is exactly what WoT can do.
Compare current IoT and WoT
As more and more things will be digitally enhanced, the next logical step is to use the World Wide Web ecosystem and infrastructure to build applications for IoT, effectively breaking this “one device, one protocol, one application” model. It’s interesting to push the exact same technology across tiny devices that can help modern websites like Facebook or Google scale to millions of concurrent users without compromising security or performance. The idea of making the most of existing and emerging tools and technologies and applying them to developing IoT scenarios is what we call WoT.
While IoT has been busy solving network problems, WoT relies entirely on application-level protocols and tools. Mapping any device to a Web mind-set allows WoT to ignore the physical and transport layer protocols used by the device. As you will learn in this book, software or hardware “Bridges” (via proxies or gateways) allow almost any custom protocol or standard to link to the Web.
Figure 4 – WoT relies only on the OSI top layer (7) for processing applications, services, and data. Operating at such a high level of abstraction makes it possible to connect data and services between multiple devices regardless of the transport protocol actually used. In contrast, IoT does not advocate specific application-level protocols and generally focuses on the lower layers of the OSI stack.
Abstracting the complexity and diversity of the underlying protocols behind a simple Web model has many advantages. Just as the Web has become the global integration platform for distributed applications over the Internet, WoT facilitates the integration of devices and the applications that interact with them. In other words, by hiding the complexity and differences between the various transport protocols used in IoT, WoT allows developers to focus on the logic of their applications without having to worry about how the protocol or device actually works.
Going back to our smart hotel scenario, it would be easier if all devices (regardless of their manufacturer) could provide standard Web apis, cross-device and application data sets, because all devices would use the same language. In this case, the hotel owner (or system integrator) only needs to worry about building a “hotel control Center” application, which might be a mash-up Web- a single Web application that combines data and services from a variety of sources. He does not have to bother to learn the details of every protocol used by the various devices he wants to use [1]. This not only significantly reduces the time required to build, but also minimizes the amount of work required to maintain the system each time a device or service is added, removed, or updated.
Making this vision a reality has been our goal with the WoT Community we created in 2007 [2] and the IoT platform EVRYTHNG launched in 2011 [3]. Using HTTP, WebSockets, JSON, and other Web standards or tools to interact with embedded devices is perfect for us. At the time, the idea seemed quixotic, even pointless, and we got our fair share of criticism. However, the latest embedded Web servers with advanced functionality can only be implemented with 8 KB of memory. Thanks to efficient cross-layer TCP/HTTP optimizations, they can run on small embedded systems and even on smart cards, such as chips on credit cards! Embedded Web servers in IoT often have limited resources than the clients that access them, such as browsers or mobile phones, and with the massive growth of the JavaScript community, it is becoming easier and easier to move a lot of workloads from devices to client applications or even the cloud.
Figure 5 – WoT has the ability to use modern Web standards directly on embedded devices. By applying all of these standards to IoT scenarios, we can build new types of interactive applications and ensure that devices can integrate with modern Web applications and services with minimal effort.
In WoT, devices and their services are fully integrated into the Web because they use the same standards and technologies as traditional Web sites. This means that you can write applications that interact with embedded devices in exactly the same way that you would with any other Web service using Web APIS, especially using RESTful architecture.
REST is an architectural style for developing distributed applications and is the foundation for building the modern Web. At its core, REST focuses on creating loosely coupled services that are easy to reuse, implemented using URIs, HTTP, and standardized media types. Loosely coupled services can be easily built by abstracting them from their application-specific semantics through a unified interface (HTTP predicates and response code), because it provides a simple mechanism for clients to choose the best representation of interaction. This makes the Web an ideal foundation for building “generic” architectures and application programming interfaces (apis) that interact with things.
In practice, this means that you can start interacting with things and exploring WoT through a Web browser just as you surf the Web (through links to other related things). It then uses HTML, CSS, and JavaScript to easily retrieve, process, and display real-time data collected from distributed sensors.
The programming model behind the Web is easier to learn and use than many of the protocols and standards that exist in IoT. Notably, it enables anyone with basic Web programming skills to build websites and applications around not only multimedia content but also real-time data from the physical world.
Figure 6 – WoT allows developers and applications to exchange data with any device using standard HTTP/WebSockets requests, regardless of how the device is connected.
While WoT emphasizes the use of Web standards to exchange data between devices, it is not meant to dictate how devices are physically connected. In other words, the device can, but does not have to be, publicly connected to the Web and can be publicly accessible by anyone just like a Web site. WoT can run on a local area network (for example, your company’s Intranet or home network).
In some cases, it makes sense for a device to have a common URL and be publicly accessible through the Web. For example, government-managed traffic or pollution sensors in cities. In this case, the device can also be crawled and indexed through a search engine just like any other web page, and allow users to literally Google the physical world, or bookmark the URL of the smart device and share it with friends. Web-connected objects can also become active and engage with other users of the network by using apis of services such as Twitter and Posting their own blogs or chats.
Using services such as IFTTT [4] or Node-Red [5], users can create small logical rules that fuse with real-world devices, such as sensors in the home, and virtual services in the cloud, such as SMS gateways or weather forecasting services. This application is called a physical mashup. Learn some principles and tools to use in my book (Build WoT) so you can create physical mashups on devices.
To truly understand why WoT represents the next phase in the evolution of IoT, we first need to understand what has happened in the space so far. What led to the idea of connecting devices first appearing? If the vision of a global network of connected devices is so promising, why hasn’t it emerged yet? These are the questions we seek to answer in this book.
[1] automation protocol table: https://en.wikipedia.org/wiki/List_of_automation_protocols
[2] webofthings.org
[3] evrythng.com
[4] ifttt.com/
[5] nodered.org/