Listen to this articleAny IoT application starts with the hardware at the centerstage. You need data to provide value to the end-user and you need hardware to collect that data. Largely, across all major IoT application domains (energy, healthcare, transportation, industrial or consumer goods), one can now easily find commodity sensors that can deliver significant value since they can now be connected to gateway devices that can collect data at both the time and spatial resolution that was never seen before. Of course, there is a lot of innovation that is happening on the sensing side (and some of these breakthroughs will lead to the next generation innovation in the next decade) but the point is that a lot of low hanging fruits can be delivered simply with commodity sensors. In one of my recent discussions, this data was termed as “Dark data” – something that was not available before. I could not agree more. The key to collecting this “dark data” is high spatial and temporal resolution. This implies a lot of hardware is to be deployed and data from this hardware is to be collected at fine time scales (depending on applications, this may range from a few samples every second to 1000s of samples every second). This brings forth the first critical factor for a successful IoT implementation – “Hardware Robustness and Extensibility”.
My experience, with several years of playing around with the hardware systems (and more so in the recent 5 years of research in the energy efficiency space), tells me that a quick proof-of-concept is much easier to build, using several off-the-shelf hardware that are available (RaspberryPi, Arduino, ESP to name a few). However, extending the proof-of-concept to the next level so it works flawlessly even at scale (the scale brings a variety of conditions which the prototype systems typically haven’t seen before and test them for the robustness) is non-trivial and requires years of engineering and deep domain expertise. This is all the more difficult with the non-conducive hardware ecosystem in place in India. Early in our journey, like everyone else, we wanted to be away from hardware (since it creates friction to scale overnight – although on second thoughts, the same friction will help create a moat for others to compete with you once you have built and deployed the technology) and thought that outsourcing the design and manufacturing to third party vendors will be fine. However, we failed miserably and whoever I talk to echo the same experience thus showing a big gap in our “Make in India” ecosystem. Eventually, we decided to do all the design and manufacturing ourselves, using third party vendors wherever possible. Until the time, any IoT vendor (like us) becomes big enough to take the manufacturing completely to the big boys in Shenzhen (or the time when web-connected hardware really becomes a commodity), one has to live through this hard journey of designing and manufacturing the hardware on their own. If you want to be successful in IoT domain, this is something you shouldn’t shy away from and rather should invest in from day one. When eventually the web connected hardware, that is ubiquitous, does become a reality (and I believe it will, in the next 5-7 years), a stable installed base with lessons learned (and machine learning models built with the use cases experienced) from that installed base will give you a competitive edge in many different ways.
A study from University of Virginia illustrates how hardware deployment and maintenance in residential settings is non-trivial. Even big players such as Google tried with Power Meter and failed (eventually acquiring Nest in 2014 and making some inroads over the past couple of years though still there is a long way to go). One of my PhD students in his early days did an extensive deployment of sensors across his home. Lessons learned from this deployment are available here. This study also brings forth unique challenges in the Indian context (specifically voltage fluctuations, frequent power failures, intermittent network connectivity). Such challenges makes it even more difficult to develop a hardware system that can sustain the rugged conditions (beyond the non-reliant electrical and network infrastructure, the environment is very dusty, people’s attitude is very casual and the market is very price sensitive) in India. After developing hardware systems both in the USA (when we worked with Biologists to develop robotic systems for monitoring pollution in rivers and lakes) and in India, I believe that if one can build a successful IoT business in India then scaling anywhere else will be much easier (at least from the hardware perspective). On similar lines, any European or American company that has built a successful IoT product for their environment will find it hard to scale in India for all the challenges (technical and non-technical) mentioned above.
We have built hardware so as to address each one of these challenges, and many more that we experienced as we scaled our deployments to a few 100s, in our own unique way – an engineering art which is our secret sauce that will likely come in handy (and will differentiate us from others) when we have to scale across tens of thousands of sites across the country. The hardware is also developed ground up, keeping in mind different types of sensors that we may need to support, allowing us to easily extend the use cases beyond what we generally support as per specific customer requirements. This becomes an important lever for innovation as we look upon our customers as our partners who bring wealth of experience from running their own operations. This collaboration helps us to develop use cases for automated control driven by sensory data (largely driven by machine learning models developed on top of it – that are simple to begin with but with time and more data will likely become more complex). Such use cases then deliver value to the customers, helping them in their own operations and help us building generally applicable analytical use cases across different industry vertical (which eventually will differentiate us from others, once the web connected hardware and IoT stacks become commodity). Such partnerships with our customers also provide the stickiness required in the SaaSy business we are in.
Another important feature to think through from the beginning is “hardware extensibility”. I define hardware extensibility as the ability to add new hardware and sensors to the existing system in a way that value addition increases significantly with a small additional cost. During early stages, if the hardware is easily extensible as per the new demands that emerge after discussing with potential customers, then the journey towards an evolved product which fits into the market requirements will be both easier and faster. “Hardware extensibility” thought through well in early stages, can help provide a lot of opportunities to up-sell at a later stage by providing additional value with small hardware changes. To make things concrete, let me give an example of where we feel we have benefited from an early decision on which we are now planning to build extensive future use cases (that extend beyond energy as well). We took an early decision (it was more an informed decision after I had spent a couple of years with the same hardware and found it to be reliable enough to start off with) to have a processor based system (rather than a micro controller based system that are otherwise preferred in other IoT systems that I have seen). We now have the confidence to integrate any sensor that comes with open communication protocol to our system with minimal effort (often just a couple of hours but if its a standard we have never seen before then maybe a few days).