The Hows and Whys of IoT for OEMs
For OEMs, the Internet of Things (IoT) is a challenging place—even more so because of the unique position that an OEM holds in the product distribution channel. That unique position presents two learning curves – one for the OEM and another for the end user/customer’s needs. Varun Nagaraj, President and CEO of Sierra Monitor Corporation, knows this learning challenge firsthand.
Sierra Monitor designs, manufactures, and sells protocol gateway products called “FieldServers” that are used in industrial and commercial automation applications. Their core customer base includes OEMs as well as system integrators. The company’s unique protocol translator technology is used by leading industrial and commercial brands to enable communication between central management systems and various automation subs-systems. “Protocol gateways have been used in building automation for several years,” explains Nagaraj. “We provide a gateway for our customer’s product to become multilingual in terms of protocols. Increasingly, in addition to connecting their products to central supervisory systems such as building management systems or industrial SCADA systems, OEMs are now also looking to the gateway to connect their product to the cloud. In other words, OEMs are looking to transform their products into smart connected products using our gateway as the on-ramp to the IoT.”
Nagaraj notes that usually the cloud or the IoT platform is not part of the typical conversation that occurs about protocol gateways, but that is changing as IoT strategies evolve. “We’ve been looking to enhance our protocol gateway to enhance its capability as an IoT gateway. We’ve been working with OEMs to understand what’s needed to drive our product development,” he adds. “For system integrators, customers are expecting their system designs to be multilingual off the bat, especially for a retrofit.”
Trends and Impacts
As IoT strategies continue to involve, there is increasing clarity in how the availability of real-time data from smart connected products can be used to drive product innovation for OEMs. However, the initial focus is on using this data to provide superior service and support. Nagaraj explains that service and support is a tangible concept that affects every player in the value chain, but there are still challenges, such as how the channel structure affects how OEMs take their product to market. For example, the service and support contract might be held by the distributor; not the OEM or end customer. “There are practical challenges in implementation even for a business benefit like better service and support, so the challenge becomes one of how you do it – how do you achieve that benefit in a multi-tier, channel-based environment where there still may be some reluctance to share data between the various members of that value chain?” asks Nagaraj.
So “how to do” is the key implementation challenge around service and support. On the flip side, the “what to do” is the key challenge around product innovation. Smart connected products allow businesses to transition from a traditional product-oriented business model to a Product-as-a-Service (PaaS) model. “IoT also allows OEMs to gain other insights on how their products are being used so they can improve their products or provide more innovative features that customers would value,” he says.
Rethinking the Cloud
As an IoT solutions provider, Sierra Monitor’s learning curve is different than their customers’ learning curve. “We want to be our customers’ IoT on-ramp partner, and so we needed to figure out what drives our customers to want IoT and how we bridge from our current product line to an IoT-enabled product line,” says Nagaraj. “A lot of our learning had to do with what our customers really want. By engaging our OEMs and asking what they would with all of that connectivity, we were able to inform our strategy with this data.”
Through the learning process, Nagaraj also shares that his company came to the conclusion that they “need to own our own device cloud because it is very specific to my gateway,” he explains. “The realization is that I better deliver and own my device cloud along with the gateway. Thinking of the cloud as one entity is very, very dangerous. I think we have to make a distinction between the device cloud and the application/analytics cloud.”
If you’re doing a proof of concept (POC) design, you can do some scripting and get one or a few field devices ‘into the cloud’ – and speak as if it’s one thing. But expand that POC to thousands of field devices speaking different languages; you want devices in the field talking through the gateways to a device cloud, and the device cloud serving as the point of integration to the larger applications and analytics clouds such as ThingWorx. “Generally you don’t tend to hit that point in a POC, but that’s what needs to happen to have a sustainable, long-term, scalable IoT system,” he concludes.