1. Introduction
1.1. Narrative
The following is a summary from MAIB’s (2021) accident report. In March 2020, the 90 m long general cargo vessel Kaami loaded 2,000 tonnes of solid recovered fuel bales in the port of Drogheda, Ireland (point 1 on the map in Figure 1). The vessel had two bridge officers working 6 h on, 6 h off. The chief officer was responsible for the cargo operations in port, so the master carried out the voyage planning for the voyage to their next port of call, which was Slite in Sweden.
The final voyage of MV Kaami in March 2020 from Ireland to Sweden came to an end on a rock in a strait in Scotland. See details in the text. Maps from MarineTraffic and MAIB (centre). Photo from MarineTraffic.
Figure 1. Long description
Panel A: A map showing the journey of MV Kaami from Ireland to Sweden. The route is marked with an orange line, starting from a point near Dublin, Ireland, and ending near Slite, Sweden. Key locations are numbered: 1 near Dublin, 2 off the coast of Ireland, 3 off the coast of the United Kingdom, 4 near the grounding position, and 5 at the grounding position. Panel B: A detailed map of the grounding area in Scotland, showing the recommended routes by the International Maritime Organization (IMO) and the actual AIS track of MV Kaami. The grounding position is marked with a red dot. Panel C: A photograph of the MV Kaami ship.
At 20:30, March 21st, 2020, Kaami departed Drogheda with a draught of 5.4 m aft. Of high importance, the ship followed the pre-planned route that the captain had previously made (the darker red route in MAIB’s post-accident screen shot from Kaami’s ECDIS in Figure 2).
Screen dump by MAIB (2021) of Kaami’s ECDIS route and alternative route though the Little Minch planned by the captain.
Accordingly, Kaami’s voyage proceeded up the Irish Sea, through the North Channel and, 24 h later, the vessel reported to Stornoway Coastguard Operations Centre on entering the Minch voluntary reporting system in the strait between the Outer and the Inner Hebrides (point 2 on the map in Figure 1). At 22:55, Kaami’s master again reported to the coastguard that the vessel had entered the Off Neist Point traffic separation scheme (point 3 on the map in Figure 1). The weather had deteriorated and the wind was by now south-westerly 6 to 9 Beaufort severe gale with rough to very rough following seas. It was a dark night, with total cloud cover, but the visibility was good. Just before eleven in the evening (which was midnight by the ship’s onboard time), the chief officer, along with an able seaman, arrived on the bridge to take over the watch from the master, and 2 h later, just before 01:00 on 23rd March, Kaami‘s chief officer contacted the Coastguard Operations Centre reporting that the ship was approaching reporting point F (point 4 in Figure 1), which marked the start of the International Maritime Organisation’s recommended northbound route.
Kaami, however, did not turn starboard to follow the recommended route (approximately NE), but instead continued straight ahead, still following the track the captain had previously planned in the ECDIS, which took the ship north of the southern cardinal mark on Eugenie Rock. Kaami was now on an autopilot-controlled course of 032° with a speed of 10.6 kts. At 01:35, a watchkeeper on the nearby fishing vessel, Ocean Harvest, contacted Kaami on VHF radio to warn that Kaami was heading into ‘shoal waters’. Kaami‘s chief officer responded promptly and he thanked Ocean Harvest for the information, confirmed that he understood and that he would be altering course in the next few minutes. Soon after, Kaami‘s chief officer used the autopilot to alter course 10° to starboard at waypoint 19 in accordance with the voyage plan (see point 5 in Figure 1 and screen shots in Figure 3).
The grounding place. Screen dump by MAIB and from the Admiralty paper chart no. 1794. See the text for further details.
Figure 3. Long description
Panel A: A nautical chart displaying a maritime route. The chart includes various labels such as ‘IMO recommended route’, ‘Kaami’s route’, and ‘Missing ENC cell’. Key locations like ‘WP 19’, ‘THE LITTLE MINCH’, and ‘Eugenie Rock’ are marked. The chart shows different types of terrain and underwater features like ‘rock’, ‘sand’, ‘mud’, and ‘pebbles’. Arrows indicate the direction of the routes. Panel B: A zoomed-in view of a specific area on the nautical chart. It highlights the route taken by Kaami and the recommended route by the IMO. Key locations and markers are visible, including ‘Eugenie Rock’ and various depth measurements. Panel C: The same zoomed-in view but from a traditional paper chart. The map shows Kaami’s route in orange and the red sector light warning for the grounding place.
In Figure 3, the left chart shows Kaami’s grounding place on an ECDIS screen dump by MAIB immediately NE of waypoint 19 (WP 19). The orange dashed line is the planned route followed by Kaami. The chart also shows the ‘jail barred’ inset depicting a missing chart cell through which the IMO recommended route passes. Right top in Figure 3 is a closeup of the grounding place showing WP 19, and the X symbols of ‘isolated dangers’ and highlighted 5 m Safety Contour. Right bottom is a comparison with the Admiralty paper chart no. 1794 of the same place (with Kaami’s route inserted in orange). The red segment here is a lighthouse sector.
At 01:41, two heavy impacts were felt and the vessel came to a stop. The deck lights were switched on, and the chief officer realised that the vessel was aground and he put the engine telegraph to stop.
1.2. Baseline and approach
Today, bridge equipment required to conduct safe navigation is described in the SOLAS convention (IMO, 1974), notably in Chapter V, Regulation 19 (SOLAS V/19), which mandates the availability and use of ECDIS on SOLAS ships. The 1974 Convention has been amended by the Maritime Safety Committee (MSC) many times to keep it up to date as the regulatory foundation for ECDIS – currently MSC.232(82) for ECDIS systems fitted before 1st January 2026 (IMO, 2006). To ensure that individual ECDIS implementations provides the functions required by the IMO, testing and approval of ECDIS is both very detailed and comprehensive, as contained in IEC 61174:2015 (IEC, 2015).
As a starting point, we certainly agree that ECDIS overall has improved the safety of shipping immensely over the years since the 1990s. It has allowed navigators to perform automated and highly precise navigation. During the years, new technical features have been introduced making the system even more efficient. However, evolving technical capability has, in our view, come with the price of increased complexity, potentially endangering the intended safety gains brought about by ECDIS. The fate of the Kaami once again brings our attention to what could be called ‘ECDIS induced’ incidents and accidents: how and why a fully functional ship with state-of-the-art equipment fails to navigate a well-known and well-marked fairway in good visibility.
The MAIB accident investigation reveals several faulty settings in the ship’s ECDIS system, a well-known problem that has been observed in accidents before. Mandatory safeguards that have been added to avoid accidents are bypassed or turned off, causing us to speculate that the complexity and lack of proven usability of modern day ECDIS have reached a level where some users may not be able to fully comprehend and correctly use ECDIS for the purpose intended: safe navigation. The cure, as we see it, is to apply the principles of Human-centred design (HCD) of future systems, with an increased focus on usability testing to ensure that everyday use is matching work-as-done on the bridge and is within the scope of current users.
In way of approach, this study is a desktop case study, using the secondary data in the form of MAIB’s accident report on the Kaami grounding in combination with Reason’s ‘Swiss Cheese’ as a lens to identify and discuss safety barriers which failed that night. We have neither conducted interviews with any of the persons involved nor done any experiments with proposed solutions; however, we firmly believe the assertive quality of the reflections and arguments presented, and hope, if nothing else, that our suggestion can inspire or foster discussion of the next generation of ECDIS.
3. Method
In an early gap analysis, a close reading of accident reports revealed several accidents that, to different degrees, were connected to the usability of ECDIS. A recent accident with a Norwegian ship was identified as a particularly interesting case for this study. Case study was the method chosen, where a commonly used definition comes from Yin (Reference Yin2017) who defines the case study research method as: ‘An empirical inquiry that investigates a contemporary phenomenon in depth and within its real-life context, especially when the boundaries between phenomenon and context are not clearly evident’ (p. 50). In the actual case, this study exclusively uses secondary sources, predominantly the accident investigation conducted and reported by the UK Maritime Accident Investigation Branch (MAIB, 2021).
Already in 1990, James Reason wrote that the development of technology has led to a point where the greatest dangers stem not so much from the breakdown of a major component or from isolated operator errors, ‘but from the insidious accumulation of delayed-action human failures occurring primarily within the organizational and managerial sectors’ (p. 476). James Reason introduced the first embryo of the now-classical Swiss Cheese Model in his paper ‘The contribution of latent human failures to the breakdown of complex systems’ in 1990. In the introduction he writes:
‘Several recent accidents in complex high-risk technologies had their primary origins in a variety of delayed-action human failures committed long before an emergency state could be recognized. These disasters were due to the adverse conjunction of a large number of causal factors, each one necessary, but singly insufficient to achieve the catastrophic outcome. Although the errors and violations of those at the immediate human–system interface often feature large in the post-accident investigations, it is evident that these “front-line” operators are rarely the principal instigators of system breakdown. Their part is often to provide just those local triggering conditions necessary to manifest systemic weaknesses created by fallible decisions made earlier in the organizational and managerial spheres’ (Reason, Reference Reason1990, p. 475).
He continues to acknowledge that, thanks to the sophistication and abundance of engineered safety measures, many high-risk technologies now are largely proofed against single failures, either of humans or components. ‘This represents an enormous engineering achievement. But it carries a penalty. The existence of elaborate “defences in depth” renders the system opaque to those who control it’ (p. 476). Reason points to the need to distinguish two ways in which human beings contribute to the breakdown of complex systems (see also Rasmussen and Pedersen, Reference Rasmussen and Pedersen1984): active and latent failures. The active failure in the Kaami case was the misdrawn track across the shallow area, and the latent failures are the complexity of the many different ECDIS systems ship navigators have to learn and manage during work on different ships. Reason developed this inspiring model and finally called it the ‘Swiss cheese model’ in his book ‘The human contribution’ (Reference Reason2008). See Figure 4.
James Reason’s Swiss cheese model, where an unlucky trajectory of accident opportunity passes through a number of holes (‘windows of opportunity’) in successive layers of defences, barriers and safeguards. Reason, (Reference Reason2008).
As will be seen in the following, simple omissions (the failure to carry out necessary actions) is the reason for most breaches to the safety barriers crafted by designers and regulators.
4. Analysis of the Kaami accident
The ‘local triggering event’ or ‘active failure’ in the Kaami case was drawing the track leg passing over the rock in the Little Minch strait. Standing navigational watch is an example of a socio-technical system which contain complex technical artefacts needing human input, conceivably presenting windows of opportunity for mistakes. Being the primary voyage monitoring and grounding avoidance system among the mandatory navigational instruments, ECDIS should, in and of itself, be a metaphorical block of Swiss cheese, made up of several slices – safety barriers – which together leave no holes open all the way through. In other words, the safety barriers built into ECDIS should be designed to prevent that a mistake promulgates into an accident.
In the present case, the Kaami was equipped with a Japan Radio Company (JRC) JAN-2000 Electronic Chart and Display Information System (ECDIS). This system is type approved according to the standards in force and thus lived up to all test criteria required for ECDIS systems on the day it was installed. On the night of the accident, the chart was in its dark night-mode to preserve the bridge officer’s night vision. The ships position was correctly shown in real-time on the navigation chart showing the own ship’s symbol approaching the accident shoal, which was highlighted as a danger. For some reason, the navigator did see this, and holistically, since the Kaami did run aground despite having a fully workable ECDIS system, the incident seems to indicate that type approval essentially is insufficient to safeguard the socio-technical work system from failing. We discuss this in the following, grouped into three consecutive parts of interacting with ECDIS: ECDIS settings, pre-voyage ECDIS activities and during-voyage monitoring.
4.1. ECDIS settings
4.1.1. The first barrier: the Safety Depth and the Safety Contour
When a ship has finished loading and is ready to depart, a ‘draught survey’ is carried out and the draught is read from the quay side by one of the officers from numbers on the stem and stern of the ship. Some ships also have pressure sensors connected to the loading computer that is calculating the stability of the vessel. The draught is then used to calculate the amount of cargo loaded and is added to the AIS message transmitted for VTS, port authorities and other ships. It is also part of ECDIS own-ship-settings, and if Safety Depth and Safety Contour are not set with a value, there is an alarm. However, the operator is not alerted in the case where the given value is incorrect.
Figure 5 right shows MAIB’s screen shot from Kaami’s Chart settings window. Kaami left Drogheda with a maximum static draught of 5.4 metres aft. As you can see, there is no field for ‘draught’, but there is instead a ‘Safety Depth’. The Safety Depth is a combination of static draught (when the ship is still in calm water) and a safety margin, called Under Keel Clearance (UKC), normally approximately 10% of the draught. The UKC should consider tides, squat (ship’s increased draught when moving) and wave-induced heave. Taking into consideration the rough seas expected, Kaami’s Safety Depth setting of 7 m is small but acceptable, resulting in the ECDIS highlighting all spot soundings with a value 7 m or less. Moreover, in the Kaami accident, an isolated danger mark was also displayed because the Shallow water dangers box was ticked. See the top chart insets to the left in Figure 5.
In the Chart Settings window, the important Safety Depth and Safety Contour are set. To the right is MAIB’s screen dump of the settings onboard Kaami. Top left shows the graphically the effects on the Safety Depth deeper than the Safety Contour. See the text for more details.
However, setting the Safety Depth is not enough. ECDIS has a mandatory feature that requires the system to check if the route enters different forms of dangerous areas, including shallow water, both at the planning stage (MSC.232(82)/A11.3.4)Footnote 1 and during the voyage (MSC.232(82)/A11.4.3).Footnote 2 For this feature to work, the ECDIS Safety Contour must be correctly selected in the system from the start. For bulk vessels the draught might be different for each voyage depending on what and how much cargo they carry. In this case, a Safety Contour with a depth of 7 m or more should have been chosen. As there is only a limited number of Safety Contours available in the chart database, a setting of 7 m would highlight the closest deeper Safety Contour which would be 10 m. However, instead, the Safety Contour setting was 5 m, a contour which was available in the chart database, but too small for a ship with a draught of 5.4 m and less than the set Safety Depth (see the graphic, top left in Figure 5).
In the two small insets bottom left in Figure 5, the effect on the graphical appearance can be seen. In the top screen dump from Kaami’s chart, an isolated danger with a depth of less than the Safety Depth (7 m) has been highlighted (the magenta circle with a cross in it). At the bottom inset, the actual grounding place is seen. This was an area with a depth of less than 5 m. The screen shot published in the MAIB report is not very clear, but you can distinguish two purple circles (isolated danger marks) and an oval shape which is the 5 m Safety Contour. It is highlighted because the Shallow pattern box is checked. You can also see the planned track of Kaami (dashed line) passing straight over the highlighted area. Although the settings were wrong, the topography of the reef (with areas above the water at low tide) has made the area conspicuous enough to be visually noticed if sufficiently zoomed in.
Design comment. That it takes a full page and several illustrations to explain the issue of Safety Depth and Safety Contour serves as a good illustration of the complexity of chart settings on ECDIS, and considering that incorrect settings of these values have been a contributing factor in several other maritime accidents, e.g. the Ovit grounding in 2013 (MAIB, 2014), a revision towards a safer design seems to be appropriate. An important safety barrier like this should not be something even schooled mariners find difficult, and the application of human-centred design principles and extensive user testing will serve to ensure whether a particular design has overcome the pitfalls described in the foregoing. Even the clarity of wording may be an issue here, which reflects back onto the standards in force; indeed, the difference between ‘Depth’, ‘Safety Depth’ and ‘Safety Contour’ may not be obvious to all users. While ‘Depth’ is a physical property of the ship and ‘Safety Depth’ is a derived, vertical measurement, ‘Safety Contour’ relates to the presentation of ECDIS data – two very different things.
A more radical design change would be to pay heed to a suggestion by the working group DIPWG4 of the International Hydrographic Organization, who, in 2012, suggested that
‘ECDIS should provide the mariner with the possibility to select only one ECDIS safety parameter – the Own-Ship Safety Depth – that is calculated by the mariner as Vessel draught + dynamic draught + Safety margin. The ECDIS Safety Contour should be calculated by ECDIS, i.e. SENC depth contour equal or next deeper to the Own-Ship Safety Depth’ (IHO, 2012).
A further safeguard could arise from data consistency and a tighter integration of devices on the bridge. The draught of a ship is a parameter used in several other places, in departure and arrival documents, and written into the AIS to be broadcasted over the AIS network. Automatic reading of the depth from a shared source would further reduce the risk of the issue seen on the Kaami.
4.2. Pre-voyage ECDIS activities
4.2.1. The second barrier: making a voyage plan in advance
While underway, there are other tasks to attend to on the bridge, rather than constantly monitoring the chart. For this reason, the International Maritime Organization (IMO) have since long mandated that every voyage must be planned and drawn into the navigational chart ahead of departure, when the navigator has time to study the details along the track in peace and quiet. IMO’s International Convention on Standards of Training, Certification and Watchkeeping for Seafarers (STCW), Part 2, Voyage Planning says: ‘The intended voyage shall be planned in advance taking into consideration all pertinent information and any course laid down shall be checked before the voyage commences’. A pre-made voyage plan was present on Kaami’s ECDIS. However, ‘all pertinent information’ had not been taken into consideration because the planned route passed right over the grounding position in the Minch strait, as well over shallow water north of Skagen, Denmark.
Design comment. By IMO rules (A232) and IEC 61174Footnote 3 , in case a route leg is drawn through a hazard, the ECDIS must provide an indication ‘textually in the user dialog area of the route plan’. It is to us not clear what role the mandatory, textual warning played in the current case, or how it was not noticed or reacted on by neither the master nor the chief officer, but the fact that it was overlooked is evidence enough of a design problem: the ‘indication’ was simply insufficiently salient. This takes us again towards a possible lack of user testing and of designs being inadequately validated from a usability perspective. In the present case, prominently requiring acknowledgement of Safety Contour violations could be a design element to consider to reduce the risk exhibited by the Kaami, but there are many alternatives to this for designers to consider and test.
4.2.2. The third barrier: visual inspection of the planned track
Nautical charts have for centuries warned mariners about the dangers that hide beneath the sea surface. All details of the bathymetrical landscape cannot be depicted, but in the old paper charts, dangerous reefs and shoals were highlighted by salient shading or colouring (see Figure 6, right). With GNSS and ECDIS came Electronic Navigational Charts (ENCs). The benefits of ENCs are multiple. They allow for seamless zooming and graphical shading of danger zones to be tailored to the particular draught of the own ship, and foremost, automatic detection of hazards along the planned route.
Comparing the graphical clarity of the electronic navigation chart (ENC) in night mode onboard Kaami (left), with Admiralty paper Chart 1794 (right). Some retouching has been done to the Kaami ENC picture to remove MAIB’s markings (visible in Figure 3).
Figure 6. Long description
Panel A: A digital nautical chart in night mode. The chart displays various bathymetric features with different shades and colors. Key locations and labels include ‘PSSA’, ‘LEK’, and ‘Eu’, with a prominent red line running diagonally across the chart. Panel B: A traditional paper nautical chart. The chart shows detailed bathymetric contours with labels such as ‘East Bank’, ‘Speir Graidach’, ‘Eugenie Rk.’, and ‘Fladda-chuain’. A red and a pink line is drawn across the chart indicating a red lighthouse sector and a chart insert.
Design comment. However, there are also several drawbacks. The skill with which cartographers designed paper charts has so far not been achieved by computational presentation algorithms, causing cluttering and graphical unclarity. Previously, each scale size of the chart was crafted making sure information was not piled on top of each other, but even current algorithms appear unable to match the skill level of the past. This may be pertinent in the case being discussed. In a small-scale ENC of the Little Minches, a small shoal like the one Kaami grounded on will disappear due to the algorithm’s management of zoom levels. However, cartographers of traditional paper maps could keep prominent dangers in the middle of a transit area, although they would otherwise be removed. In Figure 5 left, MAIB’s screen dump from Kaami’s ECDIS shows the planned track passing over the grounding rock and to the right is the same area from the Admiralty’s paper chart. Although the hazard is marked with two magenta isolated danger symbols, the conspicuity is still not comparable to the old paper chart. The navigator’s choice to only have two and not four shades, marking the ‘shallow contour’ and the ‘deep contour’ (the ‘Four shades’ tick box in Figure 5) also added to the masking of the grounding rock.
We think the minimum size of the ECDIS screen (270 × 270 mm) constitutes a problem. When zooming out to get an overview of the whole voyage, the chart scale becomes so small that important details disappear. While route planning adding waypoints at insufficient high-zoom level, there is a risk that important hazards disappear in larger scaling or become obstructed by cluttering. This could have been a reason for the leg being drawn over the shallows. We do not know and the accident reports does not give an answer. Moreover, we believe that the cartographic artistry of the past must be matched also in digital charts, aiding the mariners to stay attentive of salient chart features. It is also, in the present case, important to remember that for the graphical conspicuity of dangers in an ENC to work as intended, it is necessary to set the correct Safety Depth and Safety Contour.
4.2.3. The fourth barrier: the route safety check
To prevent ships from grounding due to negligent visual inspection of the planned voyage track, ECDIS manufacturers have developed an automatic ‘Route Safety Check’ in response to MSC.232/A11.3.4 as mentioned earlier. By selecting the Route Safety Check, the system will walk through the selected route and produce a list of violations, e.g. if the track should pass over land, cross the set Safety Contour, a spot sounding less than the set Safety Depth or a precautionary area of some kind. Regulators have mandated that a route safety check must be done prior to departure.
To give some margin for this check, a Cross Track Limit (XTL) to the port and to the starboard of the track line can be entered into the Route Plan Settings window (see Figure 7, left). In Kaami’s case, the XTL was set to 0.1 nautical miles port and starboard, thus producing the ‘corridor’ visible in Figure 8, inside which the checks for shallow water or obstructions are made. There is also a Cross Track Difference (XTD) value showing how much to the port or starboard side of the planned track the ship is presently. If the XTD is larger than the XTL, an alarm can be triggered (activated by the tick box in Figure 7, right, from the JAN-2000 manual). MAIB’s report does not mention if this alarm was activated, but then Kaami never left her planned corridor.
To the left is a screen dump from the Route Plan Settings window on Kaami’s ECDIS. It shows the XTL settings and that the Check Safety in Editing was not activated (the tick box is unchecked). Yellow highlights by MAIB. To the right is an illustration from the JAN-2000 manual showing the Ownship/Track menu where the mandatory Safety Check can be activated. This is also where the Cross Track Distance (XTD) alarm is activated. MAIB’s accident report does not mention if this alarm was set.
After the accident MAIB conducted the missed route Safety Check and for the route leg between WP19 and 20 which crossed the grounding place, an error list was produced. Crossing Safety Depth and Safety Contour both indicated an ‘hazard’ in the list of errors, and a pop-up message on the chart.
Even with the Safety Contour set to the faulty 5 m, the ECDIS Route Safety Check would have warned the captain of the mistake made in the voyage plan as the grounding position was a rock with less than 5 m of water. The MAIB did such a Safety Check on the Kaami’s ECDIS after the accident and this test indeed produced the alarms and warnings shown in the screen dumps in Figure 8 for the leg between waypoint 19 and waypoint 20, passing over the grounding place.
While the MAIB writes ‘It was not possible to ascertain from Kaami’s ECDIS whether a safety check had been conducted for the route before it was used’ (p. 22), it is reasonable to assume that the safety check was not done, considering that the Kaami grounded following this exact route during the accident night. In some systems, a route cannot be ‘Activated’ and sent to a track pilot if the route is not safety checked (another safety barrier), but Kaami was probably navigated using manual input to the autopilot during the voyage in question.
Did the captain forget the mandatory Safety Check? Forgetfulness is a human trait. As a defence against forgetting to do the Safety Check, ECDIS developers have designed an automatic feature which automatically checks the route as the waypoints are entered during the voyage planning phase. However, this automatic feature was not activated, see Figure 9.
The bottom part of the Route Planning Setting window (shown in full, left in Figure 7). By ticking the box in front of Check Safety in Editing, an automatic feature will check the past leg each time a waypoint is clicked in – but at a cost of waiting time while the system does the Safety Check. The yellow highlighting and comment are made by MAIB.
Design comment. From the foregoing, it can be seen that the safety barriers designed into the system were bypassed either wilfully, by mistake or maybe through forgetfulness. In recent years, IMO has required mandatory, type specific ‘familiarisation’ training for all bridge officers. However, considering that the MAIB states that ‘ECDIS training undertaken by the ship’s master and deck officers had not equipped them with the level of knowledge and skill necessary to operate the system effectively’ (p. 41), it is however also possible that the operators were never aware that these safety barriers were disabled, i.e. the operators suffered from a kind of ‘mode confusion’, daunted by the overall complexity of ECDIS, and the rather massive amount of information to be absorbed and processed. The length of the error list in Figure 8 serves as a good illustration. Some of the errors are crucial (in this case, the ‘Hazard’ warning), while some are less important but still must be understood. In practice, almost every coastal leg produces a list with errors, which is cognitively demanding for navigators to check. From a design and user testing perspective, ways of simplifying and especially sorting these message flows are much needed, supporting the operator to focus on alerts in the order of importance to the safety of navigation.
Correspondingly, we are also suggesting exploring whether highlighting unchecked routes distinctly from checked routes would help remind operators to not only perform the Route Safety Check, but also deter anyone from manually following a route that was unchecked.
4.3. During-voyage ECDIS activities
4.3.1. The fifth barrier: the danger detection warning (look-ahead alert)
Even if the safety barriers intended to catch problems during the planning phase have failed, there are additional safety barriers designed to warn for dangers during sailing. One of them is the ‘Danger Detection Vector’ (and/or ‘Sector’). This feature, sometimes called the look-ahead function and mandated by MSC.232(82)/ A11.4.3 (see also above), uses a vector and/or sector in front of the ship and continuously searches for safety violations, checks related both to the set Safety Contour as well as other charted features and objects. If the look-ahead function detects a possible violation, it generates an alert. In Figure 10, a look-ahead vector just reaching the Safety Contour is illustrated to the left. The two figures to the right are copied from Kaami’s ECDIS manual, explaining the features. The look-ahead feature acts as a final layer of safety should a navigational hazard be missed by either the ECDIS Route Safety Check or visual check of the route.
Left image, the Look-ahead function checkes the water depths in a vector and/or a sector in front of the ship in real-time while the ship is sailing and generates an alarm if the Safety Contour is crossed (illustration by the authors). Right, the Danger Detection Sector and Vector description from the JRC JAN-2000 Instruction Manual (JRC, 2016).
In the JAN-2000 system used onboard Kaami, setting up the look-ahead feature is done in the ‘Alert Limit Setting’ window (see Figure 11). Left is the panel from the JAN-2000 manual and right is the screen dump from MAIB. What we can see is that none of the safety alerts available in this window were activated.
Left is the description of the Alarm Limit settings window from JRC’s JAN 2000 ECDIS manual (2016). Right is a MAIB’s screen dump from Kaami’s ECDIS screen showing boxes for activating look ahead were unchecked, as were indeed all of the alarm features available (highlight and comment by MAIB).
Design comment. The MAIB report does not answer the obvious question of why none of the alert features were activated, but we cannot help but speculate that if the look-ahead function had been ‘on’ on the Kaami during the fatal night, the accident could have been avoided. However, from our experience talking to bridge crews over the years, we know that false alarms are considered a significant distractor in navigation, anecdotally leading to the operators disabling safety features. The contradiction is worrying: safety and distraction. From a design perspective, it seems to be a significant failure to design a safety function which is such a nuisance that it prevents operators concentrating on safe operation, leading to the very function providing a last barrier against accidents being turned off or otherwise disabled.
The design challenge is ‘simple’. Look-ahead features, as they are required by the ECDIS performance standards, are unintelligent as they look straight ahead even if the track is winding between islands and shoals, and thus are causing annoying, false alarms. Similarly, they are static in terms of settings, which often causes nuisance alarms in narrow fairways, port entrances and similar restricted waters. As we see it, the next generation of look-ahead feature should follow the planned track, and become context-aware with respect to fairways and other depth limitations, greatly reducing the nuisance alerts – and, in parallel, once more advanced solutions become available, the maritime industry should discuss whether it should be possible to turn off crucial safety features in ECDIS.
4.3.2. The sixth safety barrier: alarm buzzers
IMO Resolution A.1021(26) ‘Code on Alerts and Indicators’ (2009) regulates how visual and audible navigational alerts on the bridge, including those originating from ECDIS, are to be provided to the mariners.
The JRC JAN-2000 has almost 100 audible navigation alarms. The audible alarms are given by an alarm buzzer. The volume of these alarms can be set in the Buzzer Volume panel (see Figure 12). Upon inspection after the accident, MAIB discovered that the volume of all types of audible alarms on Kaami was set to zero – no sound. Only the visible, on-screen alarms remained.
MAIB’s screen dump of the Buzzer Volume settings panel on Kaami’s ECDIS. Buzzers for all the different alarm types were set to zero (no sound).
Design comment. As we touched upon in an earlier design comment, our experience over the years of interviewing navigation officers is that the most prominent complaint about the work environment on the bridge is the multitude of alerts. All instruments have audible alarms and, possibly due to the acoustic properties of wheelhouses, it is often difficult to locate which system is emitting an alert. It is also the case that the intensity (sound pressure) of the buzzer has often nothing to do with the importance of the alert and alert cascades are often experienced, in the sense that one issue triggers alerts from other systems as well. Again, the cure is ‘simple’: careful alert management, including setting priorities and using interlocks to avoid cascading alerts. As we see it, the IMO Bridge Alert Management standard (MSC.302(87)) and, especially, Centralised Alert Management (CAM) applications take an important step in this direction, but conceivably, the next generation of alert management needs to be context-aware, in the sense that the situation of the ship and the environment determine the priority of alerts, including supressing alerts that are of lesser importance in any given situation. We also believe that a discussion within the maritime community as to whether it should be possible to entirely turn off audible alerts should be permitted – in some cases, like the Kaami, they could be a last barrier standing between a very real, very dangerous situation.
4.3.3. The seventh barrier: a second pair of eyes
As demonstrated in the foregoing, someone onboard the Kaami, at some stage, had turned off important alerts and ECDIS safety barriers appear to have been breached on the night of the accident. We cannot help but wonder whether this includes a disregard of IMO’s Resolution A.893.21 (1999), which says: ‘Each voyage or passage plan as well as the details of the plan, should be approved by the ships’ master prior to the commencement of the voyage or passage’ (section 3.4). Moreover, also SOLAS, Chapter V, Annex 23 recommends using the four eyes principle: ‘Masters, skippers and watchkeepers should therefore adhere to the IMO Guidelines taking the following measures to ensure that they appreciate and reduce the risks to which they are exposed: [- - -]. b) ensure that there is a systematic bridge organisation that provides for: [- - -]. iii) cross checking of individual human decisions so that errors can be detected and corrected as early as possible’ (IMO, 1974). As we know it, the normal procedure on ships with three or more deck officers is that the 2nd officer makes the voyage plan which is then checked and signed by the captain. On a small vessel like Kaami, with only two deck officers and the first officer busy with cargo operations in port, for the voyage being discussed here, the captain both made and signed the voyage plan, breaching the independent check recommend by the IMO.
Design comment. While perhaps not being directly associated with the design of ECDIS, bridge procedures should have adopted the spirit of the rules, which could be expressed as ‘The voyage plan should be accepted and signed by two officers, one of whom should be the captain, before the departure of a ship’. Clearly, this is a procedure which could be policed by ECDIS, requiring signed login and signing off of routes, but we realise that there would be many downsides associated with this kind of rigour, including making changes while underway etc. It is also the case that even this would not have had an impact on the Kaami incident, since the ship manually followed the planned route, rather than automatically.
4.3.5. The eighth barrier: traditional manual, looking-out-the-window night navigation
The Little Minch strait is well equipped for night navigation with lighthouses and light buoys. The IMO recommended route between Comet Rock and Eilean Troddy has sector lighting and for ships taking a route north of Comet Rock, the Eugene Rock light buoy was working the night of the accident providing a visible warning at the precise grounding place that became Kaami’s fate. However, as MAIB writes, ‘neither member of the bridge team appreciated its significance’ (p. 36).
Design comment. There is no obvious, single improvement or design change to ECDIS that will make operators notice the unnoticed, especially in cases as the one being discussed here where most of the safety barriers were already breached. We however believe that visual (re)design of the ECDIS presentation shows promise, especially dynamic amplification of hazards. As of today, ECDIS symbols are static and of a fixed size. Redesign and extensive testing with users would demonstrate whether highlighting and amplification of places and aids to navigation (as well as Radar and AIS targets) which pose a risk would be effective, thus using the power of advanced algorithms and the modern computers used to run ECDIS rather than simply displaying a chart mimicking the traditional paper charts. Conceivably, in case the ECDIS on the Kaami had displayed the Eugene Rock light buoy in increasingly large size, possibly marked with a highlight, the operators would have noticed it when routinely scanning the ECDIS. There are several other ways dynamics could be introduced into ECDIS, including visual confirmation based on sector lights, bearings to known marks and land features, and all in all, we recommend such possible improvements are made a subject of discussion in the maritime community. Getting and keeping the attention of the operator could also be through the system requiring a continuous use of manual Lines of Position, which would give the operator an active role, rather than the anecdotally passive one seen today – the cure to missing cues could well be to engage the watchkeeper continuously, which, at the same time, would also keep manual navigation skills sharp.
5. Discussion
Sharing of data between ship–ship and ship–shore systems has increased shipping safety immensely. The constantly lower number of ship losses and accidents carry this message. For the future, ship traffic management and sharing of routes and route intentions could possibly increase safety even more. However, the fundamental issue in the Kaami accident remains: how is it still possible for a fully compliant and well-equipped ship to ground on a charted rock in the middle of a monitored seaway, as ‘the system’ the whole time was aware of the position of both the ship and the hazard that brought it to a halt. In the foregoing, we provide several design suggestions which could have changed the course of events, but is an underlying, greater problem also present?
Donald Norman (Reference Norman1990) tells the story of an Air China four-engined plane, which in 1988 suffered a slow loss of power from its outer starboard engine. This caused the plane to yaw to the right, but the autopilot compensated, until it finally reached the limit of its compensatory abilities and could no longer keep the plane stable. The plane rolled and went into a vertical dive of 31,500 feet before it could be recovered. Norman reflects on this case, and muses whether had it instead of the autopilot been a second officer that had the control, would he quietly have kept compensating for the loss of power? Would he not instead have told the captain that there was something wrong? The problem is not in automation, Norman concludes, it is lack of feedback. ‘When automatic devices compensate for problems silently and efficiently, the crew is “out of the loop”, so that when failure of the compensatory equipment finally occurs, they are not in any position to respond immediately and appropriately’ (p. 589).
In the case of Kaami, we speculate whether the navigation systems have become so complex that the users can no longer master them, as an alternative to being negligent, or not showing good seamanship. Has maritime navigation, with ECDIS, GNSS, AIS and VTS/VTM, entered into a paradigm of ‘over-automation’, where traditional manual navigation using buoys, lights, beacons, and leading lines using charts and looking-out-the-window has been forgotten? Drawing anecdotally on the past, we would not be surprised if the stress on a small ship with only two deck officers, having just completed loading and port departure, the captain and the chief officer did not have sufficient mental headroom to be aware of all the settings and where to find them. Similarly so, it would not be greatly surprising that being unaware of the safeguards that have been turned off, they trusted that ECDIS and automation would give them a safe passage. As the story goes, once the track was drawn into the ECDIS, each of the two officers (also the master who forgot the Safety Check) trusted the system to warn of any dangers along the way (even though many of the alarms were disabled). As no alerts were shown on screen (due to turned off safety features), they trusted that the route was safe.
We suggest there is a parallel to be made to Donald Norman’s story about the airplane autopilot above. Due to the settings and use of the ECDIS, the crew on the Kaami essentially put themselves in an ‘out-of-the-loop’ position, trusting the ‘system’, but unaware that the same system had all of the relevant safety features turned off.
One of the reasons for providing the detailed review of the different safety barriers breached above is to illustrate the complexity of one of the many different brands of ECDIS on the market, but also, constructively, to suggest possible design improvements. For years, the human factors community has been nudging for better design and improved usability through Human-Centred Design (HCD). Simplification of the HMI is seriously needed to get rid of the complexity of settings and different panels. The many different ECDIS manufacturers’ different ways of handling interface complexity is a known problem and standardisation (S-mode) has met corporate resistance. Automation is not, as we have seen, infallible. However, maybe the problem is, as Norman implies, not over-automation, but designs that provide inappropriate feedback (if at all), which does not cater for work-as-done, and are providing poor human–machine interfaces and, in total, provide poor human–system interaction.
6. Conclusions
In this case study, we have tried to answer the question of how an advanced system like ECDIS, developed with numerous features designed to help seafarers navigate safely, after three decades, still is subject to what we consider serious usability problems. In an in-depth analysis, we have been looking at the grounding of the small Norwegian bulk carrier Kaami to detect design issues that may explain the usability shortcomings found. Based on the authors’ many years of experience in maritime human-factors research, we came up with some suggested solutions.
Overall, we find it arguably demonstrated that the complexity in ECDIS has grown to a point where some navigators in a practical environment no longer can master the system fully. In the Kaami accident, safety barriers and features designed to help operators were deactivated, possibly without the officer of the watch being aware of the status of the system and, equally importantly, without any obvious indications on the ECDIS of that state. Designers, regulators and engineers need to be made aware of this, and solutions must be found.
The conclusion of the Kaami analysis can be summarised in the following five points.
-
1. Prevent ‘dangerous’ settings, such as the ability to turn off alarms, buzzers and warnings, deactivate look-ahead functions and automatic route checks. Clarification and simplification of settings relating to the correct display of ECDIS hazards (e.g. Safety Depth and Safety Contour).
-
2. Develop reliable alarm management systems reducing/removing nuisance alerts. Part of the solution can be to further have a systems-wide perspective, to introduce context-dependent alert filtering and sorting, to introduce variation in alert tones, pitch, frequency to ease identification, and to consider the use of voice messages explaining the issue.
-
3. Rethink the idea of ECDIS as a replica paper chart, but instead use modern computer power and advanced algorithms, possibly even a flavour of machine learning or AI, to help dynamically highlight hazards while toning down less important chart elements, supporting a user focus on safe navigation. Taking inspiration from traditional cartography could be useful and designing-for-salience is highly recommended.
-
4. Increasingly appreciate that bridge equipment – perhaps especially Radar and ECDIS – could be designed from a user-in-the-loop perspective, rather than as a pure information display system. By fostering interaction, user attention is most likely going to be higher, with improved situation awareness being the key result.
-
5. Mandate the use of seafarers’ expertise during type approval in the cases where the IEC standards call for ‘expert evaluation’, to ensure that designs make sense to end-users.
Speculatively, there are further options to be explored. One such idea is to highlight ships on Radar and ECDIS that do not follow a checked route, making them possibly ‘unreliable’ (see Figure 13) or even bring such ships to the attention of other ships, of VTS and/or of Coast Guards. This is however not necessarily a foolproof method, as the Kaami case shows. Here, the challenge came from the greater maritime community in the form of a radio warning from the fishing vessel Ocean Harvest. Six minutes before the grounding, the Ocean Harvest called on channel 16 to warn that Kaami was heading into ‘shoal waters’. Kaami’s chief officer responded promptly to the call and, after changing radio frequency to a working channel (channel 67), he thanked Ocean Harvest’s watchkeeper for the information, confirmed that he understood and that he would be altering the vessel’s course in the next few minutes. The reason this message did not help avert the grounding appears to be a case of different situation awareness and misinterpretation – the Kaami would have been changing course a bit later, had it not been for the accident, and the chief officer appears to have responded accordingly.
The red-flagged AIS symbol of a ship sailing without safety checked route and deactivated safety settings. Is this a way to use social pressure on ships to enforce rule observance? (Example image by the authors).
Reiterating, we believe it is time for a reconceptualisation of ECDIS, considering how ECDIS safety barriers and functions fit into current navigation (both voyage planning and voyage monitoring), and how the objective of safe navigation is best served by the high-power algorithms, computers and computer graphics now available at low cost, but completely beyond imagination when ECDIS was first conceived. In the widest perspective, a takeaway from the authors long experience with maritime human-factors research is to always use the Human Centred Design (HCD) work processes and heed its mantra: test with the users – while certainly the ECDIS on the Kaami ticked any and all the boxes of type approval, this is no guarantee of a system or device that is usable, i.e. being effective, efficient and satisfactory to the end-user. We firmly believe the mandatory use of HCD is the single-most important safety-related change relating to the design of future maritime systems needed and we invite a broad discussion in the maritime equipment industry to that effect.
Acknowledgement
EU project OCEAN (Operator-Centred Enhancement of Awareness in Navigation, www.ocean-navigtion-awareness.eu) started in 2022 focusing on enhancing operator awareness in navigation to reduce the frequency of severe accidents like collisions and groundings. This study has been presented at the ErgoShip conference in Esbjerg, Denmark on 2 November 2023 and was supported by the EU program Horizon Europe CL5-2022-D6-01 with grant number 101076983, which hereby is gratefully acknowledged.
Competing interests
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
M.H.L. is an Editorial Board Member for Journal of Navigation and was not involved in the editorial review or the decision to publish this paper.
Open access
