What is the relevance of MQTT for telecontrol and SCADA? Meeting with experts.


MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe network protocol using low bandwidth and with low energy consumption. Frequently associated with IoT, it offers many advantages for the transmission, centralization and distribution of real-time information locally or between remote sites.

With the kind permission of Atys Concept, longtime PcVue partner and SCADA specialist, we offer here a translation of the article entitled "What is the interest of MQTT for remote management?" that appeared on the Atys Concept blog on May 25, 2021 (source at the bottom of the article).


Meeting with experts

VERDONE, a Toulouse-based (France) company specialized in the implementation of automation and regulation solutions, has carried out several PcVue projects using MQTT protocol for remote monitoring of distant sites via 3G connections. Alexia Waroude and David Caillier, respectively Automatician and Director of Operations, were kind enough to answer Atys Concept questions in order to share their experience with this protocol.


What are the advantages and qualities of MQTT compared to other protocols?

There are many advantages. First of all, it is a simple protocol to grasp, it is easy to find tutorials on internet and to quickly set up a platform for a reasonable budget. It is a really accessible protocol compared to LonWorks, KNX and BACnet protocols which require expertise and regular practice to keep a good command of it.

MQTT is very efficient for the start-up and maintenance of the supervision. By using a broker as a central point of communication, it is easy and fast to identify the origin of a communication problem: one only has to subscribe to the data in parallel of the subscribers and the publishers, to stop the communication on one side or the other of the broker in order to identify if the problem comes from the PLC/broker link or from the broker/supervision link.

The diagnostic tool called MQTT Explorer facilitates these operations to find communication problems. As a comparison, with Modbus IP, you have to use a sniffer like WireShark to see the frames that pass, which is not very user-friendly; as for BACnet, the search for issues can be even more time consuming.

MQTT is an event-driven protocol, so it is very light on bandwidth. On one of our projects, retrieving data from 40 water towers at a period of 5 minutes weighs only 600MB per month! The fact that it is purely event-driven has a second advantage: when a variable changes value, the data arrives immediately at the supervision. Thus, we carried out tests with a PLC communicating in MQTT and the broker connected to PcVue® through a 3G connection. The time lapse between the sending of a command from the supervision and the return of the calculated state in the PLC requires less than a second. 

MQTT is naturally designed to communicate from 1 to n (editor's note: understand from a Publisher to a Subscriber). If we take the example of telecontrol for water towers, when a temperature measurement of a probe or a meter index change, the value is sent simultaneously to the supervision and the energy management software. The PLC only has to make one request to refresh the variable.

The MQTT protocol integrates buffering in case of link failure. For a 3G remotely connected site, if the connection is interrupted, the PLC stores the events in its central unit. Once the connection is re-established, the broker publishes all the events and the supervision recovers all the historical data; there is no data loss. The same is true between the broker and the supervision.

What is particularly powerful, is that this operation is native to MQTT and does not require programming like it must be done with Modbus TCP/IP. Moreover, in the case of the PcVue® supervisor that we use, the payloads are coded in Json which allows to pass the timestamp in the payload structure. This means that all the data is time-stamped at the source. This is extremely useful for discrimination and in the case of buffering after a loss of connection, it allows to recover the correctly timestamped data in the supervision.

Finally, MQTT is royalty-free, reliable and secure, and is compatible with cybersecurity constraints: implementation of a login to access the broker and encrypted exchanges.

What are the applications where MQTT is particularly fitted and why?

This protocol arrived with connected objects. For isolated sites where you have to manage communication over 3G, there is really something to be done with this event-driven protocol that uses few flows. The field of water treatment is a very good example of an application, as is the management of high voltage substations.

Why? Because it is purely event-driven with time stamping at the source. Thus, in the event of a switchover of a HV station or a disconnection, we are warned very quickly and with the right date.

All sites made in Modbus IP, because it was the only protocol totally open and working well, could use MQTT. Indeed, the big disadvantage of Modbus is that the communication is at the initiative of the master, which implies to interrogate the slave.

The big advantage of MQTT compared to Modbus is that as soon as an event changes, the slave publishes the data. Finally, MQTT could be a good replacement for Modbus because it allows time stamping at the source and offers the advantages of an event-driven protocol, while being simple to understand and deploy!

What are the constraints and difficulties in deploying MQTT?

Regarding the reliability and the location choice of the broker?

In our applications, we have chosen to install the broker where the PcVue® acquisition server is installed. The broker can also be redundant and each PLC can publish on the 2 brokers at the same time.

It is thus possible to deploy two broker software programs backed by two acquisition servers for supervision. Then in the case of PcVue, the redundancy of the supervision follows the brokers one.

Regarding cybersecurity constraints?

The MQTT integrates security by authentication of the provider-broker and broker-subscribers’ connections, which is an additional advantage compared to other protocols such as Modbus.

In addition, in the telecontrol application for water towers, VPN tunnels have been set up on the initiative of the local PLCs. The PLCs set up a IPsec tunnel via 3G to the supervisor and all exchanges pass through the VPN tunnel.

No incoming port from the outside directly to the broker, we first have to go through a VPN connection. We can say that the broker is listening on a local network because the equipment is on a VPN with a fixed IP address.

What about the broker?

We chose the royalty-free broker Mosquito®, which has been used for many applications over the years. On our applications, it has never been a problem.

It is also possible to use paid software if you want to have a specific dedicated support. However, it should be noted that by associating the broker with an end-to-end VPN infrastructure, the broker is no longer responsible for security.

How do you see the future of this protocol?

More and more manufacturers are interested in MQTT, and we are convinced that its use will grow. Today, we have implemented applications with PcVue® SCADA and WAGO® PLCs. MQTT is optimally integrated in PcVue because their R&D has included a transparent mode that allows PcVue® variables to be given the same name as the topic in MQTT.

There is no more communication to be programmed in PcVue®; this is a great time saver for programming and it is also very easy to use and maintain.

On our applications, it is impressive how well the PcVue® WAGO® package works. Furthermore, the first projects with new protocols are usually difficult because there is a lot of experience to gain and many things to know are not written in the documentation, this is absolutely not the case here.

How did you work on integrating MQTT for your first case?

We were already thinking for two or three years that the MQTT had all the qualities for telecontrol applications. Moreover, we have been integrating PcVue® software for many years and are supported by ATYS CONCEPT, its distributor, through their product expertise.

Historically, the project was based on an old PSTN protocol with classic remote reading solutions. We spoke with ARC Informatique, the publisher of PcVue®, who was seduced by the project and decided to integrate the MQTT protocol into PcVue®, with the added advantage, as I said earlier, of a very interesting approach, since programming the communication in PcVue® is extremely simple.

It's a win-win partnership that has enabled us to achieve a great result and now allows PcVue® to differentiate itself from many of its competitors.


To go further

You have a project? Contact us to discuss the implementation of PcVue® with MQTT protocol.

You have an experience with Atys Concept or PcVue Solutions that you would like to share? Write to us!


Sources via Atys Concept blog:

-What is the interest of MQTT for remote management?


-What is MQTT?


Monitoring the charging stations of the e-bus flee...
PcVue features in the first 100% Chinese owned sem...

By accepting you will be accessing a service provided by a third-party external to https://www.pcvuesolutions.com/blog/