MAIB: ECDIS Safeguards ‘Overlooked, Disabled or Ignored’ in Grounding of Cargo Ship Off England


From gcaptain: MAIB: ECDIS Safeguards ‘Overlooked, Disabled or Ignored’ in Grounding of Cargo Ship Off England

Here is the MAIB report: Report on the investigation of the grounding of Muros Haisborough Sand North Sea 3 December 2016

The captain had the 2/O change the route on the 00-04 watch. The new route took the vessel in shallow waters.


Para 1.5.3 sure caught the eye of this old software security guy. Looks like somebody bought a techie a beer to get the noisemaker shut off by fatfingering the code. No mention of a software change log or what their procedures were. And somebody (else?) locked the guard zone and alarm settings page so that the internal disabling of the audible alarm could not be discovered. (I’m presuming there is an alarm check on that page that sets it off deliberately, but I could be wrong). And nobody considered this malicious behavior?



1.5.3 Post-accident examination
Examination of Muros’s ECDIS on 10 December 2016 identified:
● ● The audible alarm was not functioning. It had been disabled via software
usually only accessed by service engineers. The unserviceability of the
audible alarm had not been reported as a defect.
● ● The depth settings were:
○ ○ Deep contour 10 : 10m
○ ○ Safety contour: 8.5m
○ ○ Shallow contour: 10m
○ ○ Safety depth 11 : 7m.
● ● The guard zone was set to 40o and 10 minutes. However, the ‘Check safety
zone’ check box was not ticked and the ‘Highlight and display dangers’ box
was set to ‘never’ (Figure 8). Therefore, the guard zone was not active.
● ● The settings in the ‘guard zone’ and the ‘target alarms’ areas of the ‘ship
alarms’ page and the contours and depth settings were ‘locked’. The
adjustment of these settings was password protected and Muros’s deck
officers reportedly were unaware of the password. The crew considered the
resulting absence of alarms to be beneficial.
● ● The cross-track distance (XTD) 12 was set to 0.5 mile and route alarms were
● ● With the Teesport - Rochefort route selected, over 3000 warnings were
indicated on the ‘check route’ page, including the risk of grounding on
Haisborough Sand (Figure 9).
● ● The 2/O was able to navigate the Maris ECDIS900 menus and sub-menus to
good effect. She was familiar with the system’s functions but did not routinely
use the ‘check route’ function due to the apparent irrelevance and triviality
of many of the dangers highlighted. She was aware that the ‘check route’
function could be applied to individual legs of a voyage plan.


I expect the service-tech setting was done at the behest of some previous master who was annoyed by too many alarms. The same master probably forgot to pass along his password for the guard zone page.

And a system that generates three thousand warnings for a mostly-ok route from Teesport to Rochefort obviously was not designed to be used by humans.


Yeah, you’re right about the false alarm rate. And the word “malicious” was probably poorly chosen. The implication is that no alarm check was made before a voyage. And no configuration management. Probably because somewhere some marketeer got the system rated as not safety-critical. I can hear it now: “It’s only safety critical if the crew believes what it tells them.”




I am luckily on a vessel that still uses paper as it’s primary navigation method. This allows me to zero out all the alarm parameters once I get near a port. Otherwise I’d have to place a mate right next to to the damn thing silencing alarms and notices every ten seconds.

The intent of the system is genuine but the execution is madness. After a short period of constant alarming telling you that you’re “inside the safety contour” or “chart is improper scale” as you zoom out to get a birds eye view, they all become false alarms in your mind.

Long before there were alarms for alarms here was seamanship. Can’t we all just rely on that instead?


Well put it all just becomes white noise after the first 50 or so alarms.

It’s a great system but its got some short comings I personally don’t like planing on the small screen a pencil and proper scale chart it’s pretty apparent when you draw a line over a shoal. I find it easy to overlook some of the details when you’re canceling one alarm after the next.


In the end it doesn’t matter what the old-timers think about ECDIS, what matters is how the mates uses it on watch. I observe that the mates rely on ECDIS heavily, even if paper charts are available. Better to accommodate than to continuous nag.

I was in the silence the alarm every 10 seconds group till I took the class (at the last minute) My thinking now is get rid of the paper charts and make a full commitment to the ECDIS.

Transas is maybe better than average but by digging in to the settings I was able to cut the nuisances alarms by about 95%. One big factor in the 3000 warning is the type of check and the cross-track error distance. We pare the warning down to less then 100 which sounds like a lot but it only takes about 3 or 4 seconds to check each one which is five or six minutes total.

Still far faster than using paper charts.


An extreme, and grim, early example of similar problems in recreational sailing was the loss of the yacht Aegean in the Newport-to-Ensenada race in 2012 with four fatalities:



Where the track-line is laid down is very important, very likely that is where the watch will take the ship, recall the USS Guardian going aground on Tubbataha Reef.

In the case of the Muros, it’s a bad idea to change the route at night. There is some risk to making changes anytime on short notice.

Likely the captain described the route change to the 2/m verbally.

Red is the original route, purple track to the west is change.


It seems to me that it would be prudent to arrange the data and software such that dangers do not fall off the display when zooming out. If that means that their size is exaggerated when zoomed out, so be it. That effect would tend to force the user to zoom in to examine things more carefully.


Zoom out should automatically revert to the best scale for transit after a few seconds of in activity.


Using ECDIS requires a different mindset. It’s true that when laying down track-lines on paper it’s easy see when the track passes into the blue which requires more attention.

With Transas ECDIS the track can be reviewed with a "check’ function. When the track-line is checked the ECDIS display automatically scrolls to each position where an alarm would sound so it can be examined, for example the spot along the track-line where the depth “safety contour” is crossed.

The problem on the Muros is that there were over 3000 such spots, so it was too time consuming and tedious to check each one so the check function was not used.

If the cross-track error and the alarm functions are set up properly there would be far less warnings and the check function would be usable.


IMO the software should not allow generation of three thousand warnings on a planned route. Warnings should be chunked into danger areas with a single master warning for each area that can then be expanded, and should not appear as an infinite list of lat/long positions but something much more graphically intuitive.


This discussion and so many like it are IMHO manifestations of a larger problem raised by semiautonomous systems: how do you split authority and responsibility between the human and the robot? The only way I know of to approach this problem is to write, and review, and rewrite a Concept of Operations (Conops) until you really understand what it is you’re doing. Nobody seems to want to do that these days; it costs money and takes time and delays the production of optimistic marketing brochures by exposing a bunch of ugly tradeoffs that have to be made.

So we end up with a “systems first, Conops second” approach in which a box is slapped together and operators are left to figure out how to use it, and distribute that knowledge in various informal and unsatisfactory ways. Some of these after-the-fact Conops are satisfactory, like the advice given above, and some are not so satisfactory, like getting the techies to disable audible alarms, and there appears be no impetus whatsoever to change this situation.




There are three levels to this problem - IMO level, company and ship. On the ship I was able to reduce the nuisance alarms to a workable level. About 95% reduction.

I set up a procedure where all the final errors are sent to a file (excel or pdf etc) and printed, that becomes part of the voyage plan, it’s one or two pages. If I was a company DPA I would ask to see that printout. If it’s 30 feet long they are doing it wrong.


The planned route is checked for everything inside the cross-track error lines. For example leaving port, in a narrow channel if the default cross-track errors are not reduced then every buoy will be a error “hit”. As the operator hits the “next error” button the program will advance the screen from buoy to buoy.

The fix is to adjust the cross-track to be inside the buoys. If there are say 15 sets of buoys in the outbound channel this adjustment will eliminate at least 30 errors.


My software answer to something like that might be to automagically reduce the allowed XTE at those parts of the route and generate a “steer small” warning in those places. I might also separate the “bean-counters’ XTE” from the safety-of-navigation XTE and change the alarm tone for the first-named to the sound of a cash register. :wink:


The 3000 warnings were from berth to berth, where the great majority was certainly on the destination side, in the pilotage area; some 20 miles In the shallow estuary and 13 miles up the tortuous Charente river to Rochefort.

…the 2/O was aware that the ‘check route’ function had checked the whole of the route from the berth at Teesport to the berth in Rochefort, and she assumed that the hazards were concentrated in the pilotage areas. The 2/O cleared the window showing the hazards…

This assumption could be seen as false by a second brain overlooking the route. Or:

… Although the 2/O was aware that the ‘check route’ function could be applied to individual legs of a voyage plan, she preferred to rely on visual checks alone.

With hindsight, nobody was harmed, it looks a bit comical:
For half an hour, the ship plowed through the sandbank with diminishing speed. At 0.3 knots the rudder could not turn the stranded ship any longer.
Since the autopilot is out of order, we try with manual steering…


Another brain could also see as false the assumption that “I zoomed on this shoal and the track line was clear of the shoal; therefor it will also be clear of this other unrelated shoal.”

Not the actions of someone on the watch for ways that the software could trip her up.