An enhanced, secure-by-design OPC UA to MQTT gateway can pass data through a DMZ or IT department, keeping all inbound firewall ports on the plant closed.
Automation professionals see how to optimize AVEVA software for digital transformation scenarios, using DataHub.
Mississauga, Ontario, September 5, 2018 – Skkynet Cloud Systems, Inc. (“Skkynet” or “the Company”) (OTCQB: SKKY), a global leader in real-time data communication for industrial systems, announces that the latest version of the DataHub will be demonstrated at the AVEVA World Conference North America in Dallas, Texas, from September 10 -13. The new DataHub provides unparalleled real-time data connectivity options for AVEVA software, meeting the needs of AVEVA users and dovetailing with the conference theme: “Your Digital Transformation: An Execution Roadmap.”
“We look forward to meeting process experts and automation professionals from all industries who are interested in connected technology,” said Paul Thomas, President of Skkynet. “The latest version of the DataHub provides seamless integration between real-time data in the plant, remote locations, and cloud services.”
The AVEVA World Conference North America is AVEVA’s first combined event in the North American region, bringing together executives, managers and engineers involved in process automation and system integration, allowing them to take advantage of game-changing technology sessions from AVEVA and familiar products and technologies powered by Avantis, LFM, SimSci and Wonderware.
Skkynet’s demo at the conference will show how the DataHub can be used to leverage existing and future investments in Wonderware InTouch and other AVEVA software for the IIoT and Industrie 4.0, by enabling secure, real-time connections between plants, from OT (operations technology) to IT, and among remote systems. With new MQTT client and broker support the DataHub can also connect AVEVA-based systems to cloud services from providers like Amazon, Microsoft, Google, IBM, GE, Cisco, Oracle, and others.
Skkynet’s products and services—DataHub for in-plant, SkkyHub for cloud, and ETK for embedded devices—provide secure access to industrial data through open, standard industrial protocols, allowing users to fully integrate OT with IT systems and other applications anywhere in the world. Secure by design, they require no VPN, no open firewall ports, no special programming, and no additional hardware. Secure integration of embedded devices, on-premise systems, and remote locations through seamless, end-to-end connectivity in real time lets users derive maximum value from Industrial IoT and Industrie 4.0.
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® middleware, 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.
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.
Automation.com, a leading online publisher of automation-related content, recently ran an article on the value of pairing OPC UA with a good IIoT protocol like DHTP. The article discusses how OPC UA was initially expected to serve as an IIoT protocol, but more recently the trend seems to be towards using OPC UA at the plant level only. Other protocols, such as MQTT and AMQP are being offered as candidates for connecting outside the plant, but they are not ideally suited to IIoT. This article explains why, and introduces 9 criteria for good IIoT data communication.
It’s big. It’s by far the biggest industrial automation show in Germany, in Europe, and possibly in the world. It’s SPS IPC Drives. “SPS” is German for PLC (Programmable Logic Controller), “IPC” stands for Industrial Process Control, and “Drives” are tools that control the speed of machinery. It comprises a dozen exhibition halls, each one practically a trade show in itself, filled with gigantic, colorful booths displaying robots, machines, and control system components. It’s where thousands of engineers, system integrators, machine builders and parts vendors gather for a massive show-and-tell featuring the latest and greatest—sensors, actuators, controllers, software, services and more.
Other exhibits featured IoT, and a few had working demos similar to ours, showing how they could put data from a sensor into the cloud. But there were significant differences. Most of them did not have bidirectional communication, and all of them had to make compromises on security and robust connectivity.
Data Communication must be Secure…
The two technologies most frequently mentioned for data communications were OPC UA and MQTT. Most users are finding out that OPC UA by itself cannot serve as an IIoT protocol, because like every industrial protocol, it functions on a client-server basis. An OPC UA client outside the plant needs an open firewall port at the plant to connect to an OPC UA server inside. This is inherently insecure, since any hacker could also enter the plant through that open firewall port. To surmount this obstacle, a number of companies have turned to the MQTT messaging protocol. Its publish/subscibe architecture allows it to make outbound connections. That does keep firewall ports closed, but MQTT is not suitable for IIoT for other reasons. Notably, it cannot guarantee data consistency.
… and Robust
Funnily enough, when you bring this up, people catch on quickly. I walked around the show and talked to people who had IIoT on their posters and brochures, who were demonstrating IIoT devices, and offering IIoT cloud services. Companies large and small, including some of the biggest names in the industry, are using or promoting MQTT or its close cousin, AMQP. And yet when I pointed out to them how MQTT is unable to guarantee consistent data, they soon understood. Everyone acknowledged that if an MQTT connection from a data source is broken, the data user will not know that his or her data may no longer be valid. “Isn’t that a problem? Couldn’t it be dangerous?” I would ask. “Yes,” they would admit, “but there isn’t any other way.”
Finding out that there is another way opened a few eyes. People coming to our booth and those we met throughout the show were surprised and pleased to find out that there actually is a way to maintain a secure, robust connection for IIoT. There is no need to open any firewall ports or to use a VPN, and yet you can guarantee consistency of the data between the server and the client. All you need is the right technology, secure by design. Our task for the coming months is to continue sharing this message with the 1500+ exhibitors and 70,000+ visitors at SPS IPC Drives, along with anyone else who wants to connect industrial process control systems to the IoT.
Part 8 of Data Communication for Industrial IoT
MQTT, or Message Queue Telemetry Transport, is a publish/subscribe messaging protocol that was originally created for resource-constrained devices over low-bandwidth networks. It is being actively promoted as an IoT protocol because it has a small footprint, is reasonably simple to use, and features “push” architecture.
MQTT works by allowing data sources like hardware devices to connect to a server called a “broker”, and publish their data to it. Any device or program that wants to receive the data can subscribe to that channel. Programs can act as both publishers and subscribers simultaneously. The broker does not examine the data payload itself, but simply passes it as a message from each publisher to all subscribers.
The publish/subscribe approach has advantages for general IoT applications. “Push” architecture is inherently more secure, because it avoids the client-server architecture problem, allowing devices to make outbound connections without opening any firewall ports. And, by using a central broker, it is possible to establish many-to-many connections, allowing multiple devices to connect to multiple clients. MQTT seems to solve the communication and security problems I have identified in previous posts.
Despite these architectural advantages, though, MQTT has three important drawbacks that raise questions about its suitability for many IIoT systems and scenarios.
MQTT is a messaging protocol, not a data protocol
MQTT is a messaging protocol, not a data communications protocol. It acts as a data transport layer, similar to TCP, but it does not specify a particular format for the data payload. The data format is determined by each client that connects, which means there is no interoperability between applications. For example, if data publisher A and subscriber B have not agreed on their data format in advance, it’s not likely that they’ll be able to communicate. They might send and receive messages via MQTT, but they’ll have no clue to what they mean.
Imagine an industrial device that talks MQTT, say a chip on a thermometer. Now, suppose you have an HMI client that supports MQTT, and you want to display the data from the thermometer. You should be able to connect them, right? In reality, you probably can’t. This is not OPC or some other industrial protocol that has invested heavily into interoperability. MQTT is explicitly not interoperable. It specifies that each client is free to use whatever data payload format it wants.
How can you make it work? You must either translate data protocols for each new connected device and client, or you need to source all devices, programs, HMIs, etc. from a single vendor, which quickly leads to vendor lock-in.
The broker cannot perform intelligent routing
MQTT brokers are designed to be agnostic to message content. This design choice can cause problems for industrial applications communicating over the IoT. Here are a few reasons why:
1) The broker cannot be intelligent about routing, based on message content. It simply passes along any message it gets. Even if a value has not changed, the message gets sent. There is no damping mechanism, so values can “ring” back and forth between clients, leading to wasted system resources and high bandwidth use.
2) The broker cannot distinguish between messages that contain new or previously transmitted values, to maintain consistency. The only alternative is to send all information to every client, consuming extra bandwidth in the process.
3) There is no supported discovery function because the broker is unaware of the data it is holding. A client cannot simply browse the data set on the broker when it connects. Rather, it needs to have a list of the topics from the broker or the data publisher before making the connection. This leads to duplication of configuration in every client. In small systems this may not be a problem, but it scales very poorly.
4) Clients cannot be told when data items become invalid. In a production system a client needs to know that the source of data has been disconnected, whether due to a network failure or an equipment failure. MQTT brokers do not have sufficient knowledge to do that. The broker would need to infer that when a client disconnects it needs to synthesize messages as if they had originated from that client indicating that the data in certain topics are no longer trustworthy. MQTT brokers do not know how to synthesize those messages, and since they don’t know the message format, they would not know what to put in them. For this reason alone MQTT is a questionable choice in a production environment.
5) There is no opportunity to run scripts or otherwise manipulate the data in real time to perform consolidation, interpretation, unit conversion, etc. Quite simply, if you don’t know the data format you cannot process it intelligently.
No acceptable quality of service
MQTT defines 3 levels of quality of service (QoS), none of which is right for the IIoT. This is an important topic and one that I have gone into depth about in a previous post (see Which Quality of Service is Right for IIoT?). MQTT might work for small-scale prototyping, but its QoS failure modes make it impractical at industrial scale.
In summary, although the MQTT messaging protocol is attracting interest for IoT applications, it is not the best solution for Industrial IoT.