Protocols

The platform speaks four protocol families. Three are for talking directly to field devices; the fourth is for publish-subscribe telemetry through an edge gateway. Most operators end up using more than one, because the right choice depends on the site rather than on a preference.

Modbus

Modbus RTU (serial) and Modbus TCP (Ethernet). It is the most widely deployed protocol in upstream production and the most likely thing an older RTU or flow computer speaks.

Modbus is a register protocol with no built-in semantics. A register is a number at an address; nothing in the protocol says whether it is pressure in PSIG, a counter, or two halves of a 32-bit float. That means configuration carries the meaning:

• the register address and function code
• the data type and word order, including how 32-bit values are split across registers
• the scaling factor, and the resulting engineering units

The platform records all of that with the tag and retains the units, so a value read from a register arrives in the model already carrying what it means.

What to watch for

Word order is the most common source of wrong values. A 32-bit float split across two registers can be assembled four ways, and three of them produce numbers that look plausible. If a value is out by a large factor or oscillates implausibly, check word order before anything else.

Modbus is polled, which means every value costs a transaction. On a metered cellular link this adds up, and it is the usual reason to move a site to report-by-exception.

DNP3

DNP3 was designed for exactly this problem — telemetry over unreliable, low bandwidth links — and it solves several things Modbus does not.

• Event-driven reporting. Devices report changes rather than being polled for every value on a cycle. Traffic scales with how much is happening, not with how many points exist.
• Timestamps at the source. Events carry the device’s own time, so ordering survives a link outage. Modbus values are timestamped when they are read, which is a different fact.
• Quality flags in the protocol. DNP3 carries per-point quality, including whether a value is online, restarted, or over-range.

The platform maps DNP3 quality flags onto its own quality state rather than discarding them. A point the device flagged as questionable stays questionable all the way through to the historian.

Unsolicited responses

DNP3 devices can report without being asked. This is the behaviour worth configuring on constrained links, because it removes the poll cycle entirely for points that rarely change.

OPC UA

OPC UA is the modern industrial standard and is what newer equipment, packaged skids, and plant systems are most likely to expose. Unlike Modbus, it carries structure: nodes have types, names, units and quality, and the address space is browsable.

That makes OPC UA the least error-prone of the three to configure, because the server tells you what things are instead of requiring a mapping document. Where a device offers both Modbus and OPC UA, prefer OPC UA.

OPC UA also carries subscriptions, so it supports report-by-exception in the same way DNP3 does.

MQTT with Sparkplug B

MQTT is a publish-subscribe transport. Devices publish to a broker; the platform subscribes. Nothing polls anything.

Plain MQTT has no more built-in semantics than Modbus, which is what Sparkplug B adds: a defined topic structure, a defined payload format, and — the important part — explicit device state.

Why the birth and death certificates matter

Sparkplug B devices publish a birth certificate on connect, declaring every metric they will report and its type and units. They also register a death certificate with the broker, which the broker publishes if the device disappears.

The practical effect is that device state is explicit rather than inferred. Under polling, a device that stops answering and a device that is reporting no change look similar until a timeout expires. Under Sparkplug B, disconnection is an event, and the platform can distinguish the tank level is steady from we have not heard from that site since 03:40.

That distinction is the same one running through the rest of the platform: a missing value is never rendered as a zero.

Where the gateway sits

An edge gateway at the site talks to local devices over Modbus, DNP3 or OPC UA and publishes to the broker over MQTT. This is the arrangement for constrained or metered cellular, because the chatty protocol conversation stays local and only changes cross the expensive link.

Choosing

Situation	Reach for
Existing serial RTU or flow computer	Modbus RTU
Ethernet device, simple point list	Modbus TCP
Unreliable link, need source timestamps and quality	DNP3
Newer equipment or a packaged skid that exposes it	OPC UA
Metered or intermittent cellular, many sites	MQTT with Sparkplug B via edge gateway

What the platform does with all of it

Regardless of protocol, an incoming value is resolved into the well and facility model, retaining:

• the source device and the original device tag
• the units as configured or as declared by the protocol
• the acquisition time, and the source timestamp where the protocol carries one
• the quality state, mapped from protocol quality where it exists

See tags and the asset model for how that mapping is defined, and connecting devices for the practical steps.