Short answer: a useful furnace alarm identifies a condition that requires a defined human or system response. Give it a clear threshold or rule, persistence/debounce, severity, recipient, acknowledgement path and enough context to act without opening three other screens.
Alarm fatigue begins when every brief fluctuation becomes urgent. Operators learn that the safest way to work is to silence the system, while important exceptions are buried among nuisance messages.
Separate conditions by purpose
- Absolute limits: a channel is above or below an agreed boundary.
- Cross-channel deviation: one point departs from a relevant group by a configured amount.
- Rate or frozen-value rules: movement is implausibly fast, slow or absent for the process state.
- Data-quality events: open input, invalid measurement, missing timestamp or communication failure.
- System-health events: local storage, power, time synchronisation or forwarding needs attention.
These are different signals and should not all arrive with the same severity. A disconnected remote dashboard is not automatically a furnace-temperature emergency if local recording remains healthy.
Design one alarm as a complete object
| Element | Example design question |
|---|---|
| Rule and context | Does the threshold apply during ramp, soak, cooling or every state? |
| Persistence | How long must the condition exist before it is actionable? |
| Severity | Information, warning, urgent process attention or system fault? |
| Message | Which furnace, channel, value, rule, time and batch should be visible? |
| Routing | HMI, audible/local annunciation, email, SMS, WhatsApp, dashboard or data-side relay? |
| Closure | Who acknowledges it, and is return-to-normal recorded separately? |
Use deviation logic carefully
If eight work-zone channels are near 975 °C and a ninth falls sharply, a configured deviation rule can highlight that exception. It cannot, by itself, prove reversed polarity, a failed sensor or a genuine cold spot. The message should say what was observed and preserve the evidence for diagnosis.
Commission with scenarios, not only setpoints
- Simulate a short spike and confirm it is filtered or classified as intended.
- Hold an abnormal value long enough to cross persistence and verify escalation.
- Remove WAN connectivity and confirm local logging health is distinguished from remote-view failure.
- Check acknowledgement, return-to-normal and event-history timestamps.
- Review alarm volume after real operation and tune under change control.
Messaging channels depend on plant IT, telecommunications availability and the project scope. Pyrolog can support the chosen path without promising that every channel belongs in every system.