Remember the Physical Environment

This is the fourth article in a series of six on designing connected devices, the previous article in the series is “Your Developers’ User Experience,” and talks about product design. The next is “Time to Market vs Common Sense,” and talks about manufacturing as a startup. Links to all six articles can be found in the series overview.

At the prototyping stage the physical environment for your device operates in is fairly benign, an air conditioned office or a lab perhaps, however once out in the world your final product may face an unforgiving natural environment — wind, rain, snow, and worst of all users.

When designing the prototype its important to consider where it will eventually be installed. Will it be inside, or outside. If inside what sort of inside environment will it face. While an office environment may be temperature regulated, a factory floor while theoretically also being an inside environment may suffer extremes of heat or cold. If installed outside there will be a large variation in temperature over the course of a year, or even over the course of each day. The device needed not only to be able to cope with the expected maximum and minimum temperature extremes, but also possible rapid variations between those extremes.

Each component of your product will have an manufacturer recommended operating regime, which means that your final product will roughly be operable in the narrowest subset of those constraints.

Beyond the obvious temperature other constrains your product may have to face other factors should play into the design, the typical installation environment may be subject to moisture and dust. If so the product enclosure may have to be sealed against water ingress, with external physical ports provided with covers for when they are unpopulated.

When your prototype has progressed beyond the breadboard stage, it’s important to take it to the physical environment in which it will normally operate if possible. It may seem obvious but this can surface problems with the design. For instance when considering how your device will be used, if it’s permanently installed into a crowded or tight space, the size and weight of the device and enclosure might become a critical factor.

Electronics generate heat, that’s why (most) laptops come with fans to dissipate the heat away from the electronics. When overheating most processors will throttle performance when the get hot to stay within their operational temperature range. Some processors will do so well below the theoretical maximum which can lead to unexpected performance degradation.

While in most cases electronics used in embedded devices can make do with passive cooling using small heat sinks, active cooling may be necessary. While fan cooling is traditionally thought of as noisy — laptops and microwave ovens spring to mind — operating a modern low-speed (under 2,000 RPM) DC powered ball-bearing brushless fan at the low end of its voltage range will result in sound levels less that 16 to 18 dB. At these levels the fan noise is inaudible from more than a meter away.

Surprisingly perhaps to anyone that’s opened an old style computer tower to be met with fans clogged with dust, if operated at low speeds small fans also only have a small dust accumulation — similar in magnitude to passively cooled heat sink systems.

Alternatives to fans do exist however, if large amounts of heat need to be moved a Peltier cooler could be utilised to move heat away from the device. Conversely in those circumstances where the electronics need to be heated, rather than cooled, Peltier heater can be used. The need to heat the electronics can occur if the device is meant to operate unprotected at altitude, or in colder climates. However care must be taken when designing heating systems, as the electronics will self-heat in many circumstances. Left “on” many systems will generate enough heat from operation to stay in operation if protected from other factors by a good enclosure.

Enclosure design starts with the “looks like” prototype, but while human interface requirements should drive the look-and-feel of the enclosure, the underlying requirements of the environment in which the device operates have to be taken into account.

A good place to start when thinking about designing enclosures, especially for industrial rather than home use, are companies like Polycase who stock a range of pre-built plastic enclosures and may be able to customise them with cutouts for little additional cost.

If the device is to operate for extended periods in an isolated location you may wish to think about adding additional environmental sensors inside your enclosure to provide a self-monitoring capability to your device. Possibly allowing it to “call for help” if it determines that conditions are starting to get outside of its operating range before a failure can occur.

The main consideration when considering power requirements is whether the device will operate on or off the power grid. If the device is designed to operate on grid, connected to mains power, then the considerations must be given to power efficiency, however just getting enough power to keep the device running will not (in most cases) be a problem.

However if the device is to operate off grid the required battery life will be the driving factor behind many design decisions in both the “works like” and “looks like” prototyping stage. Large batteries will not only heavily influence the size and weight of the device, but they are also expensive and will have a dramatic influence on the Bill of Materials cost of the product. Shipping costs may also be affected as some shipping methods can not be used with some commonly used batteries such as Lithium-ion.

The primary power drain for most connected devices will be the radio, therefore anything you can do to reduce this can in turn lead directly back to a smaller battery, and lower bill of material costs. The choice of radio may well be determined by the power requirements. For instance typically Bluetooth LE radios operate with power draws of less than 15 mA, while WiFi radios more typically require from 80 to 200 mA to operate. That can make a dramatic difference to the power consumption of a device.

In the early days of crowdfunding there were several Internet of Things smart lock projects that were initial advertised as WiFi enabled locks, and later switched to using Bluetooth LE due to the inability of the designers to make the onboard battery last long enough to make the lock a practical proposition.

In practice many connected devices do not need to be connected to the Internet at all times. Therefore one common practice when using a “use everywhere” board, which have often been designed to be used off-gird, is the make use of the deep sleep capabilities of the micro-processor.

For instance the power consumption of the ESP8266 SoC drop from a typical 80 mA in operation, down to well under 10 mA whilst in sleep mode. This figure can be brought (much) lower by eliminating power hungry additions like power LEDs attached to many of the breakout board using the chip, down into the μA range. Using a 10 percent duty cycle and the sleep capabilities of the ESP8266 means that a 200 mA battery, that would normally be exhausted in just over 2 hours of normal operation can be stretched to last over a day. If deployed outside even a small solar panel can be used to keep the battery topped off, allowing for long duration operation of the device.

Some chips, like the ESP8266, include wake-from-sleep on interrupt capability. If this is present in many cases battery life can be extended longer as instead of using a standard periodic duty cycle poll period, remote devices can be woken up if “something interesting” happens.

One issue that usually won’t be encountered by your prototypes is a hostile radio environment. WiFi, Bluetooth, Zigbee radios, and several other standards all operate at or around the 2.4 GHz bands. This means that in environments where there are lots of radios in operation your device might suffer from poor throughput, or other connectivity issues. To some extent this can be alleviated by intelligently choosing bands that are uncongested, but in the end there is only so much that can be done.

You therefore may have to consider communications protocols that are robust against data loss and disruption. One place to look for informative work done on disruption tolerant networking (DTN) standards is the work done by the Space Communications and Networking team at NASA. In addition to the basic store-and-forward inter-networking service, DTN also provides: efficient reliability; security; in-order delivery; duplicate suppression; class of service (prioritisation); remote management; rate buffering; and data accounting, all over possibly asymmetric and time-disjoint paths. Applications including file transfer, messaging, and streaming audio and video can all be implemented on top of DTN.

Another issues which may affect connectivity of your device include accounting for motion. Is the device statically installed, or in a movable enclosure. Or is it installed in a location that will itself move, e.g. under the hood of a car. If the device is intended to move then again DTN may prove to be a viable option, or alternatively more than one radio may be required to give multiple routes out to the Internet, for instance primary WiFi networking may be shutdown when the connected device detects that it has left the area of WiFi coverage and a back up WAN connection enabled. If available a low powered secondary WAN radio is obviously preferable.

Of course, unless usage it is carefully managed, adding a second radio may have adverse effects on the power budget of the device.

Another issue to consider if using an IP based radio protocol, is the availability of IPv6 over IPv4. In the longer term without a global and successful adoption and deployment of IPv6 as the primary protocol of the Internet, the Internet of Things won’t be possible as currently envisaged.

However right now IPv4 is still widely used, and IPv6 adoption is weak—as of May 2016 worldwide IPv6 traffic reaching Google accounted for just 11.6 percent of traffic. However adoption of IPv6 will not only mean that there are enough IP addresses to allocate to the growing number of Internet of Things devices, but that many of the security issues around connected devices are immediately resolved, or at least mitigated.

When designing an connected device today you may want to consider making use of an IPv6 capable SoC to future proof yourself against tomorrow.

Beyond connectivity there is also the issue of local storage. Perhaps uniquely these days, on embedded hardware resources are scarce. How much application memory (RAM) and persistent storage (e.g. flash memory) is needed by your use case. If you make use of DTN will longer term storage increase due to caching. It is difficult to discuss storage in general terms as the need for onboard storage will vary dramatically with usage, however it should be factored into your design from the start using estimates of your projected data throughput.

When thinking about storage you should also consider how and where the data is going to be processed. While it may seem initially convenient to send all the data off to a remote cloud for analysis and storage, as the number of devices scales that can become on onerous burden. An additional consideration is that you never have better context for data than at the moment of collection. Reconstructing that context later (or elsewhere) tends to be expensive if not outright impossible. Local decision making, where the data is taken, as close to the time as the data was taken as possible, can in many cases improve outcomes and the quality of those decisions.

Installation and configuration of devices that are often without keyboards for input, or screens for output, can be difficult. However some standard practices have evolved, especially for WiFi connected products.

Typically when a WiFi capable device is unboxed, and powered on, it will startup in Access Point (AP) mode. The end user can then connect to the devices network and then to the device itself — either using an app, or connecting directly to the device using a bowser — the user can then input the home WiFi networks SSID and password and other initial configuration information. The box will then reboot and join the specified home network in client mode putting it onto the Internet.

For devices that offer both WiFi and Bluetooth LE connectivity — many radio chipsets offer both — an alternative pattern is to keep the WiFi radio turned off and advertise the device via Bluetooth LE. The user can then configure the device using an advertised BLE service — limiting the initial threat surface of the device during configuration due to the much reduced range of Bluetooth LE — before the WiFi radio is turned on.

Right now, most Internet of Things devices being sold to consumers have the same architecture: there is a device, an app that controls the device, and a cloud service supporting both the app and the device. The business model behind these device-services is also formulaic: consumers make a one-time purchase of the device, but don’t commit to a subscription to support the cloud services that make the device “smart.”

This model is often times forced on the companies selling the device for various reasons. The experience of the Internet has made most consumers unwilling to subscribe to services, and while they might be willing to purchase a Thing, a physical device, they expect software and services to be “free.” Also, many of these new connected devices replicate or extend the existing functionality of our homes. Most people already have a thermostat; is the incremental gain of a “smart” one really worth being bound up into an ongoing, and endless, subscription plan? For a new class of device which consumers aren’t familiar with and so far have managed to live without, the value proposition is limited. Consumer reluctance is obvious.

However, the companies selling the network connected devices still need to maintain the cloud services behind them: not only the ones that directly support the user experience (machine learning) but also the ongoing maintenance that keeps the device working (like security). Device sellers are therefore gambling that the ongoing maintenance costs for the cloud services will be low and that a sufficient number of new customers will buy the device to cover ongoing costs with new business. Unfortunately, these assumptions about the number of new customers have proven overly optimistic.

A business model based on a one-time purchase of a device — a device that relies on an ongoing service to make it “smart” — appears unsustainable for some sectors. When building your connected device, especially if it like most relies on back end cloud services it is important to understand how many devices are expected to be sold each year. Additionally the life span of the installed device should be carefully considered, especially if this connected device directly replaces a non-smart version.

Consumers do not replace their thermostats, boilers, refrigerators, stoves, lights, or locks every year or two. The lifespan of the average refrigerator or air conditioner is about 15 years. The fabric of our homes is far more static than many companies, used to operating on “Internet time,” seem to have assumed.