Emerson Exchange 365

• Not Answered

CHARMS Logic Solver Download Issues

We are adding a new CHARMS logic solver SIS system into our existing DeltaV DCS control system.  We are reading the SIS I/O into modules which are assigned to the CSLS.  We have DCS modules which reference the logic solver I/O via external references.  When we do a download of the CSLS, the status of the external reference in the DCS module goes to BadNoCommUV.  This status stays bad for periods of up to 15 seconds.  We are looking for a way to eliminate this issue without putting in custom logic to delay a bad status alarm in each module.  Our assumptions were that by using a DeltaV SIS system, we wouldn't have this issue because they are  on the same communication bus.

• CHARMS logic solver

boykindj

• 17 Oct 2015 5:28 PM
• Cancel

7 Replies

• Ben Bishop

  

  • 20 Oct 2015 9:00 PM

  I see that you have opened a ticket with our Global Service Center on this matter. Please update the community when it is resolved.

  • Cancel
• boykindj

  

  • 22 Oct 2015 2:33 PM

  The global service center suggested wiring from the LSAI block to an output parameter in the SIS module. Then referencing the output parameter from the DCS module. It was also suggested to change the download behavior of the DCS module to "Preserve user defined and critical block values". We tried this, but got the same results. The references between systems go bad for periods of 10-15 seconds during a download.

  • Cancel
• Tadeu Batista

  

  • 23 Oct 2015 1:55 PM

  In reply to boykindj:

  First question I have is, where is this DCS modules been assigned? to the Local SZ Controller or to a remote DeltaV controller?
  One suggestion would be, instead of driving the variable using parameter, you should try to assign the Input to an AI block within the DCS module.

  • Cancel
• boykindj

  

  • 11 Nov 2015 12:59 AM

  In reply to Tadeu Batista:

  We have tried moving the modules from the BPCS controller to the SZ controller, but the result is still the same. All communication is lost between the CSLS and anything outside of it's processor. Also, moving modules to the SZ controller would not necessarily work in cases when non-safety I/O is also tied to that module. (ie. PID loop). Our current solution is to delay the status of the referenced signal by 20 seconds which is slightly longer than the time required to download and re-establish communications. I'm hoping a solution for this is released in the future.

  • Cancel
• Andre Dicaire

  

  • 2 Dec 2015 12:15 AM

  In reply to boykindj:

  Did the GSC confirm how long the IO channel status is supposed to go BAD during and following the CSLS download? I would expect the status to go BAD in this situation.
  
  What I find interesting is that you are downloading a logic solver and expect the BPCS to maintain communication to the Logic Solver IO. The Logic solver does not support partial downloads, by design, in line with IEC 61508 certified functionality. During a download, the CSLS clears its configuration for all its IO and the SIF's. It then loads the new configuration and re-establishes all communications with the SZ controller.
  
  I'm curious to know if you are now looking for a work around or are you still thinking this is abnormal behavior.

  Andre Dicaire

  • Cancel
• Padmakar Konale

  

  • 2 Aug 2024 9:04 AM

  In reply to Andre Dicaire:

  CSLS downloading leads to switch PID mode to MAN when SIS transmitters Median or selected value used as PV to PID control modules. Any suggestion or work around to resolve this issue?

  • Cancel
• Andre Dicaire

  

  • 2 Aug 2024 11:54 AM

  In reply to Padmakar Konale:

  After 9 years, if the behavior has not changed. Ie, downloading a CSLS results in interruption of IO status to the BPCS, it is not likely to change.
  
  Ideally, things should always work like we assume they would. But when they don’t, we can only control what we can control. Changing behavior of the CSLS for a non-SIS feature is not a high priority and not worth risk of unwanted consequences to any other SIS installations.
  
  At this point, if a predictable loss of Ai input status on an SIS IO read by BPCS is unacceptable in the BPCS loop, you should consider a direct signal, maybe adding a separate sensor for the BPCS, or via a splitter on the existing signal wired to both SIS and BPCS, provided doing so allows the SIF to still meet its SIL rating.
  
  Status handling in BPCS makes a temporary loss of an IO input detectable and mode shedding prevents output bump.
  
  If the loop is critical and cannot tolerate this disruption or suspension of response, a dedicated input might be your best option. At least by doing this you take control of the problem and can solve your issue on your schedule.
  
  Not what you want to hear, but…

  Andre Dicaire

  • Cancel