Go Read This – EBCV2

Introduction:  You might not have a contract involving the new experience-based comprehensive verification and validation (EBCV2) process given in the new “Unified Approach to Verification, Validation, and Assurance of Single Fault Tolerance in Dynamic Positioning Systems” guidance document, and might not think anything in the document applies to you, but you would be wrong.  The effectiveness of its procedures are going to depend on its application, but its discussions on DP concerns and good practices are worth reading.

Terms of Use:  “No responsibility.  Guidance only.  We don't mind you using it, but absolutely no AI.”  Best of luck with that last part.  For fun, I searched the document title in Google to see if I could find an AI summary of the document.  It was there.

Overview:  It's only 89 pages long and has a two page summary that provides an introduction for all DP personnel.  The procedures in the document are intended to be used by DP experts, as the lack of expertise and ability to slip by on poor documentation is the problem that the procedures hope to address.  The hope is that a more exacting EBCV2 documentation process will force participants to take their responsibilities more seriously, as the documents will be more revealing.  You may or may not be an expert, but reading this will help, as some of the discussions are clearer about issues that are soft-peddled in the DP guidance.  Additional clarity is useful.

Economic Selection:  EBCV2 process may underestimate the market's ability to innovate and adapt.  It is a paperwork solution to an economic and structural problem created by people trying to achieve DP certification at the lowest possible cost.  The lowest possible cost requires extensive shortcuts, and this document is for the part of the market that needs more than paper compliance.  Using paper to get the compliance that the previous paper system did not achieve, rather than enforcing existing requirements, is an interesting approach.  It has worked in other industries, when backed up with solid enforcement, but the old system also works, when the difficulty is understood, the goals desired, actual experts are required, and the rules enforced.  The procedures make the fence higher and wider, but it is yet to be seen if it will stop trespassers from slipping under the fence. 

Survival of the Un-fittest:  On the other hand, so many of the new builds are built and certified wrong that many people in the industry have a hard time knowing what is right.  Sure, there are lots of DP rules and guidelines, but then there are the vessels.  As the old saying goes, "Measure someone by what they do, not by what they say."  The rules and guidelines say lots of good things, but few people read them, enforce them, or even want them enforced.  Too much DP design is done to main class, rather than DP requirements.  That's where this document comes in.  Enhanced clarity, visibility, and audit-ability is hoped to reverse, or at least retard, the decay.  This may work at the high end of the market, but it will not address the race to the bottom elsewhere.  Shipyards and vendors will generally dislike the additional burden, and vessel users will generally like any improved visibility. 

History:  This is the first official release of the document.  A draft was released for comment last year and there were a number of DP industry workshops on the procedure, including some that I have reported on.  Three industry bodies and four major class societies were involved in the joint development project.  DNV has released a recommended practice that is part of the process.  So, the total is 89 pages for this document, plus the 170 pages for that document, plus the existing cross-referenced guidance.

Data vs. Knowledge:  I like their emphasis on evidence based verification, but am a little concerned about their attention on data-centricity.  Digital data and evidence can be different things.  In the old days, we aimed at ensuring enough evidence was recorded to show that the work was done and to focus on the important points.  It ensured work was done and to an acceptable standard.  One way to avoid work and thought is to record too much.  And we have all probably seen that in some reports.  Maps are useful because of their scaling, but it is possible to get lost in a 1-to-1 scale map.  We need a representative summary (landmarks) to see the work was done.  Data without analysis already shows up in reports.  I don't mind data when it doesn't distract, or hide problems, or prevent analysis, but the defensible conclusions are what we need.

Fault Tolerance:  We all know that the DP2 and DP3 vessels are to have no single points of failure within certain tolerances.  The use of redundancy matrices has sometimes distracted people from this, and too many modern FMEAs concentrate on configuration and neglect functions, because configuration is easy, vendors are secretive, and systems require experience and expertise.  This document puts the focus on single fault tolerance, which is a good holistic approach.  Vendor system functions will be incorporated in the process, like they were always expected to be.  We aren't looking to check a box, but to have a reasonable basis of confidence that bad things are acceptably unlikely to happen, and to demonstrate that in the documentation.  Some might argue that we are already supposed to be doing that in the existing documentation.  Others would argue that the existing assurance processes have become their own thing, disconnected from the original goals, and usually fail at their original task.  The industry has done this to itself, and the users are unhappy with the risk.

Roles & Problems:  The procedure identifies the roles and responsibilities of the different bodies involved in DP new builds or major upgrades.  It defines new reporting and oversight.  It notes problems can be created by insufficient specifications, competence, and resources.  If you have been involved in projects, then you have probably experienced various problems that have been caused by one of these or all three.  Knowledge that experienced DP experts breathe in and out can be a complete mystery to the people actually doing the work.  While it does not address the economic or social causes, the process is meant to help link the work with the end goals through a number of intermediate documents. 

Just a Little More:  Key documents include the redundancy concept verification document ("RCPD", something that often goes wrong early in a project), engineering studies, a hardware based "FMEA", a software/integration FMEA ("DPSI"), a combined FMEA, the trials, the intermediate assurance documents, close the gap processes, and the final EBCV2 assurance report.  It reminds me a bit of how aircraft FMEA-like assurances processes used to work.  All in all, 21 different reports and studies are required created, reviewed, corrected, and accepted.  Each report is referenced to one or more guidance documents, recommended practices, or class rules, such as RCPD to MTS TechOp-D11 for redundancy concept, or DPSI to DNV-RP-0684 for software/function/integration.  DPSI includes templates to improve the flow of control system information from vendors.  Most of the functions and concerns associated with the extra reports are not new, but many important aspects have been neglected, and are being re-emphasized and aided with documentation requirements.

Users:  Who is going to use this?  Projects whose vessel clients demand it, if they are willing to pay more to manage risk.  If it catches on, the lessons learned in those high end projects could trickle down to the vessels currently built with low DP compliance.  When the current crop of vendors, shipyards, and surveyors learn about DP redundancy, they will make less mistakes.  EBCV2 is not meant for the minimum cost projects, but the lessons from it could help train a generation unfamiliar with real DP requirements.  Or the extra costs, hurdles, and risks could limit it to a few projects.  An old joke in the Soviet Union was "We pretend to work, and they pretend to pay us."  DP has a similar problem where vessels pretend to operate to DP standards, but the lowest price vessel is often selected.  High standards don't usually come at low prices, so an EBCV2 vessel will need to charge more, unless it manages to take hidden or not so hidden shortcuts, like many DP vessels today.

Application:  The effectiveness of EBCV2 is going to depend on the people and environment it takes place in.  If it is an unprofitable hoop that needs jumped, then shortcuts will be found.  If EBCV2 vessels operate at a healthy premium and are in demand, then it will be desirable.  It's not good enough to demand that things be done "right", it needs to be worth it.  When the process is new, there will be unexpected problems that will need ironed out, so initial roll out will need to compensate all parties involved for the extra costs.

Conclusion:  EBCV2 is an option for future contracts, but not a requirement like the DP rules, which should be enforced by class, or like the industry guidelines when referenced by those rules.  The document provides a good overview of the current DP problems & current good practices (e.g. closed bus verification), and is worth reading just for them.  The need for DP assurance improvement is valid.  E.g. poor redundancy concepts and getting vendor control system information are usually struggles, and processes to help improve them are useful.  EBCV2 is one way to deal with the problems.  With proper application, and the proper carrots and sticks, EBCV2 could help address some current DP industry problems, and possibly slowly improve the overall DP operating environment.  If nothing else, it provides DP information and procedures to think through, and that is useful practice.

• I normally do a question article on the last Wednesday of each month, but I only have one question so far.  I usually have lots, but it’s been a quiet month.  I’m going to tempt fate and ask for more questions.
• The week after that is the DP incident article, so please send me any lessons learned, vendor bulletins, or links that you think could be useful.