top of page
Search

Bolt-On AI for Your SCADA: Thred, Ignition, and Minimum Viable Context

Oct 5
6 min read

Everyone in oil and gas and mining is being sold AI projects this year. A lot of those projects stall out. Not because the technology does not work, but because they start in the wrong place: a large, holistic data integration that spends more time organizing and cleaning data than solving a problem anyone has. This takes longer than leadership wants and often has hidden integration costs that are not presented up front.


We still believe a unified namespace and a solid digital infrastructure is the right foundation. We build them. Customers with UNS and solid digital infrastructure are moving faster than their peers here. After a season of demos with our oil and gas customers we have noticed something. Because of how JPI builds systems, most of them are a lot closer to that foundation than they think. The gap is not two years of platform work and extra integration. It is an adapter and a well-chosen problem.


The problem is not collecting data. It is connecting it.


Over the past few weeks we have demoed a product called Thred to four of our oil and gas customers. Different companies, different SCADA systems, similar stories.


One of them has roughly 1,500 wells on Geo SCADA, plus VTScada, plus Ignition, plus Watchdog, plus Toku, plus a handful of other systems that each hold a piece of the picture. Their words, not ours: "our problem isn't collecting data, it's connecting it." Nothing trends against anything else. Data dumps come out in different shapes. Operators and engineers need to hit 3 or more systems to do their work. The real, consolidated analysis lives in a spreadsheet that only one person has and understands.


Another runs a gas plant where the engineers mostly see condensed daily averages through their production accounting system. The SCADA system has second-by-second data. Nobody has built their users a way to look at it live and do more with what they already have.


As we find with oil and gas, these companies seem "connected enough" to believe they do not have a data problem. In a sense they are right. The data exists, and in most cases it is already flowing through a SCADA system or historian we can get at. It just cannot answer a question yet.


Today, five systems feed one spreadsheet. With Thred, the same systems feed one connected graph through an Ignition data shim.

What Thred actually is


Thred is a knowledge graph for industrial data, with an LLM (Claude, Copilot, ChatGPT, or whatever your IT group has approved), and a solid set of MCP tools and skills sitting on top of it.


Strip away the words. A knowledge graph is just relationships. This flow meter is the inlet to this battery. This pump feeds this separator. This pressure transmitter is upstream of that valve. Your P&IDs already know this. Your PLC code already knows this. Your senior operator definitely knows this. The production accountant has it figured out. Outside of construction drawings and measurement documents, nobody has written it down anywhere. And no one has put those relationships in something a computer can use for context.


Thred builds those relationships, partly automatically from P&IDs and PLC exports, with a person approving each one. Once the relationships exist, the AI can reason over your process instead of just your tags. Ask it why the separator pressure is cycling and it can walk upstream to find out. Ask for a dashboard of every water disposal site side by side and it builds one. There are prebuilt skills for root cause analysis, alarm rationalization, and failure-mode review. Every answer carries a trust score so you know how much of it is verified and how much is inference.


It is a bolt-on. It does not replace your SCADA, your historian, or your operators. It sits beside them and enables them to do more with what they already have.


Layered view from existing SCADA, through the Ignition data shim, to Thred's knowledge graph, an approved LLM, and answers the team can check.

Ignition as the data shim


Here is the part our customers always ask about first. "We run Geo SCADA. We run VTScada. We run DeltaV. How does this thing get our data?"


Thred connects through an Ignition module. Install the module, paste in a connection string, pick the tag folders you want, and the data starts flowing. Thred's team has done the connection step live on a call and at conferences in about fifteen minutes. The work before and after that step is where the real effort lives, but the connection itself is not the hard part.


Most of our customers do not run Ignition as their SCADA, and they do not need to. We use Ignition as a data shim. Think of it as an adapter plug, not a renovation. A base Ignition gateway sits between your existing system and Thred. It speaks OPC UA and MQTT to Geo SCADA or whatever you have, it can talk directly to PLCs if we need it to, and it hands the selected tags through to Thred. Your SCADA keeps doing exactly what it does today. Your operators never see the difference.


This is also where the "closer than you think" part comes in. That Ignition gateway, publishing a curated set of tags over MQTT, is the start of a digital infrastructure. It is a small, honest first layer of a unified namespace, built around a real problem instead of a diagram. If you already have Ignition or MQTT in the building, you are further along still.


For customers who already have Ignition, adding Thred is a short job. For customers on Geo SCADA with the right connectors installed, plan on a day or two. For a locked-down DCS we will quote it honestly, somewhere between a couple of days and a week, but even that is a connector project, not a platform project. Nobody has to rip anything out. That is what bolt-on means.


Minimum viable context


The adapter is the easy part. What sold us on Thred is how they approach the work. They start from the problem and do only what is necessary to get a result. No plant-wide model, no six-month data cleanup before anyone sees value. Mitch Webster at Thred has a name for it, and I have been borrowing it since I heard it: minimum viable context.


Here is where it came from. Thred onboarded a timber mill in Australia. Someone hit "select all" and the system started ingesting 60,000 tags. But the problem the COO cared about was log gap, the dead space between logs entering the line. Solving that needed about 400 tags. Not sixty thousand. Four hundred.


With roughly a thousand tags connected, they found a US$1.6 million opportunity in three days. The controls engineer went through the analysis line by line because it seemed too lucky. It held up. Five weeks and a couple of servos later, the mill was collecting that money.


That is the whole idea. Do not boil the ocean. Do not model the plant. Find the smallest part of your business with the biggest toothache, pull in only the tags that problem needs, build only the relationships that problem needs, and prove it. Then move to the next toothache. The relationships you built along the way stay, so each problem gets easier than the last.


A big program models everything before first value. Minimum viable context solves one toothache at a time while kept relationships accumulate.

Context has a cost. Every tag you ingest, every relationship you model, every token the AI spends reading it all costs money and, worse, time. The big-program approach front-loads that cost before anyone has seen a dollar back. That is a big reason those programs stall.


Minimum viable context flips it. It forces the conversation back to the problem. Not "what can we connect?" but "what is actually hurting?" A balance report that never balances. Water hauling that costs more than it should. Tank reconciliation that catches theft and ticketing errors. A gas plant that trips and nobody can say why. Pick one. The technology follows the problem, not the other way around.


What this means for you


Start with one expensive problem. If nobody can name one, that is the first thing to fix, and no platform will do it for you. If you can name one, you are probably a few weeks from a result.


You are closer to ready than you think. You do not need to finish a unified namespace or migrate to a new SCADA to get started. You need an adapter, a curated set of tags, and the relationships that matter for one problem. That work is not wasted. It is the first real piece of the foundation.


Expect results in weeks, priced like a subscription. The core cloud workspace is on the order of US$1,000 a month. The connector is a one-time install of about US$1,200. Our integration time is real but small in the grand scheme of things. Compare that to the proposals you have seen for other AI projects recently.


The companies that get better fastest will not be the ones with the biggest data architecture. They will be the ones who stayed focused on the problem and let the foundation grow underneath it.


We are lining up proof-of-concept projects with a handful of customers now. If you have a toothache and a SCADA system, we would like to talk.


Solving operational challenges in ways others have only imagined.



Links and Resources

Find out more about Thred here: https://www.thredcloud.com/

Ignition is made and sold by Inductive Automation: https://inductiveautomation.com/




 
 
 

Comments


bottom of page