See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/342643479

Alarm management on merchant ships

Conference Paper · March 2006

CITATIONS READS

3 2,690

5 authors, including:

Ørnulf Jan Rødseth

ITS Norway
86 PUBLICATIONS 1,135 CITATIONS

SEE PROFILE

All content following this page was uploaded by Ørnulf Jan Rødseth on 02 July 2020.

The user has requested enhancement of the downloaded file.

 Alarm management on merchant ships
Ø. J. Rødseth1, M. Knight2, R. Storari2, H. Foss3, A. R. Tinderholt3
1 2
MARINTEK, Norway ; Carnival Corporation & Plc, UK ;
3
Kongsberg Maritime AS, Norway

SYNOPSIS
Modern ships have complex monitoring and control systems that are designed to give a high number of technical and
operational alarms. These alarms are essential for the safe operation and management of the ship and its systems.
However, the Officers of the Watch (OOW), on the Bridge and in the Engine Control Room (ECR), can easily be
distracted by non-critical alarms during normal operating conditions, and even more so in abnormal conditions. In
addition to the distraction caused, a high number of alarms without selectivity may make it difficult to track, find and
correct the root cause of the problem. Various systems for alarm filtering have been proposed over the years but most
of these have their basis in industrial control systems and are not directly developed for use by ship officers that have
the main responsibility for operating the ship rather than the technical systems. In DSS_DC, this led to the
investigation into status assessment modules as a potentially more useful decision support mechanism than the
conventional alarm management or filtering systems. The purpose of these modules is to give an “at a glance”
assessment of ship systems such as propulsion and manoeuvring, life support, passenger comfort systems, safety
systems and environmental systems. The assessment includes the effects of any active alarms, as well as providing
operating hints only if requested by the operator. The DSS_DC project investigated this issue on board a shuttle
tanker and on a selection of cruise ships.

DEFINITIONS AND ABBREVIATIONS

Alarm – An alarm or alarm system which announces by audible means, or audible visual means, a condition requiring
attention1.
AIS – Automatic Identification System (Ship position, speed and heading transponder system)
ARPA – Automatic Radar Plotting Aid (Tracks other ships detected on the radar).
BTM – Bridge Team Management (see BRT)
BRM – Bridge Resource Management (same as BTM)
DG – Diesel Generator
DSS_DC – Decision Support for Ships in Degraded Situation. See acknowledgements.
ECR – Engine Control Room.
FSA – Formal Safety Analysis2.
GMDSS – Global Maritime Distress and Safety System.
IBS – Integrated Bridge System.
IMO – International Maritime Organization (www.imo.org).
INS – Integrated Navigation System. An INS is a combination of systems that are interconnected to increase safe and
efficient navigation by suitably qualified personnel3.

Authors’ Biographies
Ørnulf Jan Rødseth (ornulf.j.rodseth@marintek.sintef.no) is a Senior Scientist at the Norwegian Marine Technology Research
Institute. He works mainly with real-time and safety critical systems. Martyn Knight (martyn.knight@carnivalmaritime.com) and
Renato Storari (renato.storari@tin.it) are Risk Analyst/EU Project Coordinator and Principal R&D Engineer respectively. They work
with research projects as well as new buildings for Carnival Corporations. Halvard Foss (halvard.foss@kongsberg.com) is Business
Development Manager and Amund Ragnar Tinderholt (amund.ragnar.tinderholt@kongsberg.com) is Senior Project Engineer in
Kongsberg maritime AS. They work mainly with integrated automation and dynamic positioning systems.
ITEA-DS – Intelligent tools for emergency applications & decision support (see acknowledgements).
OOW – Officer of the watch
Safety Centre – A dedicated control room or area for safety related and non navigational operations during an
emergency4.
SOLAS – International Convention for Safety of Life at Sea5.
UPS – Uninterruptible Power Supply

BACKGROUND
Modern merchant ships gets more technologically advanced systems whilst crew numbers are decreasing. While the
reduction in crew ideally should be followed by systems that are easier to operate, this is not necessarily the case. Both
integration and complexity leads to problems with, e.g., an increasing number of alarms. Alarms exist to provide
information to the operator and cannot be avoided as such. One example of this is the Royal Majesty grounding6 where
the correct reaction to a GPS or a depth sounder alarm could have avoided the accident. Unfortunately one was disabled
and the other overlooked. However, alarms also cause problems:
Out of context alarms in critical situations. The OOW is required to handle alarms on the bridge whilst also
manoeuvring the ship. In critical situations alarms that are not immediately critical and that do not relate to the current
situation, can reduce the OOW’s concentration. Although not related to alarms, one result of OOW distraction is the
collision between Norwegian Dream and Ever Decent in the English Channel7.
Alarm avalanches. When some central component fails, e.g., a power supply, this results in secondary alarms from units
dependent on the failed component. A high number of alarms can confuse the operator or fill up the alarm lists, thus
making it difficult to find and correct the root cause unless the operator is very experienced. A test performed during the
DSS_DC investigation identified 205 alarms generated during the 115 seconds required to restore a partial blackout8.
Alarm overload. Systems that produce less critical alarms at a high rate can detract attention away from running the
processes. Another problem is that accepting alarms as a routine procedure may lead to ignoring a dangerous situation.
From the Norwegian Oil Directorate9, a rate of maximum 12 alarms per hour is recommended for steady system
operation. In the DSS_DC investigations8, 78 alarms per hour were found in the engine room of one of the ships. It
should be noted that while this is clearly above the suggested maximum, there was no evidence that it was a safety
problem on the ship in question.
The latter two problems are most applicable for automation and safety systems where there are a high number of alarm
sources. In navigation systems, the number of alarm sources is limited. However, bridge operation, particular at night, is
highly demanding and all unnecessary alarms should be avoided. About 40% of all serious accidents with passenger
vessels greater than 4000 GRT in the period 1990 to 2004 have been related to navigation10 and in an FSA on cruise
ship navigation, all experts ranked distraction of the OOW as the most severe challenge11.
Finally, one should also note that this is not only a technical issue. Good management of the human element is usually
more important than optimal alarm management on the technical side.

TYPES OF ALARMS
An alarm is used to alert an operator to an abnormal situation. However, there are different types of alarms: An alarm
from the food provision plant has a different importance and immediacy than one from the anti-collision radar. IMO’s
code on alarms and indicators1 defines the following main types of alarms:
1. Emergency alarms: Immediate danger to life or ship.
2. Primary alarms: Alarms which indicate a condition that requires prompt attention to prevent an emergency
condition.
3. Secondary alarms: All other alarms, i.e., those that indicate another condition requiring attention.
4. Indication: Status indicator to operator.
This is a coarse prioritization and does not necessarily reflect operational immediacy. A more elaborated list is
presented in Table I. This list relates mainly to the OOW on the bridge and is the authors’ attempt to systemize their
experiences. It is not related to IMO or other organizations’ rules or regulations.
In the table, one should in particular note the following groups:
• Group 3 - Operational: One can in many cases look at this group as not being alarms at all. They are expected and
typically used as feedback to operator to signal end of or change in operation or operational mode.
• Group 5 – Technical: Technical failures are today typically signalled as alarms. This is due to regulations and often
a lack of alternatives. Although the underlying condition may be serious enough, the OOW normally has no
possibility to do much about the alarm other than notify the engineer or the electrician. Also some alarms in group
4 are signalled as technical alarms (noted in last column).

Table I Detailed overview of alarm types

Priority Type Examples Technical

1. Immediate danger to life or ship Advise to afflicted personnel: Abandon ship, Watertight door closing,
(Emergency). CO2 release etc.
2a. Developing accident (Primary) Urgent intervention needed: AIS/ARPA collision alarm, depth sounder
etc.
2b. Developing emergency (Primary) Urgent investigative action needed: Fire alarm, bilge alarm, GMDSS
(ship distress), etc.
3. Operation related (Primary) Alarm expected as part of operation: Waypoint alarm, tank level high,
etc.
4. Safety hazard developing Maintenance or attention needed: fire detector defect, CO2 control Many
(Primary/Secondary) cabinet not closed, fire door did not close, etc.
5. Technical alarm (Secondary) Maintenance needed: No immediate safety consequence. All
6. Announcement to operator Feedback on earlier operation: Error in input, missing authorization.
(Secondary/ Indication). Repeat operation.

If one goes back to the three alarm problems outlined in the previous chapter, one can suggest how the above alarm
groups relates to the three types of alarm problems.
Out of context alarms: This is mainly a problem in groups 2 to 4, e.g., a group 4 alarm (CO2 control cabinet door open)
can be very serious in normal operation, but may be less so when the ship is in danger of running aground.
Alarm avalanches: The main problem here is basically that loss of critical functions is often signalled as a technical
alarms (group 4 and partly 5). An underlying problem is the need to signal both a degraded function, i.e., a safety
hazard and a technical problem, i.e., a need to maintain or repair. The former is mainly intended for the bridge while the
latter is mainly intended for the engineers or electricians.
Alarm overload: “Superfluous” alarms are typically also out of context, e.g., on an aging passenger ship one tends to get
a high number of technical faults due to wear and tear and the size of the plants: Several thousand fire detectors all have
sensors, connectors and cables that can fail. Another problem is loss of information. This can in part be caused by the
alarm being out of scope, e.g., the operator failing to understand the functional consequence of a technical alarm or due
to the operator losing some critical details because he or she needs to focus on the serious issues. Thus this problem
mainly is related to technical alarms (groups 4 and 5).

EXAMPLES FROM DSS_DC

DSS_DC did some on-site investigations on a shuttle tanker and three cruise ships. Below are some results from the
tanker (first two sections) and one of the cruise ships. Both are very well managed ships and can be looked at as “state
of the art” for advanced merchant ships.

General automation system alarms – shuttle tanker

The logging period was 72 hours that covered departure from land, transit and arrival at loading buoy as well as loading
and DP operations at buoy. All alarm and message events were stored in the automation system event database onboard.
This database was copied to an offline computer for analysis after the registration period.
The alarm events were extracted from the event database and categorized with assistance from vessel officers. A total of
184 alarm events that required attention from the crew was found, with the distribution as shown in Fig 1. Fig 2 shows
the alarms grouped with regards to the sub-system generating the alarm. This gives two to three alarms per hour and this
is well below the quoted limit9.
The group “Alarm” is an indication that an action is needed (groups 2 and 3 from chapter 3). “Anomaly” means that an
abnormal condition has occurred and is typically encountered as a repetitive alarm. “Discrepancy” is an event generated
because of wrong setting of equipment parameters. “Spurious” means that the underlying reason cannot be assessed or
is not justified. “Testing” is caused by ongoing test or repair activities.

Alarms - Categories Alarms - Groups

45 35

40
30
35
25
30
Percentage

Percentage
25 20

20 15

15
10
10
5
5

0 0
Alarms Anomaly Discrepancy Spurious Testing Ballast Cargo Machinery Power Misc.

Fig 1 General automation system alarms by type Fig 2 General automation system alarms by sub-system

Table II contains some comments on the alarms in the different command groups.
Table II Comments on alarm types per command group

Group #Alarms Comments

Ballast 36 The ballast process was run manually during cargo loading.
Alarms were mainly generated when the tanks were emptied. An improved control of tank stripping will reduce this
number significantly. Similar alarms will occur during cargo unload.
Cargo 30 Alarms are used as information to signal “Tank filled up”. Thus, they are mainly part of normal operation.
Machinery 61 These were identified mainly to be due to technical problems in one Boiler system component and to the Bilge tanks.
Power 42 Earth failures caused 12 of these alarms. 16 alarms were caused by equipment testing
Misc 15 These are various system internal alarms.

In several cases it turned out that an alarm delay would avoid the alarm event. This may be due to liquid movement in
tanks during rough sea, etc. Also, a function to “shelve” alarms would be useful, in particular during the unmanned
machinery mode where only one engine officer is on watch. Shelving allows alarms to be temporarily “disabled”
without being removed from the alarm system. The concept is discussed later in the paper.

Partial blackout – shuttle tanker

A partial blackout test was prepared on the shuttle tanker and executed by first opening the bus tie between engine
rooms and then tripping the running generator by introducing an earth fault. One starboard Diesel/Generator (DG) is on
standby start, the other is running. The port side generators and power systems were unaffected by the test.
The observed progress of the test is shown in Table III. Times are in seconds and relative to the initial event. The
analysis is based on inspecting the event database in the automation system.

Table III Development of blackout test

Time Event
0 Blackout condition generated for starboard DG (DG2S).
0 Alarm on DG2S due to and indicating earth failure created.
0 Starboard Switchboard: No power.
+3 Emergency DG: Breaker closed.
+4 Starboard Emergency Switchboard powered.
+4 Starboard UPS emergency power supply resumed.
+35 Starboard standby DG (DG1S): Engine started.
+45 Starboard standby DG (DG1S): Connected.
+115 All sub-systems report normal state.
A total of 206 alarms were generated during this period, with the distribution as shown in Fig 3.
Alarms - Blackout

60

50

40

Percentage
30

20

10

0
Ballast Cargo Machinery Power System Thrusters

Fig 3 Blackout alarm distribution

The examination of the event database showed that three shutdown messages, all related to the actual shut down DG,
were generated during the first two seconds. The remaining alarms are in varying degrees consequences of the
shutdown.

Engine room alarms – cruise ship

One of the cruise ship studies is summarised below. The study covered about 40 hours of watch-keeping both at sea, in
port and in port approaches and recorded 370 alarms in this period. This gives a rate of about 9 alarms per hour, which
is slightly below the suggested limit9. The findings from the study is summarised in Fig 4.

Alarms - Cruise

20
18
16
14
Percentage

12
10
8
6
4
2
0
e

ng

r
er

s
nk
e

te

te
nc

er
om
lg

at

i
wa
Ta

wa
ct
na

th
Bi

ro
lle

O
e

ay

e
h

co
nt

d
D

bl
es

gr

ol
ai

ta
Fr

C
e/
m

Po
cu
lg
g/

Bi

Va

Total (%)
in
st
Te

No action

Fig 4 Alarm distribution on cruise vessel

The two columns per entry show the percentage of alarms generated from each system and the part of these that
required no intervention from the crew (no action). A total of 42% of the alarms falls into the latter category.
The group of eight systems generated 80% of the totality of the alarms. This highlights the fact that a small part of the
controlled system generates the majority of watch-keeping alarms.

APPROACHES TO HANDLE OUT OF CONTEXT ALARMS

Bridge resource management

Bridge Resource Management (BRM) is defined in section B-VIII/2 of the STCW code12. The aim of BRM is to reduce
the risk of marine casualties by helping a ships bridge crew anticipate and correctly respond to their ships changing
condition. Thus, BRM is the effective management and utilization of all resources, human and technical, available to
the bridge team to ensure the safe completion of the vessels voyage.
As has been mentioned elsewhere, technical solutions may not be the only or the best remedy for handling the
increasing number of alarms. Improvements addressing the human factor may in many cases be better. Thus, it is clear
that BRM plays a significant role in this issue.

Two officers on the bridge

Introduction of more sophisticated and more technologically advanced systems has resulted in increased workload for
the bridge team and more distractions due to related and unrelated alarms. To help combat this, some companies have
now appointed two officers to be continuously on the bridge. The intention is for one officer to solely navigate /
command the vessel whilst the other monitors and acknowledges the various non-navigational alarms and systems, thus
assisting the navigating officer.
A FSA study performed on navigational safety for large passenger ships13 quotes an estimated Gross Cost of Averting a
Fatality (GCAF) of around USD 10 million over the ship’s lifetime for two officers on the bridge as a risk control
option. Although a commonly used implementation limit is USD 3 million14, most cruise ship owners have chosen to
implement this relatively expensive option as company policy.

Ship safety centre

The bridge is normally the “continuously manned central station” referred to in SOLAS Ch. II. It is presumed that all
monitoring and control of safety systems (fire, damage control, decision support systems etc.) is carried out from this
position.
However should an emergency occur, a situation may develop where management of the emergency could distract
watch officers from their navigational duties. The International Council of Cruise Lines (ICCL) recommended that new
larger passenger ships should be fitted with a dedicated safety centre4. This issue is still under consideration in IMO.
Although not compulsory, safety centres have been introduced as standard on many passenger ships.
The safety centre is not intended to be continuously manned and requires duplication of certain systems on the bridge to
allow for normal alarm management. It will be manned in an emergency situation when additional procedures come
into play.
The safety centre will not reduce the influence of out of context alarms. However, it will allow other members of the
bridge team to handle and manage the high number of alarms that typically occurs in an emergency situation. This
allows the OOW to continue his/her duties and concentrate on navigating the ship.

Continuously manned engine room

Normally, most alarms on ships are from the automation systems. This is due to number of individual alarm points and
the relatively complex dynamics that is being supervised and controlled. With unmanned operation of the engine control
room, these alarms are relayed to the bridge. It is clear that this can be a problem on ships that exhibit a large number of
automation alarms. On most passenger ships, the engine room is manned at all times and this should not be a problem.
On merchant ships, unmanned engine rooms are becoming the standard, particularly at night and in transit mode. The
magnitude of this problem has not been documented.

INS and IBS

On all ships, the safe navigation is a major issue. The reduced number of crew and officers onboard results in more
pressure for navigation officers. To address this problem and provide a better and safer working environment for the
officers, many new large passenger ships have now been fitted with Integrated Navigational Systems (INS) and
Integrated Bridge Systems (IBS).
An Integrated Bridge System (IBS) is defined as any combination of systems that are interconnected in order to allow
centralized access to sensor information or command / control from workstations to perform two or more of the
following functions: Passage execution; Communications; Machinery control; Loading and cargo control; and Safety
and Security15.
An Integrated Navigation System (INS) is defined as a combination of systems or functions of navigational aids that are
interconnected to increase safe and efficient navigation when used by suitably qualified personnel16.
One problem with navigational alarms is that they are not necessarily coordinated. As an example, a failure in a GPS
will normally cause several alarms to be raised in the different receivers of the GPS signal. The coming INS standard16
addresses this problem through provisions for alarm management where alarms can be “integrated” and displayed in a
more useful format for the officer. The same approach is also used in IBS where, e.g., Lloyds Register17 requires the use
of a centralized alarm system.

APPROACHES TO HANDLE ALARM AVALANCHES

Time tagging
The most commonly used and simplest method is to time tag alarms. This makes it possible to trace the temporal
development of an incident and to get an idea of what was the triggering event. This is of course useful to determine the
root cause and to find a way to rectify the situation.
However, it may not always be easy to determine the triggering event. This is particularly true when the system has a
relatively high continuous alarm rate and where the alarm list is long to begin with.

Alarm processing
The Norwegian Oil Directorate has published a document outlining principles for the design of offshore alarm systems9.
This document proposed Fig 5 for the illustration of alarm processing principles.

Fig 5 Alarm management

Alarm filtering removes “unimportant” alarms from the stream. This is not recommended as an unambiguous definition
of “unimportant” is very difficult to build into a computer program. Also, filtered out alarms are irretrievably lost.
Alarm suppression means preventing an alarm from being presented in main alarm displays, e.g. overview displays, but
leaving the alarm available in the system at a more detailed level.
Alarm shelving is a facility for manually removing an alarm from the main list and placing it on a shelve list, preventing
the alarm from re-occurring on the main list until it is removed form the shelf.
One should note that both suppression and shelving removes the alarm from immediate attention. On the bridge, one
can assume these alarms are typically related to a technical problem that has no immediate effect of the functionality of
the ship. Thus, they should be brought to the attention of the engineers. Shelving does not automatically perform this
notification and explicit procedures must be implemented to make sure that the shelved alarms are not “forgotten”. This
may, e.g., be a time limit on the shelving which re-activates the alarm if still active.

Integrated monitoring and alarm system

Integrated alarm or monitoring systems for automation are not based on IMO requirements, but is a practical
development in the automation area that tries to make life easier for engineers. This is regulated by the different class
societies with somewhat different rules and names, e.g., Lloyds Register refers to this as Integrated Computer Control18.
The principle is similar to that for integrated bridge systems: Making all alarms available on one workstation and
implementing measures to display them in a “sensible” manner will most likely help the crew to handle both normal
operation and exceptional situations. As was illustrated previously, this does not necessarily help on alarm avalanches.

THE DSS_DC APPROACH

Multi-function console (MFC)

There are a number of different persons in different physical positions that participate in handling both a ship’s normal
operation and emergencies. Thus, there is a need to distribute central information between these locations. This is
particularly of interest with regards to alarms that indicate a degradation of the ship’s capabilities and that may only be
displayed in one location, usually the engine control room. It was found that a decision support system (DSS) should be
devised for use by the ship’s Master and key officers and should contain important information that pertains to the areas
of responsibility of each of these key officers19. The DSS should be a multi-task tool available in the following four
stations:
• Wheelhouse for Officer-in-command/Master
• Safety Centre for Safety Officer/Master
• ECR for Officer on duty/Chief Engineer Officer
• Hotel Department Main Office for Hotel Manager
The DSS tool was specified as a multi-function console (MFC) where one part is a rendering area for a number of
underlying applications that can be selected from the tool. The other parts of the MFC give an overall assessment of the
status of the applications, including a high level alarm list and application display selection mechanisms. Thus, the
MFC itself is a flexible information distribution system that allows cooperative decision support between the ship’s key
officers and shore personnel21.

Status assessment display

Technical alarms carry information about degradation in ship systems that need to be brought to the master’s attention.
However, the format of the technical alarm is not always the best to convey this information and the alarm may also not
be presented on the bridge at all.
Originally, it was the intention in DSS_DC that all “important” alarms in the different ship systems should be made
available through the integrated alarm list in the MFC. The definition of “important” should be implemented as an
alarm filtering mechanism. However, after studies onboard and discussions internally, it was decided that it would be
better to use a number of “status assessment” modules to save the information and to make it accessible to the master or
the OOW in a more convenient format. The ship functions of primary interest for the master was defined as follows:
1. Power generation
2. Propulsion, Steering, Thruster
3. Navigation (Conning information)
4. Safety (Fire, Flooding, Emergency)
5. Welfare (HVAC, Fresh water, Black water)
6. Environment
Each function should have a separate status assessment module that with the help of simple block diagram graphics can
give an overview of the situation in each area. Simple colour codes are used to show the status, e.g., green – no
problem; red – problem detected. The status can represent the direct technical status or a status based on operational
mode as compared to rules laid down in, e.g., the ship’s safety manual.
The status assessment displays are made available through the MFC and can be checked at all central control locations.
Alarms in the system will now serve a dual purpose: They will be logged in the respective (integrated) alarm systems as
today, but they will also be used to update the status display for the relevant function.

Interface to maintenance system

Technical alarms will often refer to a fault condition that requires repair or maintenance. These alarms should in most
cases be brought to the attention of the engineers. Today this is done by having the engineers check the alarm system
from time to time to find these alarms. Alternatively, the maintenance personnel are notified directly by the OOW.
Ideally, maintenance related messages should be handled automatically through, e.g., the onboard periodic maintenance
system or similar maintenance systems. This issue was investigated in ITEA-DS and a simple XML format for such
maintenance messages was defined that could be transmitted through ordinary web service technology20. Arguably, it
could be possible to remove many technical alarms from the system if a combination of the status assessment display
and maintenance system messages was used. This would ensure appropriate notification of any degradation in system
capabilities as well as reliable notification of the maintenance requirements.
 Suggested new approaches to alarm systems
During the work in DSS_DC, a number of suggestions for the construction of new alarm systems were collected. Some
of these are listed in the below paragraphs. These suggestions represent personal opinion of interviewed ship personnel
and has not yet been validated or checked within the DSS_DC project.
Reduction of Information. Carefully review the process and information diagram of each of the ship’s systems in order
to reduce the quantity of information, e.g., instruments have been added without reviewing the logic for the whole
system. “Criticality” should be defined on a whole ship basis: What a supplier will see as critical for a particular piece
of equipment may have a minimal effect on the operation of the ship.
Defining Alarms and Events. Redefine alarms and events for every stand-alone automation system installed on board.
Alarm and Event annunciation to be redefined according to the following status: Critical and Not critical. Criticality
will depend on state of ship and operational condition. All alarms will be announced, sent to the graphic page, printed
and recorded according to the status above. Events are printed on the alarm printer but in a different font and colour.
They are logged in the same electronic file as the alarm for later retrieval. Events are not presented to the alarm graphic
page.
Suppression of unnecessary alarms. Review the hierarchy of alarms to ensure that only the most critical alarms will be
announced and other are suppressed from graphic page annunciation. The suppressed alarms will be treated in the same
manner as Events. The purpose is to eliminate unnecessary distractions to the operator during emergency situations.
Alarms on all graphic pages. When a new alarm occurs, it should pop up on any open graphic page. The operator
acknowledges the flashing alarm text at any control post and the alarm graphic page automatically pops up at the same
control post where the alarm was acknowledged. This will eliminate the need to designate an operator monitor
specifically for the alarm graphic page. This improvement will eliminate the need to call up the alarm graphic page and
so reduce waste time during emergency situations.
Improvement of Alarm Graphic Page. When critical alarms are active, the top part of the alarm graphic page presents
the critical alarms and the lower part contains the active not critical alarms. The view of the critical alarms should
always be on top even when operator scrolls through not critical alarm graphic pages. There shall be a clear separator
between critical and not critical alarms in the alarm graphic page.

CONCLUSIONS
This paper has described some experiences and results that we have collected in the DSS_DC project. An important
premise is that distraction to the OOW is a serious problem and that alarm handling is one of the issues that can be dealt
with more effectively. Also for the engineers, the current alarm management principles can be improved: Too many
alarms in critical or routine situations may make it difficult to determine the most appropriate corrective actions. The
paper gives some results from actual case studies that have been performed onboard state of the art merchant ships to
illustrate the problem.
One conclusion is that modern integrated ship control systems put an unnecessary high burden on the OOW through a
less than ideal alarm philosophy. This is partly based in regulative requirements and partly due to a lack of functional
integration in the systems. One possible solution to this problem is the use of automatic transfer of maintenance related
alarms to a dedicated maintenance system while the functional consequences of the various underlying problems are
collated in a status assessment module. This would help to remove unnecessary alarms, create a better status overview
as well as making sure that maintenance needs always are recorded.
The status assessment modules when displayed through a distributed multi-function console can also give general
benefits in emergencies by making a digested status information available on the actual situation in the most critical
ship systems. This information can easily be made available to all decision makers on board and on shore.

ACKNOWLEDGEMENTS
The DSS_DC project was funded by the European Community under Framework Programme 6: Sustainable Growth,
Global Change and Ecosystems / Sustainable Surface Transport, Contract TCT3-CT-2003-506354.
The ITEA-DS project was funded by the European Community under Framework Programme 4, EU research contract
IST–1999-20254.
 REFERENCES
1. IMO Code on Alarms and Indicators. International Maritime Organisation, London, UK, 1995.
2. IMO MSC/Circ.1023: Guidelines for Formal Safety Assessment (FSA) for use in the IMO rule making process.
3. IMO Resolution MSC 86(70), (adopted on 8 December 1998) Adoption of new and amended performance
standards for navigation equipment.
4. IMO MSC 77/4/1, 20 March 2003, Cruise Ship Safety Forum, Recommendations Submitted by the International
Council of Cruise Lines (ICCL).
5. The International Convention for Safety of Life at Sea (SOLAS), International Maritime Organization – IMO,
London, United Kingdom.
6. Marine accident report, Grounding of the Panamanian passenger ship Royal Majesty on Rose and Crown Shoal
near Nantucket, Massachusetts. June 10, 1995 National Transportation Safety Board, Washington, DC 20594.
7. Collision report slams safety procedure, Fairplay June 8, 2000.
8. DSS_DC Deliverable D02.1: Description of onboard and onshore processes, decision makers, actions, information
requirements and presentation format. Status with respect to onboard and onshore monitoring and guidance systems
(Restricted access), MARINTEK, 2005.
9. Principles for alarm system design, February 2001,YA-711. Norwegian Oil Directorate.
10. Lloyd’s Register Fairplay, Seaweb database at www.sea-web.org.
11. Rusås, S., Skjong R., Damage Stability Standards in a Total Safety, 9th Symposium on Practical Design of Ships
and Other Floating Structures, Lübeck-Travemünde, Germany 2004.
12. International Convention on Standards of Training, Certification and Watchkeeping for Seafarers (STCW), as
amended in 1995.
13. IMO Sub-Committee on Safety of Navigation, NAV 51/10, Passenger ship safety: Effective voyage planning for
passenger ships, FSA - Large Passenger Ships - Navigational Safety.
14. Formal Safety Assessment – Decision parameters including risk acceptance criteria. Submitted by Norway, IMO
MSC 72/16, International Maritime Organization, 2000.
15. IEC 61209 Maritime navigation and radiocommunication equipment and systems - Integrated bridge systems (IBS)
- Operational and performance requirements, methods of testing and required test results. , Ed.1, 1999.
16. IEC 61924 Maritime Navigation and Radiocommunication Equipment and Systems - Integrated Navigation
Systems - Operational and performance requirements, methods of testing and required test result, Committee Draft,
2005.
17. Lloyd’s Register Rules and Regulations - Rules and Regulations for the Classification of Ships, July 2004 – Pt. 7,
Ch. 9, Sc. 5 – Integrated Bridge Navigation System – IBS notation.
18. Lloyd’s Register Rules and Regulations - Rules and Regulations for the Classification of Ships, July 2004 – Pt. 6,
Ch. 1, Sc. 6 – Integrated computer control - ICC notation.
19. DSS_DC Deliverable D03.1: Detailed specification of total system, interfaces and requirements to the various
modules (Restricted access), MARINTEK, 2005.
20. Ø.J.Rødseth, ITEA-DS deliverable D8.4a, Integrated emergency management systems, November 13, 2001.
MARINTEK, Norway.
21. Rødseth Ø.J., Passenger ship safety and emergency management control, Lloyds register and Fairplay conference
Cruise and Ferry 2005, London, May 2005.

View publication stats