Category Archives: Communication Protocols

What Is the ICCP Protocol? TASE.2 (IEC 60870-6) Explained

ICCP is the protocol utility control centers use to talk to each other. Not to substations. Not to RTUs. To other control centers: the neighboring utility, the regional transmission operator, the power pool, an independent generator’s dispatch center. Its official name is TASE.2, the Telecontrol Application Service Element 2. The standard behind it is the IEC 60870-6 series,… Read More: What Is the ICCP Protocol? TASE.2 (IEC 60870-6) Explained »

Modbus Client-Server vs Master-Slave Terminology

You just downloaded a new device manual and it says “Modbus client” and “Modbus server.” Your RS-485 documentation says “master” and “slave.” Your PLC code has variables named slaveId. Which is right? Do you need to change your code? Are these different protocols? Short answer: no. The protocol is identical. The terminology depends mostly on the transport you… Read More: Modbus Client-Server vs Master-Slave Terminology »

Modbus TCP Security Explained: TLS on Port 802

Standard Modbus TCP has zero security. No authentication. No encryption. No integrity checks. Anyone who can reach TCP port 502 can issue Modbus requests. Depending on the device configuration, this may allow reading registers, writing coils or registers, changing operating parameters, or disrupting industrial processes. For decades, the answer was “put it behind a firewall and hope for… Read More: Modbus TCP Security Explained: TLS on Port 802 »

MQTT 5 Request Response Pattern Explained: RPC Over MQTT

MQTT was born as a publish/subscribe protocol — messages flow from many publishers to many subscribers with no expectation of a response. This model fits telemetry perfectly: sensors publish, dashboards subscribe, nobody waits for anyone. But when you need one client to ask another client a specific question and get one specific answer back, pub/sub alone falls short.… Read More: MQTT 5 Request Response Pattern Explained: RPC Over MQTT »

MQTT 5 Correlation Data Explained: Request/Response Pattern

MQTT was designed for publish/subscribe — fire-and-forget messaging from many publishers to many subscribers. For two decades, that’s what MQTT did. If you wanted classic request/response (“send a query, get back exactly one answer for that query”), you had to use HTTP, AMQP, or roll your own correlation scheme on top of MQTT topics. MQTT 5 added native… Read More: MQTT 5 Correlation Data Explained: Request/Response Pattern »