Building an IoT System: Weighing the Trade-Offs

Having covered IoT configuration using different wireless communication methods, I want to return to the system view to explore higher level trade-offs. Your decisions have ramifications, often non-obvious ones.

For example, when I visited my optometrist, knowing I work in this field, he was excited to tell me about his new thermostat. He’d opted to not pay a premium for Nest, getting another brand. He was generally happy with being able to set his home temperature from wherever he was, at home or not. I asked about configuration. He was less enthused. He’d started the process, accidentally skipped a step, and had to start over. But he got through it. He was unhappy when three days later, his thermostat lost its memory and he had to go through it again.

I suspect the device got a firmware update, clearing or invalidating the nonvolatile memory that stored the user’s information. Hopefully, this was a simple bug, perhaps the thermostat’s QA team tested the update from version 14 to 15, not realizing units in the field would be updating from version 3. I fear that it was a conscious choice where someone chose to invalidate the user information because it made their job easier, forgetting that configuration is difficult for consumers. Engineers do it on an hourly basis and probably have set up a script to do it (I certainly did, configuration is a pain, scripts are easy).

I don’t know what your device is, nonetheless there is some advice I can give. And I want to share some questions to help you recognize the options you have and the cost associated with them. You need to understand what your device has and what it needs.

These questions are intended to identify the trade-offs you will be making during the design of your system. Catching the “oh, we didn't mean to do that” before buying parts, making boards, and releasing products. The answers themselves are not as important as making sure you have answers and that they are consistent:

• Is this the first user experience the customer will have with your company?
• Is the device an information consumer or provider?
• Is power a consideration?
• How much RAM, flash, cycles does the device need (without connectivity)?
• How much can/will connectivity add to the bill of materials?
• Does the device need an RTOS? By adding connectivity, will it need an RTOS?
• How does my device connect to communications? (SPI, UART, etc.)
• How to update the firmware?

How your device connects is important to the device construction. Even after you’ve chosen what sort of communication you need, there may still be varieties that impact the device. For instance, when talking about example systems, I mentioned a WiFi module required my device to have a TCP/IP stack which required an RTOS. The combination bumped the device into a more expensive processor, using more cycles, code space, and RAM.

We could instead connect to a WiFi module via serial. That would allow my processor to remain smaller, cheaper, and more power efficient. However, configuration may be worse since the set up will not be as customizable as running a local stack.

Another interesting set of worries is around wearable and other battery-powered devices. Power optimization usually means limiting connectivity. You can do this by batching communiques and maximizing the time the radio is powered off. It’s funny that for our ubiquitous, always-on devices, we spend a lot of time trying to figure out how to get them to go to sleep.

Moving on to the communication layer’s trade-offs, don’t forget the configuration flowcharts from the previous post (How Users (Fail to) Set Up IoT Devices). I like my chorus of whiny users that showed the common errors. When you work with module vendors, get them to draw the configuration path for you, considering where your users might have trouble.

While you are there, ask a few other questions:

• How does the user set up the device? Is there a flowchart?
• What % of RMAs are your other OEMs seeing?
• How can we debug software vs. hardware issues?
• How reliable is the communication method? What are the ramifications in case of failure?
• How long will my operations take?
• What about firmware update? Are there limitations?
• What certifications are required? (i.e., FCC)
• What about security?

Security and ease of use are natural enemies, expect to make configuration more difficult as you make the system more secure.

Don’t be the person who makes the horribly hackable baby monitor, the one that hooks to the Internet to allow mom and dad to see the baby from work,  talk to the baby and, sooth it from their desks. Imagine their horror to come home to find a jerk hacker has broken in and is saying horrible things to their child. Make sure you know what you are doing with security. Secure applications are likely to need more RAM and processor cycles so this can still affect the decisions you make about your device.

As you consider the options for communication, the big questions usually revolve around how much data you need to pass and which direction it needs to go. Determining the bandwidth requirement is critical but don’t forget firmware updates. I don’t want to harp on this tweaky little feature but it easy to forget. Worse, it can break your communication methodology when you've specified 10 bytes/hour uploaded to the cloud and suddenly need to download a megabyte to the device.

After communications, we have to figure out how to get the device on to the Internet.  Bluetooth needs an intermediary, some translation application on a phone or computer that can listen to Bluetooth then send the information to the appropriate server. WiFi goes to the internet more directly but the user still needs to have a router and some sort of ISP.  (After my chorus of whiney users in the last post, are you going to be shocked when a user expects an Internet appliance to provide Internet to his home?)

As you work out how your device communicates from the system, remember to list what the user needs to have for this to work: WiFi router of the right flavor, computer, smart phone with the right capabilities, broadband, etc. It seems obvious but the product marketing folks will like having a specific catalog.

The other important concern in the Internet layer is how the data gets from the device to your servers. Going through someone else’s servers means that your service depends on theirs. There are other liabilities beyond reliability: you have to be concerned with their security and their need to monetize the traffic-- someone always pays.

The next layer is the cloud. This is where things get difficult for me. I’m a device person but the connected device is about the whole experience.

One of the big questions of cloud layer is whether to run your own servers. There are plusses revolving around control and flexibility. The minuses deal with having to have servers with high uptime and excellent security (don’t be Target and share everyone’s data). This security is data security instead of the transmission security I mentioned earlier.

Finally, we need to consider the interface back to the user (represented by the lightning bolt in the opening illustration, you didn't think that was extraneous, did you?). How the device is presented to the user is critical to the success of the system.  Some items to consider:

• How does the user interact with the connected device?
  • Web pages
  • Apps on iPhone, Android, etc.
  • Device itself
• Is there a real-time component to this? (i.e. texts)
• How does the user know the device is working? What is the time between the user doing something and seeing it on their interface?
• Is there a backup interface for when connectivity fails?
• Is the device better for the user if it is connected?
• How to make it feel magical?

The last two questions are the most important of all I've talked about in this post.  Building a connected device is nontrivial. Is the device better for the user if it is connected? If you are device maker, are you adding Internet functionality because it is trendy or because it is compelling?

Between the large software project and the significant increase to the system’s bill of material (BOM), there is a significant added expense for the consumer. Is it offset by a magical user experience?

I like the Internet of Things. I’m an early adopter of gadgets. But if you are considering adding connectivity to your device, don’t forget to ask yourself: is it worth it?