Considering Prefab

/by

An uncle of mine was an entrepreneur and quite a do-it-yourselfer.  His main businesses included a restaurant and a propane gas distributorship, but he was a real hands-on kind of guy, and spent a few summers building a cottage on Seneca Lake in Upstate New York.  It was an ongoing project, always in a state of “finishing.”

The first stage, a small one-story, was mostly done, with panelled living room and functional kitchen, although some of the bedrooms in the back were unfinished—partially drywalled with exposed plumbing and electrical.  The next stage was planned as a large two-car garage to be capped by a second story master bedroom and office with large glass doors and picture windows overlooking the lake.

That was the plan, anyway.  The reality was that his various businesses and other interests intervened.  For the several summers that my brother and I worked with and for him, the garage was his workshop, while progress on the second story proceeded in fits and starts.  A year or two after I’d moved away from the area, it was a heartbreak to find out that the cottage had caught fire and burned to the ground,  due to a short-circuit in the wiring.  Nothing useful was left but the original concrete slab.

I never got to see that cottage completed.  But my uncle was not deterred.  He rebuilt, prefab.  In a few weeks he had a very nice two-story cottage, with a two car garage and great views of the lake from picture windows on both stories.  Rather than wasting his time framing rooms, running wiring, joining pipes and hanging sheetrock, he was out on the water sailing, or cooking up a barbeque with his cousins and family.

The lesson for me?  Sure, maybe you can do it all yourself.  But should you?  It could take more time than you expect, and the results may not be what you were hoping for.  Sometimes it’s best to leave the tedious, difficult, and specialized work to the experts, and focus on what brings the most value, or the most fun.

As we explained in a recent article published in Automation.com, this is the principle behind working with Skkynet’s ETK, and its OPC UA framework, rather than a software development kit (SDK).  Using an SDK can take an expert programmer 12 to 18 months to build an OPC UA server.  Meanwhile, a developer who uses the ETK gets a pre-built OPC UA server, and can focus on his or her applications.

Some people, like my uncle, seem to enjoy doing it themselves.  They rise to the challenge, and given enough time they can succeed.  And then there’s the prefab option: buy, install, and run.  The grunt work is done.  Drop your hammer and rig the sailboat.  That’s the benefit of the ETK’s OPC UA framework—the difficult and boring work is done, so the developer can focus on what he or she knows and does best.

Automation Pros Define Industrial IoT

/by

Sometimes it’s good to take a step back from your work and see how things are going, whether you are having any impact.  For a writer that means checking in with your audience to see what they have to say.  Recently Bill Lydon, the Chief Editor of InTech, the automation magazine, did just that.  InTech has been reporting on Industrial IoT for several years now, and in this month’s column Lydon asked his readers how they would define the terms “Industrial IoT“ and “Industry 4.0”.

The automation pros that responded to Lydon’s request seem well informed, giving thoughtful and well-articulated responses.  Some were simple: “A way to integrate equipment in a network and provide this information to everybody that needs this information.”  Other responses were more elaborate: “A connected network of sensor-based monitoring and production equipment and software, providing actionable information to people to enable better informed decisions. Access to this information is not bound or restricted by a physical connection to the facility where the physical equipment operates.”

Two Main Viewpoints

What stood out to me in this informal survey was that almost all of the responses fell into one or both of two categories:

Communications and Data Transfer – All of the automation pros who looked at the practical, engineering side see IIoT as fundamentally improved communications for better data access.  The words “connect”, “transmit” and “transfer” occur frequently in these responses, among the specific kinds of connected devices and applications.

Transformational – The other type of comments were of the big picture of the benefits to the company of this enhanced data access and communication.  These comments, categorized by Lydon as “transformational,” are perhaps best summed up in the words of one respondent: “… improved quality control, sustainable and green practices, supply chain traceability, and overall supply chain efficiency in industrial manufacturing.”

Our takeaway from this survey is that Lydon and others like him in industrial trade publications are reaching their audience.  A clear picture of IIoT is taking shape in the minds of InTech readers.  We see this as an affirmation of our efforts to provide high-quality data communications for IIoT applications, enabling engineers, managers, and executives to digitally transform their companies.

Skkynet’s Approach Calms Recent Security Concerns

/by

Eyebrows were raised among the industrial automation community last week when the well-known Kaspersky Labs issued a report titled OPC UA Security Analysis that lists 17 security issues in the OPC UA protocol and products. While we see no reason to doubt their methodology, we take a different approach to the question.

As we see it, the real issue is not the OPC UA protocol itself. OPC UA was created to allow client/server networking for industrial communication. The flaws that Kaspersky identified were visible on an OPC UA server that, by definition, is listening for network connections from OPC UA clients. Any application that listens for connections on a network can equally be a point of attack for a malicious hacker. This is not unique to OPC UA—it is a fact of the design of TCP/IP networks. Period.

Think about it. How did Kaspersky Labs discover the vulnerabilities in OPC UA and related products? Using a technique called “fuzzing”, they used a specially-constructed client application to send a rapid-fire barrage of messages at the UA server, each of which was slightly altered, or “mutated”, in some way from a standard message. Sooner or later one of these messages would crash the server or uncover an exploitable vulnerability. This technique can be used on any network-connected server, like a web server, VPN server, RDP server or vendor-supplied remote access server.

We would argue that Kaspersky Labs was searching for symptoms while overlooking the cause. What the report does not address, and indeed it is so obvious that it is easily overlooked, is that this kind of attack can only succeed if the intruder has access to the server in the first place. All software has bugs. Any program exposed to the Internet is fair game. However, as long as your servers are running on a trusted network and you keep all inbound firewall ports closed, you don’t run the risk of an attack from outside, no matter how persistent or devious the attacker may be.

The Real Problem

The real problem is that the standard approach to industrial data communications is not suitable for untrusted networks like the Internet. We are used to a client on the user side connecting into a server at the data source―after all that’s the classic server-client architecture. But for Industrial IoT this approach poses a serious risk because the client is often outside the trusted plant network. It needs an open firewall port into the plant to connect. This design itself is the fundamental reason for the security problem. Rather than expecting protocols or software to be bug-free and invulnerable to attack, it makes more sense to find a more secure design approach altogether.

A Better Approach

A better approach is not to allow any inbound connections at all. The whole Kaspersky Lab scenario was built on repeated client connections into the server network. What if the server (over which the attacker has no control) connects out to the client? If you can establish only outbound connections from a data source to a data user, then the entire threat vector is eliminated. With all inbound firewall ports closed, the plant network and all of its OPC UA servers become invisible. And you can’t attack something that you can’t see.

This is Skkynet’s approach. It is running in production systems worldwide, and it is fully compatible with OPC UA. By keeping OPC UA servers within the trusted network, and keeping all firewall ports closed, Skkynet’s approach enables secure Industrial IoT connectivity, while still reaping the benefits of OPC UA in the plant.

Note: A version of this article was recently published on the Automation.com website.

System Integrators Waking Up to IIoT at CSIA 2018

/by

Each spring owners, CEOs, and other leaders from some of the world’s top automation and control system integration companies meet to share their experiences, sharpen their skills, and catch up on the latest trends at the annual Control System Integrators Association Executive Conference, CSIA 2018. This year the event was held in cool and breezy San Francisco, with a record attendance of just under 600 participants

Compared to last year the importance of IIoT is becoming more recognized among conference organizers and participants alike.  Several of the talks and workshops had “IIoT” in their title and content.  When we told people we work in the Industrial IoT space, the response was usually interest combined with varying degrees of understanding.

Growing Understanding

Despite a growing familiarity with the term “IIoT”, there seems to still be quite a bit of uncertainty about what it is, and more importantly, its value.  In one workshop I attended, there was a lively conversation about the precise definition of IIoT.  After several opinions were given, the general consensus was that IIoT can mean different things to different people.  Some, for example, saw little difference between IIoT and SCADA, while others attempted to simplify the terminology to meet their understanding, such as by defining the term “edge processing” as “a fancy way of keeping data in the plant.”  You could sense the sincere efforts to embrace the new concepts of IIoT, mixed with a reluctance to step into a new mind-set.

This new mind-set is in some ways easier to accept by professionals and experts outside industry.  In another presentation, Evolution of the SI (System Integrator) Role, Tony Rigoni of Cisco Systems spoke about the growing demand for bridging OT (Operational Technology) and IT via IIoT, and said that IT system integrators can’t do it right now.  They don’t have the industrial background or experience.  But he warned that system integrators in OT need to get on top of it quickly, because the IT people are waking up to the opportunity.

The Value of IIoT

Other non-industrial professionals at CSIA 2018 eyeing IIoT opportunities include investors.  In a panel discussion among venture capitalists and investment bankers, David Mount from Kleiner Perkins, whose focus is primarily on IoT companies said, “The value of IIoT will be in connected control.” In other words, bidirectional data communication.  Underlining his point, he said, “Closing the loop is a big opportunity.”

What he was alluding to is a capability we have been offering for several years now—the ability to not only collect data and store it in the cloud, but also the ability to send commands back to the system.  Sometimes referred to as “supervisory control,” this can be as simple as switching off a pump that is overheating to updating recipes or sending complex commands.  Instead of just storing data, the cloud now becomes a conduit for securely exchanging data and control in real time.

As system integrators worldwide wake up to the wealth of opportunity inherent in IIoT, it is our responsibility and our privilege here at Skkynet to offer them the full value of IIoT, from integrating plant OT with office IT to the ability to connect and control remote systems, anywhere, securely, in real time.

Extraordinary Remote Service Management through IIoT

/by

We’ve all heard about helicopter parents. You know, that mom or dad that keeps hovering over their child, choosing their clothes and their friends, checking out their Facebook pages, watching their every move. Hey, after all, they’ve invested a lot of time and money into their offspring, and they aren’t going to just let those kids go out on their own and mess things up, right?

While that might not be the best parenting model for human children, it may transfer well to physical products—particularly expensive, complicated products like machine tools. Builders of industrial equipment are often responsible, by choice or by contract, for the performance and maintenance of their machinery for years after the sale. Mechanical failure is not an option for an assembly line whose down-time costs can be in the tens of thousands of dollars per minute. More and more customers buying equipment are looking for 24/7 monitoring and remote service management. And more and more vendors and OEMs are turning to the Industrial IoT (IIoT) for solutions.

With or without IIoT?

Consider the options. Without the IIoT, a lot of time gets wasted between the detection of a problem and a repair. The company calls the vendor, who sends out a rep to inspect. The rep then processes a work order, which may require a second visit by someone with the right skills, tools, and parts to make the repair. The whole process can take hours, even days, while the machine, and sometimes the whole line, sits idle.

With the IIoT, the vendor or OEM maintains a full-time connection to the machine, and can continuously monitor every aspect of its health, such as operating temperatures, abnormal vibrations, fluid levels, and so on, via the web. Before a problem is even noticed by an operator, the vendor can detect an irregularity, assess the situation, manage a work order, and send out repair personnel right away. Sometimes they can even make the repair remotely, without any on-site visit at all.

“OEMs tell ARC that 30 percent or more of the repairs can be made via the web by modifying parameters remotely or with minor assistance by an onsite person,” says Ralph Rio of ARC Advisory Group in a recent article, How IIoT Improves Field Service Management KPIs.

Extraordinary service

The IIoT makes an extraordinary level of service possible. But it’s not just any IoT platform that will be so helpful. Giving a vendor access to a piece of equipment inside a plant requires deep trust. The connection needs to be secure. Within that secure connection, the vendor should not have access to the whole plant network, just to the data. And then, to modify a parameter or change a machine set point requires bidirectional data flow.

Many IoT platforms offer Internet connections, but few of them can securely connect into an industrial plant without opening a firewall. Among those that can, many rely on VPN technology, which opens the whole plant network to the vendor. Of those that are able to make a connection without a VPN and still keep all firewalls closed, most are offering only one-way data flow, from the plant to the cloud. It takes an extraordinary service to provide what Ralph Rio is talking about: the ability to modify parameters remotely, and do it securely. It is exactly this extraordinary level of service that SkkyHub offers. For those vendors and OEMs that want supervisory control over their offspring—their products—this is the kind of remote service management that works best.

What Makes an Ideal Protocol for IIoT?

/by

If you want to ship goods, you need infrastructure.  Trucks, trains, ships, and planes rely on highways, tracks, ports, and airports.  In a similar way, a key element of Industrial IoT (IIoT) is the infrastructure, in other words, a data protocol.  Just as there are many transportation modes to choose from (some better than others), there are a number of IIoT protocols on offer―and they are not all the same.

Since the IIoT is still quite new, it has been an ongoing question as to what makes an ideal IIoT protocol.  With limited experience in this new sphere, many early adopters have looked to existing protocols.  For example, companies are currently using or considering MQTT or AMQP messaging protocols, the REST web services protocol, or the OPC UA industrial protocol.  Each of these works fine in its own application space, and each seems like it could work as an IIoT protocol.  But are any of these really suited to task? Or is there something better out there?

9 Criteria for an Ideal Protocol

To answer that question, we did a comparison.  We distilled over 20 years of hands-on experience in industrial data protocols and TCP networking into 9 criteria for what makes an ideal protocol for IIoT.  The results are summarized in a new white paper, IIoT Protocol Comparison.

These 9 criteria cover all of the essential areas of high-quality industrial data communication, like real-time performance and interoperability.  They also cover the broader arena of the Internet, with its greater security risks, variations in bandwidths and latencies, and multi-node architectures.  The white paper considers specific criteria for each of these in turn, and provides a simple explanation of how each of the protocols does or does not meet them.

If you’ve been following the growth and development of Skkynet over the years, the results of the comparison should come as no surprise.  The only protocol we are aware of that was designed from the ground up to provide secure networking of industrial data both on-premise and over the Internet is DHTP.  DHTP is what our products and services have been using for over 20 years, and it is one of the keys to their success.  We invite you to read the white paper, consider the criteria, and see for yourself what makes an ideal protocol for IIoT.