Internet of Things does not rely only on devices and applications. It requires a set of capabilities that, when used in an IoT solution, deliver more value to people and companies. In this section, we will discuss some of these capabilities, such as devices, hardware, and software, that are essential for designing and implementing an effective IoT solution.
Devices are located at the edge of the IoT solution. In fact, these devices are what we call Things in the context of IoT. They are usually capable of sending and receiving data events.
As an example, a device with an embedded soil moisture probe can detect that the monitored soil has 43% moisture. It can then report this informative event to the platform it's connected to. The platform can then send an action event to the device, triggering a water valve to open and restore the soil moisture. This interaction depends on other aspects related to the device, which will be covered in upcoming sections. For now, let's focus on the device.
In order to handle these types of interactions, you may think of a device as a computing unit that has analog or digital (or both) processing capabilities. This means that it is able to read and write analog and digital signals to their probes and actuators.
An analog signal is a signal that can vary in a range of values. Let's take an Arduino Uno board, for example. Arduino Uno has a 10-bit resolution analog-to-digital converter (ADC), which means that it can read voltages from 0V to 5V and map them into integer values between 0 and 1,023 (210 = 1,024). Analog signals are generally used to read data from analog sensors.
A digital signal is a binary signal, which means that it has only two possible values: 0 or 1, high or low. This kind of signal is mostly used to identify or change on and off states, for example, turning an LED bulb on or off.
Devices are also capable of handling some actions by themselves. This could either be a simple decision: for example, if the moisture level of the soil is below 50%, open the water valve for a minute and check the moisture level again after five minutes.
Alternatively, it can be a complex task: for example, determining whether an object detected by the camera of an autonomous car is a person waiting to cross the street or a tree.
Devices that have to process these kinds of analyses cannot always rely on a network or an application for information or assistance. What if one of them is out of service? This could cause an accident.
Therefore, such devices are provided with a different type of capability called edge computing, which is the capability of processing analytics at the very edge of the solution: the device itself. Basically, edge computing allows the device to perform some actions and calculations "offline," without an active connection to a network.
When selecting the device or devices that will be part of your IoT solution, the best method is to ensure that all capabilities are present in the device.
Since there is a very high number of devices in an IoT network, exceeding capabilities can lead to different problems related to cost, power supply, connection protocol, user experience or even solution complexity.
Another important element of any IoT solution is networking. Today there are several ways to connect devices, so this is an important aspect that has to be considered when choosing your device. The most common networking standards used today are cabled networks or Wi-Fi, cellular/mobile, LPWAN, and LoRa. All of these have pros and cons, so let's take a closer look at their uses.
Wi-Fi is the most common standard communication model on the internet. It assumes that the device or object being connected to is capable of connecting to an IEEE 802.x network and therefore is able to handle IP-based networks.
There are many wi-fi capable devices available in the market. Some examples of Wi-Fi modules are the ExpressIf ESP-8266 and ESP-32 modules, Texas Instruments CC3200, Microchip ATSAMW25, Intel Edison, and Galileo. This is not the complete list of devices and there are many other combinations that combine a Wi-Fi capable controller and an MCU.
Wi-Fi modules are relatively cheap and are generally good options for when it's possible or desirable to use an available network and support high-payload transfers, given their reliability and connection speed (up to 6.7 Gbps).
A Wi-Fi-based IoT solution looks pretty much like the following diagram:
Multiple devices can connect to a node, such as a router, which in turn connects to the internet and allows connected devices to access the internet.
A cellular network is the same connection that any mobile phone uses. The basic idea with this kind of network is to divide a territory into a number of cells, each one with a wireless network connection served by a base station and a number of transceivers. The network provides a number of services, such as voice, text, and data.
Mobile networks are an option when a device type in a solution is not in the range of a Wi-Fi network, such as in a car. Another application that may require a mobile network device is when the solution cannot depend on the user's network, for example, if you are using a subscription for the device, and the device's activity depends on a network connection. When using the subscription network, the device will continue to do its job even if the user disables their own connection to the network.
The image below depicts the working of a standard cellular network:
We can see that a cellular antenna provides a signal to a limited region. The devices in range can then connect through a wireless network to the antenna and use the services provided by the mobile service provider, including the available internet connection.
LPWAN is a type of wireless network designed to work in wide areas at very low bitrates, which means that the exchange in this type of network is really small.
LPWAN uses low-power, low-bitrate, and low-frequency devices that are very powerful when used to connect to things. This is because it enables the use of long-lasting batteries and smaller devices. But there are still many restrictions, such as small data payloads or a limited number of messages per day.
Having lower frequencies allows an LPWAN to be very reliable and unsusceptible to interference, even when propagating messages for very large ranges. LPWAN providers normally have a limit for the number of messages sent in the network. There are many providers of LPWANs, and the most famous of these is probably Sigfox.
LPWANs do not have a direct connection from the device or gateway to the internet. Instead, they usually have a pre-provisioned network, where at one end of the network you will have the devices and at the other end you would have a number of web hooks and functions that allow you to connect to your application or platform:
Different from a cellular network, LPWAN networks do not provide internet connection to the devices, instead they provide means to create triggers on events received from the devices to the network. As an example, you can create an application and a trigger at the edge of the LPWAN provider network to the internet that whenever a data event is received from a device, it calls a service available at the internet with given data from the even published by the device.
A LoRa network diagram is similar to an LPWAN network, except that instead of using service provider infrastructure, LoRa networks can have a gateway that allows devices to connect to the internet. The person responsible for a LoRa network infrastructure is the owner of the network, meaning that you do not rely on a network service provider. You create your own network:
There are a few technologies that work on the same model as LoRA, with different protocols, such as ZigBee. Phillips Hue uses the same approach to connect light bulbs, LED stripes, and other Hue devices to a gateway using ZigBee, and the gateway then connects to the Hue cloud.
To summarize, you can use this table as a reference when selecting network connections:
Type | Speed | Payload | Range | Connection initialization | Cost | Infrastructure |
Wi-Fi | High | High | Low | Bidirectional | Low | Private/Public |
Mobile | High | High | High | Bidirectional | High | Provider |
LPWAN | Low | Low | High | Device | Low | Provider |
LoRa | Low | Low | High | Bidirectional | Low | Private |
After deciding the most adequate device for your IoT solution, it's important to define the protocol that will be used to communicate with devices. IoT solutions tend to use lightweight protocols, such as MQTT. This is not the only protocol that can be used in IoT, but since the IBM Watson IoT Platform relies on MQTT and REST—and REST is very popular—let's focus a little on MQTT.
MQTT stands for Message QueuingTelemetry Transport. It is an extremely lightweight messaging protocol based on the publish and subscribe pattern. As with any message queuing model, it is an asynchronous protocol.
As shown in the following diagram, publish and subscribe (pub/sub) models rely on three actors:
The three actors are explained as follows:
- The publisher is the actor that produces any content and publishes it to a given subject (known as a topic).
- The subscriber is an event consumer. The subscriber subscribes to its subjects (topics) of interest and gets the event published every time a publisher creates a publication to one of its subscriptions.
- The Broker is responsible for receiving publications and notifying the subscribers of a topic of interest.
Now let's move on to the next important technical element.
Having an analytics or artificial intelligence software component in your IoT solution is not required, but it's really interesting to use them to process data collected from devices to extract patterns and insights that could lead to predictive maintenance, a better understanding of user behavior, and so on.
For example, let's look at some data that is captured through washing machines. Someone may have bought the appliance because it was supposed to save energy. However, after processing the data collected, it becomes clear that the appliance is consuming more energy than thought. The root cause is the lubricant as it was inadequate for its motor in non-tropical countries.
Later, let's say you compare that information with sales data and realize that 1 million washing machines were sold in Europe approximately eight months ago. The manufacturer of the washing machine can get the benefit of early shipping rates for the spare parts that must be exchanged. The manufacturer can also get a predictable amount of new lubricant for their supplier, and this could perhaps lead to a new appliance design.