Leveraging the IIoT for Asset Performance Management (APM)

How well is our equipment performing?  Are we getting the best mileage from it?  When will machine/pump/motor X fail?  What can we do better?  How can we even find out?  These are the kinds of questions that keep production managers awake at night, and that may eventually lead them to consider implementing Asset Performance Management.

The term “Asset Performance Management” or APM, has been broadly defined by MESA International as “an approach to managing the optimal deployment of assets to maximize profitability and predictability in product supply.”  In other words, APM means making sure your equipment works, and works well.

The need for APM is clear.  Asset failure costs millions of dollars in lost production each year.  But that’s not all.  Workers who lack of critical data about the state of their equipment can make expensive mistakes.  Broken or poorly-functioning machinery can cause accidents.  Failure to manage assets properly will eventually lead to higher insurance costs.

A New Approach to APM

Until recently, APM has been used mainly for high-cost, mission-critical machinery.  Data collection was based on scheduled manual readings of sensors mounted on machines, a costly, time-consuming effort.  Performance stats for less expensive assets were typically derived from plant walk-throughs, operator experience, and educated guesses.  In some cases it was more cost effective to simply allow equipment to run until failure, and then replace it.

The advent of the IIoT is changing all of that.  As the cost of sensors drop, as wireless technologies improve, and as Big Data systems come online, it is now becoming cost-effective to monitor more and smaller assets, and do it in real time.  Doing APM in real time allows managers to run advanced analytics on the data, and do predictive maintenance.  Now, instead of shutting down a process to replace a burnt-out fan motor, or guessing when the motor might need to be replaced, an engineer can run the motor until just before failure, and then switch it out at the optimal time.

Early Adopters

Commenting about APM, Rich Carpenter, the Chief Technology Strategist for GE Intelligence Platforms, said, “The purpose of running advanced analytics is to have early detection of problems, so that we can prevent in real time, rather than react in real time.”  GE follows a simple, four-step process for IoT-based APM:

  1. Connect to sensors on the plant equipment or for the control system.
  2. Send the sensor data via DMZ or other protected environment to the cloud.
  3. Organize the data, according to type of customer, site, machine, etc.
  4. Run advanced analytics to manage the assets.

Hartford Steam Boiler (HSB), an industrial insurance company, has a vision that IoT-powered APM may transform their business into becoming an industrial service provider.  Instead of simply insuring against mechanical failure, by putting IoT-connected sensors on their customers equipment, the company can check performance, find the risk of breakdown, and recommend timely replacement or repair.  “The Internet of Things is the next industrial revolution and we have to position ourselves,” said Greg Barats, CEO of HSB.  “IoT start-ups are a fantastic way of jump-starting your thinking.”

What visionaries like GE and HSB have in common is an understanding of the potential of IIoT to be a game-changer for APM.  We share that vision.  In fact, we see APM as a logical application for IIoT technology, and supply the necessary software and services to securely access the necessary data in real time, to make it happen.

Tech Talk and Action in IIoT Data Communications

Is summer over already?  It may be hard to accept, but on my morning walks the sun rises later each day, the wind is more brisk, and the leaves are turning yellow and red.  Before fall arrives in earnest, I’d like to share a bountiful harvest of summer activity here at Skkynet.  While most of the world was on holiday and taking it easy for a few weeks, our technical team took the opportunity to jot down some of their thoughts on our specialty: data communication for Industrial IoT.

In this first installment of a new series of Tech Talk blogs, lead developer and company CEO Andrew Thomas discusses IIoT security, data protocols, best practices, and common pitfalls.  He starts by introducing the unique requirements for Industial IoT, and he challenges the assumptions that lead to inherently insecure system design.  He then discusses each of the data protocols often suggested for use in the IIoT: UDP, MQTT, OPC UA, and REST, pointing out the strengths and weaknesses of each.  The best approach, he argues, exhibits the best qualities of these and more, as well as supporting edge and fog processing and public, private, or hybrid clouds.

This is the thinking that underlies SkkyHub, Skkynet’s secure-by-design approach to Industrial IoT.  Combined with our ETK and Cogent DataHub, the result is Industrial IoT that actually works.  You can install it in green field or brownfield projects, and connect to new or existing systems, use open protocols, and provide secure, robust, real-time performance at speeds not much slower than Internet propagation speeds.  And it is available today, right now.

This fall we are putting SkkyHub, DataHub, and ETK on display and into play in several arenas.  We will be at conferences and trade shows in North America, Europe and the Far East, including OPC Foundation Seminars in Vancouver and Toronto, Industry of Things World 2017 in Berlin, Sensors Midwest in Chicago, ARM TechCon in Santa Clara, SPS Drives in Nuremberg, and SCF in Tokyo.  If you are attending any of these, please stop by.

In the field, SkkyHub customers are enjoying the benefits of the service, and some have expressed an interest in sharing their experiences.  We will be blogging about those soon.  Meanwhile, the tech team has shfited back into development mode, and we expect some exciting news from them soon as well.  Summer may be winding down, but Skkynet continues to move rapidly ahead.

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

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

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.

Industrial IoT that Works

Data Communication for Industrial IoT – Conclusion

The Industrial IoT holds a lot of promise for improving productivity and cutting costs for industrial systems.  Yet the IIoT is different from both the consumer IoT and traditional SCADA systems.  In particular, data communications have unique requirements that you need to keep in mind if you are planning to implement an IIoT project that works well.

Re-Thinking Assumptions

Because industrial data communication was developed independently of the Internet, the merging of these two technologies requires a re-thinking of some basic assumptions.  The most secure and reliable approach is to focus on the data, and to allow access to the data onlyAccessing a device means that the device is open to an attack.  Accessing the network leaves the network exposed, even if you use a VPN.  A more secure-by-design approach allows the data source and the data user to make outbound connections to a public or private cloud service that holds only the data.  This keeps all plant firewall ports closed, and provides a secure spot independent of the plant where the data can be accessed by authorized users.

Data Protocol Problems

A number of data communications protocols have been proposed for the IIoT, each with its advantages and drawbacks.  UDP works for VOIP and streaming media, but it lacks the accuracy and completeness so necessary for good industrial communication.  MQTT offers a publish/subscribe mechanism and many-to-many connectivity, but lacks a standard data protocol and the ability to handle messages intelligently.  OPC UA is a good choice for in-plant connectivity, but suffers from the traditional server/client design that requires an open firewall port to connect from the Internet.  REST over HTTP is popular for general IoT applications, but has issues with bandwidth, latency, scalability, symmetry, and robustness when faced with the high speed and large number of connection requirements of the IIoT.  To implement security Blockchain may sound good in theory, but a closer look shows why it will fail in practice.

A New Approach

Clearly, a new approach specifically designed for IIoT is needed.  This approach should use the robust foundation of TCP, the security of a publish/subscribe model like MQTT, and the in-plant connectivity of OPC UA.  Its bandwidth use, latency, and scalability should far exceed RESTful HTML.  This new approach should support edge processing, and in fact, provide the means for edge processing, cloud processing, and fog processing, as dictated by the circumstances on the ground or in the field.  It should be available as a public cloud, a private cloud, or a hybrid combination of public and private clouds.

Something That Actually Works

Most important, this approach should actually work.  You should be able to install it in greenfield or brownfield projects.  It should connect to existing systems, use open protocols, and provide secure, robust, real-time performance at speeds not much slower than Internet propagation speeds.  And it should be available today, right now.  If you’re interested, give us a call.

Go back to Table of Contents

Red Lion adds new platforms for cellular RTUs that further IIoT connectivity

Red Lion Controls, a global expert in communication, monitoring, and control for industrial automation and networking, announced that its RAM industrial routers and cellular RTUs now support the Microsoft Azure, Cumulocity, and Nokia IMPACT IIoT platforms.

This follows the recent announcement that Red Lion’s RAM products now support the MQ Telemetry Transport (MQTT) protocol. The addition of these two platforms moves Red Lion RAM products to lead the market in the greatest number of platform integrations, providing greater flexibility for industrial customers to quickly connect to their choice of leading IIoT cloud platforms.

In addition to those announced, RAMQTT, Red Lion’s embedded MQTT client, simplifies implementations with pre-configured profiles for AT&T M2X, Amazon AWS IoT, AutoDesk Fusion Connect and Telenor Connexion. Customers connect using a simple drop-down menu to select their cloud platform of choice. Also, using the RAM Software Development Kit (SDK), connectivity can be enabled with additional platforms, including LEC IQ Web SCADA, Set-Point IPwebcontrol, Skkynet SkkyHub, and Telit deviceWISE.

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