IoT urban use cases emerge - Mrinal Wadhwa's view from the field
- Summary:
- I've been trying to track down Mrinal Wadhwa of Fybr for an Internet of Things gut check. At SAP TechEd Barcelona, I got my chance. The result was a podcast which delves into Wadhwa's work building IoT use cases for cash-strapped cities. Here's what I learned.
My skepticism about the Internet of Things has cracked a bit, mostly due to relevant use cases. At SAP TechEd Barcelona, I seized the chance to tape a podcast with Mrinal Wadhwa, CTO of Fybr, about their IoT work in urban areas. (Actually we taped two of them - a longer IoT-focused podcast, and a shorter one on SAP's IoT strategy).
Local governments aren't exactly risky innovators with deep pockets. Yet Wadhwa's team has some nifty urban IoT projects underway. Fybr builds IoT networks in the low-power, low data rate segment. Though they are primarily city-focused, their approach also plays well in agriculture.
They focus on industry situations where wireless devices are needed - devices that only need to send a little bit of data, but must have a long battery life. And the devices must withstand brutal weather conditions, with appropriate security to boot.
Fybr's IoT use cases - helping cities move beyond reactive mode
So what's new? Parking implementations:
We've been doing parking sensor implementations to start with in cities. The most recent one is downtown in Washington D.C., about twenty blocks outside the White House area in Chinatown. It's been going great.
Geographic conditions are high on the list of challenges:
There's a lot of learning from doing something like this. Radio around all of those government buildings can be quite challenging.
Then there's punishing weather:
Another example of an installation is Montreal, and Montreal has - over the last two winters that we've been installed there - seen minus 27 degrees Celsius.
So what problems do these IoT projects solve? They start with the city in reactive mode, struggling to provide citizens with information:
It's an area where traditionally either the city or its citizens didn't have access to information. Processes were reactive. You would go to a place and try to find parking. In the process of finding parking, you'll go around in circles and waste a lot of time, fuel, create noise, create pollution, create traffic.
He sees IoT fitting into a pro-active approach:
From a city infrastructure standpoint, I think city processes are starting to become pro-active. Rather than their customers - or their citizens - complaining about something not working, they want to pro-actively detect that something is about to fail in the various services they offer.
And yes, that even applies to sewage:
We're working with a partner, and these guys do sewage planning for cities. Cities pay per gallon of stuff that goes into the sewage treatment plant. When it's raining, a lot of what ends up in the sewage treatment plant is rain water. Drain systems are designed to segregate that, but they don't work very well.
We have a device that we built that goes under a manhole cover. It's a wireless device with a radar in it, and it's looking downwards into the pipe. It can tell the level of sewage and the rate of flow of sewage in the pipe. We can do predictions. We can predict blockages; we can predict that this street is going to be flooded in a little while - that kind of thing.
The pre-IoT approach requires a $15-20,000 piece of equipment, which must be periodically submerged in different areas. Data is collected, and a model for predicting what a city should do based on rain patterns is laboriously constructed:
[Our partner would like to work with us] to make this whole decision making real-time. That could reduce the amount of rain water that ends up inside sewage treatment plants.
Building the IoT business case with budget-conscious cities
The use cases are appealing, but most cities are fiscally strapped. They aren't looking for expensive tech or early adopter risks. So how does Fybr make the case?
There are several stakeholders in a city. These decisions require all of them to feel good about a particular infrastructure change that's coming. Yes - "Where's the money going to come from to fund these initial things?" is a big challenge.
Fybr starts with an application that can either save or make the city money. The city can then use the IoT platform they already funded to pursue projects with civic interest that might not be money-makers:
With a parking sensor network, it's easy to show how the optimizations can pay back the cost of the network in 1-2 years. Once you have a parking sensor network, you can layer other nice things on top of it. Take our parking deployment in Washington D.C. The city has been talking to us about smog sensors along with our gateway, so they can recommend bicyclists which route to take today, or which roads to avoid today, because there's a lot of smog. Especially for somebody who has an asthmatic condition, right?
The IoT use cases I find compelling usually have two elements: infusion of a new data source, and a shift in the business model as data becomes a service, or the IoT platform enables a new service offering. These two themes made me reconsider my position that IoT is Sriracha marketing sauce for ERP slide decks.
Wadhwa has seen both themes in action:
IoT enables a combination of data and value from that combination that wasn't possible before... I live in Bangalore, and like most cities around the world, streets lights are powered by a timer. This timer is a dumb timer and hard coded into firmware that somebody wrote ten or twenty years ago, which says at 6 PM, turns the lights on. At 6 AM, turn them off. Street light energy bills are the biggest bill most cities pay every month.
Just with a very simple combination of that trigger you can automate with IoT, and weather data that tells you sunrise time and sunset time, or tells you when a storm is coming and it's going to be dark. Just that very little combination can save cities, I believe on an average, hours of time per street light. That has a huge monetary return. A return that is only possible because of the combination.
Then there's the as-a-service transitions. During a talk with SAP's Tom Raftery, formerly of RedMonk, now SAP's Internet of Things Evangelist, Raftery discussed an interesting example of the product-to-service model, Kaeser. During our podcast, Wadhwa elaborated:
The Kaeser example Tom was referring to. This was the second part - the new kind of business model. A compressor company may go from selling compressors to selling compressed air as a service, and charging the customers for the amount of air. That's very interesting. It's interesting because it enables several pieces of the puzzle to reduce their cost.
If somebody was building a machine that uses a compressor, that manufacturer does not have a capital expenditure in buying a whole bunch of compressors, they just include it, and they get it for free. They pass it on as a service cost to their consumer.
The wrap - IoT security matters
There's one more piece we shouldn't overlook: security. Too often, IoT security is a buried amidst the whizz-bang. I asked Wadhwa for his take:
I think it is wrong for the industry to dismiss it, which we saw during the craziness that ensued during those [DDoS attacks]. We saw a lot of people just dismiss it. I don't think that's correct. There are some serious, difficult challenges for us to solve.
For Wadhwa, field devices force him to rethink:
I come from a software background. I was suddenly introduced to this world where I was asked to put a device into the field where anybody has physical access to it - on a city street for example. Traditional security in everything I have ever done before relies on the end point keeping a secret. A web service trusts you because you can produce a password, and based on that password, it can figure out that it's you.
However, a physical device sitting on a road can be tampered with, and anybody can get that one key out of that device. There are no models in our industry on how to deal with this. Making sure one compromised device compromise the whole network is a good place to start:
You have to ensure that keys across device are unique so that [hacking] one device means the compromise of one device, not the whole network - which is the DDoS example.
When it comes to IoT, you have to design for security, from the first mockups. Wadhwa's team takes security design seriously, but he acknowledges it's an ongoing conversation:
It's a community discussion. I don't think we have, as an industry and as a community, solved this yet. We need to talk about it, and we need to talk about it openly rather than shoving it under the rug.
I'd call that a full plate for Wadhwa and Fybr. I look forward to revisiting these topics as they add more IoT go-lives.
End note: some of the podcast quotes from Wadhwa were slightly edited for reading clarity. You may also want to check out my other IoT-related post from SAP TechEd, Mapal’s early adoption of SAP’s iOS SDK is part of a bigger IoT platform play.
You can also download the podcast or get it on my Busting the Omni-channel iTunes feed.