Alarm Monitoring System
An alarm monitoring system continuously scans engine room sensors against set limits and raises audible and visual alarms the moment a reading goes out of range, forming the backbone that lets class grant unmanned machinery space notation instead of requiring a permanent watchkeeper.
Read more — Alarm Monitoring System explained ▾
What defines this type
An alarm monitoring system is the data-acquisition and alarm-handling layer that reads pressure, temperature, level and status signals from sensors throughout the engine room and auxiliary systems, compares each against pre-set limits, and raises an alarm the instant a limit is crossed. It is distinct from the individual protective trips built into a specific machine, such as a diesel engine's own overspeed shutdown, in that it covers the whole engine room as one integrated picture rather than one machine at a time, and it is what allows the vessel to run with a periodically unattended machinery space instead of a continuous watch. Where an automation and control system also takes protective action, such as starting a standby pump or slowing the engine, the alarm monitoring function is the layer that first detects and reports the abnormal condition.
Main components
- Field sensors and transmitters throughout the machinery spaces, feeding pressure, temperature, level and limit-switch signals into the system
- Remote I/O modules or multiplexers that gather signals locally and pass them to the central processing units over a data network, reducing the amount of individual wiring run back to the control room
- Central processing units running the alarm logic, limit comparison and event logging, usually duplicated for redundancy
- Operator stations in the engine control room and on the bridge, displaying mimic diagrams, alarm lists and trend graphs
- Extension alarm panels in crew accommodation, required so an alarm can wake an engineer during unmanned periods
Selection and sizing
- Number of monitored points required by the vessel's machinery configuration and the class unmanned machinery space notation being sought
- Redundancy of processing units and network architecture, since a single point of failure in the alarm system defeats the purpose of unmanned operation
- Integration scope with other systems: engine control, ballast, cargo, fire detection, and whether these stay as separate systems with hard-wired alarm repeat or are fully integrated on one platform
- Data logging and trend capacity for troubleshooting and for satisfying survey requirements on historical alarm records
Regulations and class
SOLAS Chapter II-1 sets requirements for periodically unattended machinery spaces, including the alarm system's capability to detect faults and alert crew in accommodation. Class societies issue an unmanned machinery space notation, terminology varies by society, only after verifying the alarm system covers all machinery required by their rules for that notation, including dead-man alarm arrangements confirming an engineer acknowledges and responds to alarms during unmanned periods. Periodic survey confirms the alarm points still match the as-built list and that extension alarms in accommodation actually function.
Typical faults
| Fault | Cause | Consequence |
|---|---|---|
| False or nuisance alarms | Sensor drift, loose wiring, or limit settings too tight for normal operating variation | Crew starts ignoring or silencing alarms, risking a missed real fault |
| Missing alarm point | Sensor failed or disconnected without the fault itself being flagged | A genuine abnormal condition goes undetected because the sensor path is dead, not the machine |
| Extension alarm silent in accommodation | Speaker or wiring fault, or dead-man timer misconfigured | Unmanned machinery space requirement effectively not met even though logged as compliant |
| Processing unit failure without failover | Redundant unit not actually independent, sharing a common power feed or network switch | Total loss of alarm coverage instead of a graceful switchover |
What to look for in a supplier
- Genuinely independent redundancy in processing units, power supply and network path, not just a duplicated cabinet
- Open or documented protocol for future integration with other systems rather than a closed proprietary bus
- Alarm point list and setting documentation handed over in a form the crew and future surveyors can actually audit
- Track record of software support and spare parts availability over the system's expected service life, since these systems run for decades between major upgrades
A high nuisance-alarm rate is the single biggest threat to an alarm monitoring system's purpose: a crew that mutes alarms out of habit has quietly turned an unmanned machinery space back into an unmonitored one.
5 manufacturers · 136 models
Kongsberg
84
- I/O module failure
- Operator station HMI crash
- Network switch failure
- Sensor input calibration drift
- Modular I/O architecture allows scalable expansion and easy replacement of faulty modules.
- Redundant network backbone (dual‑redundant Ethernet) enhances system availability.
- Intuitive HMI with customizable alarm screens reduces operator workload and improves situational awareness.
- Built‑in remote diagnostics and Kongsberg software updates simplify maintenance and lifecycle support.
- Fully compliant with IMO guidelines for engine‑room automation, facilitating classification approvals.
- High upfront capital cost compared with basic monitoring panels.
- Complex integration may require specialised engineering support during installation.
- Proprietary software ecosystem can limit third‑party device compatibility without additional gateways.
- Network switch failure has been reported as a single point of failure if redundancy is not correctly configured.
- Operator station HMI crashes have occurred, necessitating regular UPS and backup workstation checks.
- Komponenten-Verschleiß durch Betriebsstunden und Umgebungsbedingungen
- Korrosion durch Seewasser-/Salzluft-Exposition
- Elektronik-/Steuerungsausfall durch Feuchtigkeit oder Vibration
- Wartungsintervall-Überschreitung verursacht vorzeitigen Ausfall
- Wireless sensors eliminate heavy cable runs and simplify installation on existing vessels
- Integrated with Kongsberg automation platforms for centralized alarm management
- Marine‑grade housing rated for salt‑water exposure and vibration
- DNV approved, meeting class survey requirements for temperature monitoring
- Remote diagnostics via the ship’s network reduce on‑site maintenance time
- Battery life of wireless nodes requires scheduled replacement (typically 2–3 years)
- Potential corrosion of sensor housings in harsh sea‑water environments if maintenance is delayed
- Wireless link can be affected by electromagnetic interference from other ship systems
- Higher initial capital cost compared with simple wired thermocouple loops
- Requires adherence to manufacturer’s inspection intervals to avoid premature failure
Kongsberg Maritime
39
ABB Marine
7
ABB
4
- Cloud connectivity loss
- Edge computing unit failure
- Sensor integration error
- Dashboard rendering fault
- Centralised view of all critical alarms across the vessel, reducing crew overload
- Remote access for shore‑based support and predictive maintenance
- Scalable cloud platform that can integrate new sensors without hardware changes
- Built‑in analytics to prioritise alarms and suggest corrective actions
- Supports both satellite (Inmarsat) and 4G/LTE connectivity for redundancy
- Full functionality depends on continuous high‑bandwidth satellite/4G connection
- Potential cybersecurity exposure if network is not hardened
- Edge computing unit may be a single point of failure without redundant hardware
- Initial integration with legacy ship sensors can require custom adapters
- Higher upfront cost compared to standalone local alarm panels
Wärtsilä
2- I/O card failure
- HMI workstation fault
- Redundancy switchover failure
- Alarm flooding from sensor drift
- Seamless integration with Wärtsilä engine control and other NACOS modules (propulsion, power, cargo).
- Built‑in redundancy options (dual I/O cards, hot‑standby HMI) for high availability.
- Scalable alarm database capable of handling tens of thousands of alarm points.
- Graphical HMI with customizable alarm screens and colour‑coded prioritisation.
- Remote monitoring via web interface and support for mobile devices.
- Proprietary hardware – limited compatibility with non‑Wärtsilä PLCs or third‑party sensors.
- Higher capital cost than generic PLC‑based alarm panels.
- Requires a dedicated spare inventory of I/O cards to maintain redundancy.
- Configuration complexity often needs specialised Wärtsilä engineering support.
- Potential for alarm flooding if sensor drift is not regularly calibrated (known failure mode).