Asset-Health Fusion to Work Order: A Build Playbook for Utility Reliability Teams
Asset-Health Fusion to Work Order: A Build Playbook for Utility Reliability Teams
Start at the substation. A transformer is telling you it’s aging in four different languages at once: an online monitor reports rising vibration, the annual dissolved-gas sample shows a creeping acetylene trend, the loading history says it’s been run hot through two summers, and a lineworker’s hand-typed note from a routine patrol mentions “oil weeping at the bushing.” Each signal is real. Each lives in a separate system — the condition-monitoring platform, the lab’s spreadsheet, the historian, the inspection app — and none of those systems talk. So nobody puts the four together until the unit fails on a July peak and you’re explaining a multi-feeder outage to a regulator.
This is the build document for the team that has to stop that from happening: the asset-analytics lead, the OT/reliability engineer, the person who owns the question which of our 40,000 distributed assets is actually about to fail, and what do we do about it this week. It is not a strategy memo. It is a reference design for the pipeline that fuses those four signals into one defensible asset-health score, turns that score into a crew-schedulable work order, and — the part most demos skip — does it without rolling a truck for a sensor glitch or sleeping through a slow degradation that ends in a catastrophic failure.
The fusion problem: four signals, four silos, one asset
The reason condition-based maintenance underdelivers is rarely the model. It is that the inputs never arrive in the same place at the same resolution. A health score worth scheduling crews against has to reconcile four signal families that disagree about almost everything:
- Sensor telemetry — vibration, partial-discharge, dissolved-gas, temperature — continuous, numeric, high-volume, but only on the minority of assets that are instrumented.
- SCADA / operational state — loading, fault counts, switching events, ambient stress — the duty cycle that explains why an asset is aging, not just that it is.
- Inspection observations — free-text patrol notes, photos, thermography findings — sparse, irregular, and the richest early warning you own, locked in prose a numeric model can’t read.
- Maintenance history — rebuild dates, prior failures, warranty status, manufacturer recalls — the slow-moving prior that should anchor every score.
The trap is letting one family dominate. Score only on instrumented sensors and you’re blind on the 80% of the fleet with no monitor. Score only on inspection cadence and you miss the fault that develops between annual patrols. The asset that fails is usually the one where three weak signals agreed and no single system was alarmed. Fusion is the product. Everything downstream — the work order, the escalation, the false-alarm control — depends on getting heterogeneous, differently-clocked, differently-trustworthy signals into one comparable score. And that fused score is the asset a competitor can’t buy off a vendor: a foundation model can read a transformer manual, but it can’t reproduce the degradation patterns of your asset classes under your loading and your climate. That tuned judgment is what compounds, versioned in the scoring layer instead of stranded in a veteran planner’s intuition.
Architecture: ingest, normalize, score, weight by consequence
The pipeline is four stages with a hard rule at the boundary — the scoring layer reads from the authoritative systems and writes only proposed work orders back, never corrupting the record.
The mechanic worth engineering is the per-asset feature record keyed on the EAM asset ID — the join key every source already shares. Numeric telemetry is aggregated into trend features (slope, time-above-threshold, rate-of-change). Inspection prose is run through a language model that extracts structured findings — “oil weeping at bushing” becomes a seal_integrity flag with a severity and a source citation back to the note — so a qualitative observation lands in the same feature vector as the dissolved-gas trend. SCADA gives the loading context that scales degradation. From that vector the engine produces two outputs, not one: a health index (how degraded is this asset now) and a failure probability over a horizon (how likely is it to fail in the next 90 / 180 / 365 days).
Health and probability are necessary but not sufficient. A failing pole-top fuse on a redundant rural lateral and a failing transformer feeding a dialysis clinic can carry the same probability and could not matter less alike. So the engine multiplies failure probability by a consequence weight built from what the asset actually serves:
RULE AssetWorkPriority
score = failure_probability(asset) * consequence(asset)
WHERE consequence(asset) = w1 * customers_served
+ w2 * critical_load_flag // hospital, water, telco
+ w3 * replacement_lead_weeks // long-lead = act early
+ w4 * safety_exposure // public / worker risk
WHEN critical_load_flag AND failure_probability >= 0.20
THEN consequence_tier = "high" AND require_engineer_review = true
WHEN signal_count < 2 OR max_signal_confidence < 0.6
THEN suppress_work_order = true AND reason = "insufficient_corroboration"The weights are yours; the structure isn’t optional. A queue ranked by raw condition sends crews to the worst-looking oil sample. A queue ranked by probability × consequence sends them to the asset whose failure would hurt the most people — which is a different list, and the right one.
From score to work order: auto-schedule the routine, escalate the consequential
A score that just lights up a dashboard changes nothing. The pipeline’s job is to emit a work order and decide who gets to approve it — and that decision is the governed gate at the center of this whole design. Authority is earned per action class, never granted globally.
- 01Detectflag anomalous trend across fused signals
- 02Scorehealth + failure probability per asset
- 03Weightmultiply by consequence, assign tier
- 04Draftgenerate work order with recommended task
- 05Routehigh-consequence → engineer review (the gate)
- 06Schedulelow-consequence routine work auto-booked into EAM
The split is the safety architecture. A low-consequence, well-corroborated finding — a recloser due for a routine service, a non-critical asset trending toward its inspection window — is auto-scheduled: the engine writes a work order straight into the EAM at routine priority, and a human sees it only as a line on the weekly crew plan. A high-consequence finding — anything touching a critical load, a long-lead replacement, or public-safety exposure — is escalated: it goes to a reliability engineer’s review queue with the full evidence bundle attached (the contributing signals, the trend charts, the inspection note it cited), and no crew is dispatched until that engineer accepts, modifies, or defers it. The engine never autonomously commits a high-consequence intervention. That gate does not move, and that is the correct design — the cost of being wrong on a critical asset is not symmetric with the cost of an extra review click.
Every order the engine produces is a persisted, replayable event, so the morning after you can answer what did we propose, what got auto-scheduled, what an engineer changed, and why:
{
"eventType": "AssetWorkOrderProposed",
"eventVersion": "2.0",
"assetId": "XFMR-4471",
"assetClass": "power_transformer",
"healthIndex": 38,
"failureProbability90d": 0.22,
"consequenceScore": 86,
"consequenceTier": "high",
"contributingSignals": ["vibration_trend", "dga_acetylene", "loading_history", "inspection_note:seal_integrity"],
"signalConfidence": 0.81,
"recommendedTask": "Bushing inspection + oil sample, schedule outage window",
"routing": "engineer_review",
"engineerDecision": "accept_modified",
"engineerNote": "Advance to this week; clinic on FDR-11A, no redundancy until tie rebuilt",
"policyVersion": "energy.asset-health.v4",
"modelVersion": "health-fusion-3.2.0",
"correlationId": "ah-58812-c4",
"evaluatedAt": "2026-02-24T14:09:55Z"
}Three fields here are load-bearing and missing from most “AI for maintenance” pitches: contributingSignals makes the score explainable — an engineer can see it was four signals agreeing, not one noisy sensor; signalConfidence makes the engine’s certainty inspectable; and engineerNote turns a human’s modification into recorded evidence instead of an untraced override. The same record persists to a queryable store:
CREATE TABLE asset_work_order (
order_id TEXT PRIMARY KEY,
asset_id TEXT NOT NULL,
asset_class TEXT NOT NULL,
health_index NUMERIC(5,2) NOT NULL,
failure_prob_90d NUMERIC(4,3) NOT NULL,
consequence_score NUMERIC(5,2) NOT NULL,
consequence_tier TEXT NOT NULL, -- low | medium | high
signal_confidence NUMERIC(3,2) NOT NULL,
contributing_signals TEXT[] NOT NULL, -- >= 2 required to emit
recommended_task TEXT NOT NULL,
routing TEXT NOT NULL, -- auto_schedule | engineer_review
engineer_decision TEXT, -- accept | accept_modified | defer | reject
policy_version TEXT NOT NULL,
evaluated_at TIMESTAMPTZ NOT NULL,
correlation_id TEXT NOT NULL
);
CREATE INDEX idx_ao_triage ON asset_work_order(consequence_tier, failure_prob_90d DESC, evaluated_at DESC);False alarms are the failure mode — suppress them by design
A condition-monitoring program dies the day crews stop trusting it. Roll three trucks for nothing and the fourth real alarm gets ignored. So false-alarm suppression isn’t a tuning afterthought; it’s a first-class part of the scoring contract. Three controls do most of the work:
- Multi-signal corroboration. No work order emits on a single signal. The
signal_count < 2suppression in the rule above is the floor — a lone vibration spike with nothing in the gas, loading, or inspection record to back it up is logged as a watch item, not a dispatch. The failures worth chasing announce themselves in more than one language. - Persistence windows. A threshold crossing must hold across a defined window before it scores, filtering the transient sensor dropout, the calibration blip, the single bad reading. Degradation that’s real is degradation that persists.
- Confidence thresholds with abstain. Every score carries a confidence; below the band, the engine abstains — it widens the asset’s next inspection rather than generating a dispatch on a guess. Abstaining is a valid, logged output, not a gap.
The cost asymmetry runs the other way too, and the design has to respect both edges. A suppressed real degradation is far more expensive than a suppressed false alarm — a missed slow fault is the catastrophic failure this whole system exists to prevent. So suppression never deletes a signal; it down-tiers it into a monitored watch list with a tightened re-evaluation cadence. The two failure modes — crying wolf and sleeping through it — get traded off explicitly, per asset class, and the trade-off is a number an engineer owns, not a hidden default.
Closing the loop: every outcome is a training label
The model that ships is the worst model you’ll run. What makes it sharpen is that this is a closed loop, not a one-way scoring feed. Three outcome events flow back as labels:
- A confirmed failure stamps every signal that preceded it as a true positive — the strongest label you can get, and the most expensive to earn.
- An inspection outcome that found the asset healthy after a dispatch is a labeled false positive; one that confirmed the predicted degradation is a true positive caught in time.
- A deferred order that later failed is the costliest label of all and the one that must re-weight the consequence model hardest.
These outcomes write back into the feature store as labels and re-train the fusion model on a governed cadence — never silently. A model version is pinned in every event (modelVersion above), so a re-train is a reviewable, rollback-able release, not a drift you discover in a hearing. The payoff is specific to operating one fleet for years: the engine learns your assets’ failure signatures, so its precision climbs on exactly the equipment you own while a vendor’s generic model stays generic.
Integration: the EAM stays authoritative
The fastest way to kill adoption is to make crews work in a new tool. They live in the EAM and the work-management system, and those stay authoritative for asset master data, work history, and scheduling. The fusion layer integrates as a producer of proposed work orders, not a replacement. The contract is narrow on purpose:
Two integration disciplines keep this governable. The write-back is idempotent and traceable — a proposed order carries the correlationId so a re-run never double-books a crew, and an engineer in the EAM can click from any work order back to the evidence that generated it. And the heavy scoring runs inside your OT boundary: tens of thousands of telemetry features evaluated continuously is exactly the workload you don’t ship to a metered external API, both for the data sensitivity and because you’d pay a per-call tax on millions of routine evaluations. External models earn their place only on the open-ended slice — summarizing an inspection narrative — not the high-frequency scoring.
A decision that schedules a crew or holds back a critical-asset call needs unambiguous owners. The engine proposes; named humans stay accountable.
| Role | RACI | Responsibility |
|---|---|---|
| Reliability / Asset Engineering Lead | A | Owns consequence weights, escalation policy, model-release sign-off |
| Reliability Engineer (on rotation) | R | Reviews high-consequence orders; accepts, modifies, or defers with note |
| Asset-Analytics / Data Engineer | R | Owns the fusion pipeline, feature store, and false-alarm thresholds |
| Maintenance Planner | R | Schedules auto-booked and accepted orders into crew capacity |
| OT Security | C | Enforces read-only source access and OT-boundary scoring |
| Compliance / Regulatory | C | Audits the order-and-override trail and reliability reporting |
Runbook: standing up monitoring for a new asset class
Bringing a new asset class online — say, going from transformers to underground cable, or adding reclosers — is a repeatable sequence, not a rebuild. The first class carries the platform cost; each one after reuses it.
- Weeks 1–4 — map the signalsInventory every source that touches the new class and confirm the EAM asset ID is the shared join key. Define the trend features, the inspection-text findings to extract, and the staleness budget per signal. Set the corroboration floor and persistence window for this class.
- Weeks 5–10 — score in shadowRun health + failure-probability scoring in shadow against history; backtest against known past failures for this class to baseline precision and the false-alarm rate. Tune consequence weights with the asset engineer. No work orders emitted yet.
- Weeks 11–16 — emit behind the gateTurn on work-order generation with full evidence logging. Route everything — even low-consequence — to engineer review at first; relax to auto-schedule for low-consequence only once the false-alarm rate clears the bar. High-consequence stays gated permanently.
- Ongoing — close the loopWeekly: false-alarm rate, suppressed-watch promotions, override reasons. Monthly: reliability/cost/risk KPIs. Quarterly: re-train on accumulated outcome labels and re-tune consequence weights.
The KPIs that tell you it’s working are specific to a maintenance program, not a generic dashboard — track them as a before/after, calibrated to your fleet:
- False-dispatch rate (trucks rolled, nothing found)15–40%3–10%Cost / trust
- In-service failures of monitored assets2–7%1–3%Reliability / risk
- Lead time before failure (warning horizon)daysweeks–monthsResilience
- Reactive vs. planned maintenance mix40–60% reactive15–30% reactiveCost / crew efficiency
- Engineer review time per high-consequence order30–90 min5–20 minThroughput
What we covered
The goal was never an autonomous maintenance program. It is a reliability team that finds the aging transformer in four weeks instead of finding it in the outage report — because for the first time, the four systems that each knew something finally agreed in one score a crew could act on.
References: IEEE C57.104 (transformer DGA interpretation) · ISO 55000 (asset management) · IEEE 1366 (SAIDI/SAIFI) · condition-based maintenance practice · OT/IT segmentation · NIST AI RMF · NIST CSF 2.0 · CISA Secure by Design.