Control Valve Failure: Dynamic Gas Blow-by

Disclaimer: This article and the example provided is for instructive purposes only. Any model calculations and methodologies
should be verified depending on your specific regional and/or project requirements.

One common scenario assessed in process safety is failure opening of a control valve on the inlet of a
vessel as shown in Figure 1 below.

Figure 1. Simple system for control valve failure analysis

If the fluid upstream of the control valve can overpressure the separator, then standard valve sizing
equations (e.g. ANSI/ISA, vendor-specific flow models) can be used to determine the required relief load
if the control valve fails 100% wide-open.

Let’s say, however, that when you zoom out of this system the process flow looks like Figure 2.

Figure 2. System where gas blow-by should be analyzed

In this case there are additional concerns to note. There’s already a lot of great content out there
providing guidance on the concerns of gas-blowby as well as estimating the relief load conservatively
using steady-state assumptions.

But, since this is a fundamentally dynamic situation, I wanted to show how to use dynamic simulation to
analyze this system.

Dynamic Gas Blow-by

This article is not a step-by-step guide to construct the dynamic model. I’m just going to talk you through
a “tour” of the example case that I’ve already created. I’ll also walk you through the general mindset as
you prepare a dynamic model – and for more details you can open up the file and play around.

For a step-by-step guide on the basics of HYSYS Dynamics from scratch, start here. Also, this other guide
is a bit older (and has some outdated screenshots), but it provides some priceless tips and tricks on
setting up dynamic models.

Setting up the model

The first step in creating a dynamic model is to ensure that you have specified your steady state model
in a “pressure-flow” set-up. This may require you to add resistance unit operations (e.g. valves, pumps,
compressors) on boundary streams.

The easiest way to determine whether your model is set up appropriately is to change the color scheme
of the flowsheet to “Dynamic P/F Spec” (Figure 3). This color scheme will help identify whether you
specified pressure, flow, both, or neither on a stream to help catch specification errors.

Figure 3. Change color scheme to Dynamic P/F Specs

Figure 4. On left, flowsheet with normal color scheme. On right, flowsheet in Dynamic P/F Spec color scheme
After setting up the controllers, we can enable Dynamics Mode.

Figure 5. How to enable Dynamics Mode in Aspen HYSYS

Next, you want to run the model and make sure that the system achieves a steady state that reflects the
process. We recommend perturbing the system methodically in order to test that the control systems
are working as expected and in accordance with any plant data you may have.

Figure 6. Dynamic model running in steady state

Once you have verified your dynamic model, the next step is to define the “overpressure scenario” using
the Event Scheduler.

Setting up the Overpressure Scenario

The event scheduler allows you to set up ‘events’ – in this case we will use the event scheduler to
change the model in a way that will simulate the 1st stage separator’s level control valve failing wide
open. You can find the Event Scheduler on the Dynamics tab of the ribbon.
 Figure 7. How to open the Event Scheduler

I’ve already created an event that represents the “Failure” – as well as an event to “Reset” the entire
system back to normal operating mode.

When setting up the event logic, we need to be careful. In accordance with API 521 6e Section 4.2.4
guidance, we don’t want to take any credit for controller behavior helping us (or making the situation
less bad).

Why? Because if a controller failed in-position (the valve rusted in place, or is stuck for some other
reason), there would be no signs of the failure until some other initiating event happened (like a control
valve failing wide open). This is known as a “latent failure” -- a failure that waits in hiding until some
other event happens, and this latent failure makes the event worse. In process safety, since PSVs are a
last-line-of-defense, reasonable conservative assumptions are made – and generally we look to
RAGAGEP-documents like API 521 for guidance on what a “reasonable” conservative assumption is. If
you’re interested in learning more, here’s a great article that describes why latent failures must be
considered in overpressure analysis (and do not constitute “double jeopardy”).

To satisfy the API 521 guidance, we need to go controller-by-controller and, if that control valve
behavior would normally make the scenario less bad, we need to “freeze” that valve in its normal
operating position (assuming a “latent failure” on that valve prior to the valve failure event). Here’s
what I came up with for this sample system:
 Figure 8. How each controller will behave during overpressure contingency

In the event scheduler, the red text that is on the flowsheet above translates into the following set of
‘actions’ defined in the event scheduler:

Figure 9. Individual 'actions' that make up the event

If you’re curious about why I let the pressure-controller on the first stage separator continue to operate,
keep reading; I’ll demonstrate the rationale in the next section.

Running the Scenario

Now we are ready to run the scenario. Before we start, I recommend popping out the “Status Panel”
window, because this will allow you to easily initiate then reset the system. You can find the Status
Panel on the bottom right corner of the Event Scheduler tab.
 Figure 10. Finding the Status Panel

Let’s ‘Start’ the Failure scenario and click run.

Figure 11. Initiating the scenario

In the first docked graph, you can see RV pop open (bold red line) as well as the varying liquid levels in
the system. The liquid levels are important because you don’t want the 2nd stage separator to be 100%
liquid-full at any time during the scenario in order to avoid a “liquid displacement” scenario which
results in a very high relief load (where the liquid must be relieved at the volumetric rate that vapor
enters the vessel).

The second docked chart lets you see the relief phase and relief load over time. If the relief phase is two-
phase, then you need to use the “HEM” method in the relief device unit operation that was newly added
in v9.
 Figure 12. System response & relief requirement during overpressure scenario

Now back to the question posed in the last section: Why did I assume that the first-stage pressure
controller continued to function? Because assuming proper functioning of the pressure-controller
resulted in the most conservative relief requirement. You can run through a relatively simple thought-
exercise to convince yourself– or you can test it using dynamic simulation (recommended). If you
assume the pressure-controller fails in place (set the controller to Manual mode during the event), you
will see a reduction in the relief requirement on the 2nd stage separator. And according to the API 521
guidance, you want to assume a latent failure on a control system only if this will result in the worst-case
relief requirement. This verifies the assumption that normal-operation of the first stage pressure
controller will result in the most conservative load on the second stage relief device.
 Figure 13. Relief requirement when 1st stage pressure controller assumed to fail in place

Once you’ve successfully run the overpressure contingency, the next step is to save the peak relief load
information for documentation & reporting purposes, and to more easily transfer the information into
Flare System Analyzer. The next section describes how to do this.

Save the peak relief load data for reporting & for transferring to Flare System Analyzer
As many of you know, there is a new PSV Sizing feature in the Safety Analysis environment of Aspen
HYSYS. This tool allows you to size and document your relief system analysis in a systematic way – then
allows for easy transfer to Flare System Analyzer to rigorously assess any hydraulic concerns on the flare
header.

How then do you take this rigorous dynamic analysis and store it for the Safety Analysis environment?

I’ve created a strip chart to store the peak relief load, and the stream composition, temperature, and
pressure. You need to take the peak conditions and store it in a stream.

Figure 14. Saving the Peak Relief Requirement

 Figure 15. Creating a stream with the peak relief requirement details

Now that it’s in a stream, you can use the normal Safety Analysis workflows to document and transfer
the information to Flare System Analyzer. In the example file, if you go to the Safety Analysis
Environment, you can see an example of how to incorporate the dynamic analysis as a scenario in the
safety Environment.

Figure 16. Storing the scenario in the Safety Analysis Environment

Final Note
The objective of this article was to show the mindset as you approach dynamic simulation for process
safety analysis. I didn’t spend a lot of time on discussing how to set up the dynamic model – but this is a
big (and important) piece of the puzzle.

While setting up the model, I did run sensitivity studies on a variety of variables in the model to
understand how a 5%, 50%, or 100% change in a value would affect my peak relief results. It’s always
important to use process simulation as a tool – and to try to understand the assumptions in the model
as well as the effect that those assumptions play on your final results.

I hope this article brought a little more clarity in using dynamic simulation for relief load calculations.

Thanks for reading!

Anum Qassam
||| Senior Product Management Specialist
Aspen Technology, Inc. ||| +1 781-221-1885 ||| +1 817-999-9707 ||| www.aspentech.com