How Does an IoT Device Work?

After surveying hundreds of Product Managers across industries and backgrounds, I’ve found that only about 20% of PMs working in IoT have hardware experience. By contrast, over 76% of them are familiar with managing software products.

But in IoT, hardware and software work together across the IoT Technology Stack. And managing hardware products requires very different skills than managing software. That is one of the reasons why building IoT devices can be very daunting for new and even seasoned IoT Product Managers.

If you’re an IoT PM who comes from a software background, take a minute to arm yourself with the information in this post. You’ll be glad you did next time you talk with Hardware Engineering teams or are faced with a hardware-related challenge.

Based on my IoT Decision Framework, the hardware is part of the Technology Decision Area. Therefore, you are here:

Recommended article: A Product Management Framework for the Internet of Things.

Why Do I Need to Understand the Hardware Inside My IoT Device? Doesn’t Engineering Make Those Decisions?

Yes, Engineers are responsible for researching, proposing, and executing hardware choices for the IoT device. But it’s important for the Product Manager to be involved and guide Engineering on what the product needs are so that they can choose the best solution. After all, hardware decisions will impact your product’s cost, user experience, application capabilities, and more.

The more you understand how the hardware inside an IoT device works, its nuances, and its terminology, the more empowered you’ll be to have smart conversations with your Engineering team.

The 4 Building Blocks of IoT Device Hardware

First, let’s take a look at the main hardware building blocks of any IoT device.

With as many IoT applications as there are IoT entrepreneurs, it would be impossible to generalize a hardware architecture. But regardless of the application, all IoT devices share some commonalities or “building blocks,” as shown below:

Let’s look at each of these components.

Building Block 1: Thing

I define “thing” as the asset you want to control or monitor.

Many IoT devices integrate the “thing” into the smart device itself. For example, think of products like a smart water pump or an autonomous vehicle. These products control and monitor themselves. In this case, your product includes all four building blocks in a single package as shown below.

But there are many other applications where the “thing” stands alone as a “dumb” device, and a separate product is connected to it to make it a smart device. In this case, your product only includes the three modules in blue below.

This approach is very common in industrial applications where companies have existing assets, and they want to make them “smart” by connecting them to the Cloud. Some examples include wind turbines, jet engines, conveyor belts, etc.

The reason I point out this difference is to make you aware that there are different business models you could choose from. Your company can decide to build brand new devices that are smart from the very beginning, or you can determine that your value proposition is to provide a way to turn existing things into smart things, opening the door to what’s called “brownfield opportunities.”

Either one is fine, just keep in mind that this distinction will affect many other decisions you make for your product.

Most of the examples above are B2B products, but what about B2C products? In the consumer product world, many IoT products only include the three modules in blue above. That’s because the “thing” they are monitoring is often a human or the environment of the home. Think of a FitBit or a Nest thermostat.

Building Block 2: Data Acquisition Module

The data acquisition module focuses on acquiring physical signals from the “thing” and converting them into digital signals that can be manipulated by a computer.

This is the hardware component that includes all the sensors acquiring real-world signals such as temperature, motion, light, vibration, etc. The type and number of sensors you need depend on your application.

The data acquisition module includes more than sensors though. It also contains the necessary hardware to convert the sensor signal into digital information for the computer to use. It includes signal conditioning, analog-to-digital conversion, scaling, and interpretation.

For the data acquisition module, the critical considerations to focus on are:

• What real-world signals do I need to measure? (i.e., what type of sensors do I need)
• How many sensors of each type do I need?
• How fast should I measure the real-world signal? (i.e., sample rate)
• How much accuracy do I need in my measurement? (i.e., sensor resolution)

The answers to these questions will inform the requirements for your data acquisition module, as well as give you an idea of how much data your device will produce.

Recommended article – Data Acquisition: A Primer for IoT Product Managers

Building Block 3: Data Processing Module

The third building block of an IoT device is the data processing module. This is the “computer” that processes the data, performs local analytics, stores data locally, and performs any other computing operations at the edge.

You don’t need to be an expert in computer architecture to have a robust conversation with your Engineering team about this module. Your role should be to understand the overarching goal of the product and ask the right questions that will guide your team to the right decisions. The two most important considerations to focus on are:

• Processing power (i.e., how much processing will you do at the edge?)
• Amount of local data storage (i.e., hard drive size – how much data will you need to store at the edge?)

The decisions you and your team make will have a direct correlation with performance, functionality, cost, size of the device, useful life, etc. Let’s discuss each of those questions in more detail.

How much processing power do you need?

To determine how much processing power your device needs, you should start by understanding all the different tasks that the device needs to perform.

Items that will impact your decision include:

• How many sensors do you need to read? (More sensors will require more processing power.)
• Do you need to perform real-time control? (This will increase the processing power needed.)
• Does your application need to perform analytics at the edge? (This will also increase the processing power required.)
• Do you have enough processing power to support future software upgrades/releases? (Your new and improved software upgrades will likely require more processing power.)
• What are the size constraints of your device? (For example, a Fitbit only has so much space, limiting the computer size and processing power.)

How much local storage do you need?

The amount of local storage you need depends on your data retention policy. Once you define how much data you need to acquire, how often, and how much you will send to the Cloud, then you can calculate how much local storage you’ll need as temporary storage to perform calculations or to serve as a buffer in case you lose the connection to the Cloud.

If your IoT device is expected to work offline, you need to define for how long it will operate without a connection, and therefore, how much data you need to be able to store locally. Some applications require no interruptions in the data, either because the Cloud Analytics won’t be able to handle data gaps or because you have a legal agreement with the customer for data continuity.

Building Block 4: Communications Module

The last building block of your device’s hardware is the communications module. This is the circuitry that enables communications with your Cloud Platform, and with 3rd party systems either locally or in the Cloud.

This module may include communication ports such as USB, serial (232/485), CAN, or Modbus, to name a few. It may also include the radio technology for wireless communications such as Wi-Fi, LoRA, ZigBee, 3G, 5G, etc.

The communications module can be included in the same device as your other modules, or it could be a separate device that is specifically for communications. This approach is often referred to as a “gateway architecture”.

For example, if you have three sensors in a room that need to send data to the Cloud, you might have those sensors connected to a single gateway in that same room, and the gateway consolidates this data and sends it to the Cloud. That way, you only need one communications module, not three.

The Bottom Line

As an IoT Product Manager, you don’t need to be an expert in all areas of the IoT Technology Stack. But you do need a solid understanding of the major components and how an end-to-end IoT solution is put together.

My recommendation is to get as familiar as possible will all layers of the IoT Technology Stack. I’ll be covering all the other layers of the stack in future articles. Subscribe to my newsletter below to make sure you don’t miss out on those posts.