Author: Nurettin Mert AYDIN, Group Manager (Energy)

In today’s digital world, communication and integration play important roles, combining independently operating devices and systems under one roof and as the new era in energy generation and distribution dissolves power grids into smaller smarter grids, people interested in the energy & utilities domain have one common chapter in hand: Communication protocols. Looking at this introduction, this sounds quite straightforward and like a trivial process, huh? Let’s take a look at the evolution of communication protocols for energy & utilities to find out more.

The early 80s had a big influence on stakeholders of energy & utilities as dominant players started to introduce cutting-edge energy measurement devices to the market. The very first communication protocol, called Modbus was the earliest, widely-known protocol introduced for connecting SCADA and RTUs (Remote Terminal Units) in 1979.

Although aimed to be specific to industrial processes, Modbus has some flaws: It does not support peer-to-peer communication out-of-the-box and is slow compared to other protocols. Of course, this is related to the fact that Modbus is older than the others. Modbus has a quite nice feature, though: It provides two modes for communication: ASCII mode and RTU mode. RTU mode is used in production since it is in hex form and smaller in size whereas ASCII mode is handy in development and testing platforms because it provides human-readable content that can speed things up in the kitchen.

After the popularity of Modbus, IEC (International Electrotechnical Commission) introduced two protocols called IEC 101 (IEC 60870-5-101) and IEC 104 (IEC 60870-5-104) in early 90s and 2000 respectively.

IEC 101 is one of the companion standards defined along with IEC 60870-5, the set of standards to be used in SCADA (Supervisory Control and Data Acquisition) systems.

IEC 101 is purely built on top of serial communication (i.e. RS232) and hence, none of the cutting-edge central systems support it because they are mainly interested in protocols supporting TCP/IP. There are some implementations of IEC 101 on top of TCP by using ethernet as a backbone (and serial-to-ethernet converters) but due to lack of native TCP/IP support, IEC 101 and IoT (Internet of Things) are not even mentioned in the same context.

IEC 104, on the other hand, is widely-deployed in SCADA systems. It not only extends IEC 101 (IEC 104 is one of the companion standards defined along with IEC 60870-5 as well) but also is built on top of TCP/IP so it supports default network infrastructures such as ethernet and GPRS.

Although insufficient for IoT, being developed specifically for SCADA systems and including features like asynchronous response made IEC 104 the most famous of all, in energy & utilities.

Finally, we have DNP3 which was proposed for industrial processes to be “the protocol” in this domain. However, it could only find limited number of supporters in water and electricity sectors. Water and wastewater telemetry systems are now trying to make the most out of DNP3, boosting its features such as open protocol support, communication with multiple central systems (masters) and support for time synchronization.

IMHO, the nicest feature of DNP3 is that the end units (slaves) can report to the central systems (master) on their own: Once an event occurs, this can be immediately percolated up to the central system without waiting for the next polling cycle.

Being built on top of TCP/IP stack, DNP3 is insufficient for IoT due to limited security features and limited peer-to-peer communication.

Of course, there are many other communication protocols used by industry-leading products of big vendors and even more suggested by academic people but as of now, the most fitting one seems to be IEC 104.

Any alternatives for these communication protocols? Well, yes. With the inauguration of IoT, people started using message queuing for their infrastructural and communication backbone. There are numerous options for message queuing like AMQP, MQTT, STOMP and among these, big players seem to have chosen a winner: MQTT due to its network bandwidth friendly nature and low power consumption.

MQTT is a generic message queuing solution. Being built on top of TCP/IP, it makes use of publisher/subscriber message transmission model where MQTT clients publish messages to topics on an MQTT server and MQTT server forwards these messages to other MQTT clients subscribed to topics.

The added values of MQTT are security and QoS (quality-of-service). MQTT can make use of TLS for data-on-the-fly security and in addition to this, there are client authentication mechanisms to make sure that only the eligible clients are sending or receiving data.

With optional and configurable QoS approach, MQTT provides ensured message delivery which is most probably the most important aspect since people are looking for real-time, complete, time-tagged data.

Although not specifically designed for SCADA systems, MQTT adds a nice flavor to existing systems and many new solutions support MQTT out-of-the-box in addition to legacy communication protocols because it is easy to implement and there are many open-source clients and servers that can be integrated to existing systems right away.

Today, in energy & utilities, we are mainly talking about IEC 104 and MQTT. What will the future bring? We don’t exactly know because there are many big players in this domain and what they decide tends to rule the sector. What I can say for sure is that this sector is frequently commemorated with IoT and there are other big players such as Amazon (AWS) and Google who have already started using MQTT as their backbone for their IoT architectures and so, it would be a good investment to support MQTT in addition to existing portfolios for conformity and durability.