A data set says what an IED can send. A report control block says when, why, how much detail, and to whom. Every reporting problem in a substation — missing events after a comms drop, a client that never receives anything, reports flooding the station bus during a fault — traces back to an RCB attribute somebody set… Read More: IEC 61850 Report Control Blocks: BRCB and URCB Explained »
The confusion is understandable. Both protocols are built on MMS. Both use the same OSI upper-layer stack. Both listen on TCP port 102 and 3782. Both show up in Wireshark labeled “MMS,” decoded by the same dissector. Vendors often implement them with shared library code. And yet they solve completely different problems, and no project ever chooses between… Read More: ICCP vs IEC 61850: Two MMS Protocols, Two Jobs »
TASE.2 defines its functionality as operations and actions on objects, then maps each one onto an MMS service. That mapping is the Rosetta Stone of ICCP work: vendor documentation speaks TASE.2 (“Start Transfer”), the wire speaks MMS (“Write”), and moving between the two is half of every troubleshooting session. This reference lays out the complete map in both… Read More: ICCP Operations and Services: The Complete TASE.2 Map »
Every value an ICCP link carries is an instance of an object model from IEC 60870-6-802:2014. When two control centers negotiate a bilateral agreement, a large part of the technical work is agreeing, point by point, which of these models and which type variant each point uses — because the type determines exactly what crosses the wire: value… Read More: ICCP Object Models: Indication Points and Control Points »
RabbitMQ is an open source message broker. It sits between the parts of a system that produce data and the parts that consume it, and it moves messages between them. Neither side has to know the other exists. They only need to know the broker. In industrial automation, that role fits a common problem. Plants run a mix… Read More: What Is RabbitMQ? The AMQP Message Broker, Explained »
Once your MQTT deployment matters — because it carries production telemetry, or controls physical equipment, or supports customers who expect uptime — a single broker becomes a liability. If that one broker fails, the entire system stops moving messages. For deployments where this is unacceptable, you need redundancy: multiple brokers configured so that the failure of any single… Read More: MQTT Broker Redundancy and High Availability: Complete Guide »
Modbus and MQTT solve the same problem from opposite ends. Modbus reads and writes numbers in a device. MQTT moves messages between systems. Put them together and you can take a register sitting inside a serial meter and land its value in a cloud database a continent away. But the two don’t connect on their own — they… Read More: Modbus to MQTT: How the Gateway Bridge Works »
MQTT is deliberately unopinionated about what your payloads contain, how you structure your topics, or how devices announce themselves to the network. That flexibility is a big part of why MQTT is popular. It is also the reason MQTT alone is not enough for industrial IoT, where two vendors’ devices need to interoperate on the same broker, where… Read More: What Is Sparkplug B? A Complete Guide to MQTT for… »
If you write Python and you need to move small messages between devices or services, MQTT is usually the right fit. It is a publish/subscribe protocol: a client sends a message to a topic, a broker holds the connections, and every client subscribed to that topic gets a copy. Publishers and subscribers never talk to each other directly.… Read More: Python MQTT: Complete Guide to paho-mqtt 2.x »
On a Modbus serial line, every byte you send is wrapped in a few extra bits before it hits the wire. Those extra bits — the start bit, an optional parity bit, and one or two stop bits — make up the character format. Get them wrong on one device and it won’t talk to the rest of… Read More: Modbus Parity and Character Format »