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

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.

1 Like

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.

1 Like

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.

1 Like

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.

Just to pick a nit, the way I read it the speed decreased because of shallow water at the beginning of the sand; then a number of minutes later they gently ran up on their final resting place. Mate noticed the sudden decrease to under a knot, but was too sleepy or zoned-out to make the obvious connection when the engines are chugging along but the vessel has stopped.

With Transas there is a menu where the items to be “checked” can be selected. Some items are mandatory and cannot be disabled.

I suspect that in the case of the Muros that none of these features were being used.

As an guesstimate I’d say voyage planning can be done with an ECDIS with about 30%-50% of the time/effort of paper charts (transferring track-lines to the various different scale charts takes time).

If the various setting and checks are disregarded voyage planning on ECDIS takes maybe 5% of the time/effort of paper. This is how the Muros was doing it.

1 Like

Just as Traffic Schemes are strongly “suggested routes” through busy confined waters, agreed upon suggested major shipping routes (that cannot be changed) should be programmed into ECDIS.

Make a new ECDIS route to save a few miles by dodging and weaving thru shoals,rock piles, and fleets of small fishing vessels if you want to, but be prepared to explain why if anything goes wrong.

Once it becomes easier to just take a standard tested route, it will usually be taken.

I have to say – and I mean this sincerely – that I find it fascinating to watch the contributors to this thread develop the Conops that the people who built the ECDIS system should have written before they started pounding code.




You get used to every Tom, dick, and Harry telling you “this is the newest, bestest thing” we developed for you, when you work at sea. Most of them having never stood a watch in their life.

I don’t think I’ve ever been asked how I would like a piece of software to work as the end user in all my years floating around out here.

A lot could be gained if they would simply treat us like professionals and ask for our input.


Before nav equipment was available to compute bearing and distance to the next waypoint formal (not by eye) navigation was done entirely on the chart. Track-lines were laid down, fixes were plotted, the course was adjusted accordingly.

If you switched charts and the was an error in the track-line and the fixes were no longer on the track-line the mate would just adjust the course and get back on track.

Once the GPS came along with screen and “highway” the mates began to follow that instead. No one told them to, they just did.

If the track line in the GPS and on the chart did not match, mates would follow the GPS and assume the paper track-line was wrong.

This can be seen when going GC, the fixes will match the track at the segment ends but arc away between segment ends (unless the 2/m used the steel globetrotter edge-wise). That is because the watch mate is following the GPS screen highway, not truly using the paper plot.

I recall being 2/m and if there was an difference between the paper track-line and the GPS the mate loved pointing it out. Before GPS they just followed the track on the paper and didn’t complain.

EDIT: change “waypoint” to “segment”

Off-topic but why not use a series of rhumb lines to approximate a GC arc?

1 Like

That’s how it’s done on the chart. You mean in the GPS? You could but it is easier/quicker to cross the ocean with just two waypoints. Especially if you make weather route changes.

There’s not enough difference between the rhumb lines segments on the chart and the GC on the GPS to worry about, it’s more of an observation than a complaint.

EDIT: We sail GC by entering the two waypoints in the GPS and then using Waypoint for Windows to generate the rhumb line segments to plot on the chart between the two waypoints.