Alarms that survive a real operations week.

The problem

Single-threshold alarms on raw SCADA tags generate noise. Vendor portals each speak a different alarm vocabulary; the on-call ends up filtering email rules to survive. Real failures get lost in the storm of "gearbox temperature high" alarms that are seasonal and expected.

How WindTwin solves it

• Multi-condition rules — combine signals with AND / OR and time windows. "Gearbox temp > 75 °C AND oil-particle count rising AND vibration above baseline for > 15 minutes".
• Baseline-aware thresholds — compare against the same hour last week, same wind-speed bin, same ambient temperature, so seasonality stops triggering pages.
• OEM tag normalisation — a rule once, applied across Vestas, Siemens Gamesa, GE, and the rest. No re-writing per portfolio.
• Severity routing — critical alarms page on-call; warnings batch into a daily digest; info-level events land in the timeline only.
• Branded email and webhook delivery — to your team, to your CMMS, to PagerDuty / Opsgenie / Slack.
• Acknowledge, snooze, escalate from the alarm itself, with full audit.

How it works

1. You author rules in plain language using a structured editor — no DSL to learn.
2. WindTwin evaluates rules continuously against the live telemetry stream and historic baselines.
3. On a match, the alarm fires with full context: which turbine, which signals, what the rule said, what the values were.
4. Routing kicks in based on severity, time of day, and on-call schedule.

What you can do with it

• Quiet your on-call queue without missing real events.
• Catch the precursor pattern to a gearbox failure two weeks before the OEM alarm fires.
• Hold every alarm to the same standard across every farm — including the ones the OEM only gives you a portal for.