Making the IoT. Part 2: Processing
In Part 1 of this series on breaking down the components that make up the Internet of Things, we covered:
- A perspective on how the IoT evolved
- We looked at some examples of IoT solutions.
- And hopefully left you with a sense that all the pieces of an IoT solution are of a level of complexity that the average startup/coder/maker can learn about them and get started building solutions.
In Part 2, let's look at these topics:
- System Overview of a typical IoT solution
- Take one of our examples from Part 1, break it down, and see how it aligns with the typical System Overview
- Then do a deeper dive into the individual technology areas, starting with the IoT application processor. We'll look at options and consider why you might choose one over another for a given application.
Almost all IoT systems have a simplified system architecture like the diagram at the top of this article. You have many IoT devices which talk (via some appropriate signaling and protocol) to an internet-connected gateway. The gateway relays data (via the internet) to a central server where the data is "consumed".
Note: One exception to this is the extremely exciting possibility use of blockchain technology instead of a centralized server. Some think the centralized server model doesn't scale to the huge number of connected devices predicted.[^3] But for now we're using centralized servers.
Let's take our "No more 'garbage day'" example and see how it aligns with this diagram.
Each garbage bin has embedded battery-powered electronics with sensors to detect the amount of garbage. When the bin is full, it prepares a message object (with proper identification and authentication) and sends that to the nearest LPWAN gateway. LPWAN is low power, low data rate, and great for occasionally chirping messages to a gateway that might be several kilometers away. The gateway relays the message over the internet to a server (cloud, VPS, or physical) that ingests the data into a conventional software stack implementing the sanitation department's business logic. For instance, maybe optimal truck routes are calculated on the fly and sent to roving trucks via an LTE connection to a navigation system in the cab.
There are lots of pieces to this example. Let's take a second to unpack it:
- Sensor in the trash bin with:
- Sensor for detecting amount of trash
- Battery or small solar panel
- Gateway (one or two for a small city)
- Internet connection
- Radio to talk to trash bins
- Custom software implementing the business logic
- Truck component
- Small computer with 3G/LTE data connection
- Custom software to present data to driver
I think you can see that designing and building each piece is quite a manageable task.
You can take small steps and build up your own IoT solutions.
Now let's take a closer look at some of the underlying technologies. This will be where some design decisions lie because which option is best is dependent on your application.
Device Processing Hardware
Certainly your device will need a processor. There are many options here, but the decision tree breaks down like this:
Decision 1: Will a microcontroller suffice or do we need more?
For all but very simple applications, we bump out of the class of 8-bit microcontrollers and into more capable 32-bit processors, perhaps something that can run Linux.
The goal is to get hardware engineers comfortable running Linux and get desktop/server software developers comfortable developing very close to the hardware.
Let's say we want to run an operating system (like Linux).
Decision 2: Use a module or build from scratch?
Depending on your tolerance for learning, cost, risk, you might choose to base your design on a pre-built module. The module is an collection of parts that you might need for you application, assembled into one functional unit that you use as a single part. It might have an application processor, radio, memory, and testing and documentation that assures this design works as you would expect.
As with any of these pre-built solutions[^4], some design decisions have been made for you. And that might be fine in your application. However, another option is to build up your platform from the component level.
This might be a big step for some, but I assure you, like the rest of the parts of this system, it is a manageable task when you take it step-by-step. Each component comes with a datasheet with documentation on how it works and descriptions on how to use it.
In Part 3 of this series, we'll look at IoT device communications. We'll look at design tradeoffs between long-range and short-range options, what technologies are commonly used, and what new tech is coming out of research.