I’ve spent the last decade of my career working on software and hardware tools for developers. Every product I’ve worked on – from web UI tools and mobile app dev services to developer-biased IoT tools – was created to help developers get something done faster. Tools designed to foster collaboration and lower the learning curve of complex technologies so that teams and companies can solve problems faster. And every product was focused on untangling all of the complexity associated with building solutions in that space.

In IoT, we have more than our share of complexity. We get all of the complexity of the software world mixed in with a healthy dose from the physical world around us.

In cellular IoT, I like to refer to this complexity as “the strings of cellular IoT.” They are the things that developers often cannot control about building IoT solutions or which exist by pure inertia. They are things that slow developers down, cut off choice, or provide unnecessary duplication of effort. They are things that lead us to search for alternatives that may be less than ideal but which feel worth the tradeoff in our frantic efforts to reduce friction.

And while there are many such strings in the cellular space, these are the ones I tend to see most often:

• Difficult-to-program modems
• Developer Guardrails
• Device lifecycle management pitfalls
• Security not included
• The meandering path from prototype to scale

Difficult-to-Program Modems

This command set – often referred to as the “AT command set” because many of the commands start with the string “AT” – was developed by Dennis Hayes in 1981 as a standard command set for interfacing with dial-up modems. If you’ve ever had to work directly with a cellular or Wi-Fi modem, you’re no doubt familiar with the Hayes command set. It’s terse and was created in a time when instruction sets were designed to save space. As a result, it’s about as developer-friendly as machine code.

It’s also still in use on many modems, including most cellular IoT devices.

For those unfamiliar with the AT command set, here’s a brief example of the commands needed to turn on a cellular IoT module, set its APN, configure an LTE band, and start scanning for towers:

For many developers, myself included, AT commands are cryptic and inaccessible. They are non-intuitive and differ from one module to the next. It’s a painful way to add a connectivity module to your application. Yet, it’s still the way of the modern world if you’re looking to integrate a cellular modem into your IoT solution.

Developer Guardrails

The challenge of working with cellular IoT modems is well-known, and solutions do exist to create developer-friendly abstractions on top. The problem is that these abstractions often come with guardrails that do too much, or too little, to help accelerate building a connected solution.

Some vendors create narrow guardrails and abstract away the complexity into developer-friendly APIs. The problem is, they also force you to adopt their Host microcontroller, their RTOS, and even a particular programming language. As nice as it is to abstract away the AT command set, cutting off developer choice in the rest of the stack is a steep price to pay in exchange.

Other vendors give you wide guardrails. They sell you only a SIM or a piece of hardware that requires you to furnish your own SIM and plan. This approach has certainly brought down the cost of IoT and M2M data plans, but it swings too far in the other direction. Developers get cheaper connectivity but are left to build up the rest of their solution stack themselves. As a result, the developer ends up with the equivalent of “writer’s block” or “blank page syndrome” because there is so much to choose from.

The either-or nature of the guardrails in place today leaves developers with a difficult selection: accept too much restriction, or forge ahead with too little guidance?

Device Lifecycle Management Pitfalls

How do you design a real-world IoT device when the cost model isn’t built to account for real-world use?

Beyond cryptic interfaces and guardrails, developers must also contend with the cost of managing devices and data, much of which is hidden from view. Every device has a price, but some have multiple: the price you pay up-front, the price you pay for data, and the price you pay for a device to change its state, for instance, when activated or deactivated.

When a device has multiple price components or shadow costs, it can be hard to know exactly what your IoT solution will cost you. Especially since the reality is that IoT products don’t follow a happy path where they fly off the shelf, are deployed into the field immediately, and are used forever and ever without end.

Instead, most IoT devices tend to go through a pretty consistent lifecycle:

• A inventory and distribution stage where they sit idle.
• Activation when they are first used.
• A period where they fall into less than regular use, but the device is still “online” and accruing fees.
• A period of temporary breakage, and it can often take months before the issue is identified and fixed.
• Re-commissioning after the device is fixed.
• A period where the device is decommissioned permanently.

Now imagine that you’re paying the same monthly data fee for every one of these stages, regardless of actual use, as well as charges for activation, re-commissioning, and decommissioning. The challenge in the cellular IoT space is that each of these phases in the device lifecycle comes with carrier fees and transaction costs that can be difficult to plan and budget for. As a result, when most developers look at an IoT device, they don’t know its true cost.

How do you design a real-world IoT device when the cost model isn’t built to account for real-world use?

Security Not Included

Key and certificate management is an essential part of every IoT solution. There’s also the string of security, a topic that developers are ever conscious of, but many providers don’t bake into their products. And with all major IoT cloud services now requiring TLS, in the absence of baked-in security, developers are forced to store keys and certificates in firmware to connect their devices to cloud services.

With keys and certs in firmware, your IoT devices become yet another sensitive vector that an attacker can use to get the (literal) keys to your kingdom.

The Meandering Path From Prototype to Scale

Finally, there’s the string of the disconnect between prototype and production solutions, even as developer-friendly tools abound. As developers, we should consider ourselves fortunate that prototyping is accessible today, thanks to companies like Arduino, Adafruit, SparkFun, and the Raspberry Pi Foundation. But because much attention has been paid to how “maker friendly” these devices are, they are often dismissed as not production-ready. IoT engineers will gladly use these accessible tools to prove an idea at the prototype stage, but throw those prototypes away and start over when it comes time to build a “real” solution.

But if these tools are good enough for the Mars Ingenuity helicopter, they should be good enough for our solutions. And IoT solution vendors can absolutely do more to minimize the throwaway mindset with tools that make prototyping easy from the start and which level-up to pilot and production scale just as seamlessly.

Complexity Kills

When taken together, the strings of cellular IoT create a developer-hostile environment where complexity rules. From the start, the path from selecting a board to building a prototype to deploying and scaling a pilot is filled with hurdles and roadblocks that make it hard for many initiatives to succeed.

• Cellular
• Connectivity

• Cellular
• Connectivity