Voyage Data Recorder, VDR, failures have been emerging in a number of recent incidents, of which the UK Maritime Investigation Branch’s preliminary report on the contact incident between the ro-ro ferry European Endeavour and the linkspan at No. 7 berth in Calais is fairly recent. Although the save function on the VDR had been activated, and the VDR itself fully functional, data about the accident was not saved.
There were two reasons for this failure: the operators were not familiar with this type of VDR and the service representatives had not managed the capacity of the hard disk appropriately so reducing the storage capacity of the unit.
There have been several other cases in which VDR data was not stored at all or not stored properly. In another instance, the save function was activated the day following an incident but the VDR unit only stored 12 hours of data so what was saved did not include data around the time of the incident.
In the case of the tug Bugsier, reported by Germany’s Federal Bureau of Maritime Casualty Investigation, the officers aboard the other ship involved did not initiate an emergency backup of the VDR data. Waterway police asked for a backup to be made but “due to an error in the process, no data could be retrieved”.
VDRs are a valuable asset in maritime accident investigation and can be used to optimise ship operations if used wisely. Much effort has gone into ensuring that the data itself cannot be tampered with and its integrity assured but if the data isn’t saved properly, or not at all, then they’re not really very helpful.
While training and familiarity should, of course, reduce VDR failures, perhaps there is a need for better and possibly standardised human-interface design. With the trend towards higher turnover of personnel resulting in less familiarity with bridge equipment and less experienced officers, one must wonder whether this is a situation that requires to be addressed.
Here, for completeness is the MAIB preliminary report synopsis:
European Endeavour was turning while leaving port when she experienced a “brownout” (a partial loss of electrical power) and loss of her starboard main engines. The bridge control system was momentarily disconnected, before being automatically restored by emergency power supplies. The bridge team reset the manoeuvring controls to zero and waited for the situation to normalise; however, the ship began to move ahead. Unsure of what was happening, and unable to regain control of the CPP system, the master ordered both anchors to be let go. Both main engine emergency stops were activated, however not in time to prevent the vessel coming into contact with the linkspan on an adjacent berth.
Extensive tests have not revealed why both starboard engines stopped. The “brownout” is believed to have been caused by the failure of the power supply to the starboard half of the main switchboard. The CPP systems went to emergency control, and the pitch on each CPP failed to “last setting”, applying approximately 50% ahead on the port shaft and zero on the starboard. The bridge team were unaware that the port control system was now applying a pitch command via the back-up control system, and that consequently they needed to use the back-up controls.
Instructions on board were inadequate, and there was a lack of understanding of the emergency controls.
Once the situation was stabilised and the vessel had been made safe, the VDR save function was operated. However despite the unit being fully functional, the accident data was not saved. This occurred because the operators were not familiar with this type of VDR. Also, disk capacity had been poorly managed by VDR service representatives, resulting in reduced data storage capability.