This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Peeling Back the Layers of an IoT Architecture
A, B, C
It's easy as 1, 2, 3
Or simple as do, re, mi
A, B, C, 1, 2, 3, Baby you and me
-- The Jackson 5
It's easy to learn how to drive a car without understanding how an internal combustion engine works. The same can be said about many of the machines and devices that we take for granted. Who among us can explain how an air conditioner cools a room? I expect that most people cannot. We typically learn just enough to use technology without taking the time to understand how and why it works.
However, there are times when it's important to dig below the surface to grasp the importance and possible applications of a new idea. A deeper knowledge of just about anything can often lead us to solutions that would not otherwise be considered. We ask better questions and expect more complete answers.
This is certainly true of the Internet of Things (IoT). It's easy to picture IoT as a device that tells us what it's doing. For instance, everyone can wrap their heads around the idea of a clothes dryer that sends a text message when it's completed its cycle, or a car tire that turns on a dashboard light when it requires air. Having this basic level of comprehension allows us to use IoT without having to think about its underpinnings.
Those of us who are tasked with purchasing, designing, selling, or implementing enterprise-scale IoT solutions are not permitted that luxury. While not everyone is required to understand IoT down to the bits and bytes that might fly across a BLE (Bluetooth Low Energy) connection, we cannot ignore the fact that there's a BLE link and that messages are traversing it. We also need to know how a value reported by a sensor can turn into an actionable item processed by a business application.
To that effect, I would like to spend the next several paragraphs describing the major components of a typical IoT platform. To do that, I want to take you from sensor to cloud, cloud to enterprise, and finally, to event consumption. My goal is to give you enough of an understanding to visualize the different layers while not getting too bogged down in the weeds. I will introduce some of the most common protocols (e.g. the bits and bytes), but simply knowing that they exist will be good enough for most people.
Different vendors define their IoT platforms differently; but in my mind, it's easiest to view a platform as three different layers -- device, cloud, and enterprise. Each layer may be subdivided into its own set of layers, but as an easy way to grasp architecture, three comprehensive layers works well.
The device layer consists of the physical components that gather telemetry information, normalize the data, and ultimately pass it to cloud applications for ingestion, processing, and storage. This is where you find the sensors that detect temperature, air pressure, orientation, location, light, heartrate, blood pressure, weight, and a myriad of other data points. These sensors can be smaller than a grain of sand (neural dust) or larger and heavier than anything you can easily carry. Sensors are the devices that make smart cities smart and automate our homes and office buildings.
Sensors transmit their data over any number of different transports and protocols. Common data transports include LTE, Wi-Fi, BLE, LoRa (Long Range), and ULE (Unidirectional Lightweight Encapsulation). Distance, power consumption, cost, and size are all factors in the choice of transport for a particular sensor.
Sensors move data to cloud applications in one of two ways. First, some send their telemetry data directly to the cloud. This requires that the sensor supports the appropriate data transport. For example, Wi-Fi and LTE would work for these sensors, but BLE is definitely out of the question.
The second, and more common way, is for a sensor to connect to a gateway, which in turn moves data between the device layer and the cloud layer. These gateways aggregate data from many different sensors of potentially many different types. They then normalize the data before acting as the conduit up to the cloud. Conversely, they can pass data from the cloud to the sensor.
The cloud layer acts as the ingestion point for all connected sensors and gateways. Among other things, cloud services often provide:
- Provisioning tools for all aspects of the IoT platform
- Mechanisms to meter, filter, format, organize, and store telemetry data. Data storage can be short and/or long term
- Tools to implement data flow and stream processing
- A rules engine to turn incoming data into actionable items. For example, send an email if the temperature for a particular sensor rises to 100 degrees
- External access mechanisms such as a RESTful API or MQTT (Message Queuing Telemetry Transport)
As with any cloud strategy, these services can be hosted publically, privately, or in a hybrid manner.
The enterprise layer is a collection of business applications that access the functionality exposed by the cloud layer (e.g. through RESTful APIs). These may be cloud applications themselves, or live within the bounds of an enterprise's on-premises network. For example, Avaya Breeze workflows would be part of the enterprise layer that is hosted on premises. Zang IoT workflows are still part of the enterprise layer even though they are hosted in the Zang public cloud. This means that the enterprise layer is not exclusive to the functionality provided by an enterprise's own resources. Think of it as a logical collection of applications that access the cloud layer to execute business logic.
The enterprise layer is where service management technology resides. For example, the cloud-based ServiceNow ITSM (IT Service Management) system can be used to bring IoT into an enterprise and allow it to be processed by humans and machines.
Depending on the platform, some functionality can live in either the cloud or the enterprise level. An example of this crossover is an IoT dashboard. Some platforms might build a real-time dashboard inside their cloud offering, while also offering enterprises the ability to create their own via an MQTT connection.
One Complete System
This distribution of services delivers a flexible and highly scalable platform that can support anything from a handful of centrally located sensors, to millions of sensors scattered across the world. Solutions would need to be engineered to support the required connections, storage, and both real-time and historical access to the collected data. It's important to not over provision and waste money, as well as under provision and miss critical data.
Although not previously mentioned in this article, security is paramount and must be included at every level. This includes encrypting data in transit as well as data at rest. Access to API functions must be authenticated. It's also necessary to provide mechanisms to ensure that rogue devices and gateways are detected and isolated from other devices and cloud applications. IoT data will be used in life or death situations, and it's essential that the data can be trusted beyond any doubt.
My goal for this article was to provide an introduction to IoT as a platform. As I stated earlier, I left out some of the goriest details, but they are not required to grasp the main components and how they work together. Also, different providers (e.g. Microsoft, IBM, Google, Amazon, etc.) will define their platforms using their own set of terms. However, they all follow the pattern I've just outlined.
In future articles, I will add a little more color to this discussion. Arguably, understanding IoT may be one of the most important things we as technologists can do, and the more we know of it, the better our solutions will be.