The “Internet of Things” (IoT) is “big” and “confusing”. An important source of that confusion is that there are a myriad of perspectives on this space, and you’ll hear every technology vendor tell a story from their own vantage point. And the trade press will unfortunately parrot these narratives without providing much further organization.
A cloud platform vendor tells a cloud story, vendors who want to sell you hardware will tell you an “edge” (as antonym to “cloud”) story, a mobile network operator will tell a mobile network story, an analytics services firm will tell an artificial intelligence story. Each of these stories will tell you that an IoT solution cannot exist without that vendor’s respective piece of the “big” puzzle.
This post is an attempt to provide an relatively compact overview of key architectural patterns and related terminology in the realm of the Internet of Things that doesn’t hit too many readers’ “too long, didn’t read” threshold. The foundational assumption for all of this is that we’re building systems and not just put devices on the Internet.
Terminology
Let’s start with defining the key roles in an IoT architecture. The goal of these definitions is to keep the number of concepts down to a minimum.
-
Terminal - any kind of device or aspect of a device that is specifically designed to provide information to and interact with the human mind (!) is called a terminal. Phones, PCs, Tablets, Kiosks are terminals. Voice control devices such as the Amazon Echo also count as terminals. Terminals provide people with information and control surfaces related to the overall system. Terminals may have significant local smarts. An AR device that can project diagnostics and servicing information holograms onto industrial equipment is still a terminal.
-
Thing - a thing is any kind of device or aspect of a device that interacts with anything in the world except the human mind. A body temperature and blood pressure sensor device interacts with a human, but by this definition it is a thing since it doesn’t interact with the mind. A display on that device is a terminal. “Interact” means that the device may sense conditions and/or manipulate the environment. A factory robot with an arm is a thing. A logistics robot that moves shelves in a warehouse is a thing. A smoke detector is a thing.
-
Hub - a hub is a mediator that enables communication between multiple things and terminals inside some “local” environment. Hubs may speak multiple protocols and may play the role of an access control gate keeper. “Local” maps to some physical location scope. The hub bridges to and from devices that can be wired to it or that are within its radio range. The hub and all its connected devices form or are part of a “local network”. A wireless mobile network base station is a hub and its “cell” is a local network. Hubs may have significant local compute capabilities. A complex machine, like a car, has a large number of subsystems that are, by design, independent things and are integrated via some integration unit that acts as a hub for “connected car” communication.
-
Backend - a backend is any kind of system implemented “off site” and away from things, hubs, and terminals. This may be in the public cloud or some other datacenter facility. The backend provides compute, communication, and storage capabilities. More specific capabilities like analytics, AI, database storage, business process management, web portals, and others are based on these primitives, and solution building blocks are built on top.
Terminal, Thing, Hub, and Backend are a complete enough set of core elements for the remaining discussion.
However, let’s also define the concept of Gateway since that’s a widely used term: A Gateway facilitates moving information out of or into some scope, from and to one or multiple devices, typically via the Internet or some other inter-network. We distinguish:
-
Cloud Gateway - a cloud gateway sits somewhere in a datacenter and facilitates inbound and outbound communication with datacenter resources. I will consider the cloud gateway as being a function of the Backend for the remaining discussion.
-
Field Gateway - a field gateway resides “on the ground” (not in the cloud) and facilitates inbound and outbound communication beyond the local network scope for any hubs, things, or terminals connected on its local network. Field gateways often bridge to cloud gateways. I will treat field gateway as a function of Hub for the discussion.
Finally, we’re going to ignore all devices and components of an architecture that don’t play an active role beyond directing network traffic. A cellular network base-station is irrelevant for solution patterns unless it were to play an active role by hosting some sort of fog functionality. Fog is mentioned at the appropriate place in the pattern list below.
Architectural Patterns
Now that we have four elements to play with, let’s look the relevant combinations of these elements. Most of these combinations form easily recognizable patterns. In cases where a party in the pattern can be “any of the above”, it’s listed as Any.
-
Terminal-Backend - this is what you commonly refer to as “web” or “mobile web”. A web browser or mobile phone app is talking to some web site(s) or web service(s) in the cloud or some server somewhere else. A Smart TV (a terminal per our definition) connects to the manufacturer’s services and its app store, and the downloaded or built-in apps may connect to streaming video providers. A smart voice control speaker may connect to streaming audio providers.
-
Thing-Terminal - an app on your mobile phone is directly communicating with a nearby thing using a protocol the phone immediately supports, usually Bluetooth or Wireless LAN (WLAN). Whether a WLAN router and/or repeater is involved or whether the connection is routerless is architecturally immaterial if those intermediaries do nothing but packet routing. Many entertainment and household devices that can be paired with smartphones or tablets use this pattern.
-
Thing-Hub-Terminal - if your terminal device, like your tablet, doesn’t speak the same protocols as your things, you need a device that actively translates these protocols. Such protocols might be very low-level, such as radio signals of a particular type that the phone doesn’t have suitable on-device hardware (or drivers) for, or they might be incompatible to due different reasons. A hub is also useful in that it allows multilateral relationships. Any one thing and any one terminal to be paired with a hub once, and those devices can then communicate via the hub without having to maintain many peer relationships each. A smartphone app that allows you to control several LED lamps and light-strips around the house via one hub and while in the house is an example of this pattern.
-
Thing-Thing - if a thing wants to control another thing, they need to be connected. Some modern smoke-detectors can easily interconnect into a peer mesh that will cause all smoke-detectors around a house to start sounding if one of them detects a potential fire. A motion sensor might want to signal the hallway light switch to turn on when motion is detected.
-
Thing-Hub-Thing - as indicated above, there is greater flexibility to interconnect things via a hub. The hub will broker protocols, but it also provides a neutral place where cross-thing automation and analytics logic can be run. If the motion sensor trigger shall do more than just turning on one light, and if turning on the lights shall happen also based on a sensor on the different side of the hallway, a hub is a far better place to host that logic than in either one of the lights or in any of the sensors.
-
Any-Hub-Hub-Thing - since not all hubs speak all protocols or use some sort of proprietary technology, you might need and not all hubs have the capabilities you’ll want, you may need a “hub of hubs” in some cases. A home automation hub talking to LED lights via a lighting hub is an example. Most discussed “fog” scenarios where analytics, storage, or compute reside somewhere in the network infrastructure, but neither on-site nor in the cloud also fall into this pattern bucket.
-
Thing-Backend - many (from a security perspective hopefully all) Internet-Protocol connectable things, especially in the consumer realm, will be directly connected to one or multiple off-site backend systems. The backend relationships will be used to send and retrieve data for a variety of reasons, but the most important one is to provide a delivery path for safety- and security-critical software updates. The backend may also send commands and notifications to the thing.
-
Thing-Hub-Backend - things that are attached to a hub because they either don’t speak the required protocols or do not have permission to communicate directly will communicate with backends though that hub (and vice versa), in which case the hub takes on the aforementioned field gateway role. The hub is also the delivery path for software updates.
-
Thing(-Hub)-Backend-Terminal - if you want to control your home’s thermostat or light while you’re out in town shopping, the sane way to implement this is by sending the commands to a backend, which will then forward the commands to an already connected hub or thing. That allows the hub or thing to maintain an outbound-only connection out of the house (or business site) without having to mess with firewalls or figuring out what address to talk to. An (awful) variation of this is Thing-Hub-Terminal where the hub gets published on the Internet with a network name (DNS) and a hole is punched into the firewall to permit direct access. That’s ok for geeks who know exactly what risk they’re taking, but not for regular consumers.
-
Thing(-Hub)-Backend-Thing - A sensor that makes an observation and wants to send a command to another thing in reaction to that observation may quite well require a round-trip through a backend system, even if the devices are located in close proximity to each other. Reasons may be that the devices use different networks (WLAN vs. Mobile carrier network), have different owners, or that one of the devices is “nomadic” and only temporarily present inside a context.
I believe this set of patterns, which describes the relationship of the four elementary identified roles, covers the vast majority of the “Internet of Things”.
Buzzword concepts like “Edge Analytics” fit into this set in multiple places. You can perform analytic work in the thing, in the hub, and there will always be some sort of final customization of analytics results, such as a good deal of the visualization, performed in the terminal.
“Cloud” is where all or some of the backend functionality may be implemented. The specialized IoT capabilities in those cloud systems focus on providing a suitably scalable and robust cloud gateway as described above, and infrastructure that allows managing and providing software updates to enormous fleets of devices. Otherwise, cloud platforms and the analytics (including AI) capabilities are as generally useful in the IoT context as they are in finance, entertainment, games, retail, and many other areas - which is a great because a broad ecosystem foundation is a win for everyone.
“Fog” is a concept for hosting active logic inside the network fabric where it’s neither “edge” (standalone things and anything in and behind a hub) nor “cloud”. Whether marketecture concept of “fog” will turn out to be architecturally relevant remains to be seen. So far, “fog” deployment and management concepts are not different from “hub” in that they are usually scoped to a single system. A radio base station with active analytics that a local electricity company uses to connect neighborhoods of wireless smart meters is just a hub. “Fog” would be different if it provided a compute and analytics and storage layer infrastructure that is as massively multi-tenant as a public network, but with “zero hop” latency towards connected devices. That’s easy to dream up, but very hard to realize (securely) and it’s not at all clear whether there’s enough value in the concept and the factual gains to justify the effort.
I hope you’ve found this discussion somewhat useful. Leave feedback below or via Twitter @clemensv.
