6 Aug 2026 · 4 min read

Ignition 8.3 can now do the job of the box in the middle of your drawing

ignition · uns · scada

Nearly every drawing I have seen for getting plant data into a modern data platform has the same shape. The gateway publishes its readings one way, a small program in the middle picks them up and translates them, and the data platform receives them in the format it wants.

That middle box exists purely to translate. It is a thing you have to install, patch, monitor and explain to whoever inherits it.

I built that arrangement to test how it copes with failure. Then I looked at what was already installed in the gateway and found I had drawn a box that no longer needs to exist.

What is already sitting in the gateway

Ignition 8.3 ships with two features that most people have not noticed yet: a connector for Kafka, which is the sort of data platform the middle box usually feeds, and a feature called Event Streams for routing data around.

Between them the gateway can send readings straight to the platform itself, and receive from it too.

THE BOX YOU MAY NOT NEED ANY MORE

GATEWAYtranslatorno longer neededDATA PLATFORMthe gateway can now do this itself
If the box in the middle only ever translated, it is now something you are maintaining for no remaining reason.

Which changes the shape of the problem. If the only job of your middle box was translating between the gateway and the platform, the gateway can now do it directly, and that box is something you are maintaining for no remaining reason.

It still earns its place if it does more than translate. Holding onto data while the far end is down, sending one stream to several destinations, or speaking to equipment the gateway cannot reach are all real jobs. But "we need something to get this across" stopped being a reason.

Worth checking your own gateway rather than taking my word for it, because this is recent and most drawings in circulation were made before it existed.

The part I actually built it to test

The reason for putting both on a cluster was to find out what happens when something dies. Clusters are supposed to notice and restart things without anybody being called out.

So I wrote five hundred known readings into the data platform and then deleted it outright, mid-flight, the way a server failure would.

SWITCHED OFF ON PURPOSE, LEFT TO RECOVER ALONE

7s
the data platform
every reading still there
16s
the SCADA gateway
answering again
Both unattended. Nobody logged in, nobody restored a backup, nobody was phoned.

Seven seconds to come back, with all five hundred readings still there.

Then I did the same to the Ignition gateway. Sixteen seconds from deletion to the gateway answering again. The difference between the two is Java starting up.

Both happened unattended. Nobody logged in, nobody restored anything from a backup, nobody was phoned.

That is genuinely the whole story on that front, and it is a dull one, which is the correct outcome for infrastructure you are trusting with a plant.

The detail that will actually catch you out

WHAT SURVIVED BEING SWITCHED OFF AND ON

its nameunchanged ✓
its number on the networkdifferent ✕

Things move for entirely routine reasons: a machine drained for maintenance, an update applied. Refer to them by name and they simply reconnect.

The habit to change coming from a plant floor. Write down the name, never the number.

Look at the second row. Both came back with the same name and a different network address.

That is the one habit that has to change coming from a plant floor. The instinct everywhere in this industry is to write the address down: put the historian's address in a config file, type the server's address into a gateway screen, note it on the drawing so the next person can find it.

Every one of those breaks the first time something moves, and things move for entirely routine reasons. A machine gets drained for maintenance, a memory limit trips, somebody applies an update.

Refer to things by name and they simply reconnect. The name is the stable thing being offered to you. The address explicitly is not.

Who is actually the expensive one

One more result, because it contradicts the usual objection.

When people hear "we are adding a streaming platform to the plant" they picture something enormous. It sat there using a quarter of a gigabyte. The Ignition gateway next to it used three and a half times that.

The new thing everybody is nervous about is the cheap tenant. The SCADA gateway you already run is the expensive one.

What I would take from this

Check what is already in your gateway before commissioning a box to sit in the middle. On 8.3 you may be about to build and maintain something the platform already does for free.

If you do run this arrangement on a cluster, the single most important change is referring to things by name rather than by address, because that is the thing that quietly breaks later.

And the honest limit on all of it: this measures software coming back, not a plant coming back. A gateway answering in sixteen seconds still has device connections to re-establish, and anything that was half-finished when the power went is a different question that this test does not answer. A cluster will restart your software reliably. It has no opinion whatsoever about your process.

The setup, both failure tests, the full feature list and a check of my own that hung instead of failing are in the lab write-up.

The sequel, where the data actually flows and everything gets switched off on purpose: I switched off every part of a streaming plant pipeline. The data only died once.

Keep reading

Newsletter

New essays, by email.

SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.