Streaming computer vision predictions into the event bus a plant already runs

A filling line in a beverage plant has two cameras that matter. One sits over the capper and sees every bottle leave with or without its cap. The other sits past the labeler and sees whether the label is on straight, skewed or missing. Both models produce boxes, and for a year those boxes went to a screen in the line office that nobody watched after the first month.

The plant already has an event bus. Every PLC tag change, every reject count, every downtime reason is published on it, and the dashboards on the production floor and the maintenance ticket queue both read from it. The cameras were the only sensors on the line that did not.

The fix is to treat a detection like any other sensor reading: a timestamped event, published once, consumed by whoever needs it.

A detection becomes a timestamped event with its bounding box

The event for a missing cap on line 2 is small. It carries the camera, the line, the time to the millisecond, the class the model found, the bounding box in pixels, the model version, and a reference to the frame. That is enough for a dashboard to count it, enough for a ticket to describe it, and enough for a person to go back and look at the bottle.

The bounding box is worth carrying even when the consumer only wants a count. A downstream rule that later asks "was the missing cap on the left lane or the right" can answer from the box without anyone touching the model. Strip it out and that question needs a redeploy.

The model version belongs on every event for a reason the plant finds out later. When two versions are compared on the same line, the events are the comparison.

The webhook is the door into the bus the plant already has

An alert on the platform is a rule written as a sentence, with a severity and a cooldown, approved before it goes live, and it is delivered to Slack, email or a webhook. The webhook is the one that matters here. The plant runs a small receiver that takes each alert as it arrives and publishes it on the bus under the line's topic, and from that moment the camera is a sensor like any other.

The monitoring and alerts guide covers the rule and the delivery. What it does not cover is the receiver, because the receiver is the plant's, written in whatever the controls team already uses, and it does one thing: accept the payload, stamp it, publish it. Ten lines is usually enough.

On the filling line, the capper rule is "a bottle leaves the capper without a cap", severity routine, cooldown short enough that a run of missing caps is a run of events rather than one. The labeler rule is written the same way. Two rules, two topics on the bus.

Dashboards and tickets consume the stream without touching the model

Once the events are on the bus, the consumers are the ones the plant already has. The floor dashboard adds a tile: missing caps this hour, next to the reject count from the checkweigher. The maintenance queue opens a ticket when the labeler events cross a rate the line lead set, and the ticket carries the frame, so the technician sees the skewed label before walking over.

The model was not touched to make any of that possible. The consumers on line 2 are reading a stream, and the stream has the shape the plant's other streams have. When the quality team later wants a weekly report on cap events by shift, that is a query against the bus, the same query they run for downtime.

This is the same shape the wider multi-sensor monitoring use case takes: the camera is one input among many, and the plant's own systems decide what to do with it.

An overnight firmware update shows up as a step in the stream

On a Tuesday the capper events tripled from the start of the morning shift. The line had not changed, the bottles had not changed, and the operators on the morning shift swore the caps were fine. The stream showed exactly when it started: the top of the hour, on that camera, and on no other.

The plant's IT team had pushed a firmware update to the cameras overnight. The white balance moved, the compression setting changed, and the frames the model received were no longer the frames it had been tested on. The drift catalog calls this firmware and compression, and it is the first thing to rule out on any sudden drop or spike, because a step to the exact hour means something discrete changed, and the change log will say what.

The event stream is what made the step visible. A person looking at the screen in the line office would have seen more boxes and assumed the capper was failing. The stream, plotted against its own history, showed a cliff on one camera at one hour, which reads as a pipeline event and not a capper event. The fix was a revert, not a retrain, and it took an afternoon.

My own view is that the event rate against its own history is the cheapest monitor a plant will ever run on a vision model, and most plants never plot it because the events were never published anywhere a plot could be made.

The stream carries the events, the recorder keeps the footage

What the bus carries is the event and, where the rule asked for it, the frame with the box drawn on. What the bus does not carry is the video. With a runner beside the recorder, inference happens on site, alerts fire locally first, the footage stays where it was recorded, and only the frames the model doubted leave.

LexData takes the capper model through its whole life. You type what to look for, Lexi puts a box on every frame, and a person checks each label before anything trains on it. The model then watches the two cameras on the filling line, in the cloud, on your servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime. The events on the bus carry the new version number from the first frame it sees.

The line lead on this filling line keeps a laminated card by the HMI with the two topic names on it, because the dashboard team and the maintenance team kept asking. That card is the whole integration, as far as the floor is concerned.

Backpressure and ordering are the plant's problem, and they always were

A bus that carries PLC tags at high rates does not notice a camera publishing a few events a minute. Where it does get interesting is a run: a jammed capper produces an event on every bottle until someone stops the line, and a cooldown on the rule keeps that from becoming a flood. The bus itself handles ordering per topic, and the timestamp on the event comes from the frame, so a late delivery still sorts into the right minute.

Retention follows the plant's existing policy for sensor events, which on most lines is longer than anyone expected the cameras to need. That is fine. The events are small, and a year of them is the record the quality team will want when a customer asks about a lot.