{"id":51603,"date":"2026-04-17T21:26:21","date_gmt":"2026-04-17T20:26:21","guid":{"rendered":"https:\/\/maritimehub.co.uk\/?p=51603"},"modified":"2026-04-17T21:26:21","modified_gmt":"2026-04-17T20:26:21","slug":"ecdis-alarms-and-alert-management","status":"publish","type":"post","link":"https:\/\/maritimehub.co.uk\/ecdis-alarms-and-alert-management\/","title":{"rendered":"ECDIS alarms and alert management"},"content":{"rendered":"
\n

BRIDGE \u2192 ECDIS & Charts<\/strong><\/p>\n

Position on the Bridge<\/strong><\/p>\n

System Group:<\/strong> Navigation \/ Collision Avoidance<\/p>\n

Primary Role:<\/strong> Real-time positional alerting against chart hazards and operator-defined boundaries<\/p>\n

Interfaces:<\/strong> GNSS receivers, AIS, radar overlay, VDR, conning display, watchkeeper<\/p>\n

Operational Criticality:<\/strong> Absolute \u2014 alert failure removes the last automated layer between the vessel and a charted hazard<\/p>\n

Failure Consequence:<\/strong> Unacknowledged safety contour alarm \u2192 watchkeeper attention elsewhere \u2192 vessel crosses into shoal water \u2192 grounding. The sequence is well documented in post-incident reports and takes minutes to complete.<\/p>\n<\/div>\n

An alarm that sounds constantly teaches the watchkeeper to silence it.
An alarm that is silenced is an alarm that no longer exists.<\/em><\/p>\n

Introduction<\/h2>\n

ECDIS did not eliminate the grounding problem. It changed its character. Where paper chart navigation produced incidents from positional ignorance \u2014 the officer who did not know where the ship was \u2014 ECDIS-era groundings increasingly involve officers who knew exactly where the ship was and whose alarm system had been telling them something was wrong for the previous forty minutes. The alarm had been acknowledged, or silenced, or buried under seventeen others, and the watchkeeper had learned to treat it as background noise.<\/p>\n

Alert management on ECDIS is not a secondary administrative task. It is the mechanism by which the entire investment in electronic charting is converted into something that actually changes behaviour on the bridge. Without it, ECDIS is an expensive chart table that happens to flash.<\/p>\n

MSC.302(87) introduced a coherent framework for alert management across bridge systems in 2010. The standard exists because, by that point, there was extensive evidence that alarm floods were degrading watchkeeper performance across a range of integrated bridge configurations. ECDIS contributed heavily to that evidence base. Understanding what the standard requires, and why ECDIS in particular generates the conditions it was designed to address, is part of operating the system competently.<\/p>\n

This article addresses the alarm categories the system generates, the settings that govern when they fire, and the management discipline required to make them meaningful rather than habitual background noise.<\/p>\n

\n

Contents<\/strong><\/p>\n

    \n
  1. The alarm categories and what they represent<\/li>\n
  2. Default settings and their relationship to reality<\/li>\n
  3. Silencing versus acknowledging \u2014 a distinction with consequences<\/li>\n
  4. Alarm flooding as a navigation hazard<\/li>\n
  5. MSC.302(87) and the alert management framework<\/li>\n
  6. Passage planning as alarm management<\/li>\n
  7. The cluttered alarm screen as diagnostic evidence<\/li>\n
  8. Watch handover and alarm state awareness<\/li>\n
  9. Closing Reality<\/li>\n<\/ol>\n<\/div>\n

    1. The alarm categories and what they represent<\/h2>\n

    ECDIS generates alarms across several functional categories, and conflating them produces poor management decisions.<\/p>\n

    The safety contour alarm is the most operationally significant. The safety contour is a depth contour selected by the navigator to represent the boundary between navigable water and hazardous shoaling for that vessel’s draught and underkeel clearance requirements. Crossing it is not a navigational inconvenience. It is an indication that the vessel is entering water where it may not float. The alarm fires when the projected position, or the vessel’s actual position, crosses that contour. This is not a setting to be toggled off on a busy passage because it keeps sounding.<\/p>\n

    The guard zone alarm operates on a different principle. The navigator defines a zone around the vessel \u2014 customarily forward and to the sides \u2014 and the alarm fires when a charted object or depth falls within that zone. Guard zones are operator-configured and require deliberate thought about what constitutes a meaningful detection distance for the current speed, visibility, and sea room. A guard zone set to three cables on a vessel making eighteen knots in open water is providing less than a minute of warning. Most officers know this in the abstract but do not recalculate it watch by watch.<\/p>\n

    XTE \u2014 cross-track error \u2014 fires when the vessel deviates beyond a set tolerance from the planned track. The tolerance is configurable and in default settings is often generous to the point of uselessness. XTE alarms have their role in confined water or traffic separation schemes where precision matters. In open ocean passages, a large XTE tolerance is appropriate. The error is in applying the same value everywhere.<\/p>\n

    No-go area alarms are triggered when the vessel’s position or projected track intersects a zone that has been designated impassable for the vessel type or draught. These zones can be defined by the navigator or pre-loaded from chart data. They are only as useful as the draught entered into the system. A vessel that has loaded since the last system update, or whose trim has changed significantly, may have a no-go area definition that does not reflect the ship’s actual underwater profile.<\/p>\n

    Danger area alarms reference charted areas associated with specific hazards \u2014 submarine exercise areas, prohibited zones, TSS boundaries, military practice areas. They are informational rather than collision-critical in most cases, but they contribute substantially to alarm volume on complex coastal passages.<\/p>\n

    Every one of these categories produces a legitimate alarm. None of them should be reflexively dismissed. The problem is the conditions under which they fire, not the alarms themselves.<\/em><\/p>\n

    2. Default settings and their relationship to reality<\/h2>\n

    ECDIS leaves the factory with default alarm thresholds. Those defaults are set by the manufacturer to satisfy type-approval requirements under IEC 61174. They are not set for the specific vessel, the specific voyage, or the specific risk profile of the passage being planned.<\/p>\n

    The safety depth and safety contour values carry manufacturer defaults that may bear no relationship to the vessel’s actual draught plus required UKC. A default safety depth of 10 metres applied to a laden Panamax is not a safety setting. It is a delayed grounding.<\/p>\n

    Guard zone dimensions default to values that may be appropriate for a slow ferry approaching a berth and entirely inappropriate for a VLCC transiting a busy coastal approach at speed. The alarm will fire at the same distance regardless of what the ship is doing.<\/p>\n

    XTE tolerances in default configuration tend toward leniency because a tight default would generate constant alarms during autopilot steering in any kind of sea state. The consequence is that on passages where XTE is genuinely critical, the default provides no meaningful protection unless it has been tightened deliberately.<\/p>\n

    There is a well-established pattern in accident investigations: the ECDIS settings at the time of grounding reflect the manufacturer defaults, or near-defaults, with no evidence that they were reviewed during passage planning. The vessel’s draught is sometimes not correctly entered. The safety contour does not reflect the actual UKC requirement. The guard zone was not adjusted from the previous passage.<\/p>\n

    A default is a placeholder. It is not a passage plan.<\/em><\/p>\n

    3. Silencing versus acknowledging \u2014 a distinction with consequences<\/h2>\n

    IEC 61174 and the broader alert management framework draw a hard distinction between silencing an alarm and acknowledging it. The distinction matters operationally and it matters in the VDR record.<\/p>\n

    Acknowledging an alarm means the watchkeeper has received and understood the alert. It does not cancel the underlying condition. If the vessel remains in proximity to the hazard that triggered the alarm, the alarm will re-fire after a defined interval. Acknowledgement is a confirmation of awareness, not a resolution of the condition.<\/p>\n

    Silencing an alarm suppresses its audible component without necessarily indicating that the condition has been reviewed. On some ECDIS implementations, silencing a visual alarm without acknowledgement is possible. On others, the distinction in the UI is subtle enough that watchkeepers conflate the two actions under time pressure.<\/p>\n

    The VDR records alarm events. An investigation that reveals a pattern of rapid successive alarm acknowledgements, particularly in the minutes preceding an incident, is reading a transcript of a watchkeeper managing an alarm flood rather than managing a watch. Those records have been central evidence in prosecutions and flag state investigations.<\/p>\n

    Acknowledging an alarm is not the same as resolving the condition that caused it. Knowing that distinction is basic. Acting on it under pressure is another matter.<\/em><\/p>\n

    4. Alarm flooding as a navigation hazard<\/h2>\n

    Alarm flooding is not merely an annoyance. It is a recognised mechanism of navigational accident causation.<\/p>\n

    The human response to sustained alarm exposure is well documented in process control and aviation: desensitisation. An alarm environment in which the watchkeeper encounters fifteen alerts in the first ten minutes of a coastal approach has already degraded the environment’s ability to communicate genuine emergency. When the safety-critical alarm fires in minute eleven, it enters a cognitive context in which alarms are noise to be cleared rather than information to be acted upon.<\/p>\n

    This is not a failure of the watchkeeper. It is a predictable human response to a poorly managed alarm environment. The IMO and classification societies recognised this explicitly in the period leading to MSC.302(87). The concern was not theoretical.<\/p>\n

    ECDIS is particularly capable of generating alarm floods because it is monitoring multiple conditions simultaneously and is heavily dependent on correct configuration. An ECDIS with an incorrectly set safety contour, an oversensitive guard zone, and a tight XTE tolerance on an open-water passage can generate a sustained alarm state throughout an entire watch. Each individual alarm is technically correct. The collective effect is to train the watchkeeper to clear them without reading them.<\/p>\n

    A system that produces false positives reliably enough will eventually produce a false positive at the exact moment the alarm is real. By then, the watchkeeper will have stopped checking.<\/em><\/p>\n

    5. MSC.302(87) and the alert management framework<\/h2>\n

    MSC.302(87), adopted by the IMO Maritime Safety Committee in 2010, established the Performance Standards for Bridge Alert Management. It came into force for new vessels from 2011 and has been progressively required on existing vessels through SOLAS amendments.<\/p>\n

    The standard introduced a structured hierarchy: Warning, Caution, and Alarm. Not every alert demands the same response. Alarms require immediate action. Cautions require awareness and monitoring. Warnings require attention at a defined interval. The hierarchy is designed to direct cognitive load toward the conditions that actually require it immediately, rather than producing a flat landscape of undifferentiated alerts.<\/p>\n

    The standard also mandated the bridge alert management system (BAMS) concept \u2014 a centralised alert presentation layer that aggregates alerts from multiple bridge systems rather than allowing each system to manage its own alert queue independently. In practice this means that ECDIS alarms, radar alarms, GMDSS alerts, and machinery control alerts feed into a single prioritised queue visible at the conning position. The watchkeeper sees a ranked list, not seventeen separate alarm boxes competing for attention.<\/p>\n

    What MSC.302(87) did not do is configure the individual systems. The alert management framework provides the architecture. The passage planner provides the settings. If the ECDIS enters the coastal approach with default contour settings and an unconfigured guard zone, the BAMS will correctly prioritise and present the resulting flood of alarms. The flood still occurs. It is simply better organised.<\/p>\n

    MSC.302(87) reformed the presentation of alerts. It cannot reform the planning that determines how many there are.<\/em><\/p>\n

    6. Passage planning as alarm management<\/h2>\n

    The passage planning process, under SOLAS regulation V\/34, requires appraisal, planning, execution, and monitoring. Alert management sits squarely within the planning phase, but it is rarely treated as such in SMS documentation or in practice.<\/p>\n

    For each leg of a passage, the ECDIS alarm settings should reflect the specific geometry of that leg. Safety contour must be set to the vessel’s actual draught plus the required UKC for the area, accounting for any tidal calculations already incorporated into the plan. Guard zone dimensions should be calibrated to the planned speed and the detection-to-action time required for the sea room available. XTE tolerances should reflect the track corridor width that is genuinely acceptable at that point in the passage \u2014 tight in confined water, appropriately relaxed in open ocean.<\/p>\n

    Waypoint-by-waypoint review of alarm thresholds is not a theoretical ideal. It is what the system is designed to support. ECDIS implementations permit route-specific alarm settings on most modern platforms. If those tools are not being used, the passage plan is incomplete.<\/p>\n

    Danger area alarms for military exercise areas, TSS boundaries, and restricted zones should be reviewed during appraisal and disabled for zones that the vessel will not approach within meaningful distance. Leaving them active on the assumption that more information is always better is a category error. More undifferentiated information is not better. Relevant information is better.<\/p>\n

    Every alarm that fires unnecessarily on a watch is a small withdrawal from the account of watchkeeper attention. That account is not unlimited.<\/em><\/p>\n

    7. The cluttered alarm screen as diagnostic evidence<\/h2>\n

    A bridge inspection that reveals a routinely cluttered ECDIS alarm display \u2014 multiple unacknowledged or repeatedly re-firing alarms normalised across watches \u2014 is not evidence of a demanding passage. It is evidence of inadequate passage planning.<\/p>\n

    PSC inspectors and vetting inspectors have become increasingly literate in reading ECDIS alarm histories. The VDR captures alarm events. The ECDIS itself retains an alarm log. An alarm log showing continuous firing and rapid acknowledgement of safety contour or guard zone alarms throughout a coastal transit raises questions that will be asked by any competent inspector, and answered either by an explanation of why the configuration was appropriate or by evidence that it was not.<\/p>\n

    The argument that a demanding coastal passage justifies a busy alarm screen inverts the logic entirely. A demanding coastal passage is precisely the situation that requires the alarm environment to be clean, calibrated, and immediately legible. Complexity in the external environment demands simplicity in the alarm presentation. The two are not in opposition \u2014 one depends on the other.<\/p>\n

    A cluttered alarm screen is also a visible signal to the OOW taking over the watch. If the incoming officer accepts a handover with multiple active or recently acknowledged alarms without understanding the reason for each one, the watch has begun with incomplete situational awareness. The alarms are telling the ship something. Whether anyone is listening is a different question.<\/p>\n

    8. Watch handover and alarm state awareness<\/h2>\n

    Watch handover is a structured transfer of situational awareness. The alarm state of the ECDIS is part of that situational awareness and should be explicitly communicated, not assumed.<\/p>\n

    The outgoing officer should be able to state which alarms have fired during the watch, why they fired, what action was taken, and whether any alarm condition remains active or is expected to become active. If that account cannot be given, either the alarms were not properly monitored during the watch, or the alarm configuration is producing events that are not being tracked \u2014 both of which are problems.<\/p>\n

    The incoming officer should review the alarm log for the preceding watch before accepting the conn. On a long coastal passage, this is particularly important when the preceding watch negotiated a constrained area that has now been cleared. Settings appropriate for that area may not be appropriate for the current leg, and if they have not been adjusted, the alarm environment is already misconfigured.<\/p>\n

    Alarm acknowledgements by the officer going off watch, just before handover, to present a clean screen to the incoming officer, are a documented phenomenon. The motivation is understandable. The effect is to transfer a watch in a falsely clean alarm state, with the incoming officer having no record of what fired and why in the preceding period.<\/p>\n

    A clean alarm screen at handover is only meaningful if the conditions that might cause alarms have not changed. If the vessel is two miles from a headland and the screen is clear, the question is whether the screen is clean or has been cleaned.<\/em><\/p>\n

    Closing Reality<\/h2>\n

    The ECDIS alarm system is not a passive safety net that catches navigational errors independently of how it is operated. It is a configurable tool whose value is entirely determined by the quality of the configuration decisions made during passage planning. Poorly configured, it produces alarm floods that train watchkeepers to dismiss alerts. Well configured, it provides a tiered, manageable signal set that directs attention to genuine hazards at the moment when action is still available.<\/p>\n

    MSC.302(87) provided the architecture for rational alert management. It did not provide the passage planning culture needed to use it. The distance between what the standard requires and what is observed on many bridges is not a gap in regulation. It is a gap in professional practice.<\/p>\n

    An ECDIS that is alarming constantly is not protecting the vessel. It is doing the opposite. And somewhere in that noise, there is an alarm that matters.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Why ECDIS alarm flooding is a passage planning failure, not a system problem, and what MSC.302(87) actually changed on the bridge.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"fifu_image_url":"","fifu_image_alt":"","c2c-post-author-ip":"2a02:c7c:2ef8:2400:931:afb1:9971:4a62","footnotes":""},"categories":[10,1],"tags":[9129,9126,9127,9130,8949,9128,8953,8959],"class_list":["post-51603","post","type-post","status-publish","format-standard","hentry","category-bridge","category-latest","tag-alarm-flooding","tag-alert-management","tag-bridge-watchkeeping","tag-chart-systems","tag-ecdis","tag-msc-30287","tag-navigation-safety","tag-passage-planning"],"acf":[],"_links":{"self":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts\/51603","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Fcomments&post=51603"}],"version-history":[{"count":1,"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts\/51603\/revisions"}],"predecessor-version":[{"id":51621,"href":"https:\/\/maritimehub.co.uk\/?rest_route=\/wp\/v2\/posts\/51603\/revisions\/51621"}],"wp:attachment":[{"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Fmedia&parent=51603"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Fcategories&post=51603"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/maritimehub.co.uk\/?rest_route=%2Fwp%2Fv2%2Ftags&post=51603"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}