Emerson Exchange 365

Best way to give the control room operators a reminder?

Hello everyone,

I am trying to implement a reminder to operations to log equipment downtime on a mean time between failure system I created.  The issue is that when a pump shuts down, or is turned off for repairs, the operator is not logging the reason as to why it is down.  The system basically only works as good as the input it receives from the operators, which is sporadic.

We are trying to implement a reminder system for the operators to remember to log "Why" equipment is not running.  When a pump or motor shuts down, it is automatically logged as "standby" unless the operator logs it differently. (PM, Seal failure etc.)

I am looking for any suggestions on the correct way to remind the operator to log the equipment downtime.

I have already added a visibility to the dynamo which has "Log Downtime" with a blue border to try and visually remind the operators.  This is obviously still flawed, as the operator needs to be on that particular page with the equipment.  One of the operations lead has suggested having a built in reminder (through schedules I am thinking) to cause one of the deltav pages to switch to the equipment tracking page every Tuesday at midnight.

I am not exactly fond of this idea, as I think it adds unneeded distraction to the operator.

Any suggestions are greatly appreciated!

Jayme

• DeltaV

controls_wl

• 2 Nov 2020 11:16 PM
• Cancel

9 Replies

• Minerva Martin

  

  • 3 Nov 2020 3:25 AM

  I find it hard to ask favours to operators too. Basically, this is a favour. All you can do is create sort of a statistic like how long does a pump gets stopped after a trip or manual stop, after all, the maintenance people only cares about the runtime of an equipment isn't it? why you need to know how long it's stopped, I don't know other than knowing some history between 2 consecutive stops, especially if stop time between 2 restarts are always short (less than 30minutes). Maintenance team might want to know this as this could impact their plan. Avoid the WHYs :p

  • Cancel
• Dmitrii Kapitonov

  

  • 3 Nov 2020 4:42 AM

  Hello, Jayme.

  How about small pop-ups in the corner of the screen like on the picture. When an event occurs, a window opens with the necessary information and prompts the user to move to another scrin or close the window. To open a window, you can use the sheduller or gloabal user variables.

  

  • Cancel
• IntuitiveNeil

  

  • 3 Nov 2020 7:23 AM

  In reply to Dmitrii Kapitonov:

  Get the user organisation to try
  
  1. Operator Training, explain why it is important to do it.
  
  2. Operator discipline
  
  3. Policing /enforcement
  
  4. incentives . Top logging operator per month type scheme.
  
  5. Work practice studies to determine why the logging is not happening. What is more important?
  
  Not sure there is any technical system without negative side effects, i.e. potentially interfering with critical incident management.
  
  I have seen non DeltaV corporate LAN system running alongside DeltaV workstations as a logging system.

  • Cancel
• Matt Stoner

  

  • 3 Nov 2020 2:23 PM

  In reply to IntuitiveNeil:

  I would strongly discourage auto switching of displays as you never know what operations could be working on at that particular time which might disrupt control by the operator during an "event".

  • Cancel
• controls_wl

  

  • 3 Nov 2020 2:47 PM

  In reply to Matt Stoner:

  Hello Matt,
  
  This advice lines up with what I was thinking. The problem with pop ups and switching graphics is where do you draw the line with what is important. In my mind, operating the plant is important to the control room, not logging downtime. I have spoken with one of the plant leads, and shared your opinion. He agrees that we need to accomplish this through policy, not DeltaV.
  
  
  Thank you everyone for your comments!

  • Cancel
• Matt Stoner

  

  • 3 Nov 2020 3:03 PM

  In reply to controls_wl:

  I have talked with someone that has a product that might address this...more to come from him!

  • Cancel
• Andre Dicaire

  

  • 3 Nov 2020 6:05 PM

  In reply to controls_wl:

  I would agree with getting a policy in place and acceptance to comply is key. One thing to consider though is how to minimize the effort to capture the required information, thus increasing the success in compliance to the policy.
  
  The DCS might offer a means to help with this. Think about dividing your requirements into two parts. One is how the DCS can capture a reason for shutdown in the event journal. The second is the app that retrieves this data and minimally identifies shutdown events that do not have a reason provided.
  
  One of our customers has implemented a "reason for shutdown" that is made available via the onscreen dynamos in Operate. The operator can pull down a list of reasons(a named set) and click from the choices. The reason is written to the same module and is held in the module. ( you could use a common parameter as the User Change message will be in the Ejournal). By making it easy to set the reason at the time of action, Operators are more likely to comply with the policy.
  
  The Operator command to stop the motor is currently in your Ejournal, the Reason could be added as a second entryd and now the Ejournal captures the needed data.
  
  Running a SQL query on the Ejournal gets all the Stop commands and Reasons, and also identifies any that don't have the associated reason. An End of Shift report for equipment shutdowns could then be provided as feedback, as well as a running list they can review at anytime and address.
  
  So rather than create an "entangled" solution requiring constant changes to the DCS to reach the end game, push the details to the solution program and use data from the DCS that would be straight forward and stable to collect using standard means.

  Andre Dicaire

  • Cancel
• John Rezabek

  

  • 3 Nov 2020 7:50 PM

  Somewhat to my dismay, our HSE asks me to create such "prompts" for operations, for example to do periodic LDAR inspections or renew entry permits. To fit this in with our alarm philosophy, we used one of the low (<7?) alarm priorities and called them "prompts". They make a unique sound that is distinct from alarm sounds (unique color as well e.g. Cyan), as a prompt is something that's "expected" and "not abnormal". Some of the faceplates have a check box for the operator to further acknowledge "I did it". Then the "alarm" goes away .

  Having said that, @IntuitiveNeil has the right approach IMO - alarms and prompts are only one aspect of influencing behavior; you need to promote and motivate the behaviors you want using multiple strategies, or inertia will win.

  • Cancel
• MauryBayer

  

  • 3 Nov 2020 10:30 PM

  The key to getting good operator feedback is not just in showing something on the screen. You must also have the system in place to make it easy for a supervisor to see which items have / have not be answered, an easy place for the operator to know before leaving a shift that something is pending, etc. Also you want to make it easy for operators to pick from predefined reasons, etc. Custom comments are great, but it is more work for the operator, and harder to get them to participate in the process.
  
  DataJaguar which integrates well with DeltaV, is currently providing both notification and collection of reason codes / comments from operators for DeltaV Batch systems. We are currently extending this functionality to monitoring continuous processes as well. This might be something you want to take a look at / participate in the beta / development process. You can find out more www.proconexdirect.com/.../ or drop me a note.
  
  Regardless of which approach you take you want it to be easy / part of standard workflow for operator, and easy for supervisors / others to check in and enforce. Typically just having a window that the operator can use, if they chose to, does not yield good enough data to improve operations.

  • Cancel