5 Key Steps To Successfully Getting Your IoT Innovation From Prototype To Production
We’ve been thinking a lot about the stages that an IoT innovation goes through, from the lightbulb over the head moment through to hopefully mass deployment. At the risk of sounding like every Buzzfeed article you’ve ever read, we’ve grouped them into five steps, each presenting a set of challenges and considerations about IoT connectivity. The decisions you make at each point about connecting the ‘thing’ to the internet will intensify as you scale. We’ve summarized in the image below the 5 key stages of an IoT project and the IoT connectivity considerations (Wi-Fi, LoRa, Satellite, LTE, NB-IoT etc.) you’ll need to make along the way.
Every IoT project starts with an idea, not a purchase order for $100,000. Today, makers have never had it so good for quickly turning those concepts and ‘what-ifs’ into something real. In many cases, a Raspberry Pi or Arduino will do the job fine. Connectivity also isn’t a problem at this stage. You could even use a physical cable to link the sensor to the Dell Edge gateway, although Wi-Fi is the more likely option.
In my time in the industry, rapid prototyping has become easier and cheaper. It used to be very expensive and a big commitment to create early-stage proof-of-concept devices; now, you can get a< Chinese manufacturer to build in volumes of one. But once you bring the proof of concept from your lab to the field – whether that’s to an actual farm or to an investor meeting – can you really rely on the Wi-Fi signal? Depending on the environment, you might think cellular connectivity is your best option, so traditionally, many makers have you gone to their nearest mobile operator (many of whom we partner with) to buy a cheap SIM card.
Here’s where the questions start to come thick and fast, however. Once you have an idea of what you’re trying to build, will any of the connectivity options you adopted at the earlier stage still be with you as you refine your original idea? Will you be able to source SIMs reliably at higher volume? Will the cost model of buying retail SIMs work with a 500-unit-a-month deployment? This step is where you’ll encounter issues like security, authentication, or authorization on your connectivity. Can your chosen connectivity handle these issues reliably?
By design, IoT devices are constrained – that term has a specific meaning which implies limited processing power, storage and bandwidth. Where you plan to physically deploy will be a factor: if you aim to put a miniature computer on every streetlight, it isn’t practical to visit every one of them every Tuesday to install a patch. Or, if you fit a sensor in the road which is then embedded under concrete, you only have one time to get it right.
So, what type of connectivity are you going to embed in your service as you deploy it? This isn’t a trivial question. If you’re serious about building an IoT innovation to operate on a global scale, it makes sense to think about IoT connectivity from the very start. Otherwise, you’re stuck on the treadmill, continually solving the same problems over and over again as you progress through the five steps as outlined here. SIMs from the EU will not roam in Saudi Arabia, and a US SIM won’t necessarily work in France. In some of the biggest growth markets, Saudi Arabia, Turkey and Brazil, the governments don’t permit global or permanent roaming. We’ve seen similar restrictions in places like Cambodia, Indonesia and Myanmar. So if you want to ship your ‘thing’ all over the world, you’d better be sure at the idea, prototype and iterate stages, that you’ve built in connectivity that works for your global> application.
The assumption we’ve made all along is that connectivity is hard. Simply putting your devices on Wi-Fi doesn’t give you guaranteed service, besides the fact that connecting constrained, or low-power devices to the public internet is not a good idea. As we like to say at Asavie, there’s nothing quite as complicated or dangerous as simple connectivity.
Fortunately, technological advancements have come to our rescue yet again. In the old days, you had to pay in advance for technological capacity that you guessed you might need to use months from now. Cloud computing services like Salesforce.com and later, Amazon Web Services or Microsoft Azure completely upended that model, giving enterprise-class software tools to smaller companies, who only had to pay for what they used.
That same model now applies to connectivity, to let you link services and ‘things’ over the internet at industrial scale but at volumes of one (idea), so you can start small and then flex your network as you go through the subsequent steps (prototype, iterate, deploy and scale). Asavie PassBridge® enables the ‘declaration’ of an IoT network topology via an API. By applying software automation to what has previously been a collection of manual, bespoke steps, we offer a million-device network for a single bench device. The environment can be stood up, used and thrown away or stood up, used and scaled.
This network contains a single unified RADIUS server, policy router, and firewall engine: in short, all of the network components that need to be present. If you need to mix and match multiple different connectivity types, you’re not locked into a solution from one mobile operator, for example.