Know Your Device’s Role

Where does your device sit? What is its role? Edge device or gateway? More and more, the answer is both.

As connected devices are increasingly deployed into every corner of our environment, the need grows for them to be self-sufficient. More and more wireless modules, such as those from Espressif and Nordic, have a microcontroller that can run custom code and interface directly with sensors over GPIO, I2C, and SPI.

Sensors can also gather a tremendous amount of data. With a low-bandwidth or limited-data connection such as a cellular connection, it’s ideal for the device to do as much processing on the data as possible before relaying it to the cloud.

As you develop your prototype, you’ll understand its role better. How much will your device do on its own? Will it just relay raw sensor readings to a central gateway device? Will it read sensor readings, perform some processing, and then relay it to a gateway? Or is the device itself the gateway, reading sensors, processing data, and sending it on to the cloud independently?

The answers to those questions will come from the physical (and software) environment you are deploying in as much as which hardware choices you make.

Don’t Fall in Love with Your Parts Bin

For the prototype, where you’re just throwing components onto a breadboard as fast as possible, it’s sometimes convenient to use whatever you have on 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 projects.

But new components, whether new generations of existing parts, or entirely new parts, become available quite regularly. When Espressif introduced the inexpensive ESP8266, it was a big deal for prototypers. Here was an inexpensive module ($2 in single-unit quantities) that not only could be used to add WiFi networking to a prototype or a device, but could itself be programmed. In many prototypes, the $2 ESP8266 has enough I/O and processing power to completely replace both an Arduino and WiFi module. This device came to attention in mid-2014, and by mid-2016, its use was widespread.

In addition to keeping on top of new and emerging components, you need to maintain reliable standbys in your parts bin. Because choices made at the start of engineering design have a tendency to become set in stone as the later prototypes evolve, you can’t afford to prototype with a component that has reached end-of-life. 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 easy to source. 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 catalogs to advise your parts choices. For example, SeeedStudio has compiled an Open Parts Library (OPL) catalog, which is a collection of the most commonly used components. If you’re working with Seeed, using OPL components in your design means that Seeed will have sufficient stock to fulfill on short lead times, at lower costs than other components.

Other sites, such as Parts.io, exist to simplify the component discovery process. Using these types of sites when considering your parts choice means that you can manage exposure to supply chain risk. You can get feedback not just on the availability of the part, but also the life-cycle 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, it’s important to consider not just whether it’s available now, but whether it’ll be available over the entire life cycle of your product. While some components may only have a single source, you should always try to find a more common substitute. Supply volatility of components can leave you unable to find a critical component, which could lead to your product being retired from the market early or a costly mid-life-cycle redesign of your product.

Creating a Bill of Materials

You may start most products with a single model, but eventually, you’ll need to make many. Whether a dozen, one hundred, or one million, you’re going to need to make more than one.

The critical starting point for mass production is your bill of materials, which serves as the list of ingredients for building the product.

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, and the time to manufacture and ship the product.

While most companies understand the importance of the bill of materials, there is little consistency in format, and that can add friction when dealing with contract manufacturers. To combat this, there have been several attempts² to produce standard bill-of-materials templates (e.g., the Dragon Standard BOM4) 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.” 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. As such, it’s important to separate 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—both in terms of price and power consumption—many manufacturers are now basing their connected devices around relatively powerful processors. A common pattern emerging in this space is to have the code that talks to the hardware running as a separate process from 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 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 it also means that the management code can expose command and control functionality in just one place. The same 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 some other network device.