What Makes a Successful IoT Enterprise Second Key Component is Integrated Hardware Software Development

This is the second in the series of articles on what we believe are three critical requirements for any IoT enterprise to be successful. The first one arguing for “Hardware Robustness and Extensibility” as the first key component is available here.

“Hardware robustness” is a journey that has to be lived through for a successful IoT enterprise, manufacturing its own hardware. In my earlier article, I elaborated on why robust and extensible hardware is at the center-stage for any IoT application to succeed. The hardware does not work in isolation. Along with the hardware, a piece of software that runs on the hardware (typically referred to as “firmware”) to provide enhanced extensibility together with the piece of software running on the cloud (for data management) are the integrated pieces of the IoT puzzle.

Early on, integrated development of hardware and software (herein, the term software is loosely used to include both firmware and software running on the cloud) is critical for faster innovation leading to quick identification of ideal product market fit. Let me now explain in a bit more detail how integrated development of hardware, firmware and cloud software can help in developing overall robust systems, through several analogies from our daily experience with our mobile phones (which are a perfect analogy to an IoT system connecting us “the things” to the internet).

For the sake of analogies, consider “apps in mobiles” as analogous to “hardware for IoT application”; “Android/iOS” as analogous to firmware and “network of service provider” as analogous to cloud software (the only difference is that apps can be deployed with a click of a button, the same is not true for IoT hardware — which on one side creates friction to scale quickly while on the other hand creates a big differentiating factor, and a reason for the customer to stick for a long time, if one is indeed able to scale it with all their efforts).

Apps Crash and the Hardware Fails

Similar to the way apps are released and then updated with fixes, one can not wait for the ideal and the most robust hardware to be developed before it gets deployed. Often a “reasonably stable” hardware gets deployed in the field. This version is typically tested enough in the controlled lab conditions but is likely to experience several new set of environments as it gets deployed in the field and hence is bound to fail for reasons previously unknown. At such times, a firmware and software that is well thought through and is developed in an integrated manner with the hardware can come to the rescue. Your mobile OS allows you to restart the app when it fails as well as report it to the developer so the reason for the crash can be fixed. The same way, the firmware for your IoT system should rescue the failed hardware sub-system (sensor or processor or any other hardware interface) and should bring it back online (besides allowing you to push over the air updates with fixes wherever a workaround is possible in the firmware). Further the cloud software should raise alarms when such conditions happen and allow for remote troubleshooting. Such features will eventually lead to quick turnaround time for addressing field failures and will also make the overall system more robust.

Phone hangs and you restart — No such luxury of manual restarts for IoT devices

Many of you must have also experienced your mobile-OS going into the hang state for which you just restart the system. For a remotely deployed IoT system, such capability (to identify and automatically restart the firmware if it goes into hang state) is another example of integrated hardware and firmware addressing a practical challenge.

Receive notifications for what you missed while you were disconnected

You also often see that if your phone is off the network, the service provider (Airtel/Vodafone) sends you a SMS with missed calls while you were off the network. In the same way, control commands from the user (or the automated rules from cloud) may interface with the hardware installed in the field while the hardware is offline. Accounting for such missed events (often this is done by creating an cloud-image of each installed hardware and syncing this image with the hardware as and when the hardware reconnects) and letting the hardware know about it is another example of integrated hardware-software development.

Seamless transition of network connectivity

A good hardware system for an IoT application typically supports all forms of network connectivity — namely Ethernet, WiFi or Cellular. In such scenarios, the firmware should support for seamlessly transitioning from one interface to another when multiple interfaces are supported for redundancy (the way your cell phone switches from 3G/4G to WiFi without you bothering about it).

New iOS conserves power — so should the intelligent IoT firmware

We have observed how some OS upgrades for our mobiles improve the battery performance as well. The same way, there will be scenarios where IoT hardware is running on batteries. Firmware for such hardware should account for each component that can result in power leakage in hardware and should be developed to plug all such leakages.

A big difference between the world of mobile phones and the world of IoT is that the latter is much more immature and much more diversified. It is hard to conceive of one piece of hardware that will work for all IoT applications (from transportation to health or energy). As a result, while in the mobile world one can conceive of three different entities taking care of each of the three different pieces (Google/Apple taking care of Android/iOS, individuals developing apps and Airtel providing network connectivity), such an approach of independently developing even one of the three pieces — hardware/firmware/software is bound to lead to failures in the IoT domain (more likely in the near term until the web connected hardware becomes a commodity and the set of protocols that connect these hardware to the cloud get standardised). Further, even in the mobile world, we clearly see that Apple devices emerging from integrated development of hardware and their OS (with restrictive access to the apps) provide much better user experience than Android phones.

Until the time big boys of the OS world (Google/Apple/Microsoft/..) are able to build a mature version of their OS for IoT hardware, independent hardware vendors (likes of Xiaomi/Samsung/…) build a common suite of specialised IoT hardware devices running the common OS (or someone takes the Apple approach developing the integrated suite of specialised IoT hardware running their own OS as well) and there are big vendors providing the cloud stack (likes of Amazon/IBM/Azure) that can seamlessly integrate with specialised IoT hardware running the specialised IoT OS, startups like Zenatix, who are working towards making it big in the IoT domain, are better served by thinking of an integrated approach for hardware-firmware-software development. Outsourcing any of these to a third party is bound to hinder the progress and delay the identification of product-market fit.

However, this integrated approach is easily said than done. And this is deep rooted in the way engineers are trained, especially in India. During my academic days at IIIT Delhi, it was a common phenomena for Computer Science (CS) students to think of hardware as rocket science and for Electronics and Communication Engineering (ECE) student to be scared of coding. Those who can practice both are rare and so does the companies in the IoT space who conceive of the integrated development approach (one of the hardware or the software is not in their DNA and hence the preference is to outsource it rather than build capabilities in it).

Let me finish by discussing a few things that such an integrated hardware software development enables at a higher level beyond what has already been discussed through analogies above:

1. Automated Device Management — Health streams, well thought through, from the deployed hardware, can allow for automatically identifying the reasons for failure. Such root cause analysis (RCA) can lead to identifying and addressing some of the problems with remote over the air upgrade of the firmware, while for the remaining identifying the exact piece of hardware that has gone bad and creating a ticket for the field technician accordingly (savings lots of time for on-field RCA and requirement for highly skilled field troubleshooting team). This is also an example of how to scale the deployment without throwing people at the problem (I will discuss more about this problem in my next post)
2. Development of technologies for which one part has to reside in the software and one in the hardware — As already discussed, IoT applications inevitably require large scale deployment of hardware. Technology should substitute people, such that highly skilled labour is not critical for deployments to scale. This can only be possible if, post deployment, the system can automatically identify what has not been deployed right and prompt the installation team to correct it (you may have experienced the service technician for Samsung pressing a certain combination of keys on the remote to shift the TV in the debug mode and then identify the exact problem). This is only possible if the firmware inside the hardware and the software running on the mobile-app/web-dashboard are developed in an integrated manner.

Both the above features, lead nicely into the third and the final piece critical for successful IoT implementation — Technology to Support Logistics Around Installation and Field Troubleshooting.

More about it in my next article — Stay Tuned!

Originally published at bwdisrupt.businessworld.in.