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 — a string that's slowly soiling differently from its neighbours, a junction box quietly heating up — get lost in the storm of "DC under-voltage" alarms that fire every dawn.

How SolarTwin solves it

• Multi-condition rules — combine signals with AND / OR and time windows. "String current > 5% below adjacent strings AND POA irradiance > 600 W/m² for > 30 minutes".
• Irradiance-conditioned thresholds — compare against the same irradiance bin, same time of year, same module temperature, so dawn/dusk transitions stop triggering pages.
• OEM tag normalisation — a rule once, applied across Huawei, Sungrow, SMA, Power Electronics, FIMER, Ingeteam. 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. SolarTwin evaluates rules continuously against the live telemetry stream and historic baselines.
3. On a match, the alarm fires with full context: which inverter or string, 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 string failure two weeks before the inverter alarm fires.
• Hold every alarm to the same standard across every plant — including the ones the OEM only gives you a portal for.