Use of API standards outside intended scope

[geesamand]

I work for a manufacturer of equipment where petroleum storage/production companies are among our customers. Many of these customers do not have corporate specs for our type of equipment - so the engineering companies that handle these for the end users just cobble together API standards that appear to apply to things within our equipment.

These API standards might appear to apply to our product based on the title, but when you read the standard it's clear that it does not apply to our product. In our experience, application of the cited API standards does nothing to add to the reliability or value of the equipment, otherwise I wouldn't be concerned. It works, just in a massively overpriced and difficult way - death by 1000 cuts. We'd develop a product just for this industry, but the engineering companies seem to spec their own blend of irrelevant standards.

Naturally, having a frank conversation about it would require the end user to be a party. The engineering companies would never allow that, and seem to believe their role is to apply as many industry standards as possible to each transaction. So this does not happen.

OK, enough of my griping; everyone is downhill of something. Has anyone else navigated this problem with success?

David

 

[IFRs]

If they say "use the following codes where applicable" then you are off the hook if they don't apply. If they say "design using the following codes" then you may have your back to the wall. I run into situations where they want a vertical cylindrical tank but it may not have its bottom uniformly supported stores some other liquid than oil, is above or below the temperature or pressure range for API 650 / 620. So, I use API 650 / 620 to design the shell and other components that seem to fall within API 650 and then use another code, perhaps AWWA if it applies to the support conditions and then basic ASME, AISC or ACI and good engineering judgement for the rest. They are looking to minimize their risk and so am I. I think if you pick and choose the sections of various codes to determine loads and design various aspects of a project you are using the knowledge gained from decades of experience ( failures and successes ) to safely design some components. Be sure to examine the cracks between the codes and the interfaces between components. Each may be safe and economical but together they may not work. If is very useful to know the reason behind the codes, to be able to properly pick and choose. For instance, plant piping is different than cross-country, low pressure vessels are different than high pressure, water is different than oil or acid.

Not much help, but that's all I got...

 

[geesamand]

I will look for that language. It could be quite helpful. As well, if it's not defined, perhaps it could be crafted into the Terms and Conditions negotiation? (Seems those are always a major negotiation nowadays)

I think the frustrating part is knowing that we have standard products designed specifically for these applications, and that the specs are written as if we're going to build everything from the ground up, for the first time. So to "comply" with these specs intended to reduce risk, we're actually breaking down a proven system and substituting various things just because. At the end, you have basically a new, unproven system, based on unrelated codes that were never intended to work together.

David