HPR4758: Programmable Logic Controls - Episode 6

This show has been flagged as Clean by the host. 01 Introduction This is the sixth episode in an 8 part series. 02 In the previous episode we looked at I/O modules, what they are, how they work, and the purpose that they serve in the system. We also discussed machine safety systems and also claims made by certain people about cyber security and industrial safety. In this episode we will look at PLC networking, together with a detailed look at one network protocol, Modbus. 03 Types of Networks PLC networks fall into three broad categories, based on the purpose of the network. These categories are • PLC to IO • PLC to PLC • and PLC to PC or Personal computer. There is a great deal of overlap between these, so don't expect them to fall into nice discrete pigeonholes. 04 A Multiplicity of Protocols Logically, you would think that the advantages of interoperability would be so great that there would be just a few networking protocols and everyone would use them. The reality is the opposite. There is such a multitude of protocols that I won't attempt to list them all. Industrial automation is a market that is firmly in the control of the vendors, not the customers, and the vendors value customer lock in over user benefits. 05 What I will focus on instead is the technological development over time so you can understand how we ended up where we are today. I will illustrate this with a few protocols from a few vendors before going into detail on one specific family of networks. 06 Basic Point to Point Serial The first and most basic networks were simple point to point serial links. You may argue that a point to point link is not a network, but in this case it is the start of networking with PLC, and one of the most important industrial network protocols today is a direct descendent of one of the early point to point protocols. 07 These point to point links initially addressed two main issues. One was that once computers were being used to run the software needed to program PLCs, some means of downloading the program to the PLC and to debug the PLC program was needed, and this took place over a point to point serial link. 08 The other was that there were various microprocessor driven instruments and devices where it was desirable to allow the PLC to communicate with them in order to obtain readings, adjust set points, and otherwise exchange data. A serial link was the obvious means of implementing this. The physical and electrical media were generally RS-232, RS-422, or serial current loop. 09 RS-232 RS-232 should be familiar to most listeners. The notable characteristic of RS-232 is that the data and control signals were referenced to ground, or "single ended" as this is also known. While this was simple, it placed limitations on length of cabling and it was somewhat problematic when the PLC and the other device were connected to different power sources and did not have a common ground. 10 RS-422 RS-422 differs from RS-232 in that the signals are differential rather than referenced to a common ground. Signal lines come as pairs, and it is the difference in voltage within the pair rather than compared to ground which defines the zeros and ones. This allows for higher data rates, up to 10 mbps at very short distances, and much longer cable runs, up to 1,200 metres, at the cost of lower data rates. 11 RS-422 also allowed for multiple receivers to be connected to the same wires, although only one driver was permitted. This allowed for multiple devices to "listen" on the same set of wires, although only one node could "talk". 12 Serial Current Loop or TTY Some PLCs, particularly Siemens, used a serial current loop instead of RS-232 or RS-422. This is known as a TTY interface, as it originated with teletypes. You may be familiar with the term TTY being used to describe terminal windows in unix like operating systems. 13 This is due to early computers adopting off the shelf teletype equipment to provide operator terminals. This used differences in current rather than differences in voltage to carry signals. When 20 mA is flowing, this indicates a "1". When 0 mA is flowing, this indicates a "0". Serial current loops can operate reliably over greater distances than RS-232, up to a kilometre at lower data rates. 14 Typical Protocols An electrical standard such as RS-232 allows for transmitting zeros and ones through a wire. It does not however define what those zeros and ones mean. That requires a data protocol. 15 Each manufacturer tended to come up with their own protocol. Modicon developed Modbus. Allen Bradley came up with DF1. Siemens created 3964R and RK512 Other manufacturers generally each had their own. I will discuss Modbus in detail later, but won't otherwise go into detail on these protocols here. 16 Multi-drop Serial Point to point serial, even RS-422 which allowed for multiple receivers, worked, but it suffered from a number of limitations. The most obvious one is that if you wanted two way communication, you needed a separate cable between each point, and a dedicated communications port or a port multiplexer. As the system becomes larger and more complex, this becomes unwieldy. 17 RS-485 What would be desirable is a means of allowing multiple serial devices to share a serial communications link. The solution to this is RS-485. Like RS-422 this uses differential signalling. It also allows multiple receivers on the same wires. Unlike RS-422 however, RS-485 allows for multiple transmitters. Up to 32 nodes can be connected to the same RS-485 cable. This limit is determined by the electrical characteristics of the cable and transmitter and receiver chips. 18 New Protocols PLC manufacturers adapted their existing protocols or came up with new ones. Allen Bradley adapted their serial DF1 protocol into Data Highway, Data Highway Plus, and Data Highway 485. Siemens came up with L1, Profibus and Profibus-DP. 19 Master Slave Versus Multi-Master Many of these networks were strictly master-slave systems. One node would be designated the network master, and it would poll each of the other nodes, the slaves. This sort of configuration suited a lot of applications where what was generally wanted was to allow a PLC to act as the network master and poll various other devices located some distance away. 20 One early application of this was to allow IO racks to be located some distance from the PLC CPU. This in turn allowed for the IO racks on very large machines to be closer to the devices they are connected to, such as switches or valves or relays, and so reducing the amount of cabling and wiring required. 21 Further development of this produced IO in the form of blocks that could be mounted directly on the machine without requiring a separate electrical enclosure. These could even be directly integrated into valve banks, which are collections of valves sharing a common plenum. 22 However, this had limitations when the goal was to network multiple PLCs together so they can coordinate with each other. With a strictly master slave system, one of the PLCs would have to be designated as the master and the PLC program would have to handle forwarding of messages between the other PLCs. 23 The solution to this was a multi-master network. The physical wiring would still typically be RS-485 or some proprietary variation on it. The protocol however would have to be adapted to allow for multiple masters. This was usually some sort of token passing protocol, where the "token", which was a piece of data designating the master, would be passed from node to node so that each node had its turn to temporarily be master. 24 Device Level Networks The reduction in cables and wires and the resulting cost savings in terms of installation labour meant that there was additional incentive to extend networks down to individual devices such as switches or single valves. I won't go into a lot of details on these, but instead just mention some common examples. There were some purely proprietary systems such as Siemens ASI. 25 There were also a number of systems based on CAN, which stands for Controller Area Network. CAN comes from the auto industry, and was meant for networking various parts of your car together. You probably have a CAN network in your car whether you realize it or not. 26 The industrial automation industry took the off the shelf CAN standards and chip sets and added their own protocols on top to create device level networks. Some typical examples of his are Canbus and Allen Bradley Devicenet. 27 The Rise of Ethernet Networking appeared on the factory floor well before it was common in the factory's offices. This combined with the highly fragmented nature of the industrial automation industry meant that it was difficult to gain economies of scale in manufacturing the networking hardware. It also meant that each company had to dedicate R&D efforts developing things which duplicated functionality already existing elsewhere. 28 Meanwhile networking technology was spreading in office environments, and gradually consolidating around Ethernet and TCP/IP. The huge scale of this market and the well developed standards meant that costs fell significantly due to economies of scale and competition between suppliers. 29 Seeing this development in the IT industry, automation companies decided to adopt IT networking standards wholesale, at least so far as the physical wiring and the low level protocols were concerned. They could still use their application level protocols, maintaining vendor lock in. 30 Some typical examples of these protocols are Siemens Profinet, Allen Bradley Ethernet/IP, and Modbus/TCP, all of which were adaptations of previously existing protocols to operate on Ethernet. 31 Summary So Far What we have covered so far in this episode is the origins of networking in industrial automation beginning with point to point serial links, to multidrop serial master slave networks, to multidrop serial multi-master networks, to the adoption of Ethernet. You should have at this point some idea of the context within which networking operates in industry and what it is used for. Next we will discuss one specific protocol in some detail, Modbus. 32 Modbus Background Modbus was created by Modicon in 1979. If you recall from previous episodes, Modicon, now part of Schneider Electric, were one of the first companies to develop a PLC. 33 Modicon published the specification to allow third parties to implement it, making it one of the few truly open royalty free industrial automation standards. I say "truly open", because the automation industry loves to put the word "open" in their brand names, although to them "open" means applying for a license, being accepted by them, paying royalties or membership fees, and paying for certification as an accepted vendor. 34 Anyone however can download the Modbus specification, implement it, and do whatever they wish with it. There are multiple free software implementations of Modbus libraries. 35 Versions or Variants of Modbus There are several variants of Modbus, differentiated by the physical media or application. These are • Modbus RTU • Modbus ASCII • Modbus Plus • and Modbus TCP 36 Modbus RTU This is the original version of Modbus, and is a point to point serial communications protocol. The RTU part of the name stands for "Remote Terminal Unit", which is the name for an industrial device which has some sort of serial or network interface and acts as an interface to field instrumentation. A typical example may be say a flow meter on a pipeline. This protocol was very widely implemented by third parties. 37 The serial data format is • 8 bit binary • 1 start bit • 8 data bits, least significant bit first • 1 parity bit • 1 stop bit A 16 bit cyclic redundancy check field is included in the message. 38 Modbus ASCII Modbus RTU is designed as a serial protocol and has very precise per bit timing specifications. This meant however that it would not work reliably over radio links servicing things such as water systems, oil fields, and other distributed applications. Furthermore, Modbus RTU is a binary protocol, and this meant that some values may be interpreted as control codes by the transmitting or receiving hardware. 39 The solution to this was Modbus ASCII. This sent data in ASCII format, with each byte converted to two bytes of hexadecimal. The serial timing restrictions were relaxed to effectively whatever the hardware would tolerate. 40 The serial format is • Hexadecimal, ASCII characters 0-9 and A-F • 1 start bit • 7 data bits, least significant bit sent first • 1 parity bit • 1 stop bit 41 A colon is used to signal the start of a new message, and a carriage return and line feed pair marked the end of a message. A longitudinal redundancy check was included as ASCII encoded data and placed just before the terminator characters. 42 Since Modbus ASCII messages took twice the number of bytes as Modbus RTU, it could only transmit data at half the speed. This meant that the use of Modbus ASCII was limited to just the applications it was meant for, which was radio communication links. 43 Modbus Plus Modbus Plus is Modbus adapted to work on an RS-485 serial multidrop network. However, it was never part of the Modbus specification, and was proprietary to Modicon. I won't bother describing any more of it. 44 Modbus TCP Modbus TCP is Modbus RTU slightly modified to be tunnelled over TCP/IP, particularly on Ethernet. This was very widely adopted, and even some of the big vendors who had their own protocols would offer it as an alternative to allow communication with devices they would otherwise not be able to talk to. 45 Modbus TCP uses port 502. This is an officially assigned port, and if you look up the official list of TCP ports you will find Modbus listed there as 502, just like HTTP is port 80 and SMTP email is port 25. 46 The standards committee for Modbus made the very conscious decision to adopt IT industry standards and conventions wholesale as much as possible and just reference those instead of maintaining a unique automation industry set of standards and conventions. This was for several very practical reasons. 47 One was that there were very few people involved in standards work and they were looking for ways to reduce the amount of work they needed to do. The other was that people working in industry found the duplication of vocabulary very confusing and difficult to keep straight as to what in IT terms translated to what in industrial automation speak. 48 One of the consequences of this is that the master - slave serial communications terms were dropped in favour of the IT networking terms client - server. As a result of this I will use the Modbus TCP terms in the rest of this episode, as this is the form of Modbus you are most likely to encounter these days. 49 Modbus UDP This was an unofficial version of Modbus TCP which simply sent the data over UDP rather than TCP. There was no change to the actual Modbus data format sent. It was done mainly to show that it could be done. The supposed advantage was the lower overhead and latency of UDP compared to TCP, but it wasn't enough of an advantage for this to spark much interest. 50 Proprietary Modbus Extensions Several companies created their own extensions to Modbus, particularly to extend Modbus RTU. These were only ever used in some niche applications. One of the most common was Enron Modbus, which was created by the Enron company in the US. This added a 32 bit data extension to the protocol. 51 Modbus Data Model The Modbus data model is centred around a PLC style data table. This is an array of memory and a set of commands to read from and write to that memory. 52 There are four types of memory • Discrete Inputs • Coils • Input Registers • Holding Registers 53 There can be up to 65,536 memory addresses of each of the four types. Each memory type can have anywhere from zero to the maximum number of elements, it is up to the implementation as to how many addresses to have. Memory addresses start at 1, so that the number "1" refers to the first address. Addresses as actually sent over the wire however start at "0". 54 Discrete inputs and Input registers are read only memory, while coils and holding registers are read - write memory. Discrete inputs and coils are single bits. That is, each address represents one bit of memory. 55 Input and holding registers are 16 bit words. When transmitted over the network, words are "big endian". That means that the upper byte of a word is sent first and the lower byte is sent second. 56 It is permitted to overlay different types of memory. For example, the coils memory could be overlaid on the holding register memory, such that for example the first 16 coils are also the first holding register, etc. 57 Modbus Functions Modbus TCP is a client server protocol. The client sends a command requesting to read or write memory, and the server responds with either an acknowledgement or with another message containing the requested data or an error code. Each command is known as a "function". Each function is referenced to by a number. 58 I won't list all of the functions, just the most commonly used ones. A Modbus instance does not need to implement all possible functions, only the ones that it uses. 59 • Function 1 is "read coils". • 2 is read discrete inputs. • 3 is read holding registers. • 4 is read input registers. • 5 is write single coil. • 6 is write single register. • 15 is write multiple coils. • 16 is write multiple registers. 60 The limits on the quantity of data elements which can be used in a single transaction for each command are as follows . • Function 1 is 1 to 2000 • 2 - 1 to 2000 • 3 - 1 to 125 • 4 - 1 to 125 • 5 - NA • 6 - NA • 15 - 1 to 1968 • 16 - 1 to 123 61 Modbus Message Format The full Modbus message is called the ADU, or Application Data Unit. Within the ADU is the Protocol Data Unit, or PDU. The PDU contains the Modbus command and the associated data. The ADU contains additional information, and can vary depending on the type of Modbus. I will limit myself to talking about Modbus TCP here. 62 MBAP Header On Modbus TCP, the PDU is preceded by the MBAP Header, which is the Modbus Application Protocol Header. It has the following format. • The first 2 bytes are the Transaction Identifier. • The second 2 bytes are the Protocol Identifier. • The third 2 bytes are the Length. • The next 1 byte is the Unit Identifier. 63 The Transaction Identifier is simply an integer that will be copied from the client request to the server response. The client can examine this to match up responses with requests. This is really only of use if there is a chance that responses may get out of order. 64 The Protocol Identifier is always zero and indicates the protocol is Modbus. The length is the number of following bytes, including the unit identifier and data fields. 65 The Unit Identifier is used for allowing messages to pass between Modbus TCP and serial Modbus, such as Modbus RTU. For example, a gateway on the Modbus TCP network may have multiple Modbus RTU devices connected to it. The Unit Identifier in this case would correspond to the serial line address or serial port number of the Modbus RTU unit the request is directed to. 66 The length field is set by the client in the case of a request, or the server in the case of a response. All of the other fields are simply copied from the request to the response by the server. 67 Example - Function 1 Here is an example of a Modbus PDU message for function 1, read coils. 68 The request has the following format. • The first byte is the function code, in this case it is "1". • The next two bytes contain the starting address in the range of 0 to 65535. • The next two bytes contain the quantity of coils, which may be in the range of 1 to 2000. 69 The response is in the following format. • The first byte is the function code, in this case it is "1". • The second byte is the number of bytes