Energy Balance Calc

I have a requirement to build an energy balance calculation in DeltaV SIS (if the heat generated is less than expected, unreacted chemicals could be pooling in the reactor). The required calculation is supposed to integrate the amount of heat removed during the previous x minutes and compare this value to the theoretical heat generated during the same time. If the values are out-of-balance the feed to the reactor is stopped.

This would be fairly easy to setup in a standard DeltaV module. But it is proving to be a little more difficult in an SIS module, due to the limited SIS blocks available – namely an integrator block, a dead time block, and an array block. Without going into the merits of including/no- including these blocks in the SIS palette, has anyone done a similar calculation in DeltaV SIS? I can think of a couple of ways to accomplish this, but I can’t find an elegant solution - (calc blocks with a large number of parameters for data storage seems inelegant and inefficient).

David Nelson

• 11 Nov 2014 8:58 PM
• Cancel

5 Replies

• Tadeu Batista

  

  • 11 Nov 2014 10:02 PM

  Hi David,
  
  DeltaV SIS was developed after IEC 61508/61511 was released and was built to meet this two standards in a very straightforward way, if you take our Safety Manual, it's a total of 9 pages only, that's why some of the Advanced Block was not considered, because they are not really safety related.
  Now, if you really need to configure this VOA to generate a variable to the SIS and the Calc Block is not an option, you can configure it to run into a DeltaV controller and transfer the variable to the SIS using a Non-Secure parameter.
  Rgs,
  Tadeu Batista

  • Cancel
• David Nelson

  

  • 12 Nov 2014 6:13 PM

  In reply to Tadeu Batista:

  I didn’t want to get into a discussion about what should/shouldn’t have been included. But since you brought it up, I would’ve thought Emerson would’ve developed the product to meet customer needs not just putting forth the minimum amount of effort required to meet a standard. This may not be a common requirement, but the lack of a similar calculation (mass balance) was cited as a contributing factor in the Texas City refinery incident. Including this in the SIS may not always be necessary, but the Heat Balance calculation is a requirement for the SIS attached to this process.
  
  The option of doing the calculation in the DCS and passing the value to the Logic Solver will violate the required separation. The heat balance can be done in calc blocks, but not in an elegant manner.

  • Cancel
• kbellville

  

  • 12 Nov 2014 7:42 PM

  In reply to David Nelson:

  David,
  
  DeltaV SIS was developed to meet customer needs as per the IEC Standards for Safety Instrumented Systems of which the blocks in question (integrator, dead time, array) are not safety related. The Chemical Safety Board (CSB) sited numerous things leading up to the Texas City incident of which none were around calculating mass balances. The main contributors to the incident was a basic lack of modern design safeguards and functioning safety instrumentation.
  
  The CSB video review of the incident can be reviewed here: http://www.csb.gov/videos/anatomy-of-a-disaster/
  
  Safety systems, like DeltaV SIS, follow strict design and installation standards and policies of HAZOPs, LOPAs, SIL Calculations, SIL Verifications, Proof Testing, and MOCs which are much more than the minimum effort that you allude to. The use of non-safety related functionality within a safety system is actually far worse and unsafe than trying to make it easy for an uncommon requirement of a mass balance calculation to be performed. The safety system is there to watch the level, temperature, pressure, and flow(s) on the process equipment and to shutdown when any of them are out of limits. This can all be done without complicated calculations and in fact, based on the HAZOP, LOPA, and SIL requirements is much safer than relying on a programmer to make sure a calculation is done correctly. More importantly is the calculation still correct when an input is wrong, missing, bypassed, etc... as it was in the Texas City level calibration.
  
  We have yet to see a HAZOP, LOPA, or SIL calculation that required a heat balance as an input to a SIF. The level transmitter(s) on the unit itself should be the input requirements (the same as the CSB states for the Texas City incident).
  
  If you wish to discuss further please email me at [email protected] or call me at (512)-832-3183.

  • Cancel
• David Nelson

  

  • 12 Nov 2014 8:44 PM

  In reply to kbellville:

  My initial post stated I didn’t want to debate the pros/cons of what was included in the palette. I have an issue that needs to be addressed and I reached out looking for a solution. Emerson responded in a defensive and unhelpful manner – that is what led to my comments.
  
  In the sequence of events for Texas City, an operator failing to notice mass balance discrepancies was listed. It’s much easier for an operator to notice a mass or heat balance discrepancy if we program it for him, instead of him doing mental calculations.
  
  As I said earlier, this may not be a common requirement for a SIS, but I have 2 units that require an energy balance calculation as a part of the SIS. I can’t really go into the reasons behind the inclusion, as the requirement predates me by a number of years – I just need to implement the requirements (besides, I’m not here to debate, I am looking for a solution; at this point changing the requirements for the SIS is not an option). Detection of missing or bad inputs can be easily handled and is covered in the diagnostics section of the documents for these units. Since Emerson is unable to provide guidance on implementing this, we will continue down the path we are already on.

  • Cancel
• kbellville

  

  • 12 Nov 2014 10:03 PM

  In reply to David Nelson:

  David,
  
  Well I had a well thought out reply but apparently a browser crash doesn't save data.
  
  Rest assured that our responses are not defensive nor were we trying to be unhelpful. Quite the opposite we were trying to address your questions and comments, but sometimes what is written vs what is read does not always match. Going both directions.
  
  Please call me at (512)-832-3183 to discuss your dilemma to see if we can help you find the best solution to your issue.
  
  Regards

  • Cancel