Closure (?)

I get annoyed when I find an interesting blog that hasn’t been updated for months or years.  Hmmm.

My last post was in January 2014, over two years ago.  I just ran out of inspiration as unexpectedly as I found the inspiration to start.  A lesser factor is my role as chair of the AS 2885.1 committee which is working on a major revision of the Standard.  I did not want to appear to be pronouncing on matters that might be quite important to a revised AS 2885.1 but which are still unresolved (and Standards Australia has rules about that sort of thing).  And a gradual but accelerating transition to retirement is relevant too because I know I’m getting increasingly out of touch with the latest practices.

Since this blog still gets several hundred unique hits per month and has over 300 followers I thought I should (very belatedly) do you all the courtesy of a (probable) closing post.  I won’t rule out further entries but don’t hold your breath waiting.

I have been immensely gratified by the success of Pipelines Oz and its wide readership.  Despite being written very specifically for the Australian pipeline industry it gets a surprising number of hits from countries all over the world.  All that has greatly exceeded my expectations.

Thanks for reading!

Approval revisited

It’s quite a long time since I wrote about approval under AS 2885.  Since then the 2012 amendment to AS 2885.0 added considerable detail although the basic requirement that certain items must be approved by the “Licensee” remains unchanged.  Nevertheless there is still some confusion on a few aspects of approval.

It is worth reiterating that approval under the Standard means approval by the organisation responsible for the pipeline (the Licensee), not the regulator.  The regulators in each state may have additional requirements, but that is separate to compliance with AS 2885.

There are only a few basic elements to the approval requirements:

• Just about everything under AS 2885 must be approved by somebody
• Certain things must be approved by the Licensee and not delegated
• Other things may be delegated, and the Licensee must prepare an approvals matrix to define who can approve what
• Approval can only be granted by people or organisations who are competent, and that competence must be audited occasionally

Although the Standard does not spell it out, it seems reasonable to interpret these rules as having the objective of ensuring that senior management of the Licensee organisation are aware of, and knowingly take responsibility for, everything to do with the design, construction and operation of a pipeline and in particular are directly aware of the important documents that have been nominated as not to be delegated.  The note at the end of Clause 3.1 in Part 0 gives a pretty clear clue:  “Approval demonstrates that the Licensee has accepted responsibility for the safety and integrity of the pipeline for the matters addressed by the document.”

The two main areas of uncertainty appear to be who can be the Licensee’s official representative for the purpose of approval under the Standard (given that the Licensee is an organisation, not a person), and the “design and construction records” item in the list of things that cannot be delegated.

The Standard does not clearly indicate who can be the Licensee’s representative.  The term “Licensee” itself gives a hint – I take the view that the representative should be the person who is authorised to take responsibility for all other things required under the Licence such as approving reports to the regulator.  (This assumes that the pipeline is in fact licensed, which is another ambiguity I’ll come back to shortly.)

It follows that the representative does not have to have full technical expertise in every matter that they are required to approve.  This has caused a bit of discussion around some parts of the industry but is not an unusual situation.  All senior executives must make decisions on a variety of matters in which they do not have full personal competence.  It seems to me that part of the executive role is to be competent in selecting support people who can provide trustworthy advice.  Certain approvals cannot be delegated, but there is a difference between delegation and taking appropriate expert advice.

It also follows from this that for pipelines in Queensland the representative does not have to be an RPEQ, which is a question that arises from time to time.

One interpretation of the “design and construction records” item is that it means all design and construction documents.  However it is unreasonable to expect the Licensee to approve (without delegation) every minor document such as data sheets for DN 25 valves.  A more reasonable interpretation is that it applies to the design and construction records handed over to the operator on completion of commissioning. Any conscientious Licensee should want to be satisfied that the documentation received from the project team provides an adequate basis for the long term future operation and maintenance of the pipeline.

Finally, a bit about who is the “Licensee”.  There are a couple of different definitions in the Standard (unfortunate).  Clause 1.6.27 of Part 1 has one definition.  There is a similar but expanded definition in Part 0, Section 2, paragraph (c).  Because the latter is more comprehensive I’ll rely mainly on that:

(c) The Licensee is the entity responsible for the design, construction, inspection, testing, operation and maintenance of a pipeline. The Licensee is responsible for the safety and integrity of the pipeline.

Where a pipeline is licensed, the Licensee is the entity held responsible by the regulatory authority.

Where a pipeline is not licensed, the Licensee is defined in legislation or approval documentation that applies to the pipeline.

The first paragraph is pretty clear.  The subsequent paragraphs clarify that the term “Licensee” does not necessarily imply that a pipeline is actually licensed.  The clear intention of the definition is that the Licensee is the entity responsible.  Depending on legislation in each state or country that may be a literal licensee (of a licensed pipeline) or or it may be an entity referred to by some other title but whom the regulatory authority views as holding responsibility for the pipeline, regardless of the actual terminology.  Whether that intention actually meshes correctly with the legislation is a moot point.

This has ended up being rather longer and more complicated than I intended (and probably pretty dry).  However approval is an important requirement, and the principles outlined in the bullet points near the top of this post remain clear and simple.

San Bruno – organisational analysis

If you are in this industry you must be aware of the San Bruno failure in September 2010. The immediate causes are now well known.  Equally interesting is recent analysis of the underlying organisational failures in both the pipeline owner and the regulator which allowed a catastrophic latent defect to remain undetected for over 50 years. Jan Hayes of ANU and the EPCRC has reviewed the organisational factors that contributed to this disaster. She spoke about the findings at the APIA Convention in Adelaide, and for members of the APIA Research and Standards Committee the full report is available from the EPCRC website (RP6.4-02). The detailed analysis and linking of technical and organisational failures is good reading.

Some of the findings reported seem to be unique to the USA, where the pipeline industry is much older and hence has accumulated a number of legacy issues. Nevertheless I would like to highlight a few selected points for the Australian industry:

• Avoid disconnects between risk/safety management and real world performance. Actions must be linked to consequences. The PG&E integrity management system was divorced from field data and took on a life of its own that had no grounding in reality. This is a warning that systems can take on a symbolic value that is detached from the originally intended use of the system, especially when divorced from any real world feedback. Risk management is always problematic when the model itself becomes reality. I think (hope) that the AS 2885 SMS process minimises this problem, but it is not inconceivable that it could be misused.
• In particular, blind compliance divorced from risk assessment does not assure safety. Compliance with standards and regulations is not enough – either to prevent accidents or to meet overall legislative duties in a duty of care regime. AS 2885 is a minimum standard.
• Identification of risks must be wide-ranging, not constrained by models or preconceptions or compliance with rules. The SMS process explicitly requires this approach, but I have too often seen it misused through thoughtless application of checklists as discussed in the comments to the previous post.
• Good regulation is a benefit to the industry as well as the community. Some companies may need to be protected from themselves. More importantly, the rest of the industry needs to be protected from such companies. A serious failure caused by a maverick could have drastic repercussions for all the conscientious players. Effective regulatory oversight of the whole industry protects the whole industry.

The final section of the EPCRC report on San Bruno contains a list of probing questions that companies and pipeline managers should ask themselves to assess how well they are avoiding the organisational problems that lead to catastrophe. Worth reading and applying.

SMS preparation

The most prolific commenter on this blog is Chris Hughes of OSD who is passionate about good pipeline engineering.  Chris and I communicate regularly off-line as well, and he has offered the following for me to reproduce here.  I’ll add a comment or two at the end.

Far too many people in the pipeline industry seem to think that the SMS is a workshop where a group of people sort out the design of the pipeline from a safety point of view, whereas the workshop is only one stage in an ongoing process of ensuring the integrity of a pipeline and the safety of the operators and the public. 

AS2885.1 Clause 2.2.1.1 states very clearly:

For new pipelines, or modifications to existing pipelines, the detailed design and the safety management study are undertaken as integrated iterative processes. The output of these processes is a design (generally shown on alignment sheets), and a safety management study document (generally recorded on a database). 

In other words the design process should at all times be considering the threats to the pipeline and how to best mitigate those threats, and documenting all the reasoning behind their decisions.  The first part of 2.2.1.1 makes this clear by saying:

All aspects of the safety management process shall be documented with sufficient detail for independent or future users of the safety management study to make an informed assessment of the integrity of the process and its outcomes, including the identification of threats and the reasoning behind the assessment of the effectiveness of the control measures applied.

I have lost count of the number of times I have turned up to facilitate an SMS workshop only to find that there was no pre-populated list of threats, let alone a detailed assessment of how the design was intended to mitigate those threats – I have even been asked to bring my own list of generic threats.  How anyone thinks they can design a pipeline without knowing what the threats to it are is beyond me – except of course they probably think they can use AS 2885 as a design cookbook to avoid having to think.

The workshop phase of the SMS is for validation purposes only: it should never be used to populate the threat list.  And the mitigations need to be thought through properly for each threat and not just cut and pasted from threat to threat: I have seen SMS threat and mitigation lists presented to a workshop where DBYD and patrolling are listed as mitigations against a truck bogging in the trench.  The validation workshop should be just that – a validation of a properly thought out SMS prepared as an integral part of the design process.

The normative Appendix B states in B3.2:

The safety management study shall be undertaken by personnel with expertise in each component of the design, construction and operation of the pipeline, including, or with the support of, personnel closely familiar with the land uses and environments along the entire route.

In other words the pipeline designer needs to be aware of how the pipeline will be constructed and operated, and also must take into account the needs and requirements of the owners of the land across which the pipeline is laid.  Again in many cases I have seen the construction, operation and land use specialists invited to the workshop only for them to tell the workshop that the pipeline can’t (or won’t) be built or operated in the way the designer assumed, and that the landowners do things that the designer had not anticipated: the designer should be acquiring this information during the design phase rather than at the workshop so that the design takes all these factors into account.

So please remember and appreciate that the SMS process starts the moment the contract is signed for any design work to commence, be that feasibility, FEED or detailed design, and is not just an irritation stuck on to the end of the design process.

—————

On first receiving this I was a little taken aback by one paragraph, because I routinely run workshops where there is no pre-populated list of threats.  In fact in many cases the value of the workshop is in the synergy of group brainstorming to identify threats that might otherwise be overlooked.  However SMS workshops are run for a surprisingly wide range of purposes, and for a detailed design SMS, undertaken when the design is mature, I agree 100% with Chris that the workshop is indeed just a validation review of work that should have already identified and mitigated all conceivable threats.

For workshops run for other purposes, such as conceptual design, early FEED phase, encroachments or operational review there are several reasons why a fully pre-populated threat list might not be the best approach.  In the early stages of design the workshop brainstorming is valuable, and will identify many more issues than could be found by a design engineer sitting alone at his desk.  For an encroachment situation involving external stakeholders the workshop is a very effective means of getting all the parties to understand each others’ positions and then identify threats and negotiate solutions accordingly.  None of which contradicts Chris’ view that the detail design SMS requires all threats to have been fully identified and mitigated before the workshop starts. 

Re-read Chris’ last paragraph above – I couldn’t agree more.

Risk matrix selection

I am surprised too often by people who think that they can do an AS 2885 risk assessment by using some risk matrix other than that published in the Standard.  AS 2885.1 makes quite clear that risk evaluation must be done using the risk matrix in Appendix F.  The words in the Standard say that the severity class and frequency of occurrence shall be selected from Tables F2 and F3, and the risk rank shall be determined from Table F4.  The only flexibility is some limited scope to adjust the severity scale to reflect the nature of the pipeline, which really applies only to the supply dimension of the consequences – interrupting the flow from a gathering line is clearly not of the same severity as interrupting gas supply to a major city.

Using the AS 2885 risk matrix is important partly because it ensures consistency across the industry, but more fundamentally because it has been calibrated and shown to produce results that are broadly consistent with the best alternative methods used internationally.  I wrote about that here.  (The calibration might not be perfect in absolute terms but at least it shows consistency with worldwide practice).  I view this validation of the matrix as highly important.

Although the frequency scale in the AS 2885 matrix does not currently show numerical guidelines, its intent is clearly to span a range of many orders of magnitude.  If the words don’t convey that then a bit of history will.  When risk assessment was first introduced in the 1997 edition of the Standard it was thought that a handbook would help the industry come to grips with this new approach.  Accordingly SAA HB105-1998 was published.  It was superseded by the 2007 edition of the Standard which incorporated much of its content.  However one thing that got lost was a table of numerical frequency guidelines.  I won’t reproduce that table because the risk matrix was different then, but I presented an interpretation of it in this post.

Note that the lowest frequency (Hypothetical) implies a probability approaching the 1 in a million level.  In contrast, I have seen corporate risk matrices in which the bottom of the frequency scale is a probability of 1%.  Most company matrices do go lower than that but few seem to go as low as AS 2885 (the variability itself is remarkable).  Notwithstanding their very wide use and acceptance, I really wonder if anyone has ever thought about calibrating their corporate risk matrix.  Clearly, if you run the same analysis through a matrix where the bottom of the scale is 1%  you are going to get very a different result from AS 2885.  Quite apart from the fact that the AS 2885 matrix is mandatory, would you prefer to use some “approved” but arbitrary company matrix or the calibrated AS 2885 version?

Where a company insists on using their corporate matrix, I insist in turn that they do it in parallel or outside the AS 2885 SMS workshop, not as a substitute.  There is no option – if you are doing an AS 2885 safety management study then the risk evaluations must be done using the AS 2885.1 risk matrix from Appendix F.

Penetration resistance – existing pipelines

I’ve written before about penetration resistance and the B-factor as specified by AS 2885.1 Appendix M, but that post didn’t distinguish between design of a new pipeline and review of an existing line.  From time to time I see confusion in this area so it seems worth attempting a clarification.

The design task is relatively simple (emphasis on relatively).  For each location along the pipeline:

1. Identify the maximum credible excavator size and worst-case tooth type (which should be based on a proper land user survey)
2. Determine the location class
3. From the location class select a B-factor
4. Calculate the wall thickness required to resist penetration by the selected excavator and B-factor

All that is fairly well described in Appendix M.

But existing pipelines also need assessment of penetration resistance as part of the safety management study review.  Here the objective is quite different because the wall thickness has already been determined and isn’t going to change (except in truly extraordinary circumstances).  Rather the purpose of the penetration resistance calculations, as I see it, is to provide data that can be used during risk evaluation to support judgements about the likelihood of penetration by various types of equipment.  There are no design criteria as such, it’s just a calculation for information.

My approach is to use the Appendix M equations to work out the sizes of excavator that can penetrate at B = 0.75 and at B = 1.3.  I view the B = 0.75 case as the condition in which an excavator digging normally has a reasonable chance of penetrating if the impact conditions are optimum (which is not the same as saying that penetration is probable).  The B = 1.3 case is a lower bound to excavator size at and below which no machine has any chance of penetrating no matter how aggressive the assault.  In between there is a progressively lower probability of penetration.  I find this provides a useful basis for making judgements about the likelihood of penetration when assessing any given threat – whether it’s a backhoe digging for utility maintenance or huge machine working in a big gravel pit.

I’m sometimes asked why I don’t do the calculation for B = 1.0, as listed in Appendix M.  In the light of the explanation above I hope the answer is apparent:  B = 1.0 is just a point in the middle of the range and has no particular significance.

This approach won’t work if you don’t have a basis for estimating the size and type of machinery that might be digging near the pipeline.  I’ve written about that before.  Having that data is important for both design and operational review.

Road crossings and high design factor

The rules for allowable stress at road crossings are given in Clause 5.7.3(c) of AS 2885.1.  Recently I had an interesting query which illustrated a bit of a gap in these rules.

Basically the combined equivalent stress should be calculated according to API RP 1102 and must not exceed 72% SMYS at formed road and track crossings but may be up to 90% SMYS at informal crossings where (for example) a farmer may drive a vehicle across the pipeline on infrequent occasions.  All of that is fine for design of a new pipeline.

The problem arises when someone wants to put a road or track over an existing pipeline at a location where the wall thickness corresponds to a design factor of 0.8.  There is just no way to achieve strict compliance with the stress rules – the hoop stress alone may be up to 80% SMYS so a combined equivalent stress of only 72% SMYS is clearly impossible.   The pragmatic thing to do is to build a bridging slab over the pipeline to isolate it from the vehicle loads (and it may also provide external interference protection).  If the slab is properly designed to distribute the load away from the pipe that will be a perfectly satisfactory way of protecting the pipe against high stresses.

But it still won’t comply with the current words in the Standard.  It’s a legalistic problem, not a practical problem.   The combined stress will exceed the 72% limit set by the Standard for a formed road crossing, even though the pipe will experience no greater load than in the adjacent paddock.

Now that we have increasing numbers of pipelines built with design factor of 0.8 this is a question that might arise more often.  Common sense should prevail – put in a bridging slab and satisfy yourself that the pipe stress state will not be adversely affected.  For anyone who is worried about black-letter compliance  I suggest you refer to Clause 1.6.2 of Part 0 which deals with departures from the Standard.

A final comment:  It’s fair to say that the principle behind these rules for transverse external loads is that there is a wealth of history of successful operation with pipelines designed for up to 72% SMYS at road crossings.  Operating at 80% SMYS obviously reduces the margin for additional loads.  It just seems prudent to set a lower stress level for situations (such as road and rail crossings) where the pipe is in a more complex stress state.  At busy road and rail crossings there is the added complication of possible fatigue.  The increased limit of 90% for informal crossings is consistent with the higher stresses usually tolerated for occasional loads, and the level of comfort with this is increased by  recognition that even under gross overload the most serious failure mode is likely to be ovalling of the pipe, not loss of containment.  There is a little more on this in an earlier post.