Posts

Cloud, Edge, and Fog Processing

/by
Part 13 of Data Communication for Industrial IoT

With the huge number of devices comprising the IoT, we can imagine a looming problem with processing power.  If a user wants to perform some logic specific to a device, he usually has two choices: perform that logic in a cloud application, or perform that processing directly on the device (edge processing).  There are clearly advantages to both strategies.

Cloud

Moving complex logic to the cloud means that the device can be made with lower power requirements and less expensive parts.  The device just needs to be able to read raw values from transducers or A/D converters and transmit them using a low-level protocol like Modbus.  The cloud application can decode the raw data, apply scaling, deadbands, alerts and closed-loop control.  Since you should have no direct access to the device (see Access the Data, not the Device), you may not be able to change the logic at the device.  Placing processing in the cloud lets you modify your system logic without endangering device security.  In addition, cloud applications let you write logic that uses information from multiple devices, since all of the device information is available at the cloud server.

On the other hand, placing logic in the cloud means that the device is dumb.  If the network connection is lost, the device can do nothing but collect data.  If the logic in the cloud is important to the operation of the device or the system in which it is running then the system is effectively crippled until the connection is re-established (see The Cloud is Good, Except when it Isn’t—coming next).  In many instances, particularly in industrial systems, this is simply not acceptable.

In addition, placing logic in the cloud presents a scaling issue.  If the cloud server must handle a few data change events for a handful of data items, no problem.  If it must handle millions of data changes for hundreds of thousands of data items, which is more in line with industrial processes, then the simple availability of CPU, memory and network bandwidth become an issue.  The devices already have a certain amount of processing capability on them, so why not use it reduce the load at the server?

Edge

It is easy to see how the device can perform computations like engineering unit conversion, simple alarm generation, and even some closed-loop control before ever transmitting its information to the cloud.  With a little more power on the device it could, for example, read an image from a camera, analyze it for a production error and then send only an indication of whether the image contains an error to the cloud.  Instead of transmitting 100 KB of image, it can send a few bytes of result.

In addition to reducing network bandwidth, this approach also improves response time for closed-loop control.  The latency of data arriving at the device from the physical system can be a few milliseconds.  The device can process the data and determine a response within microseconds, resulting in an event-to-response time of just a few milliseconds.  Compare this to the latencies typical of Internet round-trip times, and it’s clear that edge processing for device control can save two orders of magnitude in response time.  The difference between 2 milliseconds and 200 may not always matter, but in industrial applications it is commonly a consideration.

Fog

There is, commonly, a third option between the edge and cloud—fog.  In industrial applications it is rare, and usually undesirable, to have plant-floor equipment connect directly to the cloud.  It is far more likely that devices and equipment connect first to a local aggregator or gateway.  Even in home automation applications the devices usually talk to a gateway rather than directly to a cloud server.  Processing at the gateway or concentrator is called fog processing.

The purpose of the gateway is to collect information from multiple devices using their native protocols and to convert that information to a form suitable for transmission to a cloud service.  In industrial applications these protocols are typically standards like Modbus, Profibus, Ethernet/IP, or OPC.  In home automation you might see something like ECHONET Lite.  The communication from the gateway to the cloud is determined by the cloud service, and may bear no resemblance to the device protocol.  In essence, the gateway acts as a collection point between the devices and the cloud service.

There is no reason why the gateway cannot perform fog processing on the device data before sending it to the cloud.  In fact, since the gateway is likely to have far more computing power than the edge devices, it often makes sense to perform complex tasks there instead of at the device itself.  Latencies are low, since the device and gateway share a local connection, whether it is Ethernet, WiFi, Zigbee or some other short-range network.  Response times for fog processing are higher than for edge processing, but the difference is now a few milliseconds, not tens or hundreds of milliseconds as it would be with cloud processing.

For larger systems, there is even a fourth option—a hybrid cloud—which I will touch on later.

Continue reading, or go back to Table of Contents

Focusing on the Edge of the Industrial IoT

/by

There is more life on the edge.  People who live on the edge take risks, dream big, and claim to get the best view.  “Edge effects” in ecology can lead to greater biodiversity.  Leading edge technologies promise more of everything–more power, more functionality, more value.  Now, as the conversation around cloud computing and the Industrial IoT expands, we are beginning to hear more about the edge.

Previously we looked at fog computing, where off-cloud computing power is installed on a cloud-connected device to reduce bandwidth and conserve cloud resources.  But that’s just part of the picture, according to Harry Forbes, at the ARC Advisory Group.  The edge of the IoT, he says, is not a single thing, but rather an area between the device and the transport to the cloud that can vary widely according to application requirements.

In a recent blog, “The Evolution of the IIoT Edge“, Forbes identifies at least five different aspects, or “classes of edge.”  Here is a brief summary:

Intermittent Connection – A significant number of devices and applications don’t need a full-time connection to the IoT.  A level sensor in a tank making a cellular connection to the cloud may need to send its data only a few times per day.

Data Historian – Sophisticated data users often log real-time data from multiple devices to a single, on-site historian.  By connecting this historian to the IoT, the data can be sent intermittently to Big Data tools for processing and analysis.  The edge application in this case combines consolidation and intermittent connection.

IIoT Gateway – This is a dedicated device that consolidates data from a number of locally-connected devices, and provides a connection to the IoT. Forbes points out that the value of this kind of device is that it can be provided and maintained by a 3rd party, and improved and updated as the service evolves.

Fog – An approach to cloud computing where some amount of intelligent processing is done at the device level, before the data gets sent to the cloud.  This could include message throttling, conditional logic, and even simple control.  We discussed this approach here.

On-premise cloud – For larger users like telecom services, localized cloud computing can be installed at the edge of the cloud to do what is essentially fog computing, but on a much larger scale.

As with the Industrial IoT itself, the vision and reality of what is happening at the edge is continually evolving.  Forbes says, “Five years ago the idea of deploying a (on-premise) cloud at the base of every cell tower would be considered madness. Five years hence it may well be the norm.”