Two approaches to IoT prototyping

Taking a new device from an idea to production readiness can be a challenge. Hacks or workarounds can help you deliver a proof of concept, but they can negatively impact production devices. A development kit can be great for quickly proving out an idea, but oftentimes the hardware constraints will be more stringent in production to save costs. Some advance planning can save unnecessary effort in the beginning of the project, or heartache down the road as the project transitions to production.

Prototyping approaches

There are two broad ways to approach IoT prototyping. One is to treat the prototype as a throwaway and to start over from scratch after testing and development is complete. The other is to treat it as an evolutionary prototype and build on top of the progress already made. Each approach has its pros and cons, and there are a variety of reasons to choose one or the other. In either case, it’s better to decide which approach to take as early on as possible, as this will inform how you develop the prototype in the first place.

Throwaway prototyping

The throwaway prototype approach sounds wasteful at first, why throw away something that took so much effort to create? In reality, this can often be the best decision for your project. Here are some, but not all, of the reasons you might choose the throwaway prototype approach:

There are significant differences between the prototype hardware platform and the intended production hardware

Final hardware can be significantly more constraining than development platforms. Sometimes a quick proof of concept (PoC) will contain unnecessary bloat and computing overhead that can be difficult to root out. In cases like these, it may be better to start fresh using the lessons learned from the PoC.

The final product needs to be significantly more robust, secure, or reliable

Sometimes prototypes are only intended to demonstrate a certain set of the requirements for the final product. Has your prototype taken cybersecurity into account, for example? It may be better to take a ground-up approach when expanding to include requirements that were not a part of the PoC.

You only have the resources for a “hacky” prototype

Sometimes you need to get a PoC done in a short amount of time or on a shoestring budget. Maybe the prototype application only runs within a VM, or significant portions of the requirements were ignored (e.g. power consumption). In these cases, there may be little cost to starting fresh, and you will thank yourself in the long run for not having to constantly apply “band-aid” fixes to a messy codebase.

There were significant changes or learnings during the prototype stage

Sometimes projects evolve significantly during the prototype phase. Perhaps there are new limitations that were discovered during this phase, or new functionality that will be needed. These changes can sometimes require significant refactoring that might be more effort than starting over with a new architecture.

Evolutionary prototyping

The evolutionary prototype is the preferred method for moving to production hardware for many. With this approach, you can build on past efforts and gradually improve the prototype until it’s ready for production. There can be false promises with this approach, however, so it’s important to choose it for the right reasons. While it can seem cost-efficient to reuse existing work, trying to evolve a significantly flawed PoC can quickly become a sisyphean task. Here are some conditions where this may be the right approach:

Your team is experienced

An experienced team can more easily see the pitfalls that you will encounter along the way and will be able to lay out an architecture for the prototype that is less likely to need significant changes. An evolutionary prototype approach works much better if you have a line of sight to the end product.

Your organisation has a culture of good documentation

As the project expands and ages, documentation will be key. If the initial prototype lays a good foundation for this, it’s less likely that there will be problematic gaps in documentation in the future.

The production platform is similar to the development board

It’s key that the development hardware be reasonably close to the final hardware to use the evolutionary prototype approach. Switching from an ARM development board to x86 final hardware, for example, will present a host of challenges. Ideally the prototype will use a development kit or off-the-shelf hardware that contains the same silicon as the final product.

The OS used has official support for your production hardware

One of the main challenges moving to production hardware is the hardware abstraction layer itself. If you are using a supported OS that has certified your final hardware, this challenge disappears.

Moving to production with snaps and Ubuntu Core

 Ubuntu and Ubuntu Core have an ever-growing list of supported, certified hardware. If you planned on your production hardware being one of these supported boards, then your work is already done for you. If not, Canonical can provide board support for your custom hardware, or your team can do the hardware integration themselves. 

When enabling custom hardware for a customer, Canonical will create a “gadget snap” which provides software support for all of the required interfaces on the customer’s production hardware. This snap has some similarities to a bootloader, and contains definitions related to the physical interfaces of the board.

The PoC snap(s) will work on the new hardware with no additional intervention as long as the silicon architecture (e.g. x86, ARM) is the same. For example, a PoC snap developed on a Raspberry Pi will work seamlessly on all other ARM boards that are either certified or that Canonical has supported for the customer. This means that the engineering team working on this has absolutely no work to do as a part of this migration; they can move straight to making the snapped application production-ready.

To learn how to optimise costs during the prototyping phase and beyond, come to our webinar on October 26th. Register here.