ThreadWare User Guide

Tag Analytics

The machine-learning module. It answers one question: "I think A, B and C affect D. Am I right, by how much, and how long does it take?" - and it will tell you bluntly when the answer is rubbish. No maths background needed.

You only see what you have been given access to

ThreadWare is built from modules - Sales, Production, Quality and so on. An administrator gives you a role in each module, for each company you work in. The menu is built from those roles. So if something in this guide is not in your menu, it has not been given to you yet. Ask your administrator, or log a support ticket. To see what you currently hold, click your initials in the top right and choose My Access & Roles.

Can I use it?

RoleWhat you can do
Tag Analytics Viewer Open saved models, results and forecasts. Read-only.
Tag Analytics Editor Create models, fit them, share them, and ask for driver screens. This is the role for somebody doing the analysis.
Tag Analytics Admin All of that, plus Model Health, fixing a tag's clock, and promoting a monitor out of shadow mode.

Holding a role in Instrument Graphs does not give you this. It is a separate module on purpose: looking at a chart and building a predictive model are different jobs.

If you have no role at all you will see: "You do not hold a Tag Analytics role in any company yet. An administrator grants it under Administration ▸ User Access."

What it actually does

Your instrument tags have been recording values every few seconds for months - speeds, temperatures, throughputs. Tag Analytics looks at that history, finds a pattern, and then - this is the part that matters - checks whether the pattern actually predicts anything on days it was not allowed to look at.

That last step is the whole point. It is easy to find a pattern in the past. Most of them are coincidences. This tool's main job is telling you which is which, and it will happily say "this model is useless" rather than dress up a coincidence as an insight.

It cannot tell you what causes what

If the model says line speed and throughput move together, that could mean speed drives throughput, or throughput drives speed, or both follow something else entirely. The tool finds relationships; you supply the engineering judgement about direction. It will never print the word "causes", and neither should you when quoting it.

The four pages

Menu ▸ Tag Analytics

PageWhat it is forWho
Model StudioBuild and fit models, read the results. Viewer reads, Editor builds
ForecastsWhat a measurement is likely to do next. Viewer and up
Fault RiskWhich faults may be coming. Viewer and up
Model HealthWhich tags are usable at all. Admin only

Step 1: check the tags are usable (Model Health)

Before building anything, an administrator should open Model Health, pick a date range and press Measure. You get a row per tag, and three columns decide whether that tag can be used.

ColumnWhat it means
Coverage Over the period you chose, what fraction of the time do we know this tag's value? It needs to be 60% or more.
Time basis Which clock this tag's timestamps use - local time, UTC, or Unknown.
Status Either "fit to model", or a plain-English reason why not.

Four tiles at the top count: tags in total, tags fit to model, tags below the coverage floor, and tags whose clock is unknown. There is also an Only show problems switch.

Coverage - the bit that confuses everyone

You see two numbers: a big one, and a smaller one labelled reported underneath.

These are different, and the gap is normal, not a fault. Most sensors only write when the value changes. A room temperature that sits at 21.4 degrees for an hour writes once, not twelve times - but we still know what it was for that whole hour. So the big number is much larger, and the big number is the one that counts.

Coverage only drops when a tag goes genuinely quiet for a long stretch - the machine was off, the sensor died, the network dropped. That is real missing data, and the tool refuses to invent it.

If a tag you expected shows 0%, it reported nothing at all in that period. Either it is broken or it has never been commissioned. That is a tag problem, not a Tag Analytics one - see the Instrument Tag setup guide.

Time basis - why some tags say "Unknown"

Different equipment sometimes records timestamps in local time and sometimes in UTC, which are two hours apart. Mix a local-time tag and a UTC tag in one model and the tool would "discover" a confident two-hour delay that does not exist.

So ThreadWare works out each tag's clock from its daily rhythm, and refuses any model that mixes tags on different or unknown clocks. An administrator can settle it by hand with the Declare SAST / Declare UTC buttons on the row.

Step 2: build a model (Model Studio)

On the left is your list of saved models with a + button to add one (Editors and Admins only). On the right are three tabs: Relate, Results and Forecast.

Start on Relate. There are five decisions.

Decision 1 - Model kind

KindUse when
Driven You think other measurements affect this one. The usual choice.
Self You only want to predict a measurement from its own past.
Event Your target is an on/off fault signal and you want to predict it happening. These are the models that appear on the Fault Risk page.

Decision 2 - Target tag

The measurement you want to explain or predict. Pick an instrument tag, or a derived tag if your administrator has set one up.

Decision 3 - Target form

Decision 4 - Drivers

The measurements you think move the target. Add each one, and for each you can set:

Do not know what to add? Press Suggest drivers. ThreadWare screens every eligible tag and lists the promising ones. Two things to understand about that list:

Decision 5 - Window and horizons

SettingWhat it means
Train from / Train to The stretch of history to learn from. At least 7 days. Pick a period the equipment was actually running normally.
Horizons How far ahead to predict, in minutes, separated by commas. The default 15,60,240,480 means 15 minutes, 1 hour, 4 hours and 8 hours.
Method Leave on Auto. ThreadWare tries several techniques and keeps whichever did best on data it had not seen.
Rolling-origin folds How many times to re-test on later and later slices of history. More is stricter.
Search budget (seconds) How long to spend hunting for the best settings.
Exclude stopped periods Leave this on. A stopped machine is not information about how it behaves when running.
Target is under closed-loop control Tick this if something automatically holds the target steady. It changes how the results are interpreted.

Then Save, then Fit. Fitting happens on the server, so you can leave the page and come back.

Step 3: read the results honestly

Start at the top. Always.

The first thing on the Results tab is a big green or red box. Read it before anything else.

Green - "Has skill" means the model genuinely predicts something on data it was never shown.

Red - "NO SKILL" means it does not. Not "a bit weak" - it means the model is no better than assuming nothing will change. Nothing further down the page is worth reading. Try different drivers, or accept that these ones do not explain your target.

Under the box are four small numbers:

ChipWhat it tells you
vs persistence Did the model beat simply guessing "it will stay the same"?
vs seasonal naive Did it beat guessing "same as this time yesterday"? Anything with a daily rhythm has to clear this bar.
drivers add The one to actually care about on a Driven model. See below.
R² out of time A general goodness-of-fit number. The least useful of the four.

"drivers add" - read this one twice

A model always knows the target's own recent history, because it needs that to predict a change from where it is now. On a slow-moving process, that alone earns a little apparent skill - even if your drivers are pure noise.

So ThreadWare also fits a version using only the target's own past, and reports the difference. That difference is drivers add, and it is the honest answer to "are my chosen drivers telling me anything the target's own history did not already?"

The four tiles

Method chosen - which technique won. If a simple one beat the machine learning, that is a good result, not a disappointment.

Rows against Effective n - this catches people out. Rows might say 25,000 and Effective n might say 400. That is not an error. Readings five minutes apart are nearly identical, so 25,000 of them are not 25,000 independent facts. Effective n is the real sample size, and it decides whether the numbers mean anything. If it is small, treat everything with caution.

The chart

Actual against predicted, over the most recent slice of history the model was never allowed to see while learning. Two extra lines show the two "dumb guess" benchmarks.

If the prediction tracks the actual better than the benchmarks do, the model is doing real work. If you cannot see a difference by eye, believe your eyes over the numbers.

The coefficients table

One row per driver, saying how much the target moves when that driver moves. Look at the last column first - "Reading":

Reading saysWhat to do
interpretable (green)You can trust this row's number.
not interpreted (orange) Do not quote this number. The reason is given underneath.

The three reasons you will see:

This is deliberate. The tool shows you the number and refuses to let you read it, rather than quietly hiding it.

The lag profile chart

How strongly each driver relates to the target at different delays. A negative delay means the driver moves first.

There are two lines per driver. The grey raw line is usually big and impressive. The green prewhitened line is the honest one - it is the raw relationship with "both things happen to drift together" removed.

Trust the green line. If green is much smaller than grey, most of what you were seeing was just two signals drifting through the day together. If the green peak sits at, say, minus 40 minutes, that is your answer to "how long does it take?".

Forecasts

Pick a model and see what the measurement is likely to do next.

A Stale badge on a model means reality has drifted away from what the model was trained on. Re-fit it.

If a forecast is empty, the page tells you which of four reasons applies: scoring is switched off, the model was never fitted, it was fitted before the scoring parts existed, or it simply has not run yet.

Fault Risk

Lists your Event models only, with a live scoring switch and a risk readout.

Why the number is not "accuracy"

Faults are rare. If a fault happens 2% of the time, a model that predicts "no fault, ever" is 98% accurate and completely useless. So ThreadWare reports average precision instead, which does not reward that trick.

No models yet? The page says: "No fault-prediction models yet. In Model Studio, create a model of kind Event whose target is the fault tag and whose drivers are the measurements meant to see it coming."

Fault risk does not alert anybody yet

Everything the scorer produces is currently in shadow mode: it is recorded and shown on this page, but it does not send anyone a message. Sending real alerts is a later step, and a model has to be promoted out of shadow mode by an administrator first. Do not rely on this page to warn you - go and look at it.

When it refuses - and what to do

ThreadWare refuses a fit rather than producing a bad one, and every refusal says why in plain words. A refusal is the tool working. A model fitted on 40% coverage would still produce confident-looking numbers - they would just be made up.

What you seeWhat it meansWhat to do
"Coverage 41% is below the 60% floor" That tag went quiet for too much of the period. Shorten the window to a period the equipment was running, or drop that tag.
"the selected tags are stamped on more than one timestamp basis" You mixed equipment using different clocks. Use tags from one source, or ask an administrator to settle the clock on Model Health.
"...features against an effective sample size of 150" Too many drivers, not enough independent history. Use fewer drivers, or a longer window.
"A Driven model needs at least one driver" You added none. Add one, or change the kind to Self.
"The training window is 3 days. At least 7 are needed" Window too short.Widen it.
"the longest horizon is more than a quarter of the training window" Predicting 8 hours ahead needs far more than a day of history. Shorten the horizons or lengthen the window.
The Fit button queues but nothing happens The background service that does the fitting is not running. Tell an administrator. Existing models and charts are unaffected.

Three traps worth knowing about

1. Temperature and humidity will always look strongly related, and it is mostly physics. Relative humidity is defined partly by temperature. Cool the air and it rises without a drop of moisture moving. You get a big relationship that tells you nothing about your process. If you are chasing moisture, ask an administrator to set up a derived tag such as dewpoint, absolute humidity or VPD. Those are what materials actually respond to.

2. Two drivers that move together cannot be told apart. Two sensors on the same shaft rise and fall as one. The model predicts fine; it just cannot tell you which of the two deserves the credit. Watch for the VIF flag in the Reading column.

3. Do not ask a model to justify a change you have already decided on. Try enough combinations and something will eventually look significant by luck. Write down what you expect before you fit, and treat a surprising result as a reason to go and look at the machine, not as proof.

Quick reference

If you want to...Do this
Check a tag can be modelledModel Health, press Measure, look at Coverage and Status.
Know if a model is any goodResults tab, read the green/red box. Stop there if it is red.
Know if your drivers matterThe drivers add chip. 0.05 or more.
Know how long an effect takesThe green line on the lag profile chart.
Quote a number to somebodyOnly if its Reading column says interpretable.
Predict a faultBuild an Event model, then watch Fault Risk.