Planning Operator Workloads

by | Jul 23, 2018 | Control & Safety Systems, Operator Performance | 0 comments

There’s a great question on planning operator workloads. This Emerson Exchange 365 community, DeltaV group member posted, Is there a standard, industry reference or best practice to determine operator workload and staff requirement for DCS consoles? In part, they ask:

I’ve been dealing with a question from our management for some time: we fear that in some scenarios we have our console operators dealing with too much going on at the same time; too much loops and variables to monitor, and everything that comes with them: alarms, trends, changing setpoints, etc, so we wonder if we have staff available for our current system size in a reasonable proportion.

Emerson’s Cindy Scott provides a thoughtful response which I’ll quote an excerpt (and insert some hyperlinks):

Emerson's Cindy Scott


The Center for Operator Performance has performed some research in this area. However, this is not a simple question to answer, and likely requires operations-specific operator workload analysis. Here’s some background that may help with your evaluation.

Evaluating operator workload needs to include operator tasks, operator console design, alarm management, display design, control room environment, complexity of the process and the level of process automation. It also includes the operators – how experienced are they and what operator training is provided.

Chemical Processing: Accurately Determine Console Operator WorkloadIn the mid-2000’s, the rule of thumb used was around 200 loops. However, if there is no documentation on the basis for this 200 loops target. Here it is mentioned in this 2005 Chemical Processing article: “generally accepted that a console operator could handle about 200 control loops, with an upper limit of around 280 loops. Interestingly, it’s difficult to find the origin of this rule…” You ask what is meant by ‘a loop’. Specifically, what is the assumption about the amount of other signals being monitored and controlled (e.g. AI’s, pumps, motors, etc.) for each loop counted. I believe that a good ‘rule of thumb’ is typically about 10 DST’s per loop. This varies by application, with increased DST’s per loop for monitoring-intensive applications.

Well managed alarms, task-based display design and display navigation, along with…

Read the rest of Cindy’s response and the whole thread if your organization has similar challenges. Cindy and the DeltaV product management team incorporate many aspects of the research from the Center for Operator Performance into operator software usability improvements.

If you’re not already a member, join the Emerson Exchange 365 community and the groups in your areas of interests. You can also connect and interact face-to-face with many of these experts at the October 1-5 Emerson Exchange conference in San Antonio, Texas.

Popular Posts

Comments

Follow Us

We invite you to follow us on Facebook, LinkedIn, Twitter and YouTube to stay up to date on the latest news, events and innovations that will help you face and solve your toughest challenges.

Do you want to reuse or translate content?

Just post a link to the entry and send us a quick note so we can share your work. Thank you very much.

Our Global Community

Emerson Exchange 365

The opinions expressed here are the personal opinions of the authors. Content published here is not read or approved by Emerson before it is posted and does not necessarily represent the views and opinions of Emerson.

PHP Code Snippets Powered By : XYZScripts.com