How Many Alarms Can a Bridge Team Absorb?

The process industries put a number on it decades ago: about one alarm per operator per ten minutes in steady state, and no more than ten in the first ten minutes of an upset. Marine has a harmonisation standard for how alerts are presented on a bridge, but nothing that states a rate a watchkeeper can absorb. Detector-level identification arrived in 2026 without that number being written.

What the process industries measured

They measured the human, not the plant, and the results have held up across three converged standards. EEMUA Publication 191 is the long-standing guide, ANSI/ISA-18.2 the North American standard, and IEC 62682 the international one; the three are now aligned on their core requirements. The benchmarks are unambiguous and they are low: a steady-state average below one alarm per operator per ten minutes, roughly 150 alarms per operator per day; a peak below ten alarms in the first ten minutes after a major upset; a standing alarm population below about ten per operator; chattering alarms eliminated rather than tolerated; and a priority distribution of roughly 5% high, 15% medium, 80% low. The last one is the most quietly demanding. If everything is high priority, priority carries no information, and an operator confronted with a screen of equally urgent items is doing triage the system was supposed to have done already.

What the marine standard actually harmonises

Presentation and priority — not volume. IMO Resolution MSC.302(87), adopted 17 May 2010 and in force from 1 July 2014, sets performance standards for Bridge Alert Management. It defines four alert priorities — emergency alarm, alarm, warning and caution — and specifies a Central Alert Management function with its own HMI requirements, with IEC 62923-1 and 62923-2 providing the operational and test requirements. Its stated scope is broad: the standards apply to all alerts presented on, and transferred to, the bridge. That is the right architecture, and it does real work in stopping every alert from being treated as equally serious. What it does not do is state how many alerts per unit time a bridge team can process. There is no marine equivalent of the one-per-ten-minutes figure, no standing-alarm ceiling, and no required priority distribution. BAM tells you how to rank and display what arrives. It does not constrain what arrives.

Why 2026 changes the arithmetic

Because the unit of identification moved from the zone to the device. Resolution MSC.550(108) revised SOLAS II-2/20 to require individually identifiable smoke and heat detector systems in vehicle, special category and ro-ro spaces, with MSC.555(108) amending FSS Code Chapter 9 to match — including provisions on linear heat detectors, detector positioning and system control, and applying to ships constructed on or after 1 January 2026. Linear heat detectors are to be tested to EN 54-22:2015 and IEC 60092-504. The safety case for this is strong and this analysis does not dispute it: a zone-level alarm on a large vehicle deck tells a crew that something is wrong somewhere in a very large volume, which is close to useless for a first response.

But it is worth being precise about what the change does to alarm load. It does not create more fires, and a real fire produces the alarms it produces either way. What it multiplies is the resolution of everything else the system emits — device faults, supervisory and open-circuit conditions, isolations logged during maintenance, and the cascade when a genuine event walks across many adjacent devices in sequence rather than lighting one zone lamp. A fleet moving from a few hundred zone addresses to several thousand device addresses has changed the size of its event stream without necessarily changing its bridge.

Why the process toolkit does not transfer whole

Because the most powerful technique in it is one a fire system is not free to use. Alarm management in a refinery leans heavily on suppression and shelving: an operator temporarily removes a known-nuisance alarm from the active list so the remaining ones stay legible. On a fixed fire-detection and alarm system, taking a detector out of the annunciated set is a regulated act with its own logging, authorisation and time limits, and it reduces the coverage the ship is certificated to have. The engineering consequence is that the load has to be managed before annunciation rather than after it.

What does transfer is the discipline that has nothing to do with switching alarms off: rationalisation, so that every configured alarm has a defined operator response and anything with no response is not an alarm; priority assignment that actually distributes rather than defaulting everything to the top; elimination of chattering at source through the detection logic instead of at the panel; and treating standing alarms as a defect to be cleared rather than wallpaper to be worked around. Note also that the comparison is directional, not numerical — EEMUA's figures come from continuously manned control rooms whose operators exist to respond to alarms, whereas a watchkeeper's primary duty is the safe navigation of the ship, which argues for a lower tolerable rate on a bridge rather than a higher one.

Designing to a load budget

• Set a rate target explicitly at design time, and record where it came from. If a project adopts the EEMUA figures it should say so in the specification, because nothing in SOLAS or the FSS Code will supply that number later.
• Separate the fault stream from the fire stream. Device faults, supervisory conditions and maintenance isolations scale directly with device count; routing them at the same priority as a heat alarm is what turns a granular system into a noisy one.
• Give every configured alarm a defined response. If there is no action a watchkeeper can take on receipt, it is diagnostic information for a maintenance log, not an alert for a bridge.
• Design the cascade, not just the detector. A real event crossing many adjacent devices should present as one developing situation with a location, not as a sequence of individually identifiable annunciations competing for the same screen.
• Establish for the specific vessel whether the fire panel is inside Central Alert Management or beside it. The two arrangements give the officer of the watch materially different tasks during a multi-alert situation.
• Treat standing alarms as a defect list. A population that never clears trains a crew to read the alarm list as background, which is the failure mode every one of these standards was written to prevent.

Sources

• 1. EEMUA Publication 191, 'Alarm Systems: A Guide to Design, Management and Procurement' — benchmark performance figures: steady-state alarm rate below one alarm per operator per ten minutes (approximately 150 per operator per day); peak below ten alarms in the first ten minutes following a major upset; standing alarm population below approximately ten per operator; chattering alarms to be eliminated; target priority distribution approximately 5% high / 15% medium / 80% low.
• 2. ANSI/ISA-18.2-2016, 'Management of Alarm Systems for the Process Industries', and IEC 62682, the international standard derived from it — alarm lifecycle, rationalisation and performance metrics, harmonised in core requirements with EEMUA 191.
• 3. IMO Resolution MSC.302(87), 'Adoption of Performance Standards for Bridge Alert Management', adopted 17 May 2010, entered into force 1 July 2014 — four alert priorities (emergency alarm, alarm, warning, caution); harmonised priority, classification, handling, distribution and presentation of alerts; Central Alert Management and CAM-HMI requirements; stated to apply for all alerts presented on, and transferred to, the bridge. Operational and test requirements in IEC 62923-1 and IEC 62923-2 — imo.org.
• 4. IMO Resolution MSC.550(108) — amendments to SOLAS Chapter II-2 Regulation 20 requiring individually identifiable smoke and heat detector systems in vehicle, special category and ro-ro spaces; and Resolution MSC.555(108) — amendments to the FSS Code including Chapter 9 (fixed fire detection and fire alarm systems), with provisions on linear heat detectors, detector positioning and system control, applying to ships constructed on or after 1 January 2026. Linear heat detectors to be tested to EN 54-22:2015 and IEC 60092-504 — imo.org, via Lloyd's Register Class News 07/2026 and ABS regulatory news on ro-ro fire safety.
• 5. Bridge Alert Management implementations and the alert sources they aggregate (radar, ECDIS, AIS, GNSS, autopilot, BNWAS, GMDSS and similar) — bridge-system vendor documentation and IEC TC80 supporting material for mariners.
• 6. Companion RoRoSAFE analysis — 'Individually Identifiable Detection & SOLAS' (what the 2026 requirement demands of the detection layer, which this article takes as its starting point rather than re-arguing), 'Tuning Coherence Windows to Kill False Positives' (suppressing nuisance events in the detection logic, which is where load has to be managed on a fire system), and 'The Cost of a False Alarm at Sea' (the operational and commercial consequence of getting the rate wrong).