Hybrid Cloud

Part 15 of Data Communication for Industrial IoT

A hybrid cloud is a combination of in-house and cloud functionality in the same system.  For industrial applications, this usually means the use of a public cloud for remote access, and a locally managed, private “cloud” for interaction among application within the plant.

A public cloud is a service like SkkyHub, Azure or GE Predix that is hosted by a separate company, whose services are available to the general public.  It provides a point of contact for a remote user to access the data collected from the industrial system.  Depending on the cloud service it might also provide redistribution, storage, analysis, alerts and other processing on the data.

I put private “cloud” in quotes because the local server does not need to be a cloud service in the sense of on-demand resource balancing on a distributed collection of virtual machines.  Usually it is an aggregation and distribution point for data from the local network that allows various plant subsystems to communicate with one another.  It may fulfill the same communication role as a cloud server without the implied implementation of a cloud service.

A private cloud is run by the company that uses it, often on company hardware at a company location.  It might be, for example, be run inside the control system network, in a DMZ between different plant locations or between the management offices and the shop floor.  In terms of security and reliability, one key difference is that data communications for the private cloud typically run across the company network, while for the public cloud communications go across the Internet.

A Very Good Approach

There are several reasons why a hybrid cloud might be the best approach to data communications for the Industrial IoT.  First, a good hybrid cloud system can provide separate data paths for in-house applications and publicly available services.  Implemented correctly, this can mean exposing lower-level data to plant engineers and managers, while providing access to higher-level data like accumulated statistics for the IT department, or aggregated supply levels to raw materials vendors.  This kind of data separability, where everyone gets just the data they need, is a hallmark of a secure system.

In a similar way, running separate servers for in-plant and public cloud keeps the critical data paths on the LAN where higher data rates and more bandwidth are typically possible.  It also means that if the Internet connection goes down, the plant can continue to function unimpeded.  To achieve this, the design would need to ensure that none of the primary control necessary to run the plant is in the public cloud.  And if the system is designed correctly, when the network comes back the data should continue to flow to remote users via the public cloud, using the latest values.

Despite these advantages, there are a few practical considerations.  Costs can be somewhat higher, as you are effectively running two systems.  That may not be a huge consideration since you probably need the communication infrastructure within your plant in any case.  The requirement then becomes ensuring that your in-plant communication software can interoperate with your choice of public cloud provider.  A software or hardware protocol gateway may be all you need to act as a private “cloud” server.

Avoid Cloud Dependencies

Some cloud service companies may not encourage a hybrid cloud solution just due to their business model.  For example, consider a typical REST-based cloud service.  These services offer the ability to transmit data via HTTP directly from a sensor or embedded device to the cloud server.  However, if that sensor needs to be incorporated into a larger control system, sending the data to a cloud service and then back to the control system is both impractical and fragile.  Yet the cloud provider will not let you run a copy of their server software in your own network, as that would eliminate their service revenue.

This brings up an important requirement when selecting an IIoT cloud provider – a good IIoT device should be equally comfortable connecting to a local system or a cloud system.  The cloud service provider should formally support local receipt of data using the same protocol they use in the public cloud, through cloud-compatible software or hardware, so that the device can transmit either to the local system or the public cloud with just a configuration change.  Local cloud-compatible servers should support the protocols that the plant uses, like OPC, Modbus, etc.

When a hybrid cloud system is implemented correctly it can eliminate dependencies on the Internet connection, yet still provide all of the remote accessibility benefits of the cloud.  It can make it possible to re-purpose devices between the cloud and the local system trivially, and provide for graceful degradation in the event of a network failure by maintaining local communication and control even though remote visibility has been lost.  When the purpose of the system is process control, you don’t want to lose control of your process.

Continue reading, or go back to Table of Contents