Four weeks since my last post – apologies. I blame an interacting combination of busyness, short holidays and temporary lack of inspiration.
When do you consider a possible but improbable scenario as a design case (for which the design must comply fully with AS 2885) and when do you consider it as an abnormal situation that should be subject to risk assessment? A recent enquiry was a good example of how it is possible to dig yourself into a hole by selecting progressively more unusual situations as cases requiring strict design compliance.
In this instance the design task was to determine acceptable vehicle loads on a buried pipeline. The situation causing anxiety was a scenario where the landowner gets heavy farm equipment bogged deeply in the backfill over the pipe. (If you recognise your project here, don’t feel singled out – others have been here too!) The calculations were suggesting that through all agricultural land the pipeline would need to be buried with 1500 mm cover in order to avoid stresses that would exceed those permitted by AS 2885.
But is getting a 40 t vehicle bogged directly over the pipeline something that should be considered as a design case? To me it looks like an unusual failure that would be more appropriately treated through the safety management study. My advice was to assume normal firm ground for all of the external load calculations and to do a risk evaluation for the bogging case. The likelihood of a heavy vehicle ever becoming bogged has to be pretty low (after all, the landowner himself has strong incentives not to get 40 t of equipment stuck in a ditch and it will probably never happen). The consequences are … nothing much. The pipe stress might (or might not) exceed the value permitted by AS 2885, but any sort of damage or failure is almost inconceivable. Hence from the AS 2885 risk matrix the risk will the Low or Negligible.
A situation that involved different technical issues but was philosophically the same arose when a gas pipeline with a large drop in elevation had theoretical potential to slightly exceed MAOP at the downstream end if a whole lot of control systems failed. Conventional SIL analysis and the rules of the company required that this possibility be designed out. Because the control system could not be made 100.000% reliable the only guaranteed solution was to increase the pipe wall thickness, at great expense.
After much debate a special safety management study workshop was convened to look at risk evaluation for this single scenario. The likelihood of exceeding MAOP was extremely low. The consequences of exceeding MAOP by a small amount are negligible. (In fact AS 2885 allows 10% overpressure for “transient” events, but in this case while the overpressure was modest its duration was a bit too long to be considered as “transient”.) On this basis the risk evaluation came up with a risk level that was clearly acceptable.
In both of these examples a very unusual situation was being treated as a design case that must comply with all applicable standards in every way. But it is entirely reasonable to take a risk-based approach and consider the likelihood and consequences of the unusual situation, and then design according to the risk outcome. Both examples found that the consequences were minimal and the likelihood low so the risk was acceptable.
But what if you take a risk-based approach and the consequences of the unusual event are very serious? Well, the risk evaluation would show that the risk is intolerable and some other design would be necessary. But finding that outcome is inherent in taking a risk-based approach. So it seems to me there does not seem to be any cause for concern about where you draw the line between a compliance-based design and a risk-based design.
I’m not suggesting that risk-based design can be used as an excuse for deviating from a Standard whenever things get difficult. But for those infrequent situations where abnormal loads are leading you towards a nonsensical design a carefully considered risk-based approach might be the escape clause you need.