Everyone knows that the "IP" in TCP/IP is "Internet Protocol, but what is the "TCP"?

The answer is "Transmission Control Protocol". It defines how the message is sent. TCP is very neat stuff. It guarantees message delivery. It takes large messages that have to be broken up for transmission and reassembles the puzzle at the receiving end, even if the packets arrive out of order. It is smart enough to reduce traffic if the network is getting busy (delay transmissions). It handles the entire delivery process in a reliable manner. Unfortunately, its priority is simplicity for the user and reliability, not timeliness of the delivery. TCP/IP is many great things but it was not specifically designed for real-time control systems.

Then why do we use TCP for industrial applications?

Well, for many reasons. Not all systems require millisecond response – for most applications it is far faster than the so-called "industrial" solutions it competes with. Let us not also forget that TCP is the protocol of the Internet. Its value in that regard is hard to ignore. Also, TCP is universal and highly accepted. It has brought the dream of interoperability of industrial systems within our grasp. The question is, therefore, how do you benefit from using the protocol of the Internet and still get real-time response?

The answer is UDP (User Datagram Protocol) which is another method of exchanging messages between computers on an Ethernet network. UDP messages each have an IP address and travel the same network as TCP messages. The difference is that when you use UDP, you have more direct control of when and how to send each message. This makes UDP the best choice for many industrial situations. Since I/O data messages are typically short, the TCP capabilities of reassembling large messages is not required and the extra overhead of doing so is not desired. Even if there is a large amount of data to move, the typical I/O driver can break it up into manageable pieces, as it does for every other communications media.

The burden of tracking deliveries, acknowledging messages and making retries when necessary falls upon the I/O driver developer, but the truth is that the industry has been dealing with these issues forever. Modbus messages, for example, require an acknowledgement. The master station always knows the message was delivered. For over twenty years, SIXNET systems have been sending Modbus messages over radios and other inherently unreliable media. Dealing with message delivery is nothing new to us. SIXNET’s secret is that we use this highly developed expertise to insure reliability and do our own scheduling of UDP messages.

UDP packets do not carry the overhead of the TCP stack (memory usage and firmware complexity). They do not require explicit sessions to be established between the sending and receiving station, and they do not have the long timeouts associated with TCP sessions and delivery mechanisms. SIXNET has been using UDP messaging in Ethernet systems since 1995. There are thousands of installations of SIXNET Ethernet systems running with perfect real-time results.

Why don’t all industrial I/O systems use UDP?

Again, many reasons. The Modbus Open specification specifically calls for TCP/IP. Also, many driver developers started with their serial Modbus drivers and just opened a TCP socket in their Windows (or other software). This was the expedient thing to do. Then, there is the marketing factor – the world asked for TCP so that’s what they got.

Do I need UDP or TCP for my networked devices?

At SIXNET we believe in open choices. Therefore, all SIXNET Industrial Ethernet products automatically support both TCP and UDP messaging. If you use Windows software that utilizes the full TCP overhead, SIXNET devices will respond accordingly. However, if you use certain HMI or SCADA software, or you move I/O using the peer move capabilities of SIXNET Controllers and RTUs, you will have the UDP real-time advantage working for you. Many partnering software products also support the UDP advantage. For "inside information" please contact SIXNET.