Why Modbus TCP?

RTA recently started working with a client on a development project where we’ll be embedding multiple Ethernet application layer protocols into a new device they plan to release early next year. It’s an interesting project. They have a broad product line and customers will benefit from this device. All good.

Except this week they asked me, “Why Modbus TCP?” I was a little taken aback by the question. My initial reaction was, “Well, why not?” However on further consideration, I decided that I could be a little more thoughtful about it.

When dealing with a question from someone that jars assumptions you have about yourself or the world, it’s always best to stop and ask if maybe your thoughts, opinions and assumptions are now out of date. After all, the world changes fast and maybe what I thought yesterday, last month or last year isn’t valid anymore. So I thought about it long and hard.

I started with the deficiencies of Modbus TCP. That took a while. It has no object structure, just a register and coil address space. There are only two data types: Boolean and 16-bit unsigned integer. There is no open standard mechanism to extend the limited set of standard function calls that it supports. Modbus RTU and Modbus TCP packets don’t carry a lot of data; approximately 112 registers is all you get. It’s slow and awkward. As a comparison, if it were to become human, we would institutionalize it for its own protection. It’s that deficient.

Now the proponents of Modbus would argue that it’s easy to implement and doesn’t consume any resources. There’s little time, money or resources involved. That’s true, but in the same way that it’s easier to learn to ride a bicycle than drive a car. Most of us can competently learn to ride a bike in 15 to 20 minutes and go wherever our little pedaling feet can take us. A bike also consumes little time, money or resources – but where can it really take us? I find the resources question a really lame one in this day and age. Processors now come with so much memory, bandwidth, features, options and speed that they make the Apollo computer platform appear to have been architected by Fred Flintstone.

As a matter of fact, since taking up the question of “why Modbus TCP,” I couldn’t think of any reasons to use Modbus TCP. It offers no functionality that is not available over EtherNet/IP™, Profinet IO, OPC UA™ or any other application layer protocol. It doesn’t benefit the user. There is no metadata (available in OPC UA™) describing what data is or how it is named (EDS files in EtherNet/IP™).

In fact, I couldn’t think of a reason to implement except everybody supports it, we always implement Modbus TCP (the “we’ve always done it that way” argument) and the contention my mother would say in exasperation when arguing with me about my nightly curfew: “just because.”

Modbus TCP is the common denominator of Ethernet protocols. Look at any HMI and you’ll find Modbus RTU and/or Modbus TCP. Look at any controller, SCADA system, drive controller or any other product in the factory automation market and it’s likely that Modbus TCP will show up as a supported protocol.

It’s the way we know we can talk to one another. It would be like a German travelling to Mexico, China or Russia, the common language that can get them by is English. When you put an automation device on the factory floor, the common means of communication is Modbus. That’s just the way it is.

Will it be that way forever? I don’t know. I presume it will be. Non-standards that become standards by popular consensus are like that. They just exist because they exist. The Kardashian family is popular because the Kardashians are popular. There’s no rhyme or reason behind it (or them). Like Modbus, it just is.

So, after due consideration, my answer to the customer who asked, “Why Modbus TCP?” is “because.” Just because. Just do it and in the end you’ll be glad you did.