Short answer: multi-furnace monitoring should centralise visibility without making every furnace dependent on one network or server. Keep acquisition and safe local recording close to each furnace; aggregate normalised status, history, alarms and reports into a supervisory layer.
The goal is not a wall of miniature HMIs. A Heat Treatment HOD usually needs to see which furnaces are running, which batch or stage each is in, whether data is healthy, and which exception deserves attention.
Use three clear layers
| Layer | Responsibility | Failure principle |
|---|---|---|
| Furnace / edge | Acquire channels, timestamp, buffer/store locally, expose health | A central outage must not erase the current furnace record |
| Plant data layer | Collect, normalise identities, index history, coordinate forwarding | Retries must not create duplicate or reordered records |
| Supervisory view | Fleet status, exceptions, trends, retrieval and report access | A display fault must be distinguishable from a measurement fault |
Normalise meaning before building the dashboard
Furnace 1 may call a state “Soak”, Furnace 2 “Hold” and Furnace 3 expose only a recipe step number. Channel names, batch identifiers, timestamps and alarm severities may also differ. Build a small shared information model so the overview compares like with like while preserving source-specific detail.
Plan store-and-forward behaviour
- Give every source record a stable identity or sequence.
- Buffer locally when LAN/cloud connectivity is unavailable.
- Forward after recovery without replacing newer data or duplicating history.
- Expose backlog and last-success timestamps as system-health information.
- Test long outages, clock changes and central-server restarts.
Time synchronisation needs explicit ownership. “All PCs show the same minute” is not enough when events across furnaces must be compared or a report needs a defensible sequence.
Design the first screen for exceptions
A useful overview can show furnace identity, current batch/stage, representative temperature or spread, recording health, last communication and unacknowledged event severity. The operator can drill into trends and channel detail; the overview should not present every number at once.
Make expansion repeatable
Adding a furnace should follow a documented onboarding pattern: source interface, identities, time, channel map, buffering, permissions, alarm mapping, report needs and acceptance test. Project-specific integration may still be required, but the next furnace should not become a new data silo.