SCADA
Modbus
SCADA
Introduction to SCADAThe term SCADA is an acronym for Supervisory Control And Data Acquisition. This is a system for controlling and monitoring the various processes in the production of oil and gas in the North Sea. This is a process that started in the 1960’s and over time has become essential in the production of oil and gas.
As it is obvious due to the complexity of the processes in say a offshore production platform it is essential that a number of central control points are made available, this is exactly where SCADS comes in. Originally this was achieved by physically running wires from the control unit to individual soloinedes. Quite apart from the physical problems of running hundreds if not thousands of different wires round the platform the trouble shooting required if one soloined broke down was massive. This problem was alleviated by the introduction of PLU’ s.
Programable logic controllersPLU’ s are programmable logic controllers. These are intelligent devices that can be connected by a serial link. The advantages of these controllers are that several processes can be controlled by each PLU, thus cutting down the number of cables required. It also has the advantages that as these controllers are programmable, changes to the system can easily be made and additionally it is easy to record the data for subsequent analysis.
With the introduction of unmanned production sites the use of SCADA became of prime importance using these systems. As it is possible to control it is possible to remotely control these unmanned platforms using a viarity of microwave, radio and fiber optic links. Quite apart from the savings of manpower involved it also allowed smaller fields to be exploited, and in some cases sub sea production.
SCADA and safetyOne very important area that SCADA is highly involved with is that of safety. Due to the highly programmable nature of PLU’ s it is possible to set defined parameters directly into the PLU’s, with the result that if they are exceeded the appropriate actions can be taken immediately and the problem resolved. A couple of links to examples are shown below additionally with the facility to record all the data it is possible to then manually go over the data at a later date and determine the original reasons for the problem and thus avoid repitrtition of the problem.
As can be imagined
with the development of more and more powerful computer systems the way that
SCADA has been implemented has changed dramatically over the past few years.
One of the most obvious is the size of the control stations as can be seen from
the picture they used to be extremely large and bulky units, it is hard to imagine
from that picture that nowadays all this technology can now be fitted into a
laptop. Additionally the protocols have over a period of time become more standard.
Thus allowing more interconnection between different systems a good example
of which can be seen below.
SCADA and inbconection
One
example in the use of SCADA that is very rarely thought of is that of interconnecting
different platforms that are drilling into the same resoware. As can be imagined
in order to extract the most out of a field it is important to tie in the efforts
of several different production platforms. As can be seen from the diagram,
different rigs tend to extract at different levels of the field and take different
types of products or even inject into the field. If these processes are not
properly intrataged together the life of a field can be considerably shortened.
This is a classic example of where SCADA comes in.
Altogether the importance of systems like SCADA not just in the North Sea but in just about every manufacturing and production area can not be understated as it is obvious that the north sea would not be the thriving production area without it.
Modbus
Introduction to Modbus ModBus was originally developed by MODICON,
now a part of Schneider Automation. The protocol has been widely utilized, with
some slight adaptations by other companies. There is a significant installed
base in the USA as well as Europe, and many DCS (Distributed Control Systems)
companies use ModBus as a communication protocol to their systems. The ModBus
protocol provides the internal standard that the MODICON controllers use for
parsing messages. During communications on a ModBus network, the protocol determines
how each controller will know its device address, recognize a message addressed
to it, determine the kind of action to be taken, and extract any data or other
information contained in the message. If a reply is required, the controller
will construct the reply message and send it using ModBus protocol.
The Modbus Protocol
Modicon originally developed the Modbus protocol in 1978 to exchange information between products on the factory floor. This protocol became a de facto standard for exchanging data and communication information between PLC systems.
A relatively simple protocol, Modbus has been implemented by many manufacturers of instrumentation and control equipment to offer system interoperability. Equipment supporting Modbus protocol variants include PLC’s, RTU’s, VFD’s (Variable Frequency Drives), SCADA Hosts, MMI’s, Flow Computers, Power Meters, Power Line Reclosers, Valve Actuators, Intelligent Instruments, and Protocol Converters.
The MODBUS standard defines an application layer messaging protocol, positioned at level 7 of the OSI model that provides "client/server" communications between devices connected on different types of buses or networks. It standardizes also a specific protocol on serial line to exchange MODBUS request between a master and one or several slaves.
Modicon programmable controllers can communicate with each other and with other devices over a variety of networks. Supported networks include the Modicon Modbus and Modbus Plus industrial networks, and standard networks such as MAP and Ethernet. Networks are accessed by built-in ports in the controllers or by network adapters, option modules, and gateways that are available from Modicon. For original equipment manufacturers, Modicon ModConnect partner programs are available for closely integrating networks like Modbus Plus into proprietary product designs.
Supported by a wide range of manufacturers, Modbus protocol has been the protocol of choice when a single protocol is utilized in a SCADA communications network. A majority of industrial equipment either supports Modbus directly as a native protocol or via the manufacturers or a third party communication cards.
More recently Modbus TCP developed by Modicon has been adopted as industrial Ethernet protocol transporting Modbus protocol over LAN networks.
Enhancements to Modbus include Modbus Plus and Modbus/TCP protocols, both of which allow Modbus information to be encapsulated in a network structure to support peer-to-peer communications. Modbus Plus communicates via a single twisted pair of wires and uses a token passing sequence for peer communication sequences. Modbus/TCP is an open standard designed to facilitate Modbus message transfer using TCP/IP protocol and standard Ethernet networks.
Serial ModbusMODBUS Serial Line protocol is a Master-Slave protocol. This protocol takes place at level 2 of the OSI model.
Standard Modbus ports on Modicon controllers use an RS–232C compatible serial interface that defines connector pinouts, cabling, signal levels, transmission baud rates, and parity checking. Controllers can be networked directly or via modems.
The following figure gives a general representation of MODBUS serial communication stack compared to the 7 layers of the OSI model.
In addition to their standard Modbus capabilities, some Modicon controller models can communicate over Modbus Plus using built–in ports or network adapters, and over MAP, using network adapters. On these networks, the controllers communicate using a peer–to–peer technique, in which any controller can initiate transactions with the other controllers. Thus a controller may operate either as a slave or as a master in separate transactions.
Controllers can be setup to communicate on standard Modbus networks using either of two transmission modes: ASCII or RTU. Users select the desired mode, along with the serial port communication parameters (baud rate, parity mode, etc), during configuration of each controller. The mode and serial parameters must be the same for all devices on a Modbus network.
The selection of ASCII or RTU mode pertains only to standard Modbus networks. It defines the bit contents of message fields transmitted serially on those networks. It determines how information will be packed into the message fields and decoded.
On other networks like MAP and Modbus Plus,
Modbus messages are placed into frames that are not related to serial tranasmission.
For example, a request to read holding registers can be handled between two
controllers on Modbus Plus without regard to the current setup of either controller’s
serial Modbus port.
TCP/IP ModbusThis section goes on to describe Modbus TCP/IP and its basic operation. In the last few years it has become accepted in industry that the same components and technological principles that provide worldwide connectivity to office workstations and personal computers can also be used for distributed control and, to an extent, automation of factory line machines and PLC’s (programmable logic controllers).
Modbus/TCP is a communications protocol for automation equipment. It is a derivative of the almost universal MODBUS protocol primarily used to build point-to-point data acquisition and supervision arrangements between control devices and sensor/actuators over RS232 serial ports.
In the Modbus/TCP variant, instead of having a dedicated cable between the client (master) and server (slave), an Internet standard TCP ‘connection’ is used instead. A single device may have many such connections active at the same instant, some acting in the role of client, some acting in role of server. These connections may be established and broken on a repetitive and continual basis, or they may be left active for long periods. However they are always broken down and re-established as a method of investigating and recovering from disruptions such as those caused by power failure or loss of communication with other components.
The standard TCP frame is changed to incorporate a Modbus frame that gives information such as the address of the target device, a function code and whatever data is being transmitted. This is a connection-oriented transaction, which means every query expects a response. A diagram to illustrate this:
This query/response technique fits well with the master/slave nature of Modbus, adding to the deterministic advantage that Switched Ethernet offers industrial users. The use of OPEN Modbus within the TCP frame provides a totally scaleable solution from ten nodes to ten thousand nodes without the risk of compromise that other multicast techniques would give.
The Modbus/TCP addressing model is almost identical to that used for other Internet services such as e-mail or file transfers. A destination is selected by nominating its IP address, either in dotted decimal form (e.g. 10.0.0.1) or as a host name using the Domain Name Service (DNS) (e.g. sensor1.lancontrols.com). The computers receiving the ‘call’ differentiate a request for Modbus service from other services by the TCP port number used as part of the target address. As with Web email servers, the target device cannot tell whether it has been selected by numeric address or by DNS lookup. Both styles of selection will appear to be numeric. This has significant implications on the stability of addresses needed for automation equipment, and is the primary reason why Dynamic Host Configuration Protocol (DHCP) is inappropriate for automation use as static addressing allows for easier trace-ability of devices.
Performance of a modbus TCP/IP system is dependant on roughly two things, namely the hardware being used and the network it is being run on. If the modbus system is being run over the Internet then it is difficult to get better than typical Internet response times. While this may be suitable for some tasks, say maintenance and de-bugging, many companies do not use this technique as this offers little range in functionality due to the slower response times. Most companies run their modbus system over their own dedicated networks. These networks are often high-performance Intranets with high-speed Ethernet switches to guarantee performance.
One of the factors hindering Ethernet’s adoption as an automation network was its apparent inability to guarantee response times. The ‘exponential back off’ built into the Ethernet media access control mechanism leads to rapidly increasing retry delays in the event of simultaneous transmission by 2 stations. These delays can occasionally reach hundreds of milliseconds on general networks unless restrictions were imposed. Switches are sometimes deployed in specific points in the network to split up bulk data transport devices and important fast response devices and traffic. This allows fewer collisions and decreases the effect of workstations exponentially backing off thereby improving response times.
Some companies now are working towards designing a high-performance, reliable wireless modbus server to allow even more remote locations to be accessible. A company called elite has developed a wireless system with a 300m nominal range which can control up to 256 remote relays and has built in features to ensure its continual operation such as UPS (uninterruptible power supply and ESD (electrostatic discharge) protection. Many regard this as a potentially useful tool while others are not sure in its reliability and its performance under large data transfers.
Applications of TCP/IP ModbusThis section discusses the remote applications for Modbus TCP/IP. Modbus TCP/IP was developed mainly from another protocol, namely Modbus RTU (remote terminal unit). This was used until companies started to converge towards the use of Ethernets and the birth of the Internet. The Modbus/TCP protocol is basically the command/response Modbus RTU protocol wrapped up in a TCP packet, meaning limitations of the protocol in advanced applications still exist. The Modbus/TCP protocol is an application-layer protocol, and as such, resides on top of the TCP/IP and Ethernet layers.
The protocol is most commonly used by large Multi-national corporations who work in the primary sector of industry i.e. oil companies, gas power stations e.t.c. It is often used in place of mechanical relays to perform actions on remote devices. It can also be used for monitoring purposes. A typical application would be Tank level measurement from a reservoir or water tower back to a pump or lift station for the purpose of pump control and would look something like this:
In the above diagram the level transmitter (LT) is used to monitor the level of the tank and it is connected to a PLC, which we will name PLC1, which is subsequently connected to manual controls for the separate pumps. PLC1 is then connected through phone lines or more typically the companies own dedicated lines to a second PLC, which is used to control the pumps. Modbus TCP/IP would be used between the PLCs to allow commands at one end to communicate the appropriate response to the relevant part.
The modbus system would also allow users to perform maintenance and repair on remote devices from the office using a PC and browser thereby reducing support costs and improving customer service. Furthermore the ability to log onto a plant's control system from home allows the maintenance engineer to maximize his plant's uptime and reduce the number of times that he is called out from home. In addition, managing geographically distributed systems becomes easy using commercially available internet/intranet technologies.
Another aspect of Modbus TCP/IP is the fact
that some systems allow for a computer generated log to be viewed showing all
past actions. This would allow for operators and instrumentation engineers to
easily trace the source of a problem and remedy it or put in place to controls
to prevent it happening again. This trace-ability would not be easily used in
a system of mechanical relays. Furthermore, problems can often be scouted and
action taken before they become effective and have a negative effect on the
businesses operation.
Some of the information on this site is © http://www.modbus.org |
| Another handy reference is The Handbook of SCADA ©R.I Williams published by Elsevier Advanced Technology |