The National Transportation Safety Board issued their report on the Golden Ray capsize and, as is usually the case with those reports, it provides an interesting read.
The NTSB provides a cause for the incident, incorrect stability calculation, and provides the following recommendations to the vessel operator:
1. Revise your safety management system to establish procedures for verifying stability calculations and implement audit procedures to ensure your vessels meet stability requirements before leaving port.
2. Revise your safety management system audit process to verify crew adherence to the Arrival/Departure Checklist regarding the closure of watertight doors.
The report does not dig much deeper than that, although the report itself provides tantalizing hints that would be worthy of further consideration. I will concentrate on the stability issue since the watertight door issue was a contributory issue to the outcome of the event, but not the actual cause of the lack of stability.
I have dealt with a number of multideck Ro/Ro carrier salvages and capsizes, and when I read the report I was reminded of my earlier anxieties in dealing with stability calculations on vehicle carriers when there was limited data with regard to cargo VCG and tank levels.
Vehicle carriers are an almost unique form of commercial ship. These vessels can very quickly develop insufficient GM’s in a wide variety of loading configurations due to their inherent high VCG. Due to the type of cargo they carry, they are also designed to operate on relatively low GM’s to prevent high accelerations on the high upper decks. (For the purposes of this blog I am somewhat simplistically expressing stability in GM terms, the actual cause of the capsize was the low area under the righting curve due to a high VCG.)
These low GM’s (or high VCG’s) are almost always corrected by carrying water ballast, and depending on the load configurations, there can be a wide variety of different ballast configurations. On many vehicle carriers the effect of slack tanks is also more pronounced than on many other ships since most ballast tanks on car carriers are wide shallow tanks. (Slack tanks and confusion about tank levels caused the Cougar Ace to capsize during ballast water exchange. Ballast water exchange on a vessel like this is comparable to juggling on a tight rope)
There are other tall ships with similar tanks arrangements such as container ships and passenger ships. Passenger ships are relatively easy to manage since their only significant change in GM relates to the amount of fuel and fresh water carried and that can be compensated almost one for one with double bottom ballast tanks.
Container carriers have their own stability issues that I will discuss in a separate blog, but do not suffer from the very rapid loss of GM that occurs with vehicle carriers and actually often operate with GM’s that are too high.
The reason that vehicle carriers can lose positive GM so quickly is because they are essentially boxes that are designed to have the maximum possible car deck area for their length. In addition, they are not designed to carry the heaviest cargo as low as possible, but instead carry the heaviest cargo near their main deck with lighter cargo below and above. When vehicle carriers were first conceived, the designers must have looked at their designs and calculations and thought: “Wow that thing looks scary. Am I sure it works?” And then provided themselves a little margin. However, over a number of design generations designers became more comfortable and the 2017 Golden Ray undoubtedly was a refinement of the earlier designs with additional decks that can carry the maximum number of vehicles while still meeting the IMO/SOLAS stability criteria. At that stage nobody asked how it could achieve those criteria, but the NTSB report shows that it can only achieve that by very carefully monitoring cargo weight and very carefully adjusting ballast weight to achieve acceptable GM’s.
The NTSB report provides a failure chain that shows that this balancing act was not executed correctly. The NTSB relates it to failed Safety Management System execution. I think it is more accurately described as: Too many things to do to set a safe tightrope to cross an ocean.
NTSB notes that correct training of the crew on the loading computer is essential to manage this issue, but computers rely on data, and incorrect data can too easily result in insufficient stability on vessels of this type. It then notes that the Master should double check the Chief Mate’s calculations. In practice, the Master will look at the stability program printout prepared by the Chief Mate. However, these stability programs are quite dumb, they simply provide a pass/fail on the data entered, but do not provide a risk analysis, which I will discuss later in this blog.
There are three ways to check lengthy calculations.
The first approach is a gut check: “Does this look right to me?” However, since ballast varies according to cargo and only small adjustments achieve proper stability, there is little opportunity for rough gut checks. Moreover, what Captains on these vessels get a chance to develop these gut checks, if there are thousands of vehicles aboard that could be loaded in thousands of ways?
The second is to look at the calculation line by line and make sure everything fits. With computer stability programs like those used aboard ships, such checks are a little silly because the actual calculations are hidden. Instead, the Captain can take out the actual stability manual for the vessel and try to make a comparison to one of the various loading configurations that are provided in the manual.
A simple vessel only needs a few sample loading configurations to capture the range of safe stabilities, but the NTSB report notes that this vessel actually had 34 sample load cases in its manual. Moreover, as discussed in the NTSB report, since the vessel operates with very small margins, minor variations in cargo configuration can render the sample configurations useless. As a matter of fact, a 3.8% percent error in the Chief Mates vertical center of gravity estimate (mostly due to incorrect cargo VCG estimates) rendered the vessel unsafe.
Therefore, the only way to actually make sure the stability is correct, is to make sure the actual vessel condition matches the input data in the computer program. In other words, the Captain would have to independently perform the same calculation that the Chief Mate made. This can take several hours and could result in minor interpretational data variations (How much does that front loader weigh again? Isn’t that front loader one deck higher up than in your calculation?) that would require resolution before the vessel departs.
The NTSB report notes that this vessel does not make full cargo runs between ports, but instead picks up cargo at various ports in short stops before making a long haul run. Therefore, all this needs to be performed at a very high pace for each port of call. If this vessel were to only make fully loaded long runs between distant ports this work would be manageable, but not at the pace that this vessel encountered.
Undoubtedly the vessel operator’s Safety Management System will be revised and may require any or all of the above approaches and other paperwork, but will not remove the chance of error in this high wire act.
The real problem with these vessels is that they are quite temperamental from a stability point of view and in my opinion training, by itself, is not a suitable solution.
It makes sense to provide more training, but other measures will be needed to reduce the risk of failure and make the operation of these vessels more redundant.
The NTSB report mentions that the vessel’s heel tanks can be used for a GM check, but this check was not performed. Since the vessel’s actual stability is not firmly linked to GM alone, and also heavily relies on an acceptable VCG (KB), a GM check is only of partial use. However, if the actual GM does not match the predicted GM, at least it provides a warning that something is not correct, and would induce the vessel crew to perform an additional check of tanks and cargo. And if there is no reasonable correlation between the two GMs, they can get outside help.
Interestingly a modification in the loading computer program can significantly decrease the risk of incorrect stability calculations by requiring a heel tank GM test before it will provide a complete stability summary.
Moreover, smart computer program designers can modify the loading program to provide the users with risk assessments based on evaluation of, and comparison between, the measured GM and the GM based on crew inputs.
The program then would provide comments such as:
The calculated and measured GM are quite close, but note that a 2 percent error in your cargo vertical center of gravity estimate can result in unsatisfactory stability. Are you sure your VCG is correct?
This loading condition is extremely sensitive to accurate weight and center of gravity estimates, please lower cargoes to achieve a better margin.
These would be relatively simple system improvements that can be applied to every ship that has complex stability requirements, but the real solution is to design ships that do not require 34 sample loading conditions to show how the vessel can be operated safely. Relying on humans to manage complex actions at a high pace is not a proper way to operate ships.
In this NTSB report illustration there apparently was not enough space to show all of the decks.