A Rapid IoT Prototyping Toolkit

 

Agile methodologies have become quite popular in the software engineering community; while definitions vary, many would include building complete, though minimal, functionality first, so the product can be experimented with early on. This allows for the development team to determine if they're actually building the right piece of software early on in the process.

Obtaining early user feedback (even if just from the development team) is arguably more crucial in the IoT space. Most IoT products will involve both hardware and software components. It is important to know that the hardware can operate as desired; for example, for a product dependent on sensors, it's critical to know that the sensors are returning data of acceptable accuracy, precision, and regularity. More importantly, we need to verify that whatever is being done with this data is useful – can it be used for accurate predictions, or to prod user behavior, or to generate useful information displays?

Outlined in this article is one toolkit capable of helping to answer these questions. Specifically, this is a toolkit designed for IoT prototyping. Prototyping, as used in this article, is the process of creating a crude subset of what the final product is envisioned to be. It is developed without regard for scalability, security, or expandability. Its role is to validate design decisions quickly, and to iterate on the design until you've been able to empirically determine that the designed product is in fact the right product.¹ This is reminiscent of Fred Brooks' maxim to 'build one to throw away'²; once its purpose is served, production development can be started with appropriate tools.

"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." – Donald Knuth.³

Prototyping vs. Finish-grade Tools

A brief word is in order about the general difference between tools suited for prototyping and those for final production. Prototyping tools generally trade off some form of quality to achieve speed of development. A 3D printer allows for much faster form-factor creation than injection molding, but is obviously cruder in looks. An interpreted software language may execute slower than a lower-level compiled one, but may be quicker to develop in and have more extensive libraries. Another "tool" is the simple omission of functionality – if we are developing in a secure environment with only a few devices and users, we can simply omit security and authentication functionality and not worry about scaling issues in the prototype architecture.⁴

Toolkit Overview

The author has found the following tools and methodologies useful in IoT prototyping. The general idea is to build an architecture like that of a modern web application. At a very high level in this model, the IoT hardware sends data over a network (or the internet) to the backend software for storage and processing. The user interface is built as a web application, which allows it to be viewed on a broad range of devices. Additionally, this architecture abstracts away the IoT hardware, so teams can be helped by developers without experience in embedded software.⁵

In general, all of the needed software pieces are available for free as open-source software. Many very powerful hardware platforms are also available quite cheaply now. Often, an older computer running Linux (or Linux in a VM) is more than powerful enough for the low traffic of a prototype environment, but one could also make use of cloud computing servers. Generally, the tools the hobbyist or maker community uses make for excellent prototyping tools, even in an enterprise environment.

Hardware

There are numerous microcontroller boards available for under US$100 that have analog and digital I/O and networking connectivity. The various Arduinos have perhaps defined this category, and competitors have often released boards that are (mostly) compatible with Arduino software, which is essentially a subset of C. The Arduino Yun is a capable board with Ethernet and WiFi built-in; Particle, Intel, TI and others also make similar boards. Many of these also have daughterboards available to add functionality, e.g., motor control or sets of relays. In some situations, it can be advantageous to have a full computer available; the Raspberry Pi is extremely popular and interfaces well with Arduinos, but multiple options exist. In general, with any of these, battery operation is not recommended, as these devices are generally not built for power efficiency.⁶

Software

There are a huge number of software products to choose from in the modern web application stack.⁷ In general, a dynamic, interpreted language such as Python or Javascript (in the form of node.js) will be faster to develop with than C/C++ or Java. Additionally, these languages often have web frameworks that can accelerate the building of a web app; furthermore, those frameworks often have simple web servers that can be used for testing, removing the need to install and configure a separate webserver.

In the author's work, it was found that Python and the flask web framework allowed for very rapid web app development.⁸ With flask, a program can be built that accepts data from the hardware via an HTTP POST. Often it's useful to store this data to disk, either by writing directly to a file or to a database such as PostgreSQL. This same program can be configured to serve data to the frontend via HTTP GET requests, as well as serving the frontend program itself.

Python in particular has excellent numerical computing tools available in the form of NumPy and SciPy, in case the data requires server side analysis. If this analysis is extensive, one primitive but effective trick is to have the web server simply dump the raw data into a table in the database; a separate program can then continually poll the database for new data, process it, and write the results back to a different table. The webserver can then be serving the frontend from this second table. Again, this is an inefficient architecture in terms of machine utilization, but can be very efficient in terms of developer utilization.

The frontend will take the form of an HTML5 application. There are many ways to accomplish this and much code available online. In general, using open-source tools such as Bootstrap (for general page layout and look), jQuery (for interactivity), and D3 (for graphs) can get you quite far.⁹ Frontend development is changing rapidly, though one constant is that nearly everything will be written in Javascript. Be sure to use the developer tools available for your browser; these can be extraordinarily helpful, not just for debugging, but also for simulating different form factors and screen sizes.

Final Thoughts

Many of these tools can be found in hobbyist projects – stores such as adafruit.com and sparkfun.com have many tutorials about building things with them. It can be useful to try one or two of those to get a feel for the different components and how they interact. Once you are used to them, you'll find you can get prototypes up and running quite quickly. You'll also start to build a repository of your own code you can reuse, saving you time in the future.

Lastly, it's worth reemphasizing the point of enabling rapid development is to learn from the prototype. Make sure to test it like a user would. If it's a consumer product, try to find members of the target market to test it. What seems intuitive to an engineer may be unintuitive to a consumer. It's worth keeping in mind that you don't need a prototype – you need the knowledge it gives you access to.

References

1. In practice, it is reasonable to prototype different parts of the product at different times in the development cycle; that is, there probably will not be a time when the learning is done. Figuring out how much experimentation, and when to conduct it, is outside the scope of this article. The lean startup community has written much about iterative product development, and much of this is as applicable to IoT products as to pure software products.

2. Brooks, Frederick P. (1975). The mythical man-month: essays on software engineering. Reading, Mass: Addison-Wesley Pub. Co.

3. Knuth, Donald. 1974 Turing Award Lecture, Communications of the ACM 17 (12), (December 1974), p. 671

4. This assumes, of course, that the purpose of the device is not security or authentication, and that we have reason to believe scalability, while it may take some development time, is straightforward to achieve.

5. One other important benefit is that by making the hardware communicate to the backend through a strictly defined API is that one can 'stub out' the hardware; that is, create a software module that simulates the hardware communicating with the backend.

6. Consider putting this entire prototype on a simple consumer-grade wireless router. It will isolate it from your internal network; additionally, you can have visitors associate to the AP and run your software on their own mobile device (see next section).

7. See, for example, http://insightdataengineering.com/blog/pipeline_map.html, where three to five options are shown for each of twenty-two different functional blocks!

8. See http://flask.pocoo.org. Similar frameworks exist for node.js.

9. One useful variant on this architecture would be to have your microcontroller send sensed (numerical) data as key-value pairs, i.e., as JSONs. (You can find an Arduino library for this). Write the entire JSON into the database as-is, using the received timestamp as the primary key. The frontend can now request data for a time interval, and get back a collection of JSONs. Furthermore, you can write the frontend to be ignorant as to the contents of these JSONs, and simply iterate over each item found and graph or summarize them accordingly. This means you can change and add sensors to the prototype and only have to change the microcontroller code, with the UI automatically updating.

Acknowledgements

The author would like to thank Tyler Reid for his comments and feedback on drafts of this article and reviewing for accuracy.  Any errors, of course, remain the author's own.

 

---

 

Shayne Hodge had a career-defining moment in grad school, when he read Dealers of Lightning, a history of Xerox PARC in the 1970s, and realized his real interest was in the commercialization of really interesting technology. Mr. Hodge spent his early career working as an attorney in patent litigation, before returning to the tech world proper in the IoT and analytics fields. He was most recently at Jut.io, and, prior to that, Cisco Systems. He is a member of the IEEE and holds a B.S. and M.S. in Electrical Engineering, a JD, and an MBA. More of his musings can be found at purplequark.com.