Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Nathan Hart
on 25 October 2022

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.

Related posts

Nathan Hart
5 January 2023

Security in the smart home: considerations for device makers

IoT Article

When people think of home security they usually think of an alarm system with a keypad next to the door. These days, however, home security should have two meanings. I’m here to talk about the second: cybersecurity. In other words, security in the smart home. A recent investigation found that a shocking number of leading ...

13 February 2024

Simplify IoT device management: How to add Ubuntu Core devices to Landscape

Internet of Things Article

Landscape has been a member of the Canonical product list for almost as long as Canonical has existed. Landscape allows administrators to manage their desktop and server instances from a single centralised portal. With the latest release of Landscape Server (23.10), we’ve introduced the ability to manage snap packages from Landscape – and ...

6 July 2023

불변의 리눅스 데스크톱 기반으로서의 우분투 코어(Ubuntu Core)

Desktop Article

캐노니컬(Canonical)은 IoT를 위한 완전한 컨테이너 플랫폼을 만들기 위해 2014년에 우분투 코어 개발을 시작했습니다. 우분투 코어에서는 도커(Docker) 및 LXC가 구축된 것과 동일한 커널 컨테이너 기술을 사용하여 잘 정의된 업그레이드 및 롤백을 통해 시스템의 모든 구성 요소를 안전한 샌드박스에 넣습니다. 저희는 자율적으로 연결된 사물 인터넷 장치가 사람의 개입 없이 적용할 수 있는 업데이트를 수신하여 에지에서 보안 및 ...