API 510 Pressure Vessel Inspector
API 510 Pressure Vessel Inspector
Interpreting ASME and API Codes Passing the API ICP examination is, unfortunately, all about interpreting codes. As with any other written form of words, codes are open to interpretation. To complicate the issue, different forms of interpretation exist between code types; API and ASME are separate organizations so their codes are structured differently, and written in quite different styles.
1.1 Codes and the real world
Both API and ASME codes are meant to apply to the real world, but in significantly different ways. The difficulty comes when, in using these codes in the context of the API ICP examinations, it is necessary to distil both approaches down to a single style of ICP examination question (always of multiple choice, single-answer format).
1.2 ASME construction codes
ASME construction codes (VIII, V and IX) represent the art of the possible, rather than the ultimate in fitness for service (FFS) criteria or technical perfection. They share the common feature that they are written entirely from a new construction viewpoint and hence are relevant up to the point of handover or putting into use of a piece of equipment. Strictly, they are not written with in-service inspection or repair in mind. This linking with the restricted activity of new construction means that these codes can be prescriptive, sharp-edged and in most cases fairly definitive about the technical requirements that they set. It is difficult to agree that their content is not black and white, even if you do not
agree with the technical requirements or acceptance criteria, etc., that they impose. Do not make the mistake of confusing the definitive
requirements of construction codes as being the formal arbiter of FFS. It is technically possible, in fact common-place, to use an item safely that is outside code requirements as long as its integrity is demonstrated by a recognized FFS assessment method.
1.3 API inspection codes
API inspection codes (e.g. API 510 Pressure Vessel Inspector) and their supporting recommended practice documents (e.g. API RP 572 and 576) are very different. They are not construction codes and so do not share the prescriptive and ‘black and white’ approach of construction codes. There are three reasons for this:
. They are based around accumulated expertise from a wide variety of equipment applications and situations.
. The technical areas that they address (corrosion, equipment lifetimes, etc.) can be diverse and uncertain.
. They deal with technical opinion, as well as fact.
Taken together, these make for technical documents that are more of a technical way of looking at the world than a solution, unique or otherwise, to a technical problem. In such a situation you can expect opinion to predominate.
Like other trade associations and institutions, API (and ASME) operate using a structure of technical committees. It is committees that decide the scope of codes, call for content, review submissions and review the pros and cons of what should be included in their content. It follows therefore that the content and flavour of the finalized code documents are the product of committees. The output of committees is no secret – they produce fairly well-informed opinion based on an accumulation of experience, tempered, so as not to appear too opinionated or controversial, by having the technical edges taken off. Within these constraints there is no doubt that API 510 Pressure Vessel Inspector API codes do provide sound and fairly balanced technical opinion. Do not be surprised, however, if this opinion does not necessarily match your own.
API and ASME documents use terminology that occasionally differs from that used in European and other codes. Non-destructive examination (NDE), for example, is normally referred to as non-destructive testing (NDT) in Europe and API work on the concept that an operative who
performs NDE is known as the examiner rather than by the term technician used in other countries. Most of the differences are not particularly significant in a technical sense – they just take a little getting used to. In some cases, meanings can differ between ASME and API codes (pressure and leak testing are two examples).API 510 Pressure Vessel Inspector API codes benefit from their principle of having a separate section (see API 510 section 3) containing definitions. These definitions are selective rather than complete (try and find an accurate explanation of the difference between the terms approve and authorize, for example). Questions from the ICP examination papers are based solely on the terminology and definitions understood by the referenced codes. That is the end of the matter.
Historically, both API and ASME codes were based on the United States Customary System (USCS) family of units. There are practical differences between this and the European SI system of units. SI is a consistent system of units, in which equations are expressed using a combination of base units. For example: Stress = pressure X diameter / 2 X thickness In SI units all the parameters would be stated in their base units, i.e.
Stress: N/m2 (Pa)
Pressure: N/m2 (Pa)
Compare this with the USCS system in which parameters may be expressed in several different ‘base’ units, combined with a multiplying factor. For example the equation for determining the minimum allowable corroded shell thickness of storage tanks is:
tmin = (2.6H – 1)DG/SE
where tmin is in inches, fill height (H) is in feet, tank diameter (D) is in feet, G is specific gravity, S is allowable stress and E is joint efficiency.
Note how, instead of stating dimensions in a single base unit (e.g. inches) the dimensions are stated in the most convenient dimension for measurement, i.e. shell thickness in inches and tank diameter and fill height in feet. Remember that:
. This gives the same answer; the difference is simply in the method of expression.
. In many cases this can be easier to use than the more rigorous SI system – it avoids awkward exponential (106, 106, etc.) factors that have to be written in and subsequently cancelled out.
. The written terms tend to be smaller and more convenient.
1.3.3 Trends in code units
Until fairly recently, ASME and API codes were written exclusively in USCS units. The trend is increasing, however, to develop them to express all units in dual terms USCS(SI), i.e. the USCS term followed by the SI term in brackets. Note the results of this trend:
. Not all codes have been converted at once; there is an inevitable process of progressive change.
. ASME and API, being different organizations, will inevitably introduce their changes at different rates, as their codes are revised and updated to their own schedules.
. Unit conversions bring with them the problem of rounding errors. The USCS system, unlike the SI system, has never adapted well to a consistent system of rounding (e.g. to one, two or three significant figures) so errors do creep in.
The results of all these is a small but significant effect on the form of examination questions used in the ICP examination and a few more opportunities for errors of expression, calculation and rounding to creep in. On balance, ICP examination questions seem to respond better to being treated using pure USCS units (for which they were intended). They do not respond particularly well to SI units, which can cause problems with conversion factors and rounding errors.
1.4 Code revisions
Both API and ASME review and amend their codes on a regular basis. There are various differences in their approach but the basic idea is that a code undergoes several addenda additions to the existing edition, before being reissued as a new edition. Timescales vary – some change regularly and others hardly at all. Owing to the complexity of the interlinking and crossreferencing between codes (particularly referencing from API to ASME codes) occasional mismatches may exist temporarily. Mismatches are usually minor and unlikely to cause any problems in interpreting the codes. It is rare that code revisions are very dramatic; think of them more as a general process of updating and correction. On occasion, fundamental changes are made to material allowable stresses (specified in ASME II-D), as a result of experience with material test results, failures or advances in manufacturing processes.
1.5 Code illustrations
The philosophy on figures and illustrations differs significantly between ASME and API codes as follows:
. ASME codes (e.g. ASME VIII), being construction-based,contain numerous engineering-drawing style figures and
tables. Their content is designed to be precise, leading to clear engineering interpretation.
. API codes are not heavily illustrated, relying more on text. Both API 510 Pressure Vessel Inspector and its partner pipework inspection code, API 570, contain only a handful of illustrations between them.
. API Recommended Practice (RP) documents are better illustrated than their associated API codes but tend to be less formal and rigorous in their approach. This makes sense, as they are intended to be used as technical information documents rather than strict codes, as such. API RP 572 is a typical example containing photographs, tables and drawings (sketch format) of a fairly general nature. In some cases this can actually make RP documents more practically useful than codes.
1.6 New construction versus repair activity
This is one of the more difficult areas to understand when dealing with ASME and API codes. The difficulty comes from the fact that, although ASME VIII was written exclusively from the viewpoint of new construction, it is referred to by API 510 Pressure Vessel Inspector in the context of in-service repair and,to a lesser extent, re-rating. The ground rules (set by API) to manage this potential contradiction are as follows (see Fig 1.1).
. For new construction, ASME VIII is used – and API 510 Pressure Vessel Inspector plays no part.
. For repair, API 510 Pressure Vessel Inspector is the ‘driving’ code. In areas where it references ‘the construction codes’ (e.g. ASME VIII), this is followed when it can be (because API 510 Pressure Vessel Inspector has no content that contradicts it).
. For repair activities where API 510 Pressure Vessel Inspector and ASME VIII contradict, then API 510 Pressure Vessel Inspector takes priority. Remember that these contradictions are to some extent false – they only exist because API 510 Pressure Vessel Inspector is dealing with on-site repairs, while
ASME VIII was not written with that in mind. API 510 Pressure Vessel Inspector Two areas where this is an issue are:
. some types of repair weld specification (material, fillet size, electrode size, etc.);
. how and when vessels are pressure tested.
interpreting API and ASME codes In summary, then, the API and ASME set of codes are a fairly comprehensive technical resource, with direct application to plant and equipment used in the petroleum industry. They are perhaps far from perfect but, in reality, are much more comprehensive and technically consistent than manyothers. Most national trade associations and institutions do not have any in-service inspection codes at all, so industry has to rely on a fragmented collection from overseas sources or nothing at all. The API ICP scheme relies on these ASME and API 510 Pressure Vessel Inspector API codes for its selection of subject matter (the so-called ‘body of knowledge’), multiple exam questions and their answers. One of the difficulties is shoe-horning the different approach and style of the ASME codes (V,VIII and IX) into the same style of questions and answers that fall out of the relevant API documents (in the case of the API 510 Pressure Vessel Inspector ICP these are API 571/572/576/577). Figure 1.2 shows the situations. It reads differently, of course, depending on whether you are looking for reasons for difference or seeking some justification for
similarity. You can see the effect of this in the style of many of the examination questions and their ‘correct’ answers. Difficulties apart, there is no question that the API 510 Pressure Vessel Inspector API ICP examinations are all about understanding and interpreting the relevant ASME and API codes. Remember, again, that while these codes are based on engineering experience, do not expect that this experience necessarily has to coincide with your own. Accumulated experience is incredibly wide and complex, and yours is only a small part of it.