A Model to Categorize IIoT Use Cases – Part 1
Posted by: Varun Nagaraj | Posted on: Thursday, August 27, 2015
There is no shortage of stories and case studies about the IIoT. In aggregate, they support the assertion that the classic Buffalo Springfield song makes: “There’s something’s happening here; what it is ain’t exactly clear”.
Unfortunately, the many IIoT case studies being written up throw the phrase “cloud” around like there is no tomorrow, and all the stories begin to blur together! Personally, I find it useful to have a model that helps me categorize IIoT use cases. I’d like to share the model that we use within our company, both when we are thinking about what IIoT use cases make sense for us as an OEM (with our Sentry Fire and Gas line), and also when we are working with our leading OEM customers to discuss and enable their use cases (with our FieldServer protocol gateway products).
As the diagram shows, we categorize use cases into four steps, with each step having a different benefit or theme. And the reason they are laid out as steps is because we believe it is necessary to master each step before moving on to the next step.
Step 1 is the lowest hanging fruit. OEMs who make “smart connected products” can use the IIoT to improve support and service. By connecting securely and remotely with their connected devices (no matter where they are or how they were sold), the OEM and their sales/service agents can remotely monitor and troubleshoot their products. The OEM’s customers (the end customers) can avail of such a capability themselves as well, allowing the facility manager to always be connected to his assets. Note that we are not just suggesting that the OEMs feed their data to a SCADA or other management system and think their job is done. We are suggesting that every OEM, to the extent possible, look to establish their own secure connection to their products in the field. Armed with this remote knowledge, the OEM can either fix problems remotely or dispatch an appropriately equipped and informed service tech to the field, thereby leading to a much higher resolution rate. The key here is providing secure remote connectivity and access. This step is not about long-term data retention in the cloud, fancy analytics, and so on. In this step, the “cloud” is just a mechanism to provide this functionality. Also, as a general rule, in this step the maximum benefit accrues to the OEM, as it helps them raise their service game and helps them differentiate themselves from other OEMs. So we recommend that OEMs bundle such a secure remote access capability with their products. Shipping the smart connected product along with a FieldServer that can connect over a secure remote access “tunnel” to a cloud-based registration and access point is one way to do this.
Step 2 focuses on using the IIoT to improve operational efficiencies – for the OEM, and even more interestingly, for the OEM’s customers. We have gathered many examples from the literature that fit in this “efficiency” category. For example, an OEM may use the data from their smart connected devices to understand their product quality and failure modes over time, or the OEM’s marketing department may use this data to identify which customers might be ready for a product upgrade offer. The OEM’s customers can greatly benefit from insights too. A facility manager of a building may use the data collected from the smart connected products to identify energy efficiency opportunities, or an airline may use the data gathered from the sensors in the engines across all its aircraft to determine if certain flight paths result in greater fuel efficiency. A commercial kitchen may use the automated logging and reporting of temperature data from all its refrigerators to satisfy food safety regulations, instead of the traditional approach of sending a worker out to each refrigerator every hour to record the temperature. Smart elevators may use information about how many people are waiting and past history of where people go at what time to provision elevator banks efficiently in high rises, and commercial fans may regulate their speeds based on occupancy, external humidity, individual preferences and so on. So many cool examples – but once you get the 4 step model in your head, you’ll realize they are all just variations of Step 2, both from a benefits perspective and from a technology architecture perspective.
A word on the technology architecture required for Step 2. Identifying efficiency opportunities requires “analysis” and possibly (that other infamous word) “big data”. So while Step 1 as explained earlier is about secure remote access to the data stored in the remote smart connected products, Step 2 is about bringing that data to the cloud, organizing it, storing it, and sifting through it looking for efficiency improvements. That is the “cloud” plays a different role in Step 2 relative to Step 1. The cost of proving Step 2 benefits to themselves or to their customers are higher to the OEM relative to Step 1 as the OEM has to move and store data long-term in the cloud, and has to put in the intellectual work to define and develop the algorithms that drive the desired outcomes.We recommend that in Step 2, OEMs think carefully about selecting and pairing the right cloud storage and analytics platform to the cloud-based secure remote access capability established in Step 1. Shipping a smart connected product with a FieldServer along with the ability to plug into the right cloud analytics platform is one way for the OEM to offer Step 2 benefits.
Best-in-class OEMs are actively looking at Steps 1 and 2 (often in that order), and we are privileged to have the opportunity to brainstorm these with our OEM customers.
In the next blog post, we will look further ahead at Steps 3 and 4 and speculate on how smart connected products and the IIoT might usher in an unprecedented era of innovation, and not just efficiency.