The “Lean Startup” has convinced most of us that a minimum viable product, or MVP, is a great path to understand the viability and market value of new products and innovations. An MVP is intended to be a “low resolution” prototype that has just enough functionality to show your customer, and yourself, what the product is all about and what is its value.
With the Internet of Things ecosystem taking off the way it is, building effective IoT MVPs is getting easier and easier. This article steps through a few different ways to put a great IoT end-to-end MVP together.
To make the discussion simpler and more fun, let’s assume that we are building an IoT system to track, monitor and manage a fleet of jet skis that we rent out in Key West (that’s fun just to think about!). Our goal would be to monitor basic statistics like gas levels, oil levels and engine temperature. We could even monitor vibration at different wear points on the unit and use this data to prioritize maintenance to extend the life of our investment. We would want to receive alarms if one of our customers appeared to be stranded or in trouble, and we would also want to receive alarms if our jet ski moved outside of a “geo-fence” that we set up. We could even send our customer these stats on their smart-phone so that they know where they were and how much time is left in their rental agreement.
So how would we go about making an MVP for this? As this is an MVP, we do want to keep it relatively simple (for more a comprehensive system architecture overview see https://juxtology.com/iot-transformation/ ). So, let’s use the following (condensed stack) as our MVP “reference architecture” and get started.
And before we get too far, we should look at the components of the solution, and then think about the best way to assemble them into a solution.
First we will need some sensors. We easily find suitable accelerometers, vibration and temperature sensors that we can mount at interesting points of our crafts. We can also get data from the existing gages on the jet skis to make our work easier. The outputs of these sensors may be either analog or digital signals, so, whatever processor we choose will need some analog to digital input and probably some digital I/O as well.
Before we choose the processor for our MVP, we should decide how we want to communicate with our craft. We could see some IoT benefit even if we only connected to our device between uses, and upload “history” data for maintenance, but we really want to monitor our units all the time. Since our rental location is covered by cellular connectivity (lucky for us!), we decide to use that. 802.11 WiFi doesn’t have the range, and we don’t want to deploy anything expensive for our service, and certainly not for our MVP, So, we go with cellular. With that, we also need to decide which wireless carrier we want to use and be sure that the hardware package we choose makes it easy to connect to that carrier. We will also want to choose a carrier that makes it easy for us to set up an account, easily connect our device, provides us a good SDK for our platform to connect with and has reasonable rates for our prototype uses. Some prototyping hardware / cellular products actually provide an integrated cellular service for a monthly fee. Assuming that this option works based on your other selection criteria, this can be really easy (more on this below).
One more thing to think about before we pick our processing unit is power. Some applications are very power constrained and we need to run our application with very low power or just periodically to preserve our battery. Some applications require us to “scavenge” power from, say a light source (we can power an IoT device on indoor lighting, not just solar!). We could even “scavenge” power from vibration. But in this case, we keep things simple and decide to hook our IoT solution to the power system of the Jet Ski with a little filtering to protect the unit.
Now that we understand what is on either end of our processor – sensors on one end and cellular on the other – and how we will power it, we can look for suitable platforms for our MVP. There few things to consider here as well:
- First, it would be nice if the hardware we use for the MVP has some resemblance to our final product so that we don’t waste any learning curve and software investment we make in our prototype. So, we would like for whatever we use to have a cost effective and suitable counterpart for deployment. With the large ecosystem that has developed around Raspberry Pie, Arduino, Yun and Beagle Bone (and ARM in general), we have a bias in these directions.
- We can narrow our selection further by thinking about our real needs as well as our skill in programming devices. If we are only planning to connect a few sensors and gather statistics locally, and then upload them – and we don’t have a lot of programming skills, we can use a platform that has an operating system that is more or less invisible to us, that supports a simple programming interface for I/O, and that already has an on-board cellular device along with with all of the software smarts integrated and ready to go. This is more of an Arduino or YUN-class device and this sound pretty attractive. But, if we are more software savvy, we may decide that we want to do more local processing, run some local analytics in the future and even build in “autonomous” decision making based on local on-board analytics. This would push us towards a more sophisticated device running a small version of Linux so that we have access to open source code modules. This would be more of a Raspberry Pie or Beagle Bone type of device. But if at all possible, we want a platform already has integrated cellular support and a simple way to turn it on. Since we can find this level of integration in off the shelf solutions, there is no reason to complicate things unnecessarily for our MVP. In fact, some solutions (particle.io) not only have integrated cellular, but also provide cellular connectivity plans out of the box.
- We also need to be sure our platform choice has very good software support. The ecosystem is getting mature, and our choice should provide good tools for programming, code download, trouble shooting, etc. We really want to find sample code that does almost everything we want to do with the MVP. We can look not only to the device manufacturer, but also to the user community. We may find a near “clone” of our solution on GitHub (in fact, it is likely).
In our case, we decide to keep it simple, and use an Arduino-like device with integrated cellular connectivity. This will have the I/O we need, be simple to program, and easy to connect to the network.
Once we settle on what hardware we will need to get an account with our wireless carrier. AT&T and Verizon are working hard to pull in IoT business, and both have tools to make this fairly easy. Both provide SDKs to integrate with your software (mostly Javascript and C libraries) and you can find tutorials and examples to help you get either up and running with only a small amount of headache. As mentioned before, you can find hardware providers that have already done this for you. The Particle Electron product, for example, provides an Arduino-like development environment and can provide you with a monthly subscription that is plug and play. There are other similar solutions, but Particle can be a great solution, and because they make it so easy to connect to the network, we decide to go with this.
So now that you have connectivity, you need some software infrastructure “in the cloud” to connect your crafts to your back end software system. If you went the carrier route, our provider will have tools to help us route the traffic from your fleet to our server. Another alternative is to use “free” services from PubNub or dweet.io. PubNub has a very nice Publish / Subscribe product where you can set up your crafts as publishers of their data and your software service as subscribers to that data (a many to one arrangement). Our back end service can be set up as a publisher of commands and information and our fleet can be set up as subscribers to that information (a one to many arrangement). This is actually very easy to do, and we like easy, so we go with this.
Next, we need to set up your back-end service. We can do this “in the cloud” by setting up an account Amazon, Microsoft, or if we use AT&T or Verizon, with them. With Amazon, you can you can set up a one-year free developer account that allows you to run virtual machines with all of the resources you need – and a lot of great tools – to make this relatively simple. Still, for you proof of concept, and especially if you go the PubNub route (my choice for simplicity) you could also simply put your code on any web-connect computer that can be connected to your PubNub account. We decide to do that and once we are up and running, we will migrate that to Amazon’s one year free service.
Finally, we need to write you software for our mobile monitoring devices (our “things”), and our software for our back end application. This can be as simple or complicated as we want or think we need. On the remote device side, we are just capturing information from our sensors as well as GSM location information and uploading it. We may choose to also receive warnings or alerts to provide to your customers, but this could come later. On the back end application side, we have a modest number of tasks to implement there as well. We want to monitor basic data from our fleet and look for problems and send ourselves or our staff alarms and also create automated maintenance requests for service based on the fleet data. We can also create a latitude and longitude “geo-fence” and alarm if our customers go outside of that perimeter. If we want to get go further, we can implement some basic machine learning that will create a baseline characterization of each machine and let us know if any one machine starts to change its character (it starts vibrating more, or is running hotter for example). We could also integrate weather data into your system so that on hot days, your fleet can be expected to run hotter, or to allow you to know if bad weather is coming in.
For one more great feature for our MVP, we can also set up PubNub to forward data to another “free” (free for limited use) application, Freeboard. Using freeboard, or other tools like it, you can provide your customers with information about their craft and your mobile workforce about the fleet. With Freeboard, we can set up an account and have our back end server act as a publisher to PubNub, and make Freeboard a subscriber, and give the Freeboard URLs to your customers and your team. Now, our customers and our teams have mobility and a modern user interface to our MVP solution on our smartphones. We can include google maps, that pinpoint the location of the craft(s), as well as any critical stats or messages that we want to provide.
And, with this, now we have an IoT MVP for your business. For applications that will never reach large scale deployment, we may very well just tune, refine and harden our MVP for production. But for larger scale, we would want to make some pretty big adjustments before we go to market. But, with the MVP behind us, we will know how we need to adjust, and will know in advance if we have a winner.
I chose the Jet Ski fleet example to suggest that IoT is not only for big business (and because it was fun to think about). There are multiple business interests that can benefit from this new technology and new way of thinking. This prototype example, with a few modifications, can readily apply to many different IoT solutions from security, to heavy equipment monitoring to solar panel operation and maintenance to supply chain operations and more. While I did portray all this as being easy to do, there are a lot of pieces to the puzzle. In this example, we did use cellular connectivity and that simplifies things significantly as we have a more or less direct path to your application. In some applications, this does not make sense and you need intermediate networks to gather local devices into another transport mechanism that connects your devices (things) back to your application in the cloud or on you premise. This can be quite a bit more complicated, as much due to sorting through your best RF or wired options, as due to the added development effort. But, putting together an MVP to prove your application can be as direct as described above. The issue is really familiarity with the technologies, the tools and the vendor ecosystem. From this perspective, leveraging a partner with experience in doing this is often a good idea. Of course, I recommend that you call Juxtology!
Next we will assume that you want to go on to deploy you IoT system full scale and see what that might entail.