Home / Solutions

Solutions

Five bridges between the plant and the model

The data is already in the plant. Sensors, PLC registers, ladder logic, meters, cameras. What is missing is the bridge that gets it out cleanly, gives it context, and puts an answer in front of the person who can act. We build five of them.

Request a plant data audit

The short version

Why a bridge, not a dashboard

Most plants are not short of data. They are short of a way to use it. The signal sits in a PLC nobody is allowed to touch, a historian nobody reads, and a SCADA screen built to show what is happening now, not what is coming.

Every one of our solutions is built on the same spine, in the same order:

  1. OT. What the plant already has. Sensors, drives, PLCs, meters, cameras, the program itself.
  2. The bridge. Edge collection on the OT side, one clock, the tag model, operating state, and a one-way path out. This is the part we do.
  3. The model. A baseline per asset, anomaly scoring, classification, forecasting or reasoning, depending on the bridge.
  4. Where it lands. A screen, an alert, a work order, a report. In the hands of the planner or the person on site, not buried in a portal.

The bridge is the part most analytics vendors skip, and it is the part that decides whether a model works on a real plant or only in a demonstration. We are an automation company first. That is why we can build it.

The rule on every bridge

Read-only. No write path to the PLC, no inbound connection to the control network, and only events and aggregates cross the DMZ. Interlocks and trips stay in the control system where they belong.

1. TGE Rotating Equipment Prediction

The expensive problem. A bearing fails on a Sunday. The line is down two days, nobody sells the part on a weekend, and a delivery date is at risk.

LayerWhat happens there
OTWireless vibration, ultrasound and temperature nodes on the bearing housings. Motor current and speed from the drive or MCC. Run state from the PLC: loaded, idle, off.
The bridgeAn edge gateway in the MCC room turns each waveform into RMS, envelope and kurtosis, stamps it on one clock, joins it with the PLC state, and buffers when the link drops. Out one way over MQTT, through the DMZ or a cellular router.
The modelA baseline learned per bearing, an anomaly score on every reading, the fault class (inner race, outer race, lubrication, misalignment), and the trend that says when to act.
Where it landsOne faceplate per point, laid against the planned shutdown, with the work order raised into the CMMS and an alert to the planner, not the operator.

What the plant gets. The change happens on the planned stop, not on the Sunday.

Operating hours, not calendar days

Duty and standby machines rotate. A trend on calendar time makes an idle machine look healthy. Every reading is judged against the hours it actually ran.

2. TGE Camera Intelligence

The expensive problem. One injury is a stop-work order and an investigation. One hot joint is a dark substation. Both were visible for weeks before they happened.

LayerWhat happens there
OTThe existing CCTV, with no new cabling. Radiometric thermal cameras on switchgear and hot lines. Zones drawn from the plant drawings. Machine state from the PLC.
The bridgeA GPU edge box on the OT network pulls the streams, samples frames, calibrates thermal, and tags every frame with its zone and machine state. No live video leaves the site. Only events and clips cross the DMZ.
The modelPerson in a restricted zone. PPE checks for helmet and vest. Each panel's temperature against its own baseline and rate of rise. Suppression of anything the machine state already explains.
Where it landsOne alert per incident to the shift lead's phone within seconds, the clip and frame kept as evidence, safety and thermal dashboards, and an audit export.

What the plant gets. The audit gets evidence instead of a story, and the hot joint is found while it is still a work order.

Not every detection is equal

Helmet and hi-vis detection is mature. Footwear and face shields are not, and are proven on site before anyone relies on them. Temperature sensors also have a ceiling, and we state it for your equipment before a threshold is set.

3. TGE Energy Intelligence

The expensive problem. Energy is the second biggest cost after people, and most plants pay it blind. The bill says how much. It never says which line, which pump, or why.

LayerWhat happens there
OTA power meter on every feeder. Speed and current from the drives. Run state and production counts from the PLC.
The bridgePolled every second on one clock and joined: kW with Hz, run state and tonnes. The sum of the loads is checked against the incomer so a missing meter shows up. Kept in a historian at the edge, one-minute aggregates out.
The modelExpected kW for each load at each operating point, run states detected from the power signature, peak and consumption forecast from the production plan, and actions ranked by what they return.
Where it landsA fleet screen first, then the unit. A work list raised from the screen. The periodic energy report compiled from the data rather than typed.

What the plant gets. The waste has a line number. Drives and sequencing go where the number says, and the saving is measured after the fix, not promised before it.

Not every pump saves on a drive

Where the duty is set by static pressure rather than flow, the affinity laws do not deliver the saving a drive brochure shows. We check the duty before anyone buys the drive.

4. TGE Operations Intelligence

The expensive problem. Upstream stops and downstream keeps feeding. Every minute of it is scrap, wasted energy and a restart. Nobody finds out until someone walks the line.

LayerWhat happens there
OTThe station PLCs, belt scales and level sensors, and the plan the operation runs to.
The bridgeAn OPC UA client reads every station read-only. Tags are organised as site, area, station, tag. Loss and energy per load are calculated at the edge. One second live, one minute history.
The modelWhen the run will finish, where planned work clashes with the run plan, equipment running with nothing to do, and every station ranked best to worst.
Where it landsAn operations screen with each station's live number on the process picture, the next stop planned rather than discovered, the shift report written from the data, and a mobile view for the superintendent.

What the plant gets. When upstream stops, downstream stops with it. The shift report is a record, not a reconstruction.

SCADA is not the same thing

SCADA shows the state of the plant now. This shows how well it ran, where it lost, and what is coming next. Most plants need both, and the second one reads from the first.

5. TGE OT Navigator

The expensive problem. Line down at 3 am. The one person who reads the ladder is asleep, and the laptop with the software is locked in his car.

LayerWhat happens there
OTThe program export: ladder, sequence and function blocks with their comments. The live tag values. The SCADA alarm and event database. The HMI screens.
The bridgeThe program is parsed into one graph of rungs, tags and cross-references, with the live states painted onto it. Re-parsed on every program change. Strictly read-only, with no write path to the PLC, ever.
The modelReasoning over the graph and the live states to find the step that is stuck and the contact holding it, check every interlock in the chain, and rank the likely causes with a confidence.
Where it landsPlain steps to the phone of whoever is on site. A work order raised with the cause and the log. The lesson stored against the rung for the next time.

What the plant gets. Anyone on site is told where it stopped and what to check, without reading ladder or connecting a laptop. Downtime measured in minutes, not a shift.

Steps, never a bypass

The Navigator tells a person what to check. It never suggests forcing an output or bypassing an interlock, and it never writes to the controller.

How a bridge starts

  1. One asset or one area. The expensive problem you already know about, not a plant-wide programme.
  2. A survey of what is already there. Which signals exist, which PLCs hold them, what the network allows, and what the IT side will accept across the DMZ.
  3. A proof on that asset. Baseline, validate against what the plant already knows, and agree what counts as a useful answer before anyone scales.
  4. Scale on the same spine. The second asset reuses the bridge. That is where the cost per point falls.

If the controls underneath are unreliable, we will say so and fix those first. A model on top of a system nobody trusts gives confident answers to the wrong question.

Questions we get asked

Do we need new sensors?

Often not for most of it. PLC registers, drive parameters, meters and existing CCTV already carry most of it. Rotating equipment and thermal usually need a sensor or camera added at the points that matter.

Does any of this connect into our control network?

It reads from the OT side and sends one way out. No inbound connection, no write path to a PLC. Where a plant will not allow any link at all, monitoring can run standalone on its own network.

Where does the data live?

On your infrastructure where you require it. Only aggregates and events need to leave the OT side, and nothing leaves the site if your policy says it cannot.

Is this tied to one automation brand?

No. The bridge reads the platforms the plant already runs. Allen-Bradley, Siemens, Schneider, Mitsubishi and smaller packaged-machine controllers are all read the same way: through the protocol, never by replacing the controller.

Which bridge should we start with?

The one attached to the problem that already cost you the most this year. Usually that is an unplanned stop on rotating equipment, or a line that runs without anyone knowing how well.

Start with the plant, not the proposal

Tell us the asset, the platform and the constraint. If it is not something we should be doing, we will say so and tell you who should.