Display call-up time is how long an HMI screen takes to appear and populate with live data after an operator requests it. Human-factors guidance for control-room displays commonly targets roughly one second, because navigation that feels instant keeps the operator focused on the process rather than on waiting. When call-up drags, the delay quietly erodes situational awareness at exactly the moments it matters most.
Display Call-Up Time in one line: Display call-up time is the delay between an operator asking for a display and that display being visible with current values. Guidance for operator HMIs commonly aims for about one second, because slow call-up interrupts an operator's train of thought and slows response during upsets. Fast call-up is a core performance requirement of a well-designed HMI.
The one-second guideline comes from how people navigate and hold attention. When a requested screen appears almost immediately, the operator experiences it as a continuous action and stays oriented in the process. Once the wait stretches beyond about a second, the pause becomes noticeable, the operator's train of thought is interrupted, and each screen change costs a little more mental effort. Across a shift, and especially during a fast-moving event, those small costs add up.
The target is best understood as a design goal rather than a hard legal limit. Different guidance frames it in similar terms, and the exact number is less important than the principle: display navigation should feel effectively instant so it never becomes a bottleneck between the operator and the plant. A display that reliably calls up in about a second meets the intent; one that takes several seconds does not, regardless of how the threshold is worded.
It is worth separating call-up time from data update rate. Call-up time is how fast the screen appears and first shows current values when you open it, while the update rate is how often those values refresh once the screen is up. Both matter, but call-up is the one tied to navigation, and it is the one operators feel every time they move between screens.
Situational awareness depends on an operator being able to move fluidly through the display hierarchy - from an overview, to the affected area, to the specific loop - while an upset is developing. If each of those steps carries a multi-second wait, the operator is repeatedly stalled at the worst possible time. The very moment that demands rapid drill-down is the moment slow call-up hurts, because the operator is trying to open several screens in quick succession to find the cause.
There is also a behavioral cost. When displays are slow, operators adapt by avoiding navigation: they stay on fewer screens, drill down less often, and rely more on memory and less on the live picture. That reduces the very awareness the HMI is supposed to provide. Fast call-up encourages operators to actually use the display hierarchy the way it was designed, checking the relevant screen rather than guessing.
The consequences concentrate during abnormal situations, which is when good HMI performance earns its keep. During normal operation a sluggish screen is a minor annoyance; during an upset it delays diagnosis and response. This is why call-up time is treated as a genuine performance requirement of an operator HMI and not merely a nicety, and why it belongs in the specification alongside content and layout.
A cloud or web-based SCADA has to hit the same call-up target as a traditional local HMI, and it does so through architecture rather than raw proximity. Keeping graphics thin - restrained high-performance displays with modest imagery and few heavy elements - means less to transfer and render when a screen is requested. A lighter display is inherently faster to call up than a graphics-heavy one, which is one more reason high-performance HMI style and fast performance reinforce each other.
Caching is the other lever. When display definitions and the tiles that make up a graphic are cached close to the operator, a call-up does not require rebuilding everything from scratch; the structure is already available and only the live values need to be filled in. Separating the mostly static graphic from the fast-changing data lets the screen paint quickly and then populate current values, so the operator sees the display promptly instead of staring at a blank screen while everything loads.
In practice this means a cloud SCADA operator on a browser can move through the display hierarchy at the speed the guidance intends, even for a field that is far away, because the heavy lifting has been designed out of the call-up path. The point of engineering for call-up time is that the operator never has to think about it - screens simply appear when asked, so attention stays on the process where it belongs.
Around one second is where a screen change still feels instantaneous, so the operator stays oriented and their train of thought is not interrupted. Beyond that, the delay becomes noticeable and each navigation step costs extra effort. The exact figure is a design goal rather than a strict limit, but the intent is that navigation should never become a bottleneck between the operator and the process.
No. Call-up time is how fast a display appears and first shows current values when you open it, tied to navigation. The update rate is how frequently those values refresh once the screen is already up. Both affect the operator experience, but call-up is the one felt on every screen change and the one the one-second guidance addresses.
Yes, when it is architected for it. Thin, restrained graphics reduce how much has to load and render, and caching display structure and tiles close to the operator means only live values need to fill in on call-up. Separating the static graphic from the fast-changing data lets the screen paint quickly, so a web SCADA can meet the guidance even for a remote field.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.