How to be Strategic about Building your IoT Prototype
Guest WriterGuest Writer
“Plug it in, this time everything just might work!” is commonly spoken just before switching the power of a prototype on, only to see it catch on fire, begin convulsing, or much less spectacularly but much more commonly, do absolutely nothing.
Hmmfff! What did you miss this time?!
The fact is, creating an Internet of Things (IoT) prototype is one of the most rewarding, but also frustratingly challenging engineering processes there are.
It is rewarding because for the creative mind, the Internet of Things represents new and frontier opportunities to interact with the world around us – and for the world to interact with us – in novel ways.
It is challenging because IoT products – while appearing sleek and simple – are extremely advanced engineering projects that span many historically disparate disciplines: electrical engineering, firmware development, mechanical integration, wireless networking, mobile app development, server and database design, and cloud processing.
It is frustrating because we live in a world of gigabit internet and the ability to stream Netflix on a cellphone. How could reading/writing tiny pieces of data from my IoT device be HARD? IoT is constantly evolving, and keeping up with the newest tech can be downright disheartening.
Ok, so you have finished the ideation process and are ready to start building the prototype. Whether your ideation was on the back of a napkin, or through a detailed PDS (Product Design Specification), jumping directly into building a market-ready product is risky.
The unknowns are plenty: what features will your customers care about the most? What unexpected value items you design into your device will they simply dismiss? What will they demand that isn’t your product yet? What will be the most costly and difficult part of the design?
You may have some well educated and researched guesses, but the fact is you don’t know what you don’t know. Furthermore, making wrong guesses with IoT hardware can be much more costly than guessing incorrectly in software development, mainly due to the longer time required to “recompile” electronics.
It becomes vital to build a prototype design for feedback to begin testing some of these assumptions before expending the upfront costs of production, but oftentimes capital or time disallow you to remain in prototype-land for long. The solution to this sensitive and complex conundrum is strategic prototyping.
Now, the decisions you make as you set off with your prototype development will dictate if the prototyping process is painless, fast, and yields the information you are looking for; or if the process will take six-plus months and leave you with a sore forehead from banging your head against the multi-layered wall that is IoT hardware development.
The goal of this article series is to equip you with tools to be successful in your IoT prototyping.
There are great tools available for connected hardware development [more detail to come in part two of the series], and currently you don’t have to do much of the development yourself.
However, for every product development process, there has to be an informed captain at the wheel that understands where to start, what tools to use, and how to architect your prototype, allowing you to literally save MONTHS of development time.
Below, we will focus on deconstructing and understanding your IoT development needs to identify the primary goals of prototype, to become aware of the constraints, and to breakout the design into its functional pieces.
An IoT prototype will always have at least two, and usually three integrated interfaces:
A key frustration that makes developing an IoT prototype so challenging is that the skillset required to create an interconnected program for a hardware device is very different from the skillset required to develop and maintain a web server, and vice versa.
This leaves a skilled software engineer floundering when approached with the task of developing a schematic for a hardware prototype, and an electrical engineer scratching their head when confronted with developing an industry standard iOS mobile application to control a device.
We've developed a methodology, we call it an anatomy, for an IoT prototype roadmap which we call the Goals-Constraints-Modules [GCM] Diagram.
Below we are going to break down each of the pieces of the GCM Diagram. While it may initially look complex, it can be an extremely useful tool to put together a strategic prototyping roadmap quickly, and can substantially assist in identifying the key pieces of the prototype and the selecting the right tools to build your device correctly.
The first step in our prototype methodology is to concisely define your prototype and its purpose at an architectural level. This is the “Goals” section of the GCM Diagram.
Presumably you are building an IoT prototype because you are working to make something that doesn’t exist or is not easily attainable. What is it about your device that makes it special? What does it do? How does it work? We call this the “Goal” of the prototype, and its key to mapping out the flow of information within your device and its layers.
It turns out that even though an IoT prototype is complex, you can represent the information architecture – the “goal” – quite simply. Below are three examples showing Goals for three different IoT prototypes.
Here’s how to set the goals for your prototype. Look at each of the pieces of the prototype. Look at the physical device. What is its purpose? What is it doing? And how does it communicate with the mobile application and/or web application? Look at the mobile app and ask the same question. And again for the web application.
The goals sets the overall scope for the prototype, next it is important to understand what constraints exist upon your prototyping process and on the prototypes itself. This is the “Constraints” section of the GCM Diagram.
These tend to be the common constraints for an IoT prototype however, further constraints specific to your prototype may be determined by asking the following questions:
What is the goal of the prototype – is it to do field testing to prove out the idea? Is it to show your managers/board to get approval for further funding? Is it to show investors to raise money? Or, is the prototype the end in itself?
Understanding what are the key constraint for the prototype, what are the secondary constraints, and what are non-issues will provide more clarity on how to approach the prototyping process.
Now that the goals and constraints have been defined for your prototype, the last planning stage is boil the prototype down into its functional pieces – this will provide clarity in selecting the right tools and hardware for the prototype. This is the “Modules” section of the GCM Diagram.
All IoT products need at least one of the following elements:
Further, most IoT products will have a variety of the following modules:
Let’s look at each of these module categories to get a sense of what modules may be right for your prototype.
How is information going to be connected from your device to the internet? This can be performed either wirelessly or through a wired connection.
The most common wireless communication modules are:
Other less common communication modules that you may want to look into for you device
The processor is the brain of your prototype – an IoT device processor will typically be a low-power microcontroller.
There are three things to watch out for when selecting the processor:
Common Processors for IoT prototypes are:
An IoT device is oftentimes low energy, but it still needs to be powered. There are a variety of power options – selecting the option appropriate for your prototype stems from the constraints you’ve identified in the GCM Diagram.
Common power modules for IoT Devices are:
There are several modules that allow for user interaction with the device.
Examples of user interaction modules are
There are several modules that allow for the device to gather information from the surrounding environment.
Examples of environmental interaction modules are
There are several action modules that allow for the device to alter states of the objects surrounding it
Examples of action modules are:
Prototyping is a critical piece of IoT product development. However, without properly defining the goals, constraints, and modules of your IoT prototype, determining how and where to start the prototyping process can be daunting.
Using the GCM process to predefine all pathways of your IoT prototype provides clarity on the prototype goals and can act as a compass in selecting the proper tools to rapidly get started in a rewarding and obstacle-free prototyping process.
Once all of the functional modules of the device are identified, scoping out the correct hardware from online vendors such becomes much quicker. We will take a deep dive into selecting right tools, platforms, and hardware for your IoT prototyping in Section Two of this series.
Written by Daniel Price, CEO of Breadware.
New Podcast Episode
Recent Articles