Skip to content

Edge Gateways & Protocol Translation

The machine is already talking. Something has to listen.

Industrial equipment is rarely silent; it is usually speaking a protocol nothing upstream understands, over a physical layer nothing upstream is connected to. The gateway is the piece that resolves that, and it is where most of the hard decisions in an instrumentation project actually live: what happens when the network drops, what the buffer depth is, whether a reading arrives once or twice, and what timestamp it carries.

Buffered and replayed, by design
Offline-tolerantBuffered and replayed, by design
A replayed reading lands once
IdempotentA replayed reading lands once
Where the use case allows it
One-wayWhere the use case allows it

Sounds like

You might recognise one of these.

  • The vendor says the data is available. Nobody can tell us how to get it out.

  • We lost a day of production data because the internet went down.

  • Every machine speaks something different and we have four separate dashboards.

  • Our integrator wants to put this on the same flat network as everything else.

What this includes

The work, specifically.

Not every engagement needs all of it. This is the range we cover and what each part is actually for.

  • Protocol translation

    Modbus RTU and TCP, OPC UA, EtherNet/IP, Profinet, BACnet and the undocumented serial protocol the machine builder never wrote down. Read as meaning, not merely as bytes forwarded.

  • Store-and-forward

    What the gateway does when the uplink is gone: how much it buffers, in what order it replays, and how a consumer distinguishes a replayed reading from a live one. Decided before deployment rather than discovered during an outage.

  • Time and identity

    Every reading carries a trustworthy timestamp and an unambiguous source. Clock drift on an edge device is the quiet way a time-series dataset becomes unusable for anything correlational.

  • Network placement

    Where the gateway sits relative to the control network, what it is allowed to initiate, and which direction traffic flows. We design for a one-way boundary wherever the use case permits it.

  • Edge firmware and configuration

    Written and versioned in your repository, deployed the same way twice, and recoverable without a site visit.

What you get

Deliverables, not documents.

  • Gateway hardware specified, configured and commissioned
  • Edge firmware or configuration, versioned in your repository
  • A documented data contract: fields, units, timestamps and delivery guarantees
  • Buffering and replay behaviour, exercised by disconnecting the uplink
  • A network diagram showing the control-network boundary and what crosses it

Shapes

How this usually runs.

  1. Protocol survey

    1–2 weeks

    What each piece of equipment speaks, what it will disclose, what it will not, and which of it needs no new hardware at all.

  2. Gateway build and pilot

    4–8 weeks

    One line or one site translating end to end, with the failure behaviour tested by causing the failure.

  3. Fleet rollout

    Ongoing

    The remaining sites, with provisioning and update handled as a process.

Tooling

What we build it with.

No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.

Industrial
  • Modbus RTU/TCP
  • OPC UA
  • EtherNet/IP
  • Profinet
  • BACnet
  • Serial
Edge
  • Linux on ARM
  • Docker on edge
  • Node-RED
  • Sparkplug B
Transport
  • MQTT
  • AMQP
  • HTTPS
  • Cellular LTE-M
  • LoRaWAN

Questions

Edge gateways, honestly.

  • As little as the use case allows, and we say exactly how much before anything is installed. Read-only and one-way boundaries are the default; where a write path is genuinely required we name it, scope it and get it agreed rather than assuming it.

  • No. We put a device on the network and get data off it. Assessing that network, segmenting it and monitoring it for anomalies is the cybersecurity division's operational-technology practice, and keeping the two separate means the people auditing the boundary are not the people who installed it.

  • The gateway buffers to its configured depth and replays on reconnect, and the data contract says how a consumer can tell a replayed reading from a live one. We test it by disconnecting the uplink during commissioning, because a buffer nobody has exercised is an assumption.

Next step

Tell us what’s breaking.

Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether you should be building this at all.