The AS2885 approach to pipeline safety management (the “SMS”, the safety management study and its associated facilitated workshops) uses a tried-and-true methodology of focussing on cause-and-control. 

As a facilitator of the SMS workshops, I constantly ask people to think about why the pipeline would fail, what caused it, what is the failure mode. 

Because if we’ve identified failure modes, we can then design controls against those causes, and test whether the controls are effective. 

Simply saying ‘the pipeline is risky’ doesn’t do it for me (and spoiler alert: the risks can be managed.  Australia has never had a fatality related to a pipeline failure, ever).  And that simpe thinking (pipelines are risky) doesn’t help engineers solve it at all. 

I love the tangibility of Australia’s SMS approach: the realness of talking about actual failure modes, actual ways that the pipeline might leak or rupture.  Once we can define clearly the failure modes, then we’re in a better position to prevent them.

This week I’ve spent a terrific couple of days in the atmosphere of AS2885 SMS workshops.  On one day, I delivered a training course about SMS workshops to a fantastic group of about 18 pipeliners who were engaged, questioning, challenging and receptive to the content.  I was entirely fired up after that day, knowing that the industry is in good hands.

Then the next day, I facilitated one of those SMS Workshops for a pipeline, and that involved another set of about 15 pipeliners, and we talked about an actual pipeline and the actual possibilities of threats the pipeline might face, and how we were going to design in controls that work to prevent those threats from becoming hazards/incidents/failures. 

I thoroughly enjoyed both days – one teaching, one facilitating.

I’m also now thinking about the role of the Facilitator into the future, as the industry possibly adopts the usage of more AI in the meeting room with us. 

And so my question is to the users of facilitators out there:  what do you want in the Facilitator?  I’m wondering if we need to develop standardised approaches to the role, for AS2885 workshops, or more standardised reporting requirements.  Do we encourage the use of AI to summarise recorded meetings? 

If you hire facilitators for AS2885 workshops, and have thoughts about this, I’m interested. Contact me and let’s discuss.

In the Australian pipeline industry, AS2885 is the standout standard for ensuring pipeline safety through its full lifecycle. Unfortunately (or fortunately), because it is such a solid Standard, it’s often treated as though it is a textbook and as if “it” designs/operates the pipeline.

It doesn’t.

Engineers do.

AS2885 provides the structured safety framework, covering threat identification and control, risk evaluation, design factors, and verification. But it deliberately avoids prescribing many detailed design and operational outcomes. That’s intentional. The standard assumes competent engineers will apply judgement to real-world conditions.

Problems arise when compliance replaces thinking.

Across projects and reviews, technical decisions are sometimes justified by citing clauses, rather than demonstrating engineering reasoning. Threat assessments become templated. MAOP becomes a spreadsheet output. Rupture mitigation becomes a checklist. Documentation exists, but the technical logic is thin.

Pipeline safety is not achieved through documentation (though that’s so very important); pipeline safety is achieved through knowledge and understanding.

Every pipeline has a unique combination of route, materials, operations, and protection systems. AS2885 expects engineers to interpret how these interact and to justify why the resulting design is safe.

A simple test of real competency is this:
Can the engineer explain why the design/operational condition is safe without immediately pointing to a clause?

Clause compliance should support engineering judgement, not replace it.

AS2885 defines the framework. Engineers deliver the safety outcome.

The difference is where professional competence lives.

(disclaimer: the above article is based on a bunch of dot points from me, but tbh, ChatGPT wrote it. And by admitting that here (I couldn’t publish without disclosing the AI input) … it’s probably the last time I’ll publish a ‘mostly AI’ article like this, because, I don’t like how it makes me feel. Interesting! …

A few things going on in the past week that can be classified as ‘random updates’:

CSA Z767 Process Safety Management Standard

I listened to the podcast “Process Safety with Trish & Traci”, the episode dated 20Aug2024, titled “World’s first: process safety management standard”. 

It is, apparently, an industry-agnostic standard, setting benchmarks for organisations not covered by traditional process safety approaches.  It was originally published in 2017, and recently updated in 2024 to incorporate industry feedback and expand key sections.

If you’re already aware of this one, let me know what you think.  I’ll be reviewing it to see if there’s anything we can learn from it to improve our own approach to process safety for our Australian long distance, high pressure, buried pipelines that go through public spaces.

Protocols for Studying & Learning

I’m always interested in learning about learning, and better understanding how we can improve our competence and knowledge, especially about things we need to know about.

The Huberman Lab podcast dated 26Aug2024, “Optimal Protocols for Studying and Learning” was really interesting to me. It essentially debunked the idea that reading something over and over again is an effective way to learn anything. No, it’s when we ‘test’ ourselves to recall what we’ve just read – that’s when the learning occurs.  (Wish I’d known that in my Uni days.  Though I suppose it was all those rather competitive group discussions I got involved in that helped me learn it, after all).  So I’m taking that on board (we never stop learning, right?).  Now I know that if I need to remember something, it’s more effective to read it until I understand it, and then make the effort to put the book aside and retrieve the information from my own brain.

AS2885.1 Revision Scoping

Thanks to James C for the recent meeting to continue the effort to resolve the scope of the next Part 1 revision.  We currently have about 100 line items on the scope list; just about every Section has a line item against it for revision.  Some are editorial, many are technical.  We are always striving to improve the content of our Standards.

A relevant question was asked by a member of the team:  how do those of us involved with current revisions factor in the upcoming “one-document” strategy for AS2885?  The simple (perhaps unhelpful) answer is to, for now, carry on with ‘business as usual’ how we’ve done it so far, with the editing and the changes to the text.   The strategy is still being developed, and the long-term plan to combine the parts should not stop the words-work of editing the Standard to improve the technical content.

What might help is to think about what ‘topic’ is being worked on, i.e., can it be tagged with a category, like “corrosion”, or “external interference”, or “fluid control”.  As mentioned, there are many advances in AI and text-based engines which may mean the way Standards are written (and read) will evolve to be much more tied to ‘tags’ and keywords, so that all information related to that tag can be brought together when asked. 

But in the meantime, we still need to write the relevant words.  No AI chatbot can replace the knowledge and experience in those rooms of committee work. 

Thanks again to all involved in writing the words (and then interpreting them later when someone reads it completely differently to what we meant).  Writing Standards is an ongoing, challenging task.

Susan

Sept 25, 2024

I had a great chat with AS2885 legend Peter Tuft last week.  We reminisced on the creation of Part 6 during the revision of Part 1 from 2013 to publication in 2018.  Oh how different the pipeline world was in 2013!  No talk of hydrogen.  No talk of “energy transition” nor “shut down the fossil fuel industry”.  Back then it was go go go, and then some.  And oh it was fun.  This enthusiasm and expansion of the industry was particularly because of the LNG export pipelines being built in Queensland at the time; our first foray into 42” pipelines in Australia.  Those were the days, eh.  And it was only ten years ago…

So anyway, back then it made a lot of sense to separate the SMS (safety management study) process out of Part 1, which is the Design and Construction part of the AS2885 series. 

The SMS process, previously simply referred to as “pipeline risk assessment” when it first appeared in the 1997 version of AS2885.1, had evolved enormously over the years. 

We were especially pleased, as we congregated in early days of the revision, to discuss the application of the process to more than just detail design. 

It was proving to be an extremely useful tool to apply for operating pipelines as well, to review and confirm the safe operational practises of existing pipelines. 

This is why the separation of the process out of the Design and Construction document, into its own document (Part 6), made so much sense at the time.

In 2013 through to 2018, we also still used paper copies of the Standard mostly.  Usage of online or electronic versions of the documents was not the norm.  Many, maybe even most, of us out in the wilds of the industry were still using hard copy versions of the Standard through those years (and even now, I’ll admit). 

I will capitulate, though, that Peter Tuft himself has used exclusively electronic versions only, for many, many years – since about 2015 or earlier, I’ll bet. 

All this preamble to say thanks to Peter for all his work to separate the Parts.  Now we’re going to undo all that work, and put them together again! 😊 

Guidance Words / Appendices.

Peter and I also talked about the fact that probably half of the ~1000 pages of AS2885 are guidance words, contained in the Informative appendices. 

We talked about whether all that guidance and informational text needs to be, or should be, (shall be?) in the one-part Standard. 

This question comes up for discussion within the Main Committee every few years.  I’m always willing to listen to the arguments – take it out or leave it in – but usually land in the same place:  if we take it out of the Standard, how do we ensure that users of AS2885 actually utilise the guidance to help with using the Standard.  If it’s in a separate document, I can almost guarantee that it won’t be sourced to be read, particularly by those who need it most: those in a hurry to just figure it out in our ‘just in time’ style of engineering these days.

So while we contemplate the one-part AS2885 Standard, we need to consider how much of that guidance we include.  And how it’s included. 

If we consider the online / electronic approach, then I like to imagine a style similar to the Canadian CSA Z662 approach:  they have hyperlinks to the guidance within the pdf.  Now that’s an elegant solution. 

(So far, Standards Australia isn’t on board with this type of document.  But our publication date is still years away, so here’s hoping for that evolution before we publish).

I also have another vision of the future use of complex Standards like AS2885:

We ask the document “AI” to produce a collated bespoke Standard that addresses the issue we need resolved at that moment. 

For example: “Produce for me an AS2885 Standard for road crossings”, or “Produce an AS2885 Standard for Location Classification”.  And the AI (c’mon, it’s inevitable) crawls through the 1000 pages and just ‘prints’, or returns, the relevant requirements to that issue along with all the guidance and explanatory text.  But of course then we lose the context and flavour that the poor ole standards writers have agonised over during the five years spent writing the darn thing.  So I’m also hesitant to say that’s a good way for the future.  But alas, it might be inevitable.

So when you’re thinking about Standards this week, think about how much guidance and explanatory text should really be included in a Standard.  The Standard is meant to set out the minimum requirements.  If we stick to that definition, perhaps there should only be shall statement in the document, and everything else should not be in the Standard, but found in separate guidance documents.  There’s fighting words.

Susan
September 16, 2024