How the Asset Health Cookbook Keeps Fleet Data Trustworthy
Overview: OEM trend limits assume every machine is standard, but mining fleets rarely are. When a monitoring system can't see how an asset is configured, it flags known differences as faults. MTS's Asset Health Cookbook gives analysts one governed place to define trend limits, event triage rules and asset-level exceptions. Deviation groups handle non-standard machines without duplicating rules, and every change flows into TET, EDI and downstream reports after the next refresh.
What Does “Normal” Look Like?
For an asset health team, that sounds like a simple question.
Is the engine temperature too high? Is boost pressure outside its expected range? Is an event significant enough to investigate? Is a machine behaving differently from the rest of the fleet?
But there is rarely a single answer.
Two machines with the same model number can behave differently because of their configuration, operating environment, component history, or modifications made over their lifetime.
That creates a problem that is easy to overlook: if the system doesn't understand what is different about an asset, it can mistake a known configuration difference for an abnormal condition.
This is where the Asset Health Cookbook comes in.
It is the configuration layer behind MTS's asset health reporting ecosystem: defining trend limits, event classifications, and asset-level exceptions and other operational rules defined once and then flow consistently into Trend Exception Tool (TET), Equipment Data Interface (EDI), and every downstream reports and dashboards mine sites rely on.
It isn't the part of the system most people see, but it is one of the parts that makes everything else more trustworthy.
The Problem With “Standard” Thresholds
The OEMs provide standard trend limits to help identify when a parameter has moved outside its expected range.
That makes sense as a starting point.
But a mining fleet is rarely operating in a perfectly standard environment. A machine may have:
Different altitude arrangements that affect engine behaviour.
An different engine boost profile.
A non-standard component installed during a rebuild.
Site-specific operating conditions.
A configuration that has evolved over the life of the asset.
None of that is a data quality problem - it's a configuration gap. But if the underlying system has no way to capture it, it looks like bad data: alerts firing when they shouldn't, dashboards flagging "abnormal" behaviour that's actually just unaccounted-for variance.
This is the gap the Asset Health Cookbook is built to close.
The Solution: What Does the Cookbook Actually Do?
At its core, the Cookbook is an easy-to-access web-based tool that provides a governed classification and configuration layer covering large equipment events, small equipment events and large equipment trends.
Instead of embedding this logic across multiple reports and systems, analysts define it once.
1. Define What “Normal” Looks Like
For large equipment trends, analysts can configure threshold levels, site-specific naming, and how channels are prioritised for display. The important part isn't just the threshold itself. It's that the definition of the threshold has a single home. Change it once, and downstream consumers inherit the change.
Large Equipment Trends - threshold configuration by asset class group
2. Handle the Machines That Don't Fit the Standard
This is where Trend Deviation Groups become particularly useful.
Imagine a fleet where most machines use the standard trend configuration, but a small number have a different configuration.
The traditional approach might be to create a completely separate configuration for those machines. That works - until the fleet grows.
Instead, the Cookbook allows analysts to create a deviation group, identify only the trend channels that differ, and assign the relevant assets to that group. Everything else continues to inherit the standard configuration.
In other words: Override only what is different. Keep everything else standard.
It's a simple idea, but an important one for scalable configuration management. You don't duplicate the entire rule set because three machines are different. You capture the difference.
Trend Group Deviations - an “MA2 Brake Package” trend deviation group
3. Add Context Around the Asset
A trend doesn't exist in isolation. Understanding an asset's history can be just as important as understanding its current readings.
The Cookbook therefore also provides configuration and historical context such as: component change-out history, physical asset configuration such as payload targets and speed limits, component software versions, historical weigh scale study information over the life of the asset.
This additional context helps downstream systems interpret asset behaviour with a better understanding of what has actually happened to the machine.
Asset Configuration - SAP linkage, SMU measuring point, KPI flags and Trend deviation group assignment
4. Turn Events Into Meaningful Information
Not every event deserves the same level of attention.
The Cookbook allows analysts to configure how health events are interpreted such as event severity, descriptions, categories, component mapping and site-specific triage rules.
Large Equipment Events - event classification and Triage rules (averaging period, event count, avg. duration, auto push to Trakka)
Triage rules introduce more meaningful context around an event; rather than simply asking whether an event occurred, a site can define significance based on factors such as how frequently the event occurred, the average duration, and whether it warrants an automatic escalation into the maintenance workflow.
That moves the conversation from “Did something happen?” to “Is this something we should care about?”
And that distinction matters when you're monitoring thousands of events across a mining fleet.
Why Does This Matter?
The interesting thing about the Cookbook is that most people will never see it.
A maintenance engineer looking at an Asset Health dashboard doesn't see the configuration behind the visual.
An analyst looking at TET doesn't necessarily see where a threshold came from.
A stakeholder reviewing a report simply sees the result.
And that's exactly how it should be. The configuration layer is doing its job quietly in the background.
From a BI architecture perspective, the Cookbook enforces a separation that's easy to skip under project pressure but expensive to retrofit later: Configuration of "normal" is kept separate from the presentation of "is this normal."
Trend limits, event classifications, and asset-specific exceptions live in a governed configuration layer. TET, EDI, and the reporting suite consume that layer rather than encoding their own copies of the logic.
The payoff shows up in three places:
Change it once. If a threshold needs to change, analysts update the configuration rather than searching through individual dashboards, measures or reports. After the scheduled refresh, downstream systems inherit the new definition.
Reduce false positives. Known variations can be captured through deviation groups instead of being treated as unexpected behaviour. That means fewer alerts caused simply by applying the wrong configuration to the wrong machine.
Improve Auditability. When something looks wrong, there is a clear place to start. Instead of asking: “Which report has this rule hardcoded?” you can ask: “What configuration is this asset using?” That is a much easier problem to solve.
Summary
The Asset Health Cookbook demonstrates a principle that applies well beyond asset health reporting: even the most beautiful visual can still produce the wrong conclusion if the configuration behind it doesn't reflect the asset.
By giving analysts a structured way to redefine trend limits, isolate non-standard equipment through deviation groups, and classify health events using site-specific triage logic, MTS keeps the of "what counts as abnormal" in one governed place, allowing every downstream report and tool to consistently inherit the right configuration.
Ultimately, the Cookbook helps turn complex, asset-specific knowledge into consistent, trustworthy data that people can act on.
Frequently Asked Questions
-
The Asset Health Cookbook is MTS's web-based configuration tool that defines what "normal" looks like for mining equipment. Analysts set trend limits, event classifications and asset-level exceptions once. Those rules then flow into the Trend Exception Tool (TET), the Equipment Data Interface (EDI) and every asset health report and dashboard that depends on them.
-
OEM trend limits assume a standard machine, but many mining assets aren't standard. An altitude arrangement, a different engine boost profile, a non-standard component fitted during a rebuild or site conditions can all shift normal readings. If the monitoring system doesn't know about those differences, it flags them as abnormal. MTS's Asset Health Cookbook records them, so alerts reflect the real configuration.
-
Use a deviation group. In MTS's Asset Health Cookbook, analysts create a group, change only the trend channels that differ and assign the affected machines to it. Every other channel still inherits the standard fleet configuration. If three trucks have a different brake package, you capture those differences instead of maintaining a second full rule set.
-
You can, but it gets hard to manage as reporting grows. When the same threshold is built into several reports, changing it means finding every copy. MTS keeps trend limits and event rules in the Asset Health Cookbook instead. Analysts change a threshold once, and the Trend Exception Tool, Equipment Data Interface and reports pick it up after the next scheduled refresh.
-
Set triage rules based on how often an event happens, how long it lasts on average and whether it should escalate automatically. In MTS's Asset Health Cookbook, each site defines its own triage rules, so a one-off blip isn't treated like a repeating fault. Events that meet the rules can be pushed straight into the maintenance workflow.
