Starting with One

Designing for the Internet of Things

This is the second article in a series of six on designing connected devices, the first article in the series is “Where Does Your Smart Product Sit?” and talks about product design. The next is “Your Developers’ Experience” and talks about prototyping and product design. Links to all six articles can be found in the series overview.

Every idea begins where no one else can see it, inside someone’s head. While it lives there it always appears more fully formed than it actually is, it’s important to get the idea out into the world as quickly as possible. Because there it’ll meet the corner cases, the “what happens if?” questions that you haven’t thought about yet.

However while it’s important to take the idea and get it down on paper, it’s far more useful to build prototypes. Many individual prototypes will be needed. Sometimes a whole prototype is needed to examine how an individual feature of the product will work. But building the physical product that results often begins with two separate versions, the “looks like” and “works like” prototypes.

The “Looks Like” Prototype

The first, the “looks like,” is in the hands of designers. Typically this prototype ends up being made from materials that don’t resemble your final product in the slightest, good materials include balsa wood, clay, or cardboard, although recently many designer have started to use 3D printers to build more comprehensive prototypes than was possible before.

Almost certainly this prototype won’t do anything, except sit there and look like the product. However while early versions of this prototype can be just a solid object, a single non manipulable lump of matter, it’s vitally important that if the product itself can be manipulated, folded, unfolded, twisted, then later versions of the “looks like” can to.

The point of this prototype is so that the product designers in the first instance, but later potential end users, can get a look and feel to the new product before it exists rather than after. It can directly drive product design by influencing, say, the placement of controls and by showing how the end user may interact with it, but it also drives the “works like” prototype which should be under development in parallel.

Physical characteristics like weight of the product, its size and hence the available internal volume for components, need to be driven by the “looks like” prototype as much as possible. While engineering necessities, and the laws of physics, aren’t bendable, and can constrain the final product — for instance aerials for specific wavelengths are required to be certain lengths — its helpful to start out with a design rather than engineering led approach to building a physical product.

After all, in the end, the day-to-day experience of the end user will be with the physical manifestation of the product rather than its internals. In an age of almost instant product parity, if it can be built it can be copied, then design led product creation can be a distinct market advantage. The obvious most successful example of a design led approach is Apple.

The “Works Like” Prototype

A “works like” prototype often starts with a breadboard, some components, a micro-controller board, and some ideas. But it’s important to keep several things in mind as you sketch your project in hardware. Foremost perhaps is the interaction between the engineering and design teams. In many larger companies there is a large air gap between these two teams, however it’s important that everyone employed in building the product should think like designers. Just because something is possible it doesn’t mean it should be done. Adding extra controls, or displays to a product is a classic mistake at this stage of the product life cycle.

Over the last few years we’ve finally reached a point in the software design world where we’ve figured out that offering the user choice isn’t necessarily the best thing to do. More choice isn’t necessarily a good thing, sometimes in fact it can be a bad thing, a confusing thing. Every control you add is a design decision you aren’t making, effectively you’re offloading the design of your interface, of how things should work, onto the user.

Passing these decisions might be necessary, however they should be carefully considered design choices, taken in part by the engineering team through necessity, but driven in the end by the user.

A classic case of design versus engineering decision making was the remote controls for the original Google TV compared to the Apple TV. The Google remote was large — around the size of a small tablet — and included a full keyboard along with two large pad controllers and a number of single function buttons. The later was small, light, and featured a single way way control pad and two buttons. A deliberate design decision had been made that a full keyboard wasn’t necessary, that users would only infrequently use it, and the decision was made to make the remote control smaller as a result, and much simpler.

Not only did this decision hugely affect how the users interacted with the remote, and the TV, but it drove the “works like” prototyping and later product builds.

The Google TV remote control represented design indecision, passing on design decisions to the user, decisions that should have been taken by the designer themselves — just once — instead of by the user every day of their lives.

Don’t fall in Love with Your Parts Bin

For the first “works like” prototype, where you’re just throwing components onto a breadboard as fast as possible then it’s sometimes convenient to use whatever you have to hand. That can be a good thing if you’re an experienced product engineer, and your parts bin consists of things that you’ve used in other successful products. However it can be a bad thing if you’re not, especially for engineering teams based in the western world who will often be working under the expectation the final product will be built offshore.

A lot of the components typically used during prototyping aren’t readily available in China. While some are readily substitutable, parts that are functionally identical, its possible that even these have different footprints. If your prototype relies on a part that has to be sourced from single manufacturer, who many not be able to supply you with sufficient volume quickly enough, or is not commonly available in the local supply chain of your contract manufacturer, you may run into problems during manufacturing. Substituting a new part into a design, especially one where the footprint of the electronics is heavily constrained by the form factor of the device, at the last minute because you can’t source enough components can add large costs, and large time overruns to building and shipping your product.

While final product manufacturing may seem a long way off when your considering your first “works like” prototype, choices made at the start of engineering design have a tendency to become set in stone as the later prototypes evolve. Therefore it’s important, especially if you’re building a hardware product for the first time, to fill your parts bin with parts that are readily available. Readily available parts are more affordable, resulting in a lower Bill of Materials cost, and can be sourced from multiple manufacturers if needed, resulting in a more reliable supply.

Several contract manufacturing companies have established parts catalogues to advise your parts choices. For instance SeeedStudio has compiled an Open Parts Library (OPL) catalogue which is a collection of the most commonly used components. Using OPL components in your PCB design means that SeeedStudio will have sufficient stock to fulfil on short lead times, at lower costs.

Other sites, exist to simplify the component discovery process. Using these types of site when considering your parts choice means that you can manage exposure to supply chain risk. You can get an feedback not just on the availability of the part, but also the lifecycle stage of the component, and variation in cost over time and between competing suppliers.

When assessing whether a component should be designed into a product in the first place, its important to consider not just whether its available now, but whether it’ll be available over the entire lifecycle of your product. While some components, for instance microprocessors, are by necessity a single source purchase you should consider whether a more common component can be substituted. Especially for critical components, like microprocessors, supply volatility can lead to your product being retired from the market early or to large scale disruptions in supply of your product. In the worse case a costly mid-life cycle redesign of your product may prove necessary.

Iterating Your PCB

After moving away from the breadboard the design of your first prototype printed circuit board (PCB) should consider not just the final product but also the need to iterate quickly through a number of PCB designs. This iteration will be driven primarily in fixing the inevitable mistakes, almost no hardware prototype will make it through design without multiple ‘green wire’ prototypes—called ‘green’ wiring because, historically, assembly houses used green wires to try to make it blend in with the board. These prototypes route around design mistakes, or assembly problems, using additional wires soldered directly to the circuit board, and can persist much later in the design process than most people realise.

You should attempt to minimise the number of layers on your PCB. If your PCB isn’t clocked at a high frequency, may be able to get away with a single or two layer board, although many modern boards will require more than two layers. This will both make debugging easier, and minimise the cost of the product. It will also give you a larger number of fabrication options, the fewer the layers the more assembly houses are available to you.

If you can constrain your design to a smaller number of layers this will also speed up prototyping as you can make use of one of the community fabrication services to rapidly iterate through PCB prototypes. These services, such as OSH Park, take short run orders of boards from a lot of people and put them together on a single panel, and then order the panel from a fab. Since the cost of the panel — the minimum viable order for a fab — is split between a lot of different customers who are producing boards individual prototype costs are much lower than would otherwise be expected. However most of these services are limited to two, or at most four, layers and may have other design constraints, such as the absence of blind or buried vias.

Over time, you’ll learn to recognise which traits your prototype should pass on to its successor. While your initial prototype will make use of components you have to hand you should refine the “works like” as time goes on and production comes nearer. This refinement shouldn’t just be about choice of parts, but also PCB layout. Layout will inevitably be driven by the “looks like” prototype as it evolves closer to a final product.

Some Assembly Required

While its tempting to assume that your engineering team is competent to handle assembling your PCB prototypes, but if your board is non-trivial you should consider using professional assembly services as it may not be a good use of their time to spend a day, or more, hand soldering components onto a prototype board and then potentially more time debugging the build.

You should therefore assess the opportunity cost of outsourcing this job to professional assembly house. While assembly can be very expensive unless you are building thousands of pieces, there are specialist assembly houses such as Screaming Circuits that specialise in building short-run or one-off PCB and have rapid turn around times.

This is where a standard ‘parts kit’ can come in useful, if your board is constructed from easily obtained standard parts then a competent assembly house may well have all the components they need on hand leading to a rapid turn around and the ability to quickly iterate your PCB design.

Optimising for Manufacturing

When designing your PCB you should also consider the quantity your going to order. For small runs, a few thousand units, its potentially not worth optimising the PCB for pick-and-place over hand assembly as a surprising about of hand-finishing, or hand-assembly, of boards still continues to occur. Especially when using a single through hole component on a board, which must be hand soldered as part of the production line after the surface mount components have been added, may cut Bill of Material costs or make the board more robust to damage. For instance surface mount USB connectors are notoriously easy to for the end user to damage during use of the product and many manufacturers prefer the through hole versions as a result. However if your product is intended for an extended production run the opposite may hold, optimising for surface mount components and pick-and-place assembly may mean a significant saving in production costs.

Creating a Bill of Materials

The critical starting point for manufacturing is the Bill of Materials, this serves as the foundation for building the product. A well constricted Bill of Materials (BoM) doesn’t just communicate the ingredients needed to build the product but conveys much more information.

From the information contained in the Bill of Materials it should be possible to determine the lead-time to procure the materials necessary for production, the manufacturing processes necessary to bring them together, the time to manufacturer and ship the product.

Working from this information you should also be able to determine the robustness of your supply chain and the final cost of the product when costs, development and margin have been taken into account.

Like prototypes your Bill of Materials will evolve with time. During the early phases of your design cost of parts and materials will inevitably be high. This represents the off-the-shelf cost in low quantities of the parts you are using in the design. However even this early draft should be able to flag possible production problems, like long lead times on certain components.

While most companies understand the importance of the Bill of Materials there is little consistency in format, and that can add a lot of friction when dealing with contract manufacturers. Especially when not all the parts are listed, the importance of your BoM being complete can’t be overstated. To combat this there have been several recent attempts, for instance the Dragon Standard BOM to produce standard Bill of Materials templates and, especially for first time product builders, these can be invaluable.

Code and Hardware

In recent years hardware has come to be seen as “software wrapped in plastic” and, while it’s not a popular view with hardware engineers, these days the code running on your hardware can be just as important if not more so than the hardware itself. Like design, in an age where all things that are buildable are rapidly copyable, the software running on your device may prove to be even more important than the hardware it runs on.

You should also consider the possibility that your code can be used again, and write your code for reusability. If you’re building one product, it’s likely you may build a second version, or a third. Separating the code that talks directly to the hardware of your device — the dials, sliders, buttons, knobs, and other physical things — from the code that talks to the network.

With the drop in the cost of computing, many manufacturers are now basing their connected device around fairly powerful processors. In part because those are now easier to obtain, and just as cheap, as more limited computing platforms. But also to make development easier. A common pattern emerging in this space is to have the code that talks to the hardware running as a separate process to that which implements the functionality of the networked device. This code, which may be written in a much lower level language than the application which manages the rest of the connected device, often times uses a REST or other network level API to talk to the management code.

This means that the bulk of your device code can be written in a higher level language, decreasing developer time and increasing your pool of development talent, but also means that the management code can expose command and control functionality in just one place. The same REST API used by the device’s own hardware can in turn be exposed by the device’s network interface and used to control it from a smart phone or other network device.

Accumulating Technical Debt

Just because it’s a prototype doesn’t mean you should cut corners, because temporary solutions often times will become permanent ones due to inertia. This can mean that your final product is laden with what is known as technical debt, a measure of design or software quality technical debt occurs when work is done because it is easy to do in the short term rather than applying the best long term solution.

When you are prototyping you should alway be aware whether the prototype you are working on is what is known as a “throw away” prototype, or is intended as an evolutionary prototype. Especially in the early days of prototyping most engineers will iterate through several throw away prototype stages and, despite inevitable time pressures it is important that these prototypes are indeed thrown away.

Crowdfunding Is Not a Panacea

The way to build a software startup has been codified almost to the point where you could chisel it on stone tablets. There’s a recipe that most software startup founders follow, but founders of hardware startups always found more difficult to follow the recipe, and as a result they eagerly turned towards crowdsourcing for their funding. Even today, hardware startups seem to be far more likely to be bootstrapped, or crowdfunded, than software startups.

However for small teams crowdfunding can lead to big upsets when moving between the prototyping and production stages . If the difference between the number of units expected and the final number of units required is large, then production methodologies may need to be modified, and in the worst case a switch of contract manufacturer could be needed. This can cause large cost overruns, and long delays, to manufacturing and shipping.

You should only attempt to crowdfund your product once the product development is sufficiently near completion that your Bill of Materials, Cost of Goods Sold, fixed costs, and distribution margin, are well known. Turning to crowdfunding before this stage will almost inevitably lead to disaster.

Alasdair Allan
Scientist, author, hacker, maker, and journalist. Building, breaking, and writing. For hire. You can reach me at 📫 alasdair@babilim.co.uk.
Related articles
Sponsored articles
Related articles