Remote - Winter 2013 - (Page 6)

Feature Article Message Oriented Middleware - The Future of SCADA Arlen Nipper, President & CTO Cirrus Link Solutions This article explores how the MQTT protocol combined with Message Oriented Middleware (MOM) brokers can improve current SCADA infrastructures by drastically reducing the latency of critical alarm and event notification while increasing access to data currently left stranded in intelligent field devices. MQTT is the acronym for a messaging transport called MQ Telemetry Transport. If you Google MQTT today you will see hundreds of links showing how MQTT is becoming the next big thing in the world of M2M and the newer notion of M2M called the Internet of Things (IoT). You can see that Facebook uses MQTT for the mobile Facebook Messenger application. You will see numerous MQTT client and broker implementations in just about every programming language you can imagine (and some you may have never heard of) running on every popular Operating System. But what you won't see unless you really search for it, is that MQTT was originally designed for use in real time pipeline SCADA systems. The paradigm used to talk to most remote devices today, consists of a poll/response protocol and a central host computer pulling data into a single application. This can change to take advantage of today's technology and existing/emerging enterprise business requirements. * Poll/response protocols can be replaced with an event-driven, dataneutral data delivery mechanism. * Central computer polling applications can be replaced by MOM brokers. Poll/response protocols, no matter how sophisticated, cannot put enough data over the wire to accomplish what today's enterprise needs for data delivery. There will never be a conventional Poll/Response protocol developed that won't become a legacy problem the minute the documentation is done. This article explains why MQTT was invented to replace legacy poll/ response protocols in SCADA systems. Protocols: The Good, The Bad and the Ugly "Protocol development and implementation is a very expensive endeavor and requires a lifetime of maintenance to stay in step with technology." Arlen Nipper SCADA poll/response protocols have been in place since the late 1970's. The Modbus protocol was invented by Gould Modicon in 1979, and was a fantastic protocol for 1979, but not for 2014. Modbus is just one example of the plethora of poll/response protocols in use today. But the limitations of these protocols are resulting in stranding large amounts of useful data in the field. Why? Originally, the prevalent network topologies available were multi-drop circuit configurations such as leased phone lines and radio networks. Leased phone Figure 1 - Typical Multi-Drop SCADA Topology circuits were relatively inexpensive and radio frequencies were readily available. During the period between the early 1970's and the mid 1980's the majority of the infrastructure that exists today was deployed using these readily available and affordable technologies. Due to this topology, the data exchange was accomplished using poll/response protocols. Since the majority of these multi-drop topology networks could only support half-duplex traffic when more than two devices were on the network, poll/response protocols had to be implemented to avoid data collisions if more than one slave device tried to send data. Simple modulation techniques and low data rates precluded the use of any type of collision detection/avoidance schemes. 6 www.RemoteMagazine.com Since remote nodes on the network could only report when requested, round robin polling schemes were employed. These schemes limited the rate at which critical event data could be collected and processed. In this model, each end device must be polled in sequence with each of the response packets being fully decoded before the next device can be polled. In many cases the actual round robin poll time meant that critical data from any one site could only be examined at the poll frequency. The legacy of the multi-drop poll/response paradigm has created the following problems that must be addressed by anyone wishing to upgrade an existing network or deploy a new SCADA host application using existing poll/response based instrumentation: 1) 100 percent bandwidth consumption and system latency. 2) Impeded technology adoption and migration from legacy systems. 3) Single data consumer resulting in a "one to one" data ownership problem. 4) Stranded device intelligence. 100 Percent Bandwidth Consumption and System Latency The Poll/Response protocol paradigm presents several problems in modern network environments. Since data is not delivered until requested, the host computer must continually poll all end devices searching for any data that may have changed. In most applications this results in the same data values being returned hundreds or thousands of times without ever having changed. So the very nature of a typical poll/response system results in complete saturation of the channel bandwidth. Not only does this result in delays to critical data delivery, it also impacts network operation costs. Many modern networks used by SCADA/telemetry equipment are sensitive to the volume of data being transmitted. Figure 2 - Round Robin Polling VSAT and cellular technologies are particularly sensitive. Even in implementations where data costs are not tied to data volumes, the poll/response messages tie up bandwidth that could otherwise be utilized for data that has actually changed or for additional valuable information from the equipment on site. Poll/response SCADA system implementations can become exceedingly slow when deployed on VSAT systems. Modern day VSAT systems using TCP/IP may even exacerbate the problem. Poll/response systems must implement a sequential, "round-robin" polling algorithm. If we add VSAT propagation delay to the mix, we have added at least one (1) second to the delay of each and every transaction with the remote devices, plus the TCP/ IP socket setup/teardown time. http://www.RemoteMagazine.com

Table of Contents for the Digital Edition of Remote - Winter 2013

Editor’s Choice
Message Oriented Middleware - The Future of SCADA
Enhanced SCADA Access and Big Data Lead to New Analytics & Optimization Capabilities
Approaches to Powering Telecom Sites
Satellite Communications for Water Metering and Other Water Applications
Remote Magazine Launches Internet of Things North America
Geospatially Integrated Surveillance Systems
Tier 1 Operator Case Study: Intelligent Site Management
SCADA - The Brain of the Smart Grid
SCADA
Networking
Security
Onsite Power
Industry News

Remote - Winter 2013