Structured Trend Views and Runtime Statistics in Industrial HMIs

Why Live Gauges Are Not Enough

Live values only explain the current moment, while overloads, recoveries, and communication faults are time-dependent events

The baseline DCS HMI material requires dashboards, alarms, trends, diagnostics, maintenance tools, and alarm history because a machine cannot be understood through live gauges alone. A live speed or torque value may be useful in the moment, but it says very little about what led up to that condition, whether the machine was stable five minutes earlier, whether a recovery action already happened, or whether a communication fault briefly distorted the view before the operator noticed anything.

That is why diagnostic HMIs differ from decorative dashboards. Decorative dashboards emphasize the current display surface. Diagnostic HMIs preserve the context needed to explain process disturbances, operator actions, state transitions, and recovery outcomes after they happen. In a solids-handling platform, overload signatures are temporal, stabilization success is temporal, and shift review is temporal. Without retained history, the machine can still look modern while remaining weak as an engineering instrument.

Trend Views As Diagnostic Instruments

Trend views become useful when they align process variables on one time base and preserve when the data was incomplete or degraded

The baseline requires real-time trend overlays with time-synchronized plotting, pan, zoom, and multi-variable plotting. The amendment then formalizes broader trend views for key process variables over selectable windows such as 1 minute, 10 minutes, 1 hour, 8 hours, and 24 hours. That combination matters because the point of a trend screen is not only to show movement. It is to make behavior interpretable across operator, maintenance, and engineering time scales.

Runtime Statistics And Operational Counters

Runtime counters are valuable because many reliability and maintenance problems appear as repetition over time rather than as one dramatic event

The HMI master features already include maintenance counters such as bowl hours, scroll hours, pump hours, and service reset actions. The amendment expands that model with runtime by operating state, start and stop counts, cleanout counts, heavy-load entries, fault counts, communication-loss counts, maintenance counters, software version, network health, service-note entry areas, and selected performance statistics. That is a strong diagnostics architecture because it captures both immediate events and longer operating patterns.

These counters are useful precisely because they are not momentary. A single healthy dashboard state does not tell you whether the machine has entered heavy-load recovery ten times during the shift, whether communication loss has become more common after a network change, or whether mode time is drifting toward an unexpected operating pattern. Runtime statistics make those patterns reviewable.

• Runtime by mode Helps explain whether the machine spends most of its time in Run, Cleanout, Heavy Load, Recovery, or shutdown-related states.
• Starts, stops, and cleanout counts Support commissioning review, operator workflow analysis, and maintenance planning.
• Heavy-load and recovery entries Reveal whether a process recipe or operating condition is repeatedly pushing the machine toward protective behavior.
• Communication-loss and fault counts Show whether the reliability problem is mechanical, process-related, or rooted in communications quality.
• Maintenance counters, software version, and service notes Preserve accountability and make the review package more meaningful than process values alone.

Event And Alarm Correlation

An alarm without surrounding process context is only partial evidence

The baseline requires filtered alarm screens, accessible alarm history, timestamps, deliberate acknowledgement, event search, and CSV export. The amendment adds source device, alarm class, latched or reset state, operator acknowledgement, active recipe, active state, and drive-oriented filtering. That is the right model because the event list becomes much more useful when it is correlated with what the process was doing around the same time.

For example, a torque warning is more meaningful when it is placed beside differential changes, feed reduction, communication status, and state transitions into Heavy Load or Recovery. A communication-loss event is more meaningful when it shows whether the machine was in nominal run or already inside a recovery sequence. The HMI should not treat alarms as detached messages. It should treat them as evidence inside a larger machine narrative.

Recovery Review And Process-Control Tuning

Trend and event history should help answer whether the recovery path actually worked

The process-control cluster in the controls branch argues that differential speed, torque-limiting recovery, and feed-control stabilization are all coordinated transport decisions. Trend views and runtime statistics become the review layer for those decisions. They make it possible to ask whether the differential adjustment reduced load, whether feed restoration was too fast, whether torque stabilized for long enough, and whether shutdown escalation was justified by the evidence rather than by operator impression.

• Differential-speed review Trend overlays can show whether relative-speed changes widened transport margin or only produced temporary relief.
• Torque-limiting recovery review Correlated history can show whether recovery entered early enough, whether dwell periods were long enough, and whether repeated mitigation was masking a deeper instability.
• Feed-restoration review Runtime history can show whether returning inflow too quickly recreated the same overload condition that recovery had just relieved.
• Shutdown-justification review Alarm and trend correlation helps determine whether shutdown consequence was necessary or whether a narrower but still safe recovery path might have remained available.

Operator And Engineering Workflows

The HMI review surface should support shift review, troubleshooting, commissioning, and export without forcing each audience into the same screen path

The amendment adds operator-friendly filtering by drive, severity, time range, and operating state, along with export actions for alarm history, selected trends, maintenance counters, and diagnostic snapshots. That is a practical workflow design because different review tasks ask different questions. Shift review wants to know what changed during the last run. Maintenance wants fault and communication patterns. Commissioning wants to compare state transitions, counters, and alarms against expected behavior. Engineering wants a tighter exportable evidence package.

A strong industrial HMI should make those review tasks easier without pretending every user wants the same depth on every screen. That means filtered views, one-click drill-down from drive status into diagnostics, and preserved context like active mode, active recipe, and communication health in the global header or in the export package itself.

Data Quality And Trust

The HMI should never hide stale, missing, or uncertain data because review quality depends on knowing what evidence is incomplete

The communication-watchdog article argues that runtime legitimacy depends on distinguishing healthy from degraded communication and fresh from stale data. That same principle applies to trend and history review. A trend line that silently bridges over missing samples, a counter that does not indicate communication-loss gaps, or a diagnostic view that hides retention limits makes the history look more certain than it actually is.

The DCS source set already supports a more honest model. The amendment adds communication-loss counters, communication health in the global header, retention-status awareness, record-count summaries, and exportable diagnostic snapshots. Those are useful because they help preserve diagnostics truthfulness instead of cleaning uncertainty away.

• Stale data and communication gaps Review surfaces should make degraded periods visible instead of letting them look like calm operation.
• Invalid sensor readings and missing samples The HMI should not imply confidence that the instrumentation did not actually support.
• Retention limits Operators and engineers need to know whether the history being reviewed is complete or already truncated by local storage policy.
• Timestamp consistency Correlation only works when event, alarm, and trend timing remain coherent enough to interpret one another.

Engineering Tradeoffs

Trend systems and runtime statistics have to balance diagnostics depth, operator clarity, and practical retention limits

• Data retention versus storage More history is valuable only while the system still preserves performance and clear retention boundaries.
• Trend density versus readability More variables can help correlation, but too many lines at once can make the screen less useful during actual troubleshooting.
• Operator simplicity versus engineering depth Operators need practical review paths, while engineering still needs enough retained evidence for serious analysis.
• Polling rate versus historian resolution Not every variable needs the same retention density, and the review surface should acknowledge that.
• Local-only logs versus future remote observability The HMI can preserve strong local review value without claiming that future remote integrations already exist.
• Exportability versus cybersecurity concerns Export workflows are useful, but they still need deliberate control rather than becoming a blind data-dump mechanism.

Related System Case Study

The Decanter Control System shows why retained trends and runtime counters belong inside the operator-facing architecture

The Decanter Control System case study provides the applied context where alarms, trends, runtime counters, maintenance tools, recovery history, and communication events all need to remain attributable across multiple drives and multiple operating states. That context is why review-oriented HMI design is part of the control architecture rather than a reporting afterthought.

Related Engineering References

These controls and notebook references extend trend review into runtime visibility, communications trust, process-control recovery, and operator-facing diagnostics

Engineering Conclusions

Trend screens and runtime statistics matter when they make machine behavior reviewable instead of merely more visual

The DCS source set treats trend views, alarm history, maintenance counters, export packages, and runtime statistics as part of the HMI architecture because control behavior needs to be reviewed after it happens. Live gauges remain useful for immediate awareness, but retained trends, correlated events, counters, and explicit data-quality context are what make the system more valuable to operators, maintenance personnel, and engineers over time.

That is the main design lesson here. A strong industrial HMI does not only display current values attractively. It preserves enough structured history to explain recovery outcomes, communication faults, process instability, and maintenance patterns without pretending that missing or degraded evidence was cleaner than it really was.