How quickly would you like the order taker to approach you once you are seated at a restaurant? How much would you like to wait for the food to reach your table once you order it? How often would you like your server to approach you once the food has been delivered to find out if you want to redo your order?
All are questions not only relevant to the hospitality industry, but also to the HMI designers! Finding answers to these questions with a pinch of reality is also equally challenging! The end users want the speediest response and system designers find it hard to explain that it even takes God 08 minutes to make the sunlight reach us once you press the morning button!
The questions posed above relate to the display response and includes metrics such as call up times, and display refresh rates. Altogether, they can be called as “Duty Factors” for the HMI. Till recent past there was no way to give an answer to these questions that can be considered as “standard”. However, organizations such as ISA are now actively working on developing standard guidelines not only for duty factors, but other aspects of HMI design as well.
Let us define some terms first. These definitions are purely based on experience. You can differ to a certain degree. These definitions can become good part of your vocabulary when you are discussing this topic for a new project.
Suppose an operator presses a display button on his console. Time between his key press, to the instant the new graphic page opens up, all numeric values are displayed and all objects show the live conditions (such as valve open/close colors), is called the CALL-UP TIME. We can also say that Call-up time is the time taken for the new screen to “become alive” – “Kun Faya Kun” for our Arabic literate readers!
Slightly later (just slightly!) we will discuss what are reasonable expectations for the call up time to be and how it can be improved upon.
DISPLAY REFRESH RATE
Now that the screen has opened up, how long does it takes for the values and state of the devices (animations) to be updated.
Now lets say that our operator wants to change the %age opening of one of the valves being displayed on the screen. So, he would either go to the numeric display or open the valve pop-up to change its opening. Time required from the moment he enters the new value to the moment the controlling device (e.g. a PLC, DCS controller) receives this value is called the WRITE TIME.
The write time depends on the medium and mode of connectivity between the HMI and the controller. If your HMI is connected to the controller over a GPRS network, this time can be considerably longer as compared to these being connected over 1G copper Ethernet.
Same as write time. The only difference is that the duration does not end at the point where the controlling device receives the value. Rather it ends when the end device “starts” to respond to the new changed value. Remember we are saying, “starts to change”. Achieving the complete change may depend on the control algorithm (e.g. PID loop parameter settings) or the end device built in characteristics (e.g. response time of the actuator).
Action Time = Write Time +X+ Device Response Time
Where X = any time required for communication of command between controller to the field device, assuming it is the same both ways (may be significant in case of multiple connected devices on serial protocol)
Action Read Time
Once the device has started responding to the new change, a feedback mechanism, if it exists in the field can tell us about the response of the device. It can be a positioner in case of a control valve, or contactor status feedback in case of a motor or pump. The duration from the moment the device to give its feedback about new position / state to the moment the new feedback is displayed on the operator console is called ACTION READ TIME.
Action Read Time = X + Write Time
Operator Experience Time (or User Experience Time): The duration from the moment operator inputs the new device state to the moment he observes the new device state feedback on the console is called – Operator Experience Time – and is the notorious of all the times!
Notorious it is because the operator gauges the time performance of the HMI by this time, most of the times being oblivious to the following intermediary times. (It’s the first time I have used so many times in one sentence!)
Operator Experience Time = (Action Time + Action Read Time)
= (Write Time + X + Device Response Time) + (X + Write Time)
= 2*Write Time + 2*X + Device Response Time
Since the Operator experience time is composed of multitudes of times, it is not the correct parameter to gauge the performance of an HMI. It is better to use the Call-up Time and Display Refresh Rate as a criterion for gauging operator performance.
So let us discuss the Call-up Time in more detail. Call-up time is impacted by various factors including:
- Density of static and dynamic information on a given page
- Type / source of static information
- Complexity of the dynamic information (is it just color change or any motion animations are also used?)
- Communication medium and protocol between the controller and the HMI (e.g. medium can be ethernet or GPRS. Protocol can be OPC or a dedicated driver connectivity).
- Network traffic. How the network is designed can significantly impact this time. It is recommended that the uplink from controllers to the HMI is on a dedicated network.
The question is, what is an acceptable call up time? ISA 101 is trying to answer this question and develop a consensus in the industry. Here is what they have to say about various maximum times (in seconds) including call up times
|Metric||Display Type||HMI Category|
|Machine Control||Process / SCADA||RTU|
|Call-up Time||Level 1,4||2||10||10|
|Display re-fresh rate||All levels, yoke||1||5||5|
|Write Time||All display types||1||1||Based on dial-up / bandwidth|
|Action Read Time||All display types||3||5||Based on network topology. Usually less than 5 minutes for very large systems|
Charles Dickens would say that these are the best of times, these are the worst of times! Makes one wonder if he was an HMI designer too – torn apart by the end user expectations and system realities! What are your thoughts about these times?