Introduction to IoT

Scaling & Operations

Like the considerations around the capabilities of hardware, which we just explored in the previous chapter, another underappreciated aspect of a large-scale IoT solution is the operational component.

It’s one thing to deal with a prototype that only has a few pieces of connected hardware, or a pilot with just a few hundred sensors/devices at one location. It’s quite another when you scale up to a full production system with potentially millions of sensors/devices, and there are critical considerations purely on the operations side that you need to address.

More Battery Considerations

In the last chapter, we covered how the needs of the application influence hardware decisions like whether or not you use battery power in your sensors/devices. If you go with battery power, what happens when you need to replace the batteries? First, you need to figure out how you’re going to access or collect the sensors/devices.

Are they spread over miles of terrain? That means you’ll need to know where they all are, because if they run out of battery power they won’t be using GPS.

Or maybe they don’t even have GPS because they’re just soil moisture sensors and don’t need it. Do you go get them one at a time as the batteries die? Or do you wait and do it in batches?

How do you replace the batteries? If you’re replacing, don’t forget the cost of all the additional batteries you’ll need!

Or are they rechargeable? This means you don’t need to replace batteries, which is nice, but now you need to figure out how they’re recharging. If they can charge wirelessly that’s great, you can just put them on a wireless charging matt and decrease hassle. But if they need to be plugged in, that means either dedicated charging stations for multiple sensors/devices at once, or a ton of wires. Or maybe the devices are cheap enough that you just replace them completely; in that case make sure to consider how you’re going to dispose of them!

Sensor/Device Association

Say you’re doing an asset tracking application. Great. That means you have some way of tracking the location of the asset (probably GPS if outdoors and over large areas, probably bluetooth if indoors and within relatively confined areas) by putting a device on it. But how do you know that a specific device is associated with a specific asset?

Sensor/device association (for example, device A12B3 goes with this car) can be a big hassle. It’s critical, because otherwise you just know the location of the sensors/devices but not the specific assets they’re attached to. This means that, at some point in the process, you need to make that association. Does someone have to manually enter the information? Is there a barcode on the asset that you can scan? For example, all cars have a VIN (vehicle identification number) which can be scanned. That’s awesome, but now you need to sync the information you already have in your system (the VINs of your cars) with the new location data you’re getting, and that’s going to require some integration.

Sensor/Device Errors

As much as we all hope for things to work perfectly, inevitably there are going to be errors. These could stem from a defect in manufacturing for a specific sensor/device or could be due to a bug in the firmware.

Regardless, you need a process for how you handle when a sensor/device has an error. How do you 1) identify the error in the first place and 2) address the issue once you find out?

The ability to predict and proactively address errors is absolutely critical. Dealing with errors in sensors/devices after they happen can be a huge operational burden. Just imagine trying to find a single sensor/device over square miles of parking lot when the error means that you can’t get GPS location anymore. Not fun.

Key Takeaways

The above considerations may not matter for many applications, whether that’s because you don’t need that many devices or because you’re not relying on battery power. Again, we bring up these examples simply to get you thinking and realizing that there are many purely operational factors, beyond technology, to consider when you go from prototype to pilot to full scale.

This is why many IoT deployments fail. Not because the underlying technology isn’t good enough, but because the sheer operational burden makes the return-on-investment not worth the effort. This is also why it’s so critical that you have a clear, measurable impact you’re trying to achieve with your solution.

‍