AutomatedBuildings.com Interview -

Varun joined Sierra Monitor Corporation in July 2014, from Echelon Corporation (ELON) where he was senior vice president and general manager of the Industrial Internet of Things (IIoT) division. Previously, he served as president and chief executive officer of NetContinuum, a leading provider of Web Application Firewalls, acquired by Barracuda Networks (CUDA) in 2007. Varun received his Electrical Engineering degree from the Indian Institute of Technology, Bombay; a Master of Science degree from North Carolina State University; and his Master of Business Administration degree from Boston University.

Taking Advantage of the Industrial Internet of Things (IIoT) Opportunity

Sierra Monitor Corporation’s IIoT On-Ramp Suite accelerates the transformation of OEM devices into smart, cloud-connected products

Sinclair: In one of our previous interviews, you talked about Sierra Monitor Corporation’s (SMC) involvement with the cloud. Nearly a year later, you introduced the IIoT On-Ramp Suite at the 2016 AHR Expo. Can you tell me more about it?

Nagaraj: Sure, Ken. Our new IIoT On-Ramp Suite is a comprehensive and secure approach for original equipment manufacturers (OEMs) to take advantage of IIoT opportunities. Traditionally, device vendors have been satisfied with ensuring that their devices are capable of talking to the facility’s management or supervisory system. We feel that is not enough. We think every device vendor should be looking to connect their devices to a point of presence in the cloud that they own and control so that they are in constant contact with their products. Owning a point of presence in the cloud makes it possible for the OEMs to do remote management and analytics. To make it easy for device OEMs to turn their products into smart, cloud-connected products, we put the IIoT On-Ramp Suite together. The Suite offers distinct product offerings that can be used singly or in combination with other offerings. However, if possible, we recommend that device OEMs follow our three-step process:

Sinclair: Most of our readers are aware of the FieldServer brand, but can you tell me more about how one adds “local applications to the FieldServer via the Application Engine software?”

Nagaraj: Our FieldServer gateways and routers, such as the BACnet Router and EZ Gateway, have always been trusted by our customers to provide the required connectivity and protocol translation. We asked ourselves, “How can we provide more value beyond just being protocol translators between devices?” We concluded that the solution was to add a software-based Application Engine to the gateway that would enable the development and execution of powerful web-based applications. Then we asked, “what applications make the most sense locally?” And we concluded that there were really three or four applications that all device vendors could benefit from. Now, we are talking about applications other than the typical web-based configuration applications one sees on gateways. For example, having a local application that can automatically discover or explore the device network behind the gateway; or an application that collects and displays status information from the devices and allows the user to drill down into those devices to get and even set parameters with the right permissions. What about an application that can be configured to build a local history of data points of interest and an application that collects event logs? All these are examples of local applications enabled by our on-board Application Engine. They are “local” because they are available locally to users who are browsing to the gateway from the Local Area Network (LAN).

Sinclair: How does the FieldPoP device cloud fit with the local applications developed within the Application Engine on the FieldServer gateway?

Nagaraj: The local applications are powerful even if only available on the LAN to locally connected personnel. Imagine how much more useful these applications would become if they could be accessed remotely and securely through FieldPoP. So there is no need for a technician onsite to run these local applications. These local applications could be run remotely by authorized personnel through FieldPoP. That is, the authorized personnel could be anywhere in the world, but they would be running all the local applications on the FieldServer like they were sitting with a tablet right next to it. So how does this secure remote access to the local applications work? I had already mentioned how an OEM’s FieldServer gateways and routers in the field register in with the OEM’s FieldPoP account. Once registered, the FieldServer gateways will populate on a map on the FieldPoP device dashboard (viewed on a web browser), where the OEM’s authorized users can do a number of things: securely access and remotely monitor the entire fleet of registered FieldServer gateways and routers; set up installation and support team and customers with the right security permissions and device assignments on FieldPoP; perform FieldServer software upgrades remotely to minimize field visits; and receive notifications via text and/or email to bring information to people instantaneously.

Sinclair: How and why does FieldPoP act as device data middleware layer for 3rd party cloud platforms?

Nagaraj: FieldPoP is architected to plug into and synchronize with 3rd party cloud platforms like Salesforce, PTC/ThingWorx, Oracle IoT Cloud, and Microsoft Azure; and also with cost-effective storage targets like Dropbox or Amazon S3. Our developers have worked tirelessly to make the synchronization through FieldPoP seamless and efficient. With a click of a button, devices connected to the FieldServer will send the desired datapoints, to the 3rd party cloud platform of your choice.

What we didn’t want to do was to try and be one of those cloud platforms. We call them the “white collar” clouds internally here at SMC; these are nice, clean interfaces where businesses oversee customer relationship management, supply chain management, product development, business analytics, etc. We are not that kind of cloud, as we refer to ourselves as the “blue collar” cloud. We do the “dirty” work of field device management and security, retrieving data from the field that would otherwise be difficult to get. We saw ourselves in the perfect position for field data retrieval due to our 10+ years of connecting field devices to each other and management systems around the world. We’ve got pretty good relationships and dialogue with the white collar cloud guys. They are happy that someone is doing the blue collar work to get the data to them.

Sinclair: You mentioned Salesforce, PTC/ThingWorx, Oracle, and others. These are names you don’t hear about in the Building Automation space. Tell me why you are even mentioning these guys let alone telling me how you integrate with them?

Nagaraj: Okay – this is a curve ball, so bear with me. Take the point of view of an OEM trying to build a dashboard that keeps track of their deployed FieldServer gateways (and their devices that are behind the gateways). The OEM may additionally want to know the status of each of these devices because it is of relevance to their sales and support teams or the OEM might want to provide visibility into the data being generated by these devices to their product engineers so they can use that data to improve the product. Now ask yourself – what is the best way to build these types of visualization and analytics applications. Most likely, the OEM is using cloud platforms like Salesforce.com to manage their customer reports, or has made a decision to use Google Cloud or Microsoft Azure for all their cloud analytics projects. Perhaps that decision was driven by the finance department or someone else. What matters is that the OEM’s engineering team that is deploying the FieldServer and FieldPoP has to live within or tuck into these bigger cloud decisions already made by their companies. This makes sense. For example, if you are looking to merge product status and alarm information with the appropriate customer record information, why would you want to do these anywhere other than in the CRM system like Salesforce.com? If we look outside our narrow view of building automation, we would see that companies that make building automation devices are businesses and that their architectural choices need to fit within their business architectures. Now it is a different matter if we are talking about dashboards and such that end enterprises are implementing. Here I can see the facilities manager saying, “I want to buy a specialized BMS analytics dashboard”; but even here as facilities managers begin to report to IT managers, I can see the CIO saying,” “We’ve made a decision that all new analytics applications, whether for energy management or for financial fraud analysis, must be written on cloud platform X.” Building management is just one of several applications and can’t be a silo unto itself, is what I’m saying.

Sinclair: This is great information, Varun, even if it’s a bit different from our usual industry view. How can our readers learn more about your IIoT On-Ramp Suite?

Nagaraj: We have a webinar coming up in March that will describe our solution in more detail. Anyone who is interested can register here.

Events	Want Ads
Our Sponsors	Resources