The Way I Approach IoT Use Cases

After an amazing conversation with a few talented developers, I came to the conclusion that I should probably create an article that can double as both a reference point and illustrative purposes. This article is about the thought process I personally take when creating new Internet of Things (IoT) use cases.

Two Second Background

I was at an IoT world conference some months back and learned quite a bit about the industry, its partners, its success stories, and most of all the challenges still facing manufactures, engineers, and developers. A financial investor in attendance provided me some of the historical background of IoT as it relates to data and how, in roughly 2013, companies alike were told to store every bit of data they were collecting from every possible source because at some point it would be worth a fortune. Hundreds of millions of dollars were spent by companies world wide as an all-in approach to building this first major wave of IoT data collection. This superfluous hype resulted in a few years of financial prosperity and then crash for those who followed course. The reason? Simply put, there wasn’t an intended purpose for the data. Without focus, without intent, the data simply existed in raw form without any attributed equity. These, the financial investor cautioned, should be the first question anyone asks when venturing into IoT: Why am I doing this? What exact purpose will this actually serve? What is the specific intended effect or result? I wanted to provide this bit of history and background because the IoT market is still not fully recovered from the fatigue of 2013-2015 and many more questions now exist about the future. That said, let’s get creating!

The Three Squares

I always try to break the creative part of IoT use cases down into three main sections–each one requiring its own specific answers before anything becomes a success story. And, here’s the really fun part, these do not have to be answered in any particular order. Great ideas come from acknowledging the fact that you may have discovered one element of this and simply require the other two for completion!

Output

The output block refers to just that; The methods and delivery of data. An easy way to think of this block is to ask yourself the question, “Why am I really doing this?” Is the project’s goal to notify someone of a leaking water main so that it doesn’t cost a fortune in damages? Is the goal to generate reports on energy usage to drive better business decisions? Am I wanting to reduce veterinary bills and allow my cat to live longer? These questions provide a more rapid and focused answer to what the output should look like. Is it graphs/charts? Is the output in the form of an immediate notification like a text or e-mail? Is it an automated report? How exactly is the data delivered and digested?

Engine

The engine block contains the core components used to run the solution. Is this a virtual machine running several scripts? Does the output require physical hardware to process the information and does the engine have absolutely everything required to run? Does it involve multiple steps like an edge computing device paired with a hybrid cloud infrastructure or AWS instance? Do users need to sign up or authenticate an a particularly cumbersome or specific way to run the engine? Is the engine, either physically or virtually (or both), reliable for long term? How easy is it to provision, deploy, and scale the engine? In the most technical of terms, this is the thing that does the stuff.

Collection

Collecting data is a wide topic, so for the purpose of IoT discussions I am going to focus on physical sensor data as it is the most common knowledge gap. The collection of data via physical or virtual sensors is arguably the most difficult when considering use cases that go beyond the already discovered (things like temperature, ground speed, etc.) Physical and topological challenges also make this block a puzzle piece, so my main takeaway is to fully consider ALL options. If you’re unsure at any point, simply take a step back and revisit the other blocks for clues. If the result is to detect water leaking from pipes or tanks, perhaps collecting data on the immediate physical surroundings is a great place to start. Realize, however, that there is almost always a second or third method. For example:

• Water leak detection
  • Copper wire based resistance measurement – When enough water collects between the two copper wires, the measured resistance drops.
  • Water pressure in pipes – If a leak occurs at any point in a pipe, pressure changes may occur.
  • Water reservoir levels – Using either resistance drops between submerged leads or non-contact methods like distance sensors can output numerical results based on levels
  • Flow meter – If a leak occurs, the amount of water flow may increase or decrease.

The first observation you’ll make is that, in the end, all any sensor does is output either a STRING or INTEGER based on measurement. That’s all. Consider a sensor like an extension of abilities beyond the five human senses. Humans have the ability to feel, see, hear, taste, and smell. Physical sensors have the ability to detect tilt, change in speed, temperature, humidity, amount of light, amount of dust, distance, gas particles, pH levels, and so on. You can also think of them as apps or widgets if it helps. The goal of a sensor is to simply observe and report to the engine.

Hopefully the second observation you made is that while there are many ways to deliver an effective output, they may not all be accurate or reliable. The water leak example may yield that perhaps measuring the water flow will not be effective because the rate changes too rapidly even under non-trouble conditions. Or that the resistance sensor is impossible to deploy in every area that needs to be measured. Environmental attributes play perhaps the most significant role in determining the best sensor for the job.

Things Will Always Change

Before I continue, I will say that the content in these blocks will always change on you. New cloud services, new circuits, new and improved versions of sensors, etc. Technologically speaking, we are all living in a huge ocean with ripples being created by industries, enthusiasts, DIY makers, bloggers, developers, and students. Ideas travel at the speed of lasers through fiber optics and our only limit is ourselves; our ability to create use cases for the technology that already or will soon exist. Allow these changes to update your strategy. Allow the changes to improve your next project.

Example

Let’s run through an example using the three blocks and see how they stack up

Challenge: I want to know more about how many guests are coming into my retail store and at what times. Being able to have this information alongside my point of sale reports will allow me to staff the store more appropriately.

I’m going to begin with any block that is easiest to solve and set aside. In this example, it will be the collection method. Counting people can be accomplished a number of ways, but here are the three main methods I’m initially thinking about:

• Laser/Infrared break sensor – Attached to all entrances, this system would count upwards every time the path between the source of light (transmitter) and receiver is interrupted. This also means guests may be counted twice though since guests likely leave through the same doors.
• Passive Infrared (PIR) sensor – Commonly known as a motion sensor, this method will reliably trigger when it detects the proper heat signatures of a human. Sensitivities and thresholds can be adjusted to accommodate various environments. However, this method will not account for groups of people and will also double count guests as they leave through the same door.
• IP camera with people counter software – Utilizing a network based security camera with decent resolution and clarity, software is now able to intelligently identify and count people and can be customized to filter totals based on direction of travel and other specifics. The implementation cost is a little higher, however this method is likely the most reliable.

Now that I have determined the collection method, I will want to investigate what the point of sale reports look like to make data correlation easier. If the data is in CSV format, perhaps the engine that accepts the data from the people counter can simply output to CSV files generated daily?

My engine will need to have the ability to accept data from the collection method–in this case, the people counter. The engine can break the data down into hours via scheduled tasks or timestamp every encounter and apply filter or division rules at the end of the day. Perhaps a Linux virtual machine to process this data may be too complicated for a retail space, and a full hosted cloud solution is too much overhead. Will an Arduino engine acting as a conduit between the people counter to a cloud based IFTTT engine suffice? Will it stand up over time? Is it economically viable? If I get a green check mark next to most of these questions, it may be worth a proof of concept!

Takeaway

Every IoT idea has to start somewhere, and not every use case will have the exact same logistics and calculations. It is important to standardize a process behind the solution. Becoming very familiar with the engine and collection blocks is without a doubt the best use of time and energy. Understanding all of the tools at your disposal will help you determine the most ideal way to deliver an output or solve a challenge. Get to know the sensors. Play with various cloud and physical/virtual engines–whatever form factor they take. Determine two or three as your “go to” for some of the more common challenges. Most importantly, realize that there will always be more than one way to approach a solution and that it’s up to you to identify the most reliable and accurate.