Posts

When Edge Computing Makes Sense

As the concept of cloud computing becomes more familiar to industrial automation engineers and system integrators, the discussion has moved from “Whether I should use it?” to “When should I use it?”  In a recent blog, “Edge or Cloud Analytics?“, Michael Guilfoyle at ARC Advisory Group looks at the business case of cloud computing for industrial applications and compares it to edge computing.  It comes as no surprise that in many instances edge computing makes more sense.

So, what exactly is edge computing?  Generally speaking, it is the processing power of the “things” in the Internet of Things (IoT).  It has become an economically attractive complement for the cloud in IoT, thanks to rapid cost decreases for small-scale processors.  And edge computing has additional benefits for Industrial IoT (IIoT) because it means that data can be processed closer to its source.

Six Factors Favoring Edge Computing

Guilfoyle lists six factors that typically favor edge computing:

  • Connectivity: Some industrial systems are located in environments that make it difficult to maintain the regular connections necessary to sustain cloud computing.
  • Immediacy: For any mission-critical system, the closer you can get to real-time decision-making, the better. Running right on the device itself, an edge-processing system can respond in a few milliseconds, compared to a cloud system which would take at least 100 milliseconds, and often longer.
  • Volume: Industrial systems churn out enormous volumes of data, very little of which is of much interest. Edge computing can monitor the data and filter out what is irrelevant. This reduces bandwidth and frees up cloud-computing resources.
  • Cost: Related to volume, feeding large quantities of raw data to the cloud for processing is not cost effective. It is more economical to at least filter the data, or better still process it locally and send the relevant results to the cloud.
  • Privacy: Company policy or government regulations may prevent connecting process data directly to the cloud.
  • Security: Gateway hardware or software at the edge can be used to help control inbound access to the plant. Skkynet’s DHTP protocol, for example, supports outbound-only connections, keeping all firewall ports closed and eliminating the need for VPNs.
Data Abstraction – A Seventh Factor

In addition to these six factors, we would add another important contribution that edge processing can make towards enhancing the value of cloud computing: data abstraction, the ability to generalize data protocols.  The DHTP protocol, in addition to supporting secure connections, also supports data abstraction.  Skkynet’s edge-processing tools, the ETK and DataHub, can convert data from multiple connected protocols into one universal format consisting of name, value, timestamp and quality.  Using DHTP, data abstracted in this form can be transported with minimal overhead across a TCP connection and converted back into its previous protocol, or other protocols, upon its arrival.

Data abstraction solves one of the problems often associated with the Industrial IoT—the wide range of incompatible protocols.  To get all the IIoT devices talking to each other, they need a common language.  Data abstraction implemented at the edge provides a way for each device to share its data with the cloud, and to receive inputs from other devices.

For all of these reasons—connectivity, immediacy, volume, cost, privacy, security, and data abstraction—edge computing makes a lot of sense for IIoT implementations, as it allows data to be processed close to where it is needed, providing the most value at the least cost.

Skkynet Technology Soon Available in iBRESS Cloud by BellChild

Japanese systems integration company, BellChild, will use Skkynet’s SkkyHub technology in its new iBRESS Cloud service, available next month.

Mississauga, Ontario, November 8, 2017 – Skkynet Cloud Systems, Inc. (“Skkynet” or “the Company”) (OTCQB: SKKY), a global leader in real-time cloud information systems, is pleased to announce that starting December 1, 2017, BellChild Ltd. of Osaka, Japan will be offering iBRESS Cloud service that will be powered by Skkynet’s SkkyHub technology. This service will provide secure, real-time, bidirectional communications for Industrie 4.0 and Industrial IoT applications without opening any firewall ports, and without using any VPN.

“The iBRESS Cloud is an ideal fit for Japan’s well-established industrial base, and for the rest of Asia,” said Paul Thomas, President of Skkynet. “BellChild has a solid reputation for providing secure data communication services, and the iBRESS Cloud technology has been designed to provide the kind of secure, high-speed service that remote connections to industrial systems demand.”

Users of iBRESS Cloud will be able to securely connect industrial plants, machines, or individual sensors and actuators to a complete Industrie 4.0 or IIoT system.  BellChild customers will thus be able to monitor and control their industrial processes in real time, from a web page or mobile phone, as well as log data directly to any database or Big Data repository.  The service requires no programming, and allows users to seamlessly integrate existing systems using standard protocols, while incrementally adding Industrie 4.0 or IIoT capability as needed.

The basis for the iBRESS and SkkyHub services is Skkynet’s patented technology for secure, outbound-only connections, making it fully compatible with corporate IT policies, and ensuring no exposed attack surface – no open firewall ports, no VPN, and no extra hardware.  It provides Industrie 4.0 and IIoT connectivity at in-plant networking speeds of microseconds over network latency, and processes up to 50,000+ data changes per second.

About BellChild

BellChild is a system integration company focusing on secure system development, robust infrastructure development, and advanced operations capabilities.  The company develops and maintains secure servers used to support high-speed financial transactions, which is also used to provide a robust and secure platform to support industrial cloud-based systems in the form of iBRESS™ Cloud service.  For more information, see http://www.bell-c.co.jp/.

About Skkynet

Skkynet Cloud Systems, Inc. (OTCQB: SKKY) is a global leader in real-time cloud information systems. The Skkynet Connected Systems platform includes the award-winning SkkyHub™ service, DataHub®, WebView™, and Embedded Toolkit (ETK) software. The platform enables real-time data connectivity for industrial, embedded, and financial systems, with no programming required. Skkynet’s platform is uniquely positioned for the “Internet of Things” and “Industry 4.0” because unlike the traditional approach for networked systems, SkkyHub is secure-by-design. For more information, see https://skkynet.com.

Safe Harbor

This news release contains “forward-looking statements” as that term is defined in the United States Securities Act of 1933, as amended and the Securities Exchange Act of 1934, as amended. Statements in this press release that are not purely historical are forward-looking statements, including beliefs, plans, expectations or intentions regarding the future, and results of new business opportunities. Actual results could differ from those projected in any forward-looking statements due to numerous factors, such as the inherent uncertainties associated with new business opportunities and development stage companies. Skkynet assumes no obligation to update the forward-looking statements. Although Skkynet believes that any beliefs, plans, expectations and intentions contained in this press release are reasonable, there can be no assurance that they will prove to be accurate. Investors should refer to the risk factors disclosure outlined in Skkynet’s annual report on Form 10-K for the most recent fiscal year, quarterly reports on Form 10-Q and other periodic reports filed from time-to-time with the U.S. Securities and Exchange Commission.

Skkynet to Hold OPC UA Sandpit Event in Osaka

Technology providers from six countries gather in Japan to demonstrate secure Industrial IoT cloud connectivity for OPC UA products.

Mississauga, Ontario, September 12, 2017Skkynet Cloud Systems, Inc. (“Skkynet” or “the Company”) (OTCQB: SKKY), a global leader in real-time cloud information systems, is pleased to announce OSP 2017―OPC UA Sandpit―will be held in Osaka, Japan, on September 14, 2017.  This international event will showcase ten OPC UA products from leading industrial automation companies including Wago of Germany, B&R of Austria, Moxa of Taiwan, Comtrol of the USA, Cogent Real-Time Systems of Canada, and Kobata Gauge, Puerto, BellChild, Nissin, and NiC of Japan.  Representatives from these companies will test and demonstrate secure connectivity from their OPC UA enabled devices to the iBRESS Cloud service from BellChild, through closed firewalls and network proxies.

“These companies are at the leading edge of secure data communications for Industrial IoT,” said Paul Thomas, President of Skkynet.  “The OPC UA protocol is well-known for security within the industrial network, and this initiative demonstrates how an equally high level of security can be achieved seamlessly for IoT cloud connections.”

At the OPC UA Sandpit event, each participant will connect their hardware to a network on which BellChild’s iBRESS Box is running.  The iBRESS Box has Skkynet’s Cogent DataHub installed, which on the one hand provides OPC UA connectivity, and on the other can tunnel securely through network proxies and closed firewalls to the iBRESS Cloud.  Using OPC UA on the local network, each connected device will pass its data to the iBRESS Box, which will make it available on the iBRESS Cloud in real time.

“Skkynet’s DataHub is the key enabling technology for this kind of secure connectivity,” said Thomas.  “Functioning as the engine for both the iBRESS Cloud and the iBRESS Box, the DataHub’s unique secure-by-design approach to data communications makes it an ideal tool for Industrial IoT.”

About BellChild

BellChild is a system integration company focusing on secure system development, robust infrastructure development, and advanced operations capabilities. The company develops and maintains secure servers used to support high-speed financial transactions, which is also used to provide a robust and secure platform to support industrial cloud-based systems in the form of iBRESS™ Cloud service.  For more information, see https://www.bell-c.co.jp/.

About Skkynet

Skkynet Cloud Systems, Inc. (OTCQB: SKKY) is a global leader in real-time cloud information systems. The Skkynet Connected Systems platform includes the award-winning SkkyHub™ service, DataHub®, WebView™, and Embedded Toolkit (ETK) software. The platform enables real-time data connectivity for industrial, embedded, and financial systems, with no programming required. Skkynet’s platform is uniquely positioned for the “Internet of Things” and “Industry 4.0” because unlike the traditional approach for networked systems, SkkyHub is secure-by-design. For more information, see https://skkynet.com.

Safe Harbor

This news release contains “forward-looking statements” as that term is defined in the United States Securities Act of 1933, as amended and the Securities Exchange Act of 1934, as amended. Statements in this press release that are not purely historical are forward-looking statements, including beliefs, plans, expectations or intentions regarding the future, and results of new business opportunities. Actual results could differ from those projected in any forward-looking statements due to numerous factors, such as the inherent uncertainties associated with new business opportunities and development stage companies. Skkynet assumes no obligation to update the forward-looking statements. Although Skkynet believes that any beliefs, plans, expectations and intentions contained in this press release are reasonable, there can be no assurance that they will prove to be accurate. Investors should refer to the risk factors disclosure outlined in Skkynet’s annual report on Form 10-K for the most recent fiscal year, quarterly reports on Form 10-Q and other periodic reports filed from time-to-time with the U.S. Securities and Exchange Commission.

The cloud is good, except when it’s not.

Part 14 of Data Communication for Industrial IoT

Cloud computing can be quite useful in industrial systems to gather data and do supervisory control in some application spaces.  “Big data” services help managers and engineers to locate inefficiencies, coordinate predictive maintenance, and boost productivity.  The cloud model of software as a service (SaaS) offers a convenient way to add new functionality to existing systems, and it shifts costs from capital to operating expenses.

Despite the advantages of cloud systems, system integrators and key decision-makers in industrial facilities are reluctant to try it.   Some of the reasons for this might include:

  • License enforcement — “Will this cloud-based system be used to ensure software license compliance, in the same way my kids need an internet connection to play a single-player computer game?”
  • Vendor lock-in — “If all the processing power of the system is in the cloud service, how can I switch services?”
  • No edge processing — “There are too many cloud services that are basically just Internet-accessible databases. That’s not flexible enough for me.”
  • Security — “Once my data leaves my plant, is it safe from prying eyes?  And if I connect my plant to the cloud, will my plant be open to attack?”
  • Loss of connectivity — “If my Internet connection goes down, will I lose my ability to control my plant?”

So should we avoid cloud services altogether?  No.  They provide capability and efficiency you can’t get any other way.  In addition to data-gathering, cloud services can be used to support remote connectivity over the Internet.

Cloud as Intermediary

If we link an operation center in one city to a production system in another, there must be a network.  If we make a direct connection, then one or the other must accept an inbound connection from the Internet.  Using a cloud system as an intermediary means that neither the operation center nor the production system needs to open its firewall, thereby improving security by moving the point of attack outside either system.

Limited Data Sets

Should IIoT devices send all of their data to the cloud?  No, it’s usually not necessary.  Only the data necessary for remote monitoring and control needs to be accessed.  Device information is not monolithic – you should be able to pick and choose what the cloud has access to.

Support for Local Capability

But what happens when cloud is not available?  What happens if a cloud provider goes out of business (think Google/NEST Revolv)?  The system should degrade in a way that essential functions still remain available. The goal should be to support fundamental local capability, enhanced with cloud services.  We should still be able to use our devices when the Internet is not available.

Like most things in life, the cloud has its strong points and its weaknesses.  The most successful implementations will take full advantage of the strong points, and design around the weaknesses.  For industrial applications, that means keeping remote devices and in-plant systems behind closed firewalls and protecting them from any network slowdowns or outages.  This can be accomplished through edge and fog processing mentioned previously, and/or by implementing a hybrid cloud, which we will discuss next.

Continue reading, or go back to Table of Contents

Cloud, Edge, and Fog Processing

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

What is Edge Processing anyway?

Part 12 of Data Communication for Industrial IoT

Edge processing refers to the execution of aggregation, data manipulation, bandwidth reduction and other logic directly on an IoT sensor or device.  The idea is to put basic computation as close as possible to the physical system, making the IoT device as “smart” as possible.

Is this a way to take advantage of all of the spare computing power in the IoT device?  Partially.  The more work the device can do to prepare the data for the cloud, the less work the cloud needs to do.  The device can convert its information into the natural format for the cloud server, and can implement the proper communication protocols.  There is more, though.

Data Filter

Edge processing means not having to send everything to the cloud.  An IoT device can deal with some activities itself.  It can’t rely on a cloud server to implement a control algorithm that would need to survive an Internet connection failure.  Consequently, it should not need to send to the cloud all of the raw data feeding that algorithm.

Let’s take a slightly contrived example.  Do you need to be able to see the current draw of the compressor in your smart refrigerator on your cell phone?  Probably not.  You might want to know whether the compressor is running constantly – that would likely indicate that you left the door ajar.  But really, you don’t even need to know that.  Your refrigerator should recognize that the compressor is running constantly, and it should decide on its own that the door is ajar.  You only need to know that final piece of information, the door is ajar, which is two steps removed from the raw input that produces it.

Privacy

This has privacy and information security implications.  If you don’t send the information to the Internet, you don’t expose it.  The more processing you can do on the device, the less you need to transmit on the Internet.  That may not be a big distinction for a refrigerator, but it matters a lot when the device is a cell tower, a municipal water pumping station or an industrial process.

Bandwidth

Edge processing also has network bandwidth implications.  If the device can perform some of the heavy lifting before it transmits its information it has the opportunity to reduce the amount of data it produces.  That may be something simple, like applying a deadband to a value coming from an A/D converter, or something complex like performing motion detection on an image.  In the case of the deadband, the device reduces bandwidth simply by not transmitting every little jitter from the A/D converter.  In the case of the motion detection, the device can avoid sending the raw images to the cloud and instead just send an indication of whether motion was detected.  Instead of requiring a broadband connection the device could use a cellular connection and never get close to its monthly data quota.

Data Protocol

There is just one thing to watch for.  In our example of the motion detection, the device probably wants to send one image frame to the cloud when it detects motion.  That cannot be represented as a simple number.  Generally, the protocol being used to talk to the cloud server needs to be rich enough to accept the processed data the device wants to produce.  That counts out most industrial protocols like Modbus, but fits most REST-based protocols as well as the higher level protocols like OPC UA and MQTT.

Continue reading, or go back to Table of Contents