The dangers of having an overly stiff vessel have been around for a very long time. Sailing ships on ballast passage constructed enclosures to contain rock on deck to reduce the GM to a manageable height to lessen the load on the rigging.
On general cargo vessels we were mindful of the GM getting too large and used tween decks where we could and winging out the weights to increase the inertia of the ship.
The GM of the MSC Zoe was the kind of values that I have only experienced on a bulk carrier in ballast. There was nothing that one could do to alter the GM and it was not a voyage that I enjoyed.
There should be a great deal of soul searching over the results of this report because as I read it there was not a lot that the ship’s crew could do to change the ship’s stability.
This is a problem on HLVs as well. Too rapid acceleration due to high GMt cause excess forces on seafastenings.
It is especially a problem when carrying J/U rigs with long legs in place.High GMt cause excess bending forces on the legs at and just above Upper Guides.
In the early days of Dry transport on barges and the earliest HLVs the top section of legs were removed and placed on deck of the rig, or HLV during transport.
Newer HLV has High Deck tanks that can be used to reduce GMt, thus reducing the problem, but even so there have been cases of lost legs (few) Legs weakened by hairline cracks is more frequent, thus weather restrictions are often imposed by MWS.
Don’t get what’s being said about the CSM (Container Securing Manual) and the GM here but evidently the examples in the manual assume a GM of 2.08 meters but the actual GM at the time was 10.3 meters. Values that high are typical but are beyond the range of the tables provided and the methods used by the stability computer are “not fully transparent” according to the report.
The loading computer story shows a couple of weaknesses. The investigators were presented with the LC in the cargo office and not the one on the bridge. Why didn’t they insist on also inspecting that one? There even was a third one.
One of the recommendations was to install sensors at critical locations on the ship in order to measure accelerations and to provide this information in real-time to the captain/crew in order to allow them to monitor these. You don’t have to invent anything, a short pole on the bridges with a acceleration detector on top in a watertight enclosure and presto.
The same with the evaluating and assessing of possible technical solutions that can assist the captain/crew in the detection of the loss of containers and propose international standards for implementation of such solutions. This is more difficult as if it is done with video cameras with night vision you don’t want all the monitoring done in the wheelhouse, too much distraction and light hinder at night. It should be fully automatic, for instance based on echo location. If a location is changing in value an alarm should sound. Just an idea…
I looked at this graph with some amazement. Had the helmsman been drinking or did he steer for the first time? A constant overshoot of rudder orders, up to about 27°.
Fig. 4 shows that a significant rudder action is required to maintain the ships course. The rudder command is several times to full port, the time averaged rudder angle is abt. 16-18 degree port rudder.
The report mentions:
At the same time, the VDR data indicated a significant rudder action through the whole time. The crew switched to manual steering, and from the VDR data it becomes obvious that they must have had problems to maintain the ship’s course.
It looks like that the helmsman is overreacting to every small course change. Sometimes you have to let the ship ride as it often, due to wave action, returns to the original heading
Why did they switch to manual steering? I cannot imagine that the auto pilot would have done worse.
I read this to, but my first thought was another one.
Aren’t these three computers interconnected, using the same true data, storing locally may be only rejected working variants?
This would indeed lead to a good redundancy; if one computer crashes, the others can immediately take over with the same data, external input and local calculations.
What could be the reason to use isolated computers, importing individually external data from port and company and calculate locally, without redundancy?
Good question. My idea from the text was that they were not connected as they didn’t mention that. If the LC’s are connected and fully identical then there is no reason to investigate the others. If not connected then they could give different results which is unacceptable. You also had also have to feed the data three times which is cumbersome and can give errors. Connected in a network would be the only logical solution.
Certainly not knowing all the specifics but I would venture to say the LC in the cargo office was the “approved computer”. That does not prevent the program from being loaded and used on other computers that aren’t class approved as long as the stability program is the identical.
I would have thought that a vessel of this size would have warranted an adaptive autopilot for fuel saving if nothing else. Such an autopilot would have adjusted smoothly to the change of speed.
I would be very surprised if the computers were not networked. The chief officers accomodation is closer to the bridge than the cargo office and cargo queries and changes can come at anytime day or night. I didn’t see in the crew list runners to take the noon figures from the engine room to the chief engineers office.
I once did one of the longest voyages I have ever done, Rotterdam to Singapore via Cape of Good Hope at 4 knots back in the early 70’s.
The VLCC had an IBM system seven integrated navigation system incorporating an adaptive autopilot and it worked just fine.
IDK the details here but the bridge watch was faced with the problem of the heavy rolling and the task of leaving the inshore VTS lanes, weaving their way up to the off-shore lane and then joining that lane.
When the shit his the fan it would be expected that the bridge crew would reduce the layers of automation in the navigation/steering system.
Direct control of the rudder would have a priority over precise steering.
The root cause of the container loss is a very high stability in combination with low damping. The roll damping of the hull is not sufficient for very large values of initial stability. As the roll damping is speed dependent, it was further reduced due to the low ship speed. The ship speed of 10 knots led to a situation where the ship was rolling permanently with 5-10 degree amplitude. Under these circumstances, the transversal accelerations were not large enough to cause a cargo loss. Our calculation has shown that the ship must have been hit by a group of waves which caused roll angles between 17 and 18 degree. During this events, transversal accelerations occurred which led to the first losses of the cargo.
Had the ship speed been larger than 10 knots, this would have prevented the cargo loss. At 14 knots ship speed, the cargo loss could have been avoided definitively, at 12 knots most probably.
Consequently, the speed reduction after the first losses of containers led to further losses, because due to further reduced roll damping, large transversal accelerations have become more probable.
Most probably, the crew was not aware of the fact that their hull did not produce sufficient roll damping at 10 knots ship speed.