We've been getting a lot of surge detection questions lately - what follows are the eleven most frequent, surge-detection-related questions we've been asked.

When did Surge Detection become "a thing?"

No doubt there are patents and guidelines for surge detection and surge control throughout the Industrial world that I'm not aware of, but for sure, in the US, patents relating to surge control and surge detection have been awarded going back at least 80 years to the 1940s.  

More, kind-of-recent, surge detection patents (again in the US) were awarded to T.E. Watson and P.R. Smallwood Jr. (Westinghouse Electric) for surge detection in centrifugal compressors in 1979 and J. Gaston (Dresser Rand) in 1986 for surge detection in axial compressors.

The  patents referenced in the links above have been consolidated, along with a couple others, into a .PDF for download if you'd like to read more.

Industry standardized requirements and recommendations (at least from the American Petroleum Institute) weren't circulated until November 2014 in the fifth edition of the API670, "Machinery Protection Systems" standard.

What is the difference between AntiSurge Control and Surge Detection?

To begin with, antisurge control is "continuous" in nature and surge detection is "discrete." The antisurge control typically controls an output to a valve with nearly infinite "solutions" between a minimum and maximum (limited by the resolution of the processing). Surge detection on the other hand is discrete - either a surge is detected or it isn't. And if a surge event is detected, there is a discrete (or set of discrete) action(s) taken.

API670 defines surge detection by its function, "… to detect surges and provide output for use in minimizing the number of surge cycles."

We've also heard the relationship described as one where surge control prevents a surge event, and surge detection "affirms" a surge event.  We'll discuss the "affirmation" of surge (detect and provide output) in the topics; "how do you detect surge", and "what do you do when you detect surge?" a little later in this post.

Are there formalized Surge Detection guidelines?

Alluded to above, the 5^th edition of API670 is the current, definitive Surge detection "go-to."

Surge detection isn't controversial, but its implementation can be because of the "affirmation" thing.  Quite a few opinions are floating around about how best to implement surge detection. And while opinions vary, they are consistent in that they mostly refer back to the API670.  

The API670, for those unfamiliar with the document, is promulgated by the American Petroleum Institute and contains both requirements and recommendations for "Machinery Protection Systems," including; vibration, electronic overspeed, emergency shutdown systems, and now, surge detection.

We're not affiliated with Techstreet (the online API670 Seller).

Who needs a surge detector?

• According to API670, axial compressors have to have them (required).
• For centrifugal compressors, API670 defers to compressor vendors and users, but they are recommended.

We'll take up what exactly makes the axial compressor so much more "sensitive" to surge than the centrifugal in a follow-up post.

Can my Surge Controller do Surge Detection?

To be API670 compliant, antisurge control and surge detection have to be separate.  Specifically, surge detection and antisurge control have to be "functionally independent," so that a failure of the antisurge control doesn't affect the surge detection and vice versa.

Failures include; hardware, software, communication, mis-application, calibration, inexperience, misfortune, calamity, etc. to name a few.

Can I share inputs/sensors between Surge Detection and Antisurge Control systems?

There's a difference in the two terms inputs and sensors that will be of "tangential importance" in helping us understand what's meant by "functional independence."

According to API670, Inputs used for surge detection have to be independent (from the surge control system), unless they are redundant, which can be shared. Sensors, on the other hand, have to be independent. 

How do you detect surge?

A surge event makes itself known in a few different ways. API670 explicitly recognizes reversals in flow ("rapid decrease and recovery"), discharge pressure ("rapid decrease and recovery"), and temperature ("rapid increase and recovery") or any combination of these as acceptable ways of detecting surge.  Additionally, API670 is ok with pretty much any other, compressor vendor – end-user, mutually agreed upon, proven way to detect surge.

The only overarching stipulation to this is, whichever way a surge detector detects surge, it has to be able to discern between individual surge cycles (and then increment the surge counter (by one) for each surge cycle detected).

We'll work through the differences in these detection methods and provide some recommendations in a follow-up post.

How fast does a Surge Detector have to be, to be able to discern individual surge cycles?

To be able to discern between surge events, and do something about them, the surge detector has to be moderately "fast." API 670 includes the following performance requirements:

• the logic solver can not have a total program execution time higher than 100 milliseconds
• surge detection input devices have to be faster than 200 milliseconds
• overall, screw-to-screw, performance faster than 500 milliseconds
  
  

What do you do when you detect surge?

To be sure, the surge detector is going to have to generate an alarm when a surge event is detected (required by API670). Beyond the alarm, API670 leaves any additional surge detection action for the compressor vendor and end-user to work out.

While the API670 only requires an alarm, it does provide some examples of additional possible responses:

• independently "fast-opening" the recycle/antisurge valve (removing the air or hydraulics to the valve actuator)
• emergency tripping the compressor driver

Typically, these responses are generated by the surge detector after some prescribed number of detected surge events within some specified time frame.

In a follow-up post, we'll discuss these additional actions using a hypothesis construct that includes type 1 and type 2 statistical errors.

Do you need to integrate independent Surge Control and Surge Detection?

Probably. In most cases, the surge detector is going to have to be disarmed if the compressor is starting/stopping, or if the surge controller is being tested.  The reason for this is that you don't want to increment the surge detector surge counter erroneously. This communications is typically facilitated by some sort of  (hard or soft) connection between the surge controller and the surge detector.

Can you implement Surge Detection on a modern PLC that's doing your Surge Control and still comply with API670?

Most definitely.

Beyond the implications of sharing redundant inputs described above, Annex K (K.2.2), of the 5th edition of API670, explicitly recognizes that  a modern "redundant" antisurge controller platform can provide an (API670) acceptable surge detection interface:

"If the antisurge control system incorporates redundant transmitters and redundant controllers, the surge detection function may be included in the antisurge control system."

Annex K, 5th edition API670 

• Fully redundant platform (power supplies, I/O, logic solvers)
• Incorporates programming architecture that facilitates functional segregation 
• Meets performance requirements 100/200/500 
• Minimally alarms on Detection of surge event 

Thank you for your interest! Please let us know what you think about this or one of our other posts in the comments below.