industrial and automation communication protocols in … … · communication protocols in the age...

2017 ISA Water / Wastewater and Automatic Controls Symposium

Aug 8-10, 2017 – Wyndham Lake Buena Vista Disney Springs Resort Area, Orlando, Florida, USA –

www.isawwsymposium.com

2017 ISA WWAC Symposium

Industrial and Automation

Communication Protocols in the Age of IIoT Achieving Consistency, Reliability, High Availability, and Autonomy

Alan Hudson1*

1Trihedral Engineering Limited, Suite 400, 1160 Bedford Hwy, Bedford, NS B4A1C1

(*Email: [email protected] and Phone: 205-612-6665) 1Trihedral, Inc., 4700 Millenia Blvd., Suite 260 Orlando FL 32839

KEYWORDS

Communications, Water, Wastewater, SCADA, Protocols, IoT, IIoT, Internet of Things, Cyber

ABSTRACT

Over the last 30 years, typical water wastewater SCADA systems have exploded in the quantity of data

expected to be gathered from an ever-increasing number of digital field devices. The communication

“pipelines” used to connect these devices now include a multitude of serial, Ethernet, radio, and cellular

communication mediums via a plethora of communication protocols. What used to be simple has now

become complex. Or is it just the opposite - What used to be complex has now become simple?

In 2013, the IoT (Internet of Things) was defined as “the infrastructure of the information society.” For us,

the IIoT (Industrial IoT) emerged. Many in our industry have rightly argued that “we have always had an

IIoT” because of our documented standards, mechanisms, and best practices for how to gather

information from the field devices, store the data centrally, analyze and make decisions accurately, and

command and control the field devices through this recursive process. Yet today’s IIoT buzz largely focuses

on TCP/IP communication over Ethernet and takes advantage of the expanding IoT technologies,

connectivity, and possibilities.

Utility-wide SCADA system successes have created a hunger for data, a desire for standardization, and a

realistic concern about security. And while emerging technologies seem to be helping drive the vision, we

must continue to place a proper importance and a balanced perspective on proven technologies and best

practices. We must remember the goals of our industry – “to reliably and efficiently provide safe drinking

water to the public and remove, clean, and restore the water through environmentally responsible

methods.”

This paper explores the proven communication protocols used in today’s SCADA systems and how they

compare, contrast, and complement emerging IIoT functionalities.

----

mailto:[email protected]

Hudson 2




INTRODUCTION

History has proven that those who embrace technology and apply it appropriately are far more likely to

succeed. When technology alone is given an inappropriate amount of importance or prematurely applied,

success is often delayed or not realized. Our goal must be to better understand technology, its

implications, and its benefits. When we do, we will find the best solutions for our particular situations.

IoT, IIoT, IT, OT, and SCADA: What’s With All the Abbreviations?

It’s amazing the confusion three letters can create. It’s even more amazing the marketplace disruption

these same letters make in a world that is used to acronyms. For over 30 years, the automation,

instrumentation, and controls industry has wavered between A&C (automation and controls) and I&C

(instrumentation and controls) when defining roles and responsibilities. For many, the differences were

minor and the terms interchangeable. For others, the differences signified a huge chasm that could not be

bridged without training and experience. The same can be said for SCADA and IIoT. At least OT and IT are

completely different, right? Maybe not so much…anymore.

The term SCADA is simple: Supervisory Control and Data Acquisition.

OT is Operational Technology and IT is Information Technology.

IoT is the Internet of Things and IIoT is the Industrial IoT.

All of these abbreviations represent deeply held beliefs that their way is the best way to gather data,

analyze the situations, and make decisions. One of the biggest struggles has more to do with the “How” to

gather, analyze, and make decisions than the “Why.” But 30 years ago, the conflict was between OT and IT

– the “Leave the operation of the system to me.” group vs the “We have the technology; we will handle

it.” team. By tirelessly working through these differences and better understanding the value and

expertise of “other guys,” OT and IT are coming together and optimizing their systems.

The wonderful thing about technology is that it is

always changing, building upon the successes of the

past, and continuing to push us toward even greater

technologies, advancements, and applications.

Digital communication systems, specifically as they

apply to SCADA, have dramatically improved over

the last 30 years.

The most recent developments to take advantage of

these technological advancements is the IoT (and

IIoT). But what does this really mean and how does

it affect my existing SCADA system? Is it really so

different?

Hudson 3




Much of our industry’s future successes hinge on how quickly and effectively we, as leaders in the

industry, can bridge the philosophical gap between SCADA and IIoT. The technological gap will close

regardless of our actions but the benefits require our acceptance.

Communications: An Evolution, Not a Revolution

It has been said that the invention of the Internet is as significant as the invention of the printing press.

Not only did the printing press allow for the written word to be placed into the hands of the masses, it

encouraged the growth of the writing of the words that would be distributed. Similarly, the Internet has

caused just as much, and maybe more, of an impact on the world.

When considering the similar products of the printing press and the Internet, it is interesting that even in

this digital age, trends indicate that people still prefer the paper-based written word in lieu of digitally

consumed products. But if one combines the paper-based words with the digitally distributed words, the

quantity of words consumed has skyrocketed. Both technologies, working together, have dramatically

increased communication.

Some systems are replaced by evolutional technologies (like telephone booths, covered wagons, and

outhouses) while others are augmented. SCADA will not be replaced by the IIoT, but IIoT technologies will

influence and improve SCADA systems such that greater levels of optimization can be achieved. The

preferred result will be systems that embrace both technologies and utilize them appropriately.

Modbus and Other Serial Protocols

Serial protocols were a technological breakthrough. For years, our systems ran copper wires within the

plant and tone telemetry outside the plant. Pulse Duration was how we knew the “analog value” from the

instruments. In 1979, the invention of Modbus changed that. By the late 1980s, most new in-plant systems

were being connected with a serial communication link. By the turn of the Millennium, virtually all remote

tone and pulse systems had been upgraded to digital communications. Through technological

advancements, communication “baud rates” went from 300 to 1200 to 9600 to 19,200 and beyond, thus

greatly increasing the communications’ effectiveness and creating acceptability for smart controls and

instruments.

Today, serial communication is still used extensively via a variety of serial protocols. So what does that say

about serial communications? It means that while technology continues to progress, the basis of digital

communications remains strong. At some point it may fade away, but not for many years to come.

The methodology of serial communications is a Poll/Response (or Master/Slave) way of getting data from

the remote assets to the central hub. The host asks the remote for data and the remote responds

appropriately. The sequence continues for all the remote assets and then repeats continually. That will be

addressed again later.

Hudson 4




Ethernet Communications

Even though Ethernet was standardized in 1983 as IEEE 802.3, it really didn’t catch on in our industry until

Windows for Workgroups was released in 1992 and the HMI/SCADA software manufacturers took

advantage of the ability to network computers. Since then, the advancements have come in spurts based

on dynamics such as CPU power, Ethernet communication speeds, chip designs, etc. By the late 1990s,

Ethernet communications among PLCs and computers was becoming commonplace. By 2005, while

Ethernet was the expected protocol, it has only been in recent years that this functionality has been

implemented in remote devices.

The advantages for Ethernet include faster speeds, common addressing, simplified connectivity, and wide

acceptance. Communication protocols are still important but they are more standard in structure. In the

early 2000s, various groups were created to drive standards and directions for industrial Ethernet

communications. Common Ethernet protocols are Ethernet I/P and Modbus TCP.

In most typical SCADA applications, the method of Ethernet communications is similar to serial

communications - Poll/Response (or Master/Slave) – but faster. But when other protocols (like DNP3.0)

are introduced, the communication schemes often change.

Advanced Communication Protocols like DNP3.0

Interestingly, the Distributed Network Protocol (DNP) was created in 1983 for the electric power industry.

The need for advanced communication functionality also came with higher complexity. The problem this

protocol solved, however, was that of improved bandwidth and data through-put by creating four classes

of data (Class 0, 1, 2, and 3) that can operate as Report-by-Exception and as Polled Data. Another benefit

Hudson 5




this protocol provided was the addition of Time/Date Stamp data so that data could be chronologically

synchronized over the network, thereby making data analysis meaningful and consistent.

While much could be written about the DNP protocol, the main take-away is that this protocol, available

over serial or Ethernet, allowed a user to move from a Poll/Response method to include Report-by-

Exception. The result is reliable data acquisition and increased analytical capabilities.

The Internet of Things Protocols

Some of the industry’s most talked about IIoT protocols are HTTP (includes JSON, XML, REST), OPC-UA,

and MQTT. See summary below. As expected, the race to set the IIoT standards is moving quickly though

there is not yet a clear winner. And because there probably won’t be a winner, these protocols will have

to co-exist. The biggest challenge is interoperability, even among the open standards.

In contrast to the Poll/Response methodology of traditional SCADA protocols, the IIoT protocols operate

on Client/Server and Publish/Subscribe methodologies. Poll/Response networks require a well planned

system configuration. Client/Server systems also work best in planned infrastructures. Publish/Subscribe

protocols are a better choice when the infrastructure is unknown.

Client/Server protocols require the client to connect to the server and make requests for the data. The

servers hold the data and respond to the client’s requests. In this application, the client must have

knowledge about the servers and be able to connect. These systems are generally less scalable due to

point-to-point connectivity requirements.

The Publish/Subscribe protocols require the devices to connect and publish data to a “broker.” Consumers

of the data can connect to the broker and subscribe to the data. When the remote device sends data to

the broker, the subscriber will then get the updated data. These systems are more scalable because the

publishers and subscribers are managed independently.

Here is a brief summary of several IIoT protocols: HTTP (includes JSON, XML, REST), OPC-UA, and MQTT

Client/Server configuration:

HTTP – HyperText Transfer Protocol - A connectionless client/server protocol prolific throughout IT

and the Internet; many open source tools available; virtually every coding language has HTTP

libraries.

JSON – JavaScript Object Notation – a lightweight data-interchange format with objects and

arrays.

XML – Extensible Markup Language – similar to JSON but longer and slower; it is a language, not a

format.

REST – Representative State Transfer – A stateless protocol where the client accesses resources on

the server via requests.

OPC-UA – OPC Unified Architecture – Next generation OPC that provides standard interfaces to

PLCs and devices.

Hudson 6




Publish/Subscribe configuration:

MQTT – Message Queuing Telemetry Transport – Geared toward minimal overhead and reliable

communications; not infrastructure dependent; based on the TCP protocol; seems to be gaining

popularity and acceptability.

Poll/Response vs Client/Server or Publish/Subscribe

Interestingly, many of the IIoT system diagrams published today show an IIoT Server or Broker as a data

concentrator that communicates to remote devices via traditional serial and Ethernet protocols. The real

growth of the IIoT will occur after the remote devices incorporate the IIoT into their processors. Until

then, the server or broker is mostly a data concentrator with IoT connection to “The Cloud.”

What that means for us is that traditional SCADA is here to stay, at least for a long time to come. It also

means that the connectivity of devices will continue to evolve and the distribution of data will continue to

increase. And as more field data becomes available, there will be advancements in analyzing the data and

sharing it with other interested parties that want it for continued optimization.

The Recursive Process

For the purpose of this paper, the recursive process is loosely defined as the process in which the

technology progresses, is utilized, then optimized, then built upon. This process continues to loop back

and is either improved again or determined that its usefulness is achieved. At each point of loop-back, the

beginning is the most recent stopping point so that the process continues to increase the value of the

process and its results. In the case of SCADA and IIoT, this recursive process evolves in numerous paths as

we strive for continual improvement.

The Recursive Process of Poll/Response Communications:

Communication speeds increase;

Communication methods change (radio to cellular to wifi; serial to Ethernet; copper to fiber; etc.);

Poll/response sequencing optimized;

Data more frequent, accurate, relevant;

The recursive process continues.

The Recursive Process of Communication Protocols:

Simple protocols are developed to transfer data;

Protocols are modified to gather more/more frequent/more accurate data;

Hardware upgraded to take advantage of improvements;

Communications optimized;


Hudson 7




The Recursive Process of SCADA & IIoT Systems:

Premise-based systems are installed;

Data are gathered;

Availability of data moves to different platforms (historians, local or remote “cloud”);

Data are analyzed, turned into information, and shared;

Desire for more data ensues;

Other methods for data gathering explored;


Cyber-Security: Is There an Advantage?

When it comes to digital communications, the systems work wonderfully when going according to plan.

The real question is what happens during critical events, during times of heavy data gathering, and when

something goes wrong. For example, what happens to the serial radio connections during severe weather

events? What happens to cellular assets during times of catastrophe? What happens to SCADA and Cloud

systems during a cyber-attack?

As this paper is being written in May 2017, the world is reeling from the WannaCry virus which affected

over 200,000 computers in 150 countries. While the intent of this paper is not to address cyber-security,

we do need to briefly address the realities of the situation.

Reports say that this virus took advantage of a Microsoft vulnerability. These vulnerabilities could have

been minimized had the systems updated their software in March, but since they did not, the computers

were attacked by ransom-ware initiated by a hacking group called Shadow Brokers. Innovative cyber

threats will continue to be an issue, causing us to be even more diligent in our efforts.

So here’s the question: Which is less vulnerable - a private, premise-based SCADA system with secluded

computers, private networks, and open protocols like those discussed above or a Cloud-based computer

system with connectivity to numerous remote assets over public and private networks?

In each example, the goal of this

recursive process is synonymous:

continual improvement. Often, an

attitude of apathy develops when

continual improvement stalls.

Therefore, we, as an industry, must

seek continual improvement.

Hudson 8




While there is much discussion and disagreement over the answer, the common ground is found in that

the critical infrastructure is only as reliable and secure as the technologies deployed, maintained, and

monitored. There is a traditional view that a system is either easy-to-use to secure, but not both. The

emerging third view of security is the convergence of OT and IT (Operational Technology and Information

Technology). Once these often segregated departments come together with a common purpose, the

SCADA and IIoT systems will be able to achieve and maintain a more secure data communications network

of secure assets and secure communications.

There are no easy answers to these cyber-security questions. Money won’t solve the problem. Systems

won’t alleviate the concerns. Technology won’t keep us from having difficulties. But the recursive process

carried out by people who care about the results and are passionate about making improvements will

continue to drive us forward in technologies, applications, and best practices. Everyone benefits from

working together.

Conclusion

There is no argument that over the last 30 years, SCADA has significantly changed every aspect of

automation, instrumentation, and control. Will the Industrial Internet of Things significantly change every

aspect of SCADA? Maybe not every aspect but certainly enough to be significant.

Many say that the IIoT is just an extension, progression, or evolution of SCADA and that its success is

dependent upon the technological advancements of the devices, sub-systems, and communications within

these systems. Clearly, the consumers of these systems desire more data in which to analyze and turn the

data into information. The question is how to make it happen.

Improvements to these systems should be made when resources are available. Optimization of these

systems should be pursued when resources are limited. Data analysis techniques should be developed,

tested, and proven. Information should be shared when and where appropriate. And we must all strive “to

reliably and efficiently provide safe drinking water to the public and remove, clean, and restore the waste

water through environmentally responsible methods.”

Hudson 9




List of Acronyms

SCADA – Supervisory Control and Data Acquisition

IoT – Internet of Things

IIoT – Industrial Internet of Things

A&C – Automation & Controls

I&C – Instrumentation & Controls

OT – Operational Technology

IT – Information Technology

TCP/IP – Transmission Control Protocol / Internet Protocol

CPU – Central Processing Unit

PLC – Programmable Logic Controller

DNP – Distributed Network Protocol

HMI – Human Machine Interface

HTTP – HyperText Transfer Protocol

JSON – JavaScript Object Notation

XML – Extensible Markup Language

REST – Representative State Transfer

OPC-UA – Object Linking and Embedding for Process Control - Unified Architecture

MQTT – Message Queuing Telemetry Transport

ABOUT THE AUTHOR

Alan Hudson is US Sales Manager for Trihedral Engineering, manufacturer of VTScada. Alan holds degrees

in Mathematics from Samford University and Electrical Engineering from Auburn University and has been

in the water wastewater segment for 27 years with experience in engineering, consultative design,

programming, and system integration. Contact: [email protected]

mailto:[email protected]

industrial and automation communication protocols in … … · communication protocols in the age...

Documents