Every process engineer has been there. A lab sample comes back out of spec, and now you're working backwards through twelve hours of data trying to figure out what went wrong. The investigation eventually finds something. Maybe a feed shift, a heat exchanger drift, a utility upset. By then the batch is already off-spec and the conversation in the morning meeting is uncomfortable.
The goal isn't to investigate faster. It's to see the excursion coming. TrendMiner has the building blocks for predictive analytics in the standard toolkit, no ML Hub required. The workflow below turns one investigation into a soft sensor that runs continuously and warns you before the next excursion lands. Customers like Bayer (a 10% production capacity increase), Kuraray (30 hours of unscheduled downtime prevented) and CP Kelco (potential savings above $1M per year from process deviation reduction) have all turned this kind of analytical work into measurable operational outcomes.
The path from excursion to soft sensor
The workflow has two phases. First, an investigation that explains a past excursion. Then, the model from that investigation gets promoted into a continuous monitor. The investigation phase is the heavy thinking. The monitoring phase is mostly configuration.
| Phase | Step | Tool |
|---|---|---|
| Investigate | Define the question | Pre-work |
| Build a clean working view | TrendHub | |
| Filter out irrelevant periods | Value-Based Search | |
| Generate candidate tags | Cross-correlations | |
| Build the predictive model | Predictive Tags | |
| Validate behaviour and regimes | Scatter Plot, Event Analytics | |
| Monitor | Promote model to soft sensor | Formula tag, Monitor |
| Document for the next engineer | Investigation record |
A specialty chemicals plant runs a polymerisation line where the quality KPI has drifted toward the upper spec limit several times over recent months. The team suspects feed quality, a new catalyst batch, or a recently rebuilt heat exchanger. We'll walk this case through.
Investigate: define the question and clean the view
Before opening TrendHub, write one sentence. Target tag, time horizon, expected lag, periods to exclude. "Which feed, temperature, or utility tags predict the quality excursions over the last six months, allowing for lag up to 4 hours and excluding shutdowns?" That sentence saves you hours.
Then open TrendHub. Add the target tag first, then five or six candidates your process knowledge already suggests. Don't add thirty. TrendHub's diagnostic tools work against the active view, so a cluttered view produces cluttered diagnoses.
Investigate: filter the noise
Shutdowns, start-ups, grade transitions, sensor failures. Every plant has periods that don't represent normal operation, and every one of them will pollute your model. Use Value-Based Search to define the unwanted condition (production rate below threshold works for most cases), apply a minimum duration, save it as a filter. Two minutes of work, and the next steps run on data that actually represents your process. It's the unglamorous step that separates models you can trust from models that fire false alarms.
Investigate: generate the candidate list
Run Diagnose → Cross-correlations to find which indexed tags behave linearly like your target, with optional time lag. Set an upstream shift if lagged effects are plausible. The score tells you how strongly each candidate tracks the target. The optimal shift tells you the lead time, which is what you actually care about for prediction.
A high score means a candidate is worth investigating, not that it's a cause. Two tags that both follow the day/night cycle will correlate strongly without one driving the other. Treat the output as your shortlist for the model, not the answer.
In our example, this surfaces feed flow with a 2-hour lead and cooling water temperature with a 30-minute lead. The catalyst tag barely registers.
Investigate: build the predictive model
This is where TrendMiner earns the name. Open Tag Builder → Predictive Tags. Select your target, confirm the period, set the maximum upstream shift to match your desired warning window. Add candidates iteratively and watch combined accuracy climb, then plateau. The plateau tells you when adding tags stops helping.
A strong model gives you three things you didn't have before. The lead times tell you how far ahead you can warn. The candidate weights tell you which drivers matter most. And the formula itself becomes the soft sensor in the next phase.
If the model is weak, that's still useful. It means the target isn't driven by a simple linear combination, and you need to look at regimes (Scatter Plot) or aggregated periods (Event Analytics) before going to monitoring. Treat a weak first model as the start of the analysis, not the end.
Investigate: validate before you promote
Don't skip this. A model that fits the historical period beautifully can still fail in production if the underlying relationship shifts. Two checks save you from a noisy alarm later.
In Scatter Plot, plot the target against your strongest predictor and use Colour by Time. If the cloud shows a clean stable relationship, you're safe to promote. If you see drift or two separate clusters, you have a regime change. Investigate before you monitor, or your soft sensor will fire constantly during the regime your model wasn't trained on.
In Event Analytics, create event windows for the periods you care about (recent months, specific campaigns, batch IDs) and check whether your model's predictions separate good from bad target behaviour at the aggregated level. It's the difference between a model that explains the past and a model that warns about the future.
Monitor: promote the model to a continuous soft sensor
The investigation gave you a formula. Now make it run all the time. Create a Formula tag using your Predictive Tags output. This tag now produces a live prediction of your target, refreshed at every new data point, using the lagged inputs you identified.
Then attach a Monitor. Set thresholds at warning and excursion levels. The Monitor evaluates the formula tag continuously and alerts your team when the predicted target approaches spec. You're no longer investigating excursions after the fact. You're getting hours of warning, with the lead time defined by your slowest input lag.
In our example, the soft sensor predicts quality two hours ahead based on feed flow and cooling water. That's two hours of buffer to adjust setpoints or check upstream conditions before the lab confirms an excursion.
Document, or the next engineer redoes everything
This step gets skipped, and it shouldn't. Write a short record covering the target, the period investigated, the filters applied, the model drivers and shifts, the validation results, and the monitor configuration. Two paragraphs in a shared location is worth a folder of trend exports nobody can find again. When the soft sensor needs retuning in a year, future-you will thank present-you.
The shape of the work
The investigation phase is roughly a day spread across a few sessions. The monitoring phase is an afternoon. The payoff is continuous: every excursion the soft sensor catches early is one you didn't have to explain after the fact. And once one engineer in your team has done it once, the second one is faster because the pattern is the same regardless of which KPI you're predicting.
The engineers who consistently turn TrendMiner into predictive analytics aren't the ones who know the most features. They start from a real excursion, filter properly, treat cross-correlations as a shortlist, validate before they promote, and write down what they found. The workflow scales from one investigation to a portfolio of soft sensors, one quality KPI at a time.
Deeper reading: Cross-correlations, Predictive Tags, Scatter Plot, Event Analytics.