DP Consequence Analysis Should Become Less Useless

Introduction:  I picked up a few other unofficial lessons while in Houston for the dynamic positioning (DP) conference that weren’t covered in the previous two articles.  This article looks at one of them, and shares a link to the newly released 2023 MTS DP Conference papers.  The article title comes from the first big piece of good news that is the main focus of the article.  If you don’t have time, then skip to the end for the free stuff.

Vestigial Function:  The word vestigial is used for the remains of old functions with no current practical use, like the hip bones in a whale, your tail bone, or the old 24Vdc supplies to SDP operator stations that were provided only so there would be an indication that the otherwise unused supply was lost.  The separate 24Vdc supply used to be important in older equipment, and when the design was updated and it was no longer needed, someone insisted on the old alarm, even though it no longer did anything.  It varies by system, but this is how I view most consequence analysis functions.

Consequence Analysis:  From my first introduction to it, I have never been impressed with consequence analysis.  I found it hard to take seriously an alarm that tells the operator that they lost redundancy 5 to 15 minutes ago, especially when it was simple things that an alert operator could see at a glance and should be constantly scanning for.  The trials were annoying – create obvious faults and wait forever for each alarm to be generated.  Anyone depending on these alarms was incompetent.  It only looked at the obvious (loss of vital thruster, thruster group, or power group), ignored vital functions and important situations, and wasn’t context dependent.  But it was taken seriously by old hands and must have once been useful.  It was required before IMO 645, but just wasn’t done right.  It was a system health and capability warning that did neither.  It had become a checkbox function test of questionable utility.  Thank goodness other important alarms and safety functions don’t react to the wrong stimulus and wait 5-15 minutes to act. (Yeah, I know. Just give me this one.)

Reform:  So, I was relieved, ashamed, and concerned to hear that the industry was thinking of putting together a joint task force to address the issue.  This is a relief, because we need to stop going through the motions and start providing real consequence analysis to improve safe DP operation.  Timely useful operator information would be great, and it’s a good sign of the progress that we have made in the last few years at identifying and addressing issues together, rather than as isolated and competing secretive enclaves.  That’s why I am ashamed.  One of my oldest article ideas was entitled “When Are We Going To Make DP Consequence Analysis Useful?” but I never got around to writing it.  Fortunately, Equinor (Statoil) recently presented a paper on this subject at a recent conference in Norway, and that’s what woke people up.  Good for them.  It’s a concern, because the initial ideas I heard were more like a poor quality ASOG, without any of the nuances of redundant thrust levels.  We can do better and should.

History:  A 1997 MTS paper by Doug Phillips, who always has good writing, tells us that consequence analysis was first introduced by LR and DNV rules in the 1980s, notes the limited functions available compared to the scope, contrasts the additional POSMOOR requirements, and suggests additional things that should be included.  Since then, there have been occasional papers focused on safe operation that have noted problems with consequence analysis and identified the need for improvement.  The high point might have been 2010, with a paper by Phillips/Haycock/Cargill, a paper by Marine Cybernetics (now part of DNV), and a DNV paper noted an enhanced reliability notation would “require more sophisticated consequence analysis software compared to what is generally found in today’s standard DP-control system software.”  IMCA expressed concerns in Information Note 1601, Jan/22.  So, knowledgeable people have been concerned about the ineffectiveness of DP consequence analysis for a long time.  We knew it was bad and made tools to do the job that it was supposed to do.  Congratulations are due to Equinor for challenging this and starting the ball rolling, and to the person who has picked that ball up (Yes, I know who, but didn’t ask permission, so no name).  This initiative is to be applauded and needs supported and guided in the right direction.

Requirements:  So what is the right direction?  You can tell I’m not a fan of the status quo, and was concerned about some of what I heard.  IMO 645 tells us the following:

“2.4 Based on the single failure definitions in 2.2 the worst case failure should be determined and used as the criterion for the consequence analysis (see 3.4.2.4).”

I would argue that there is more than one worst case failure in each ship, because control systems are complex and have different internal weaknesses and WCFs.  I also point out that many design concepts are incorrect and discovering the real worst case failure modes requires expert analysis.  Either the vendor has to do the FMEA or is dependent on the person who does - not great business.  Marine Cybernetics proved what experienced people already knew – static analysis isn’t enough.

“3.3.3 The values of thruster force used in the consequence analysis (see 3.4.2.4) should be corrected for interference between thrusters and other effects which would reduce the effective force.”

This is more work than is usually done.  We don’t even measure some of the important factors.

“3.4.2.4 For equipment classes 2 and 3, the DP-control system should include a software function, normally known as ‘consequence analysis’, which continuously verifies that the vessel will remain in position even if the worst case failure occurs. This analysis should verify that the thrusters remaining in operation after the worst case failure can generate the same resultant thruster force and moment as required before the failure. The consequence analysis should provide an alarm if the occurrence of a worst case failure would lead to a loss of position due to insufficient thrust for the prevailing environmental conditions. For operations which will take a long time to safely terminate, the consequence analysis should include a function which simulates the thrust and power remaining after the worse case failure, based on manual input of weather trend.”

Before I comment on this, let’s look at what was added to IMO 645’s successor - 1580.  1580 further broke environment into “wind, waves, current, etc.” but most of those are not measured by DP systems, although sometimes vital.  1580 included the available energy from alternative energy storage as a possible addition to capability analysis.  It added a separate definition of consequence analysis as “a software function continuously verifying that the vessel will remain in position even if the worst-case failure occurs.”  This last isn’t much different from the 3.4.2.4 discussion, but emphasizes the importance of the function by repeating its purpose outside of 3.4.2.4.

Please, Sir, I want more:  First things first, the definition is slightly wrong.  If you fail to just the thrust that the vessel had before the fault, then you will lose position.  It takes time for the thrusters to turn and ramp up.  In that time, the vessel will have moved and built up momentum.  You need extra force to stop the vessel from moving and bring it back.  If the 2 split thrusters were at 40% thrust (not speed, power, pitch, or combo) before the fault, then a fault might be survived, if the vessel only needs a 20% dynamic margin to recover.  Most ships require a higher dynamic margin than 20% to recover from fault, due to various limits discussed in a series of articles (1, 2, 3, 4).  The same force isn’t enough to recover, you always need more.  A 2-split 50:50 split is a bad ASOG, and lack of that knowledge is what concerned me.  It’s no use getting an improved dynamic margin that can’t do the job.  A 2-split 40%:40% also isn’t redundant for most vessels, and the dynamic margin is involute (not to be violated during regular thruster variation, 40% is the top, not the average).  Some vessels need 30%:30% and a 40% dynamic margin.  That’s enough on that topic, and you can go read the other articles if you want to know why.  Just remember that the same amount of thrust isn’t enough, even if 645/1580 might be interpreted as saying so.  Balancing precision and brevity is always a challenge when writing, and for some 2-split vessels “same” is 30%:30% thrust, but on no vessel is it 50:50.

Go to jail, go directly to jail, do not pass go:  Take a moment and consider how all-inclusive this really is - “continuously verifies that the vessel will remain in position even if the worst case failure occurs.”  Not every 5 minutes, but continuously.  It’s not just limited to big dumb configuration failures like the actual systems use.  The rules require more, and we aren’t following them.  The ability to maintain position keeping ability would include hardware, software, and network monitoring and alarm, and a real understanding of the external forces, their trends, and the vessel response.  We don’t do anything near this, and add on ASOGs, questionable capability software, weather forecast, and rarely current and wave monitoring to try to fill the gaps.  Depending on your system, you don’t even have decent network or processor monitoring and alarms.  Most vessels struggle with their redundant thrust, especially in light of variable power supplies and shifting weather.  As an electrical engineer, I have some idea of what we would need to figure this out, and experienced vessel operators know some of this in their gut.  We have gotten away with lip service to capability analysis for a long time by only looking at large, obvious, stupid, worst case failures of configuration.  This is equivalent to the bad FMEAs that only look at if big equipment is on or off, and do not consider dynamic system response, interactions, or system limitations.  For capability limitations, we used the long disproven static DP plots, because we lacked anything better at reasonable price, but three medium waves at the right frequency can disrupt DP control and so can wind gusts at the right frequency, all far within static capability.  Consequence analysis is supposed to warn us when we can no longer keep position, but there is a lot of ground to cover.  Note that, as written, the worst case failure is just an example (“even if the worst case failure”), but the requirement is to continually verify that the vessel will remain in position, and alarm if it won’t be able to.  That is a large, but very useful, scope.

Triage:  We will not be allowed to cover it all, and the joint industry project will need to identify and focus on the high value improvements.  While the owners will be glad of some improvements, the vendors can be convinced to look at some of it as potential marketing, the big class societies can use it for reputational advantage, and the vessel clients will push for it, there will be limits to what can be accomplished.  There have been a ton of vessels that lost position after a fault, because they were operating outside their dynamic capability and didn’t know.  Simple analysis isn’t going to tell us that.  It requires vessel specific analysis validated by testing.  Some people aren’t going to want that, as their ships will have much smaller redundant envelopes than they think (e.g. slow azimuth ships).  Some of the vessels knew they were operating outside their redundant capability, and wanted to take a chance.  But if the ship is doing something dangerous and important, then the operators or clients will want to know.  I suspect we only get partial reform, clear benefits for little cost and bother.  People did not line up for dynamic capability analysis, even though it is clearly much, much better, because it is more expensive and difficult, and calibration drifts.  (IMCA will release an updated M140 soon!)  Right now, consequence analysis doesn’t really cover the basics, and a balanced reform will benefit all parties.  The basics include more than thruster and power availability, and need to consider meaningful thrust, power, control, and environmental limits.  Some systems lack meaningful DP and thruster network and processor alarms, so I hope that will be considered.

2023 MTS DP: MTS has provided another gift to the DP industry by publicly releasing the 2023 MTS DP Conference papers and presentations.  This is good practice and to be commended.  It shows their commitment to making information available to improve DP operation safety.  If you are looking for a quick guide, then a quick summary was given here and here.  I recommend downloading all of them, so your computer can index them and they become easy to search through later.

Conclusion:  If you are in a position to help with a potential joint industry project on consequence analysis, then I encourage you to do so.  Change always meets resistance, even when needed.  Current consequence analysis does not meet requirements, and this endangers safe operation.  Improvement is needed, but the costs and benefits need balanced.  While it is plainly of benefit to the crew and vessel clients, multiple parties are needed to make that balance and provide the broad experience and ideas to guide improvement to success.  I hope you won’t think of consequence analysis the same way again, and will see the benefit of improved functionality in the field. 

P.S. You can thank MTS for their free papers by presenting one yourself, attending a conference or regional workshop, or providing review comments.  They provide excellent free DP guidelines on their site and are currently offering the following draft document for comment:

GRT: Group Redundancy Tests (comments until Dec 15/24)