Does any of this sound familiar to you?

  • You are asked to update relief load calculations for an existing unit to under revamp and all of the relief cases seem to be listed randomly.
  • You have to input or update relief loads into a flare model and find duplicate scenario’s listed with loads and/or properties that differ for unknown reasons.
  • You have to verify relief loads and load scenario’s (either in a supervisors-  or  client/owners role) and you don’t find the cases you are looking for in the locations where you would expect them to be described.

Wouldn’t it be a good idea if everybody followed some kind of common standard in documenting failure scenarios? Whether or not this activity is aimed at producing a project deliverable (like a safeguarding memorandum) or “just” a project internal document, it will be obvious that it will be beneficial to follow some kind of standard. This will allow for effective verification (both on the supervisor as the client/owner side) as well as for easy retrieval of information and auditing later on.

Standard failure categories

Depending on client or contractor procedures, a standard list of failure categories may be available and even be mandatory to use on a project. Such a list will usually contain a number of general (site or unit wide) failure scenario’s like for instance cooling water- or instrument air failure, and fire. Further it may contain generic scenarios like thermal expansion, blocked outlet, gas break through, as well as specific failures as control valve failure and inadvertent block valve operation.

However, even though it is certainly advisable to work from such a list, this will not necessarily result in a well structured document. The main reason is the fact that in practice there will always be a number of discrete failures that will ultimately lead to the same relief load scenario, or can be categorized as “not being worse than” a particular more generic scenario.

Standard evaluation sequence

For this reason the evaluation of the scenario’s will need to follow some kind of standard evaluation sequence, which may actually differ from the table of contents in the document. Evaluating failures by a standardized sequence will minimize the number of discrete load scenario’s to be evaluated for subsequent relief device sizing. It also allows listing and calculating the details for these scenarios only once, while referring to them in all other instances.

Note that this principle is crucial for quality control: as a fact of life changes will need to be made to the scenario details during the course of the project (or even thereafter); having the same information in multiple locations is in general a sure recipe for disaster.

Example

As an example one could consider a cooling water failure scenario for the overhead of a column. This condition would lead to loss of condensation and lead to relief. It would also be intuitive to look for a loss of condensation scenario in the section on cooling water failure (assuming we have a water cooled condenser that is).

However, there could be a number of other failures that would ultimately result in the same load scenario:

  • Reflux pump failure
  • Blocked product outlet
  • Control (valve) failure
  • Inadvertent block-valve closing

It will be clear from the above example that without a standard approach, the details of the load scenario might be found in quite different sections of the safeguarding document, if not in more than one (which would actually be worse for maintaining it).

Work Process

So in general, one should start working on those scenarios that are characterized by a generic relief condition rather than being tied to a specific failure. Examples of these would be:

  • Blocked outlet (may result from Failure of process stream automatic controls, Opening/Closing manual valves, or Electric power failure)
  • Cooling failure (may result from Closed outlets, Failure of process stream automatic controls, Opening/Closing manual valves, Electric power failure, or Heat-transfer equipment failure)
  • Maximum Heat Input (may result from Failure of process stream automatic controls, Opening/Closing manual valves, or Heat-transfer equipment failure)
  • Thermal Expansion (may result from Closed outlets, Failure of process stream automatic controls, Opening/Closing manual valves, or Electric power failure)
  • Gas Breakthrough (may result from Failure of process stream automatic controls, Opening/Closing manual valves)
  • Backflow (may result from Pump, Compressor, Power or Control Failure)
  • Liquid Overfill (may result from Failure of process stream automatic controls, Opening/Closing manual valves)

In the description of these cases one should not try to be exhaustive on the causes for the consequence at hand. Just make it credible that one or more failures can lead to the consequence. For instance:

  • Cooling failure on E-100 may occur from closing one or more valves in the cooling water line.
  • The vapor outlet of drum V-101 may be blocked by closing one or more (control)valves in the outlet line.

Only in case there is only one cause or if there are more causes with (potentially) different relief loads, describe the cause(s) in full detail.

After completing the generic cases, start to work on the cases that pertain to specific failures. While documenting these, you will encounter failures that will lead to a relief condition that is already documented. In such cases you will simply refer to the (numbered) scenario for details and move on to the next failure.

Benefits

Following a structured approach like the one described will minimize the work required to document the relief cases as well as result in a well structured document that allows quick reference to generic relief scenario’s without having to scan through most of the document to find them. It will also ensure maintainability of the document by avoiding duplication of data to the maximum extent possible.

Leave a Reply

Time limit is exhausted. Please reload the CAPTCHA.