Modbus WINS in Water and Waste Water

Modbus TCP (and RS485 Modbus RTU) continue to be the go to protocols for simple devices that need to move a few points of data. It’s simplicity, straightforward address space, and wide adoption make it a no brainer for a lot of people building devices. Additionally, there are so many Modbus applications and trained professionals who understand and have used Modbus in the past that it has just become the default option.

You can find Modbus devices in many industries. It’s in pharmaceutical applications, packaging applications and more, but it’s strongest in water and waste water treatment plants. Devices like pumps, level measurement, temperature sensors, valves, and other devices in the water industries use both Modbus and Modbus TCP. There are any number of reasons for its popularity including:

• Water and waste water plants have been around for a long time. These were some of the first plants that required data from remote sensors. Twenty and thirty years ago, there was no other option except Modbus.
• Water and waste water plants are often part of public utilities. These plants are built from specs that aren’t often changed. If Modbus communications are part of the specification, the plants are built with that communication system even if something better is available.
• Devices in these plants are generally very simple with only a few points of data. That fits well with Modbus – a technology that can’t move more than a few hundred bytes of data in a single message.
• Since there are only a few bytes of data, the assignment of context to a data point (Register 40200 is the cooling tower temperature, for example) is tedious but not overwhelming.
• The data in these applications changes very slowly so response time is not an issue. Modbus devices are generally low resource devices without a lot of processor bandwidth for message processing.

Modbus is perfectly suited for the target devices in these applications, but where Modbus fails is on the other end of the architecture. Though any kind of host can generate Modbus TCP requests for data, these requests are generally part of some more proprietary or custom application. Communicating over Modbus communications is not often part of any database, MS Office product, or open architecture software. Even though Modbus communications are now part of many middleware products, once the Modbus data arrives, it must be decoded and converted into data formats more appropriate to higher end systems. Modbus data is normally just 16-bit unsigned integer data.

Some device manufacturers in these industries are now asking what their connectivity solutions should be in the future? Others have customers that are asking for more integrated solutions that can more easily move data from these kinds of devices into the Enterprise and the Cloud. There are many ways to do this. Here’s a few:

• HTTP or HTTPS – Use the simple Get and Put services of HTTP to deliver data to a host or receive commands from a host.
• Web Service Database interface – A device can use HTTP just as a browser does. It can open a client connection to a web server on a host system. The device can then write a web page request to the host, passing its data as parameters. On the client side, Instead of displaying a web page, the web services routines take the data and execute an SQL Insert command storing the data in a database.
• MQTT – A device can use MQTT to send data to a broker device that can receive data from the target device and make it available to any number of subscribers that are interested in that data.
• OPC UA – This option turns the Modbus device into an OPC UA Server that can just pass through the Modbus data, convert the Modbus data into Object data, or do both.

The next articles in this series will describe in detail how your Modbus data can be revised to have the higher level functionality of MQTT, HTTP, and OPC UA.