Applying KPIs for valve reliability in projects with valve manufacturers, EPCs and end-users

ANDREAS VOGT

Large capital projects in plant engineering come along with special challenges. It’s not unusual that starting up a plant for the first time and get it operating reliably causes reengineering and replacement of critical control valves which may lead to startup delays and significant operation loss in the early beginning of its live cycle. Applying new principles of operation for “Non Process Quality Control” (NPQC) shows the way to a significant increase of quality in valve selection and reduction of cost for the plant operators at a very attractive cost benefit ratio.

Looking at the impact control valves can have on additional cost starting up a process plant, a pattern will emerge. The valves involved, failing during startup or shortly after, not performing as expected, delaying startup or causing operation loss are typically among the 3 % to 6 % (depending on the process) of valves in a plant commonly called “high performance valve for critical applications”, such as anti-surge valves, valves for flashing or outgassing services, high pressure let down applications… but their proportional value on purchase cost can be up to 40 %. Figure 1 shows the situation appearing in a past project of a petro chemical plant in China.

So it makes sense to identify them as early as possible and handle them with special care and effort. Spending time and money in carefully sizing and selecting them might save up to a hundred times the money spent when they are working properly from the beginning.

To explain the approach we took on the last projects, it’s necessary to talk about the basic principles we compiled over time and made them applicable.

During the last 29 years developing software solutions for instrumentation – and especially for manufacturer independent valve sizing and selection – I was always relying on and benefiting from valve knowledge and subject matter from experts, which I would call “valve nerds” or “valve popes”, as well as from critical cases we got to know from our end users.

It took quite a while before I realized that those individuals are a rare species and not always involved in projects where their know-how would have been worthwhile. Another fact I learned is that the result of their analysis of a valve case is not repeatable and depends on who is doing it and when.

So the idea of a universal rating algorithm was born, resulting in Key Performance Indicator (KPI) that can be applied on a valve case for all operating/ process conditions. Developing, verifying and implementing it in a piece of software was severly challenging, engaging a team of “valve-nerds”, subject matter experts and software developers for a couple of years. But that’s a different story.

Surprisingly, the biggest challenge now is to introduce this KPI for valve reliability to be used in large capital projects with valve manufacturers, EPCs and end-users. Let’s have a look why I think that this was the necessary next step to take and which hurdles were to overcome.

Although some of us may answer “yes” when asked “are you a valve nerd”, most of us will say “no”. When it comes to the question “How can I repeatably decide if a valve matches the given process conditions so that it performs reliably in any mode of operation?” the variety of answers is broader. You might have gut instinct, proven rules of thumb; you follow your companies “best practices” or even ask a “valve nerd”. But none of the answers are fully satisfying.

What’s needed is a method to ensure that independence from the individual doing the analysis is given a rating that is repeatable. It should allow valve analysis cases by “non-nerds” having “only” the process conditions, yielding a KPI to benchmark the valve reliability in the given scenarios. These scenarios should cover the full range of operation.

It can now be used to quickly detect the severe cases out of a big population of valves, a common requirement on large scale projects. Furthermore, it easily allows the prediction of the impact of changing process conditions (also not uncommon between FEED and commissioning). It also finally allows proving whether all selected valves in a project are “fit for the application” (as far as known and described). The list of use cases can be easily expanded to scenarios in existing plant (trouble shooting, revamps, debottlenecking) but that’s beyond the scope of this article.

The list of use cases can be easily expanded to scenarios in existing plant (trouble shooting, revamps, debottlenecking) but that’s beyond the scope of this article.

Let’s have a quick look behind the curtain of the KPI (we will call it “Ri” for “Reliability Index”) to understand what we try to apply.

It’s, as usual for a KPI, a single number. It give us a reliability rating for any given operating point of the valve. Table 1 explains the range of applicable values.

If Ri > 0, the system even gives additional information about the root cause of the problems and hints how to improve reliability for the given operating data. Understanding the background of Ri shows that this KPI – in simple words – converts best practices and learnings from real world cases into a rating for the operating point. That’s by the way in the first step the same thing any valve manufacturer has to do when he gets an RFQ for a valve and he needs to select a suitable device.

You take all major reliability influencing factors to calculate the KPI. There are general parameters such as dp, energy conversion, noise level, outlet flow velocity and valve type to be taken into account as well as effects like cavitation, flashing and choked flow. Fluid properties are also extremely important, as there is e.g. a big difference whether you have saturated or wet steam or superheated steam in a valve; or to check how close the upstream pressure and vapor pressure are.

It’s an even longer list of things to take care of and to process this information in an algorithm finally giving us the KPI for all known process conditions, as there are normal operation (min, norm, max), startup or special operation. It’s checked and verified against many hundreds of cases we came across in the last 20 years, documented by end users as well as valve manufacturers, proving that the prediction of the KPI matches the real world.

After that hurdle is taken, the rest seemed to be easy. On the project, we just needed to get the process data for the valves and determine the KPI for all modes of operation. Then, following the hints from the results, and discussing the alternatives, we were able to find more suitable solutions. The only thing we need to ensure is that no valve would be selected and ordered with a KPI > 0.1.

Sounds easy, isn’t it?
Wrong!

When executing projects following the described approach, there are plenty of different aspects and issues making and practically applying the KPI a challenge, both expected and unexpected ones. So let’s look to the lessons learned.

In the actuals projects, we got the data directly out of the tools used by process design, instrumentation and the valve vendor in Excel or XML formats. But believing that would lead to an easy way to process the information is wishful thinking. Important data for special cases (the ones we were highly interested in) was not mapped to data fields. We found them as “prose” in note fields on the original sizing sheets, which were unstructured and not always clear to interpret.

Data for start-up cases, flashing, outgassing, purging… was specified in notes and partially did not find its way into the instrument specification nor to the valve vendor. The difficulty was to convince process design to maintain that important data differently to ensure that passed through in a structured way, implying that adjustments to their tools as well as their way of working had to be made.

When finally having all data imported with an adapter tool allowing data process, instrument specifications as well as vendor calculations, you don’t need to wait for further problems.

When discussing results, you face the fact that not all involved parties rely on the same background. When it comes e.g. to noise prediction (noise produced can be an indicator for reliability problems) we use the latest standards to predict noise in liquid, gas and steam applications. Vendors or EPCs might use propriety methods or outdated standards.

Also not matching best practices and rules of thumb cause problems in aligning the interpretation of the resulting KPI.

For example, when deriving the KPI, we look at outlet velocity (valve outlet flange), some valve vendors look to the outlet pipe size ignoring pipe reducers. Or mismatches of rules applied to velocity limits for gas and steam. The KPI algorithm has 0.3 Mach as a first trigger, some EPCs use 0.5 Mach.

We had to accept that in some rare cases the KPI mechanism could not be applied. In cases where the valve was “engineered special device” that could not be modelled by the standards used or not enough information was disclosed by the vendor to calculate it properly. But we could ensure that the valve was specially treated and always on the radar for NPQC

After solving all the issues mentioned, there was still the final challenge common to all projects - communication and coordination in the overall engineering process.

You have at least three parties involved and they are not used to nor have they even designed a project workflow that allows using a KPI as a central quality control element (Figure 2). There is also no common data language for cycling specification and selection data defined.

There is a lack of a proven best practice for ensuring quality in sizing and selection of critical control valves in these kinds of projects. We run into situations were process data was still changing while the valve was already ordered. You are right to observe that this is common and unpreventable. But if your mode of operation allows you to detect those cases, check the impact on the sizing and selection of the affected valve and take action if necessary instead of running into problems during startup, you take the next step to higher engineering quality.

SO WHY DOING ALL THIS, DOES IT MAKE SENSE?

I think definitely yes. When calculating a Benefit Cost Ratio (BCR), comparing the cost, coverage and savings of and conventional quality control mechanism (typically implemented by the owner operator of the plant) with the cost, coverage and potential saving of a KPI based quality control, we see a typical BCR in the range 30 up to 100 (not even taking production loss into account), depending on various parameters. This has been verified in a pilot project as well as by recalculating past projects. The lessons learned from actual projects will help to further shape the mode of operation to become more effective for future projects. This will lead to improved capital efficiency in those kinds of projects and should be attractive enough to take a closer look on the use of a KPI as central quality control element for valve sizing and selection

Please refer in addition to the article „Reliable valve sizing in large-scale projects” (published in Industrial Valves 2014/2015, page 43ff) were you will find complementary perspectives on the concept on usage of the Reliability Index KPI.

Valve World Expo 2016: Hall 4, Stand B02