IoT Primer: Small Things

Great things are done by a series of small things brought together.
– Vincent Van Gogh

Welcome to the first post in a series of primers designed to help you achieve great solutions by bringing together a collection of “small things” within the Internet of Things (IoT) domain.

Are you a device developer; an electrical, industrial, or hardware engineer; a hardware incubator class member; a new device manufacturer; an existing device manufacturer who wants to smarten up your next-gen devices, or a software developer working with people who identify as part of these tribes? Then this blog series is for you. We’ll show you solution architectures that take advantage of a globally accessible cloud platform to meet the challenges of providing a fleet of IoT devices to your customers.

What is a Small Thing?

Before we can build solutions, we need to understand the problem. Specifically, let’s define what is meant by “small thing” in the realm of the IoT. A smart watch or clothing that has sensors built into it is a small thing. A connected pacemaker or a connected bed is a small thing. Simply put, any device that has sensors, actuators, or both, and is expected to operate on its own for long periods of time (or even forever) is a small thing.

If you’ve already implemented a solution and are nicely past the entire suite of challenges for your fleet of devices, then we welcome feedback on how this series aligns with your experiences. But maybe you’re reading this because you haven’t started building devices yet, or maybe you’ve already started and are in the middle of experiencing the challenges firsthand. If so, you probably have a lot of questions, such as “How do I build devices that scale as a fleet, provide the device insights I need, and ultimately achieve success”? The fastest way to understand the architectural challenges of a “small thing” solution is to first ask the question, “Why a small thing?”

Why a Small Thing?

Small things maximize a resource by using it as little as possible.

A connected device is deeply shaped by its core purpose and by the fact that it maximizes the use of available resources by using them as little as possible. So, just like a glove takes on the physical shape of the hand that wears it, a small thing takes on the logical shape of its core purpose and the resource constraints with which it is confronted. Therefore, a primary consideration for any solution is that small things are constrained in one or more of the typical computing dimensions: compute, power, memory, storage, network, and human interaction.

Here are some quick visual examples:

As another example, we can think of the distinction this way: Mobile devices connect humans and often have significant computing available for general purposes, but small things connect environments and operate with specific purposes. Both mobile devices and small things are better when used with the cloud, but only small things are primarily autonomous and must fend for themselves; sometimes in harsh environments, often without human interaction.

Because small things are so good at maximizing resources in a given environment, small things are frequently deployed in counts starting in the 10 K+, 100 K+, and often the 1 M+ range. The fact that this dimension of scale exceeds the classic IT “server fleet management approaches” means there are new challenges we must address in small thing solutions.

But instead of piling on more challenges, let’s first look at a high-level perspective that will provide context for the detailed solutions we will dive into later.

A Cohesive Internet of Things Architecture

Given that we now know what small things are, let’s examine the challenges of building an IoT solution. I’ll categorize these challenges into four areas:

• Telemetry — remotely determine what a device senses
• Commands — remotely ask a device to do something
• Device DevOps — remotely ask a device to be something new
• Audit and Authorization — determine if a device should be allowed to do something

With those categories defined, let’s gather them back into a cohesive solution and start at the top.

The high-level architectural context for this entire primer series is the Pragma Architecture, which comprises layers of solutions:

• Small Thing — The logical representation of the device and fleet of devices
• Intermittent Layer — The control point for access to the Speed Layer and the nexus for fleet management
• Speed Layer — The inbound, high-bandwidth device data bus and the outbound device command bus
• Serving Layer — The access point for systems and humans to interact with the devices in a fleet as well as analysis, archive, correlation, and real-time views of the fleet

The Pragma Architecture also shows how the layers relate to one another, as shown in the following diagram.

The Pragma Architecture

For example: After a small thing uses the intermittent layer to authenticate itself with the solution, the small thing regularly sends data to the speed layer. That data could then be processed as telemetry and output for use by people interacting with the serving layer.

Of course, one diagram cannot provide a single perspective to meet different levels of detail, but this diagram does provide a conceptual framework within which customers have addressed many of the currently known Small Thing challenges. Furthermore, the diagram shows how those solutions cohesively relate to one another.

Note: If you have a background in big data, notice how this architecture is congruent with the real-time and batch-mode big data implementations that are possible on the AWS platform and with the concepts espoused in the Lambda Architecture community.

Now we have an architecture that we can use as a framework, but at this level of abstraction we don’t have much that is actionable yet. So in the next post we will dive into telemetry, which is often one of the first layers of a solution that you will need to address when building a small thing solution.

Follow us: @AWSstartups