Chapter 1

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-

1
 Quick Guide to API 510

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) 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, equip-
ment 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 codes do provide sound and fairly balanced
technical opinion. Do not be surprised, however, if this
opinion does not necessarily match your own.

2
 Interpreting ASME and API Codes

1.3.1 Terminology
API and ASME documents use terminology that occasion-
ally differs from that used in European and other codes.
Non-destructive examination (NDE), for example, is nor-
mally 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
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.
1.3.2 Calculations
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:
pressureðpÞ  diameterðdÞ
StressðSÞ ¼
2  thicknessðtÞ

In SI units all the parameters would be stated in their base

units, i.e.
Stress: N/m2 (Pa)
Pressure: N/m2 (Pa)
Diameter: m
Thickness: m

3
 Quick Guide to API 510

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:
2:6ðH  1ÞDG
tmin ¼
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

4
 Interpreting ASME and API Codes

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 cross-
referencing between codes (particularly referencing from API
to ASME codes) occasional mismatches may exist tempora-
rily. 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 signifi-
cantly between ASME and API codes as follows:
. ASME codes (e.g. ASME VIII), being construction-based,

5
 Quick Guide to API 510

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 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 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
plays no part.
. For repair, API 510 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 has no content
that contradicts it).
. For repair activities where API 510 and ASME VIII
contradict, then API 510 takes priority. Remember that
these contradictions are to some extent false – they only
exist because API 510 is dealing with on-site repairs, while

6
 Interpreting ASME and API Codes

Figure 1.1 New construction versus inspection/repair: the

ground rules

ASME VIII was not written with that in mind. 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.

1.7 Conclusion: interpreting API and ASME

codes
In summary, then, the API and ASME set of codes are a
fairly comprehensive technical resource, with direct applica-
tion 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 many

7
 Quick Guide to API 510

others. 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 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 ICP these are API 571/

Figure 1.2 Codes in, questions out

8
 Interpreting ASME and API Codes

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 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.