Project contract number: TIP5-CT-2006-031406

FLAGSHIP

European Framework for Safe, Efficient and Environmentally-friendly

Ship Operations

Instrument type: IP

Specific programme: Making rail and maritime transport safer, more effective and more competitive

D-C1.1 Standard on emergency

management

Start date of project: 2007-01-01 Due date: 2008-01-01

Duration of project: 48 months Actual delivery date: 2008-02-14

Lead contractor: Revision: 1.1

Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006)
Dissemination Level
PU Public Public
PP Restricted to other programme participants (including the Commission Services)
RE Restricted to a group specified by the consortium (including the Commission Services)
CO Confidential, only for members of the consortium (including the Commission Services)
 D-C1.1
FLAGSHIP 24.10.2012

Document summary information

Authors and contributors

Initials Author Organisation Role
ØJR Ørnulf Jan Rødseth MARINTEK Editor
BH Ben Hodgson BMT Task responsible
JKG Jan-Ketil Gullvåg AFS Contributor
GB G. Balzano CONSAR Contributor
CV Christos Vazouras Minoan Contributor
RG Rocco Gargiulo CONSAR Contributor
GF Gisle Fiksdal Lodic Contributor

Revision history
Rev. Who Date Comment
0.1 JKG 2007-08-27 Draft table of contents
0.2 JKG 2007-08-30 Filled in definitions of DSS, EMS, FMS, etc
0.3 ØJR,GB 2007-10-04 Details on processes and roles
0.4 ØJR 2007-10-12 Additional data added on incidents, legislative docs etc.
0.5 ØJR 2007-10-18 More on processes
0.6 ØJR 2007-10-26 More systematic definition of functions
0.7 All 2008-01-10 Final review at Rome meeting
0.8 ØJR 2008-01-15 Add more general requirements
0.9 CV 2008-01-23 Editing, spelling check
0.10 PNO 2008-02-14 Revised by internal reviewer
1.0 JKG 2008-02-14 Final document
1.1 ØJR 2008-02-20 Modified executive summary
1.2 ØJR 2008-10-31 Updates in

Quality Control
Who Date
Checked by lead partner BJH 2008-01-25
Checked by SP JKG 2008-02-14
Checked by internal reviewer Per Norman Oma (PNO) 2008-02-14

Company internal coding (if any)

Main responsible Internal reference number

Disclaimer
The content of the publication herein is the sole responsibility of the publishers and it does not necessarily
represent the views expressed by the European Commission or its services.
While the information contained in the documents is believed to be accurate, the authors(s) or any other
participant in the FLAGSHIP consortium make no warranty of any kind with regard to this material
including, but not limited to the implied warranties of merchantability and fitness for a particular purpose.
Neither the FLAGSHIP Consortium nor any of its members, their officers, employees or agents shall be
responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or omission herein.
Without derogating from the generality of the foregoing neither the FLAGSHIP Consortium nor any of its
members, their officers, employees or agents shall be liable for any direct or indirect or consequential loss
or damage caused by or arising from any information advice or inaccuracy or omission herein.

2 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Executive summary
State of the art and need for improvements
Integrated safety and emergency management is and will become an important function in passenger ships.
Stricter IMO requirements for safety management and requirements for safe return to port, will in most
cases require computerised decision support systems. Such systems are already common on larger cruise
ships as well as ferries and are expected to also be deployed on smaller ships in the future. However, there
is no agreed definition of what a computerised safety and/or emergency management system is. Through
SOLAS and various other instruments, IMO has defined a range of concepts that cover some parts of this
idea. The purpose of this document is to provide a unified definition of integrated safety and emergency
management systems (ISEMS), in such a way that it can be used as basis for designing, purchasing and
possibly also regulating such systems.
The potential impact of the results
This document contains definitions that are intended to aid users or designers of Integrated Safety and
Emergency Systems (ISEMS) in specifying and comparing such systems. The document is the first and
currently only systematic collection of requirements for ship board emergency management equipment.
The document does not specify any standardized and /or concrete type of ISEMS. Rather, it provides a
general framework from where incident types, management processes, possible functions and
organizational aspects can be selected. Neither does the document specify any particular architecture for an
ISEMS.
The document does, where appropriate, refer to definitions from the International Maritime Organization
(IMO). This applies, e.g., to Safety Management Systems, Decision Support System etc. However, larger
scale electronic safety and emergency management support systems are not currently described in IMO
publications in any detail. Thus, this document can also serve to provide a description of such systems.
The document does not specify any standardized and concrete type of ISEMS. Rather, it provides a general
framework from where incident types, management processes, possible functions and organizational
aspects can be selected. Neither does the document specify any particular architecture for an ISEMS. In
general, this document mostly addresses functional issues with the exception of the last chapter – Chapter 7
where general requirements are examined.
This document will be important for designers and purchasers of ISMES type equipment. Today, there is a
good deal of confusion regarding what, e.g., a safety management system or decision support actually is.
Having a clearer framework will give manufacturers, buyers and legislators a more definitive reference.
Contributions to the work
This document has been produced by sub-project C1 in the Flagship project. The partners that have
participated are Autronica Fire and Safety, Lodic (system manufacturers), CONSAR and Minoan Lines
(Ship owners) and MARINTEK and BMT (Research). The work has been performed in a number of
workshops (Trondheim, London, and Rome) and through inter-sessional contributions from the partners.
MARINTEK and Minoan have had the main responsibility for the editorial work.

3 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Table of contents

1. Introduction ........................................................................................................................... 8
1.1 Scope ........................................................................................................................... 8
1.2 Contributions to the state of art ........................................................................................ 9
1.3 Background for document and contributors ..................................................................... 9
2. Definitions ........................................................................................................................... 9
2.1 Accident ........................................................................................................................... 9
2.2 Assembly Station............................................................................................................ 10
2.3 CAS – Crew Alerting System ........................................................................................ 10
2.4 DCT – Damage Control Teams ...................................................................................... 10
2.5 DSS – Decision Support System .................................................................................... 10
2.6 EAOS – Emergency Assistance to Other Ships ............................................................. 10
2.7 Embarkation station........................................................................................................ 10
2.8 Emergency ...................................................................................................................... 10
2.9 Emergency station .......................................................................................................... 10
2.10 EMS – Emergency Management System ....................................................................... 10
2.11 EMT – Emergency Management Team ......................................................................... 11
2.12 ESD – Emergency Shut Down ....................................................................................... 11
2.13 Event ......................................................................................................................... 11
2.14 FMS – Fire Management System ................................................................................... 11
2.15 GA ......................................................................................................................... 11
2.16 General Emergency Alarm ............................................................................................. 12
2.17 GIS – Geographic Information System .......................................................................... 12
2.18 Hazard ......................................................................................................................... 12
2.19 Incident ......................................................................................................................... 12
2.20 ISEMS – Integrated Safety and Emergency Management System(s) ............................ 12
2.21 IVHM – Integrated Vehicle Health Management .......................................................... 12
2.22 MRCC – Maritime Rescue Coordination Centre ........................................................... 12
2.23 Muster station ................................................................................................................. 12
2.24 OSC – On Scene Commander ........................................................................................ 12
2.25 OSC Ship ........................................................................................................................ 12
2.26 PLC – Programmable Logic Controller ......................................................................... 13
2.27 Risk ......................................................................................................................... 13
2.28 Safety centre ................................................................................................................... 13
2.29 SERS – Specialist Emergency Response Service .......................................................... 13
2.30 SAR – Search and Rescue .............................................................................................. 13
2.31 SMS – Safety Management System ............................................................................... 13
2.32 SSD – Safety Shutdown System .................................................................................... 14
2.33 VDR – Voyage Data Recorder ....................................................................................... 14
3. Classification of incidents .................................................................................................... 14
4 of 48
 D-C1.1
FLAGSHIP 24.10.2012

3.1 Types of incidents/emergencies ..................................................................................... 14

3.2 Classification of incidents .............................................................................................. 16
3.2.1 Rank ................................................................................................................ 16
3.2.2 Primary objective ............................................................................................ 16
3.2.3 Manageability .................................................................................................. 17
3.2.4 Time to react ................................................................................................... 17
3.2.5 Shore or other ship assistance ......................................................................... 17
3.2.6 Incident classification table ............................................................................. 17
4. Processes of emergency management ................................................................................ 18
4.1 General overview ........................................................................................................... 18
4.2 Normal situations ........................................................................................................... 20
4.2.1 Training and drills ........................................................................................... 20
4.2.2 Testing, inspection and maintenance .............................................................. 20
4.2.3 Patrols .............................................................................................................. 20
4.2.4 Monitoring....................................................................................................... 20
4.3 Detection and incident management .............................................................................. 20
4.3.1 Detection ......................................................................................................... 20
4.3.2 EMT mustering ............................................................................................... 21
4.3.3 Monitor incident or emergency ....................................................................... 21
4.3.4 Prognosis ......................................................................................................... 21
4.3.5 Internal coordination ....................................................................................... 21
4.3.6 Internal communication .................................................................................. 21
4.4 Reporting and logging .................................................................................................... 21
4.4.1 Normal logs ..................................................................................................... 21
4.4.2 Reporting ......................................................................................................... 21
4.4.3 Emergency logs ............................................................................................... 21
4.4.4 Passenger and crew tracking ........................................................................... 21
4.4.5 Dangerous goods tracking ............................................................................... 22
4.5 External coordination and communication .................................................................... 22
4.5.1 External coordination ...................................................................................... 22
4.5.2 External communication ................................................................................. 22
4.6 Containment and repair .................................................................................................. 22
4.6.1 Containment .................................................................................................... 22
4.6.2 Neutralize ........................................................................................................ 22
4.6.3 Repair .............................................................................................................. 22
4.7 Evacuation and rescue .................................................................................................... 22
4.7.1 Local evacuation ............................................................................................. 22
4.7.2 Full mustering ................................................................................................. 22
4.7.3 Enter lifeboats ................................................................................................. 22
4.7.4 Launch lifeboats .............................................................................................. 23
4.7.5 Rescue ............................................................................................................. 23
5. Organization of emergency management .......................................................................... 23
5 of 48
 D-C1.1
FLAGSHIP 24.10.2012

5.1 The general framework for emergency management ..................................................... 23

5.1.1 Ship emergency management teams ............................................................... 24
5.1.2 Ship operational support teams ....................................................................... 24
5.1.3 Off-ship teams ................................................................................................. 24
5.2 System distribution requirements ................................................................................... 25
6. Specific emergency and safety management functions..................................................... 26
6.1 Mandatory safety and emergency management functions ............................................. 26
6.1.1 Fire control plan .............................................................................................. 26
6.1.2 Fire detection and alarm system ...................................................................... 26
6.1.3 Extinguishing systems monitoring .................................................................. 27
6.1.4 Evacuation control (low location lights, directional sound and similar)......... 27
6.1.5 Passenger and crew accounting ....................................................................... 27
6.1.6 Cargo and passenger data registration systems ............................................... 28
6.1.7 Ventilation control .......................................................................................... 28
6.1.8 Fire door and damper control .......................................................................... 28
6.1.9 SSD - Safety Shut-Down ................................................................................ 28
6.1.10 Water tight and shell doors ............................................................................. 28
6.1.11 Water ingress and bilge monitoring ................................................................ 28
6.1.12 Patrols .............................................................................................................. 29
6.1.13 CCTV Control ................................................................................................. 29
6.1.14 Alarm system integration ................................................................................ 29
6.1.15 Cargo condition monitoring systems .............................................................. 29
6.1.16 Tank level monitoring ..................................................................................... 30
6.1.17 ISM checklists (SMS) ..................................................................................... 30
6.1.18 ISM support functions ..................................................................................... 31
6.1.19 Reporting systems ........................................................................................... 31
6.1.20 SAR Cooperation ............................................................................................ 31
6.2 Additional basic functions .............................................................................................. 31
6.2.1 Hull stress monitoring ..................................................................................... 31
6.2.2 Electronic plotting table .................................................................................. 31
6.2.3 Evacuation monitoring .................................................................................... 32
6.2.4 Messaging module .......................................................................................... 32
6.2.5 Task tracking ................................................................................................... 32
6.2.6 Duty roster ....................................................................................................... 33
6.2.7 Logistics and resource management decision support .................................... 33
6.3 Prognosis functions ........................................................................................................ 33
6.3.1 Stability calculator .......................................................................................... 33
6.3.2 Strength calculator .......................................................................................... 33
6.3.3 Evacuation ....................................................................................................... 33
6.3.4 Fire .................................................................................................................. 34
6.3.5 Maneuvrability ................................................................................................ 34
6.3.6 Constrained ship routing – weather routing .................................................... 34
6 of 48
 D-C1.1
FLAGSHIP 24.10.2012

6.4 Integrated functions and systems ................................................................................... 34

6.4.1 Passenger ship safety centre ............................................................................ 34
6.4.2 Monitoring of systems for safe return to port ................................................. 35
6.4.3 Integrated monitoring system .......................................................................... 36
6.4.4 FMS – Fire Management System .................................................................... 37
6.4.5 EMS – Emergency Management System ........................................................ 37
6.4.6 ISEMS – Integrated Safety and Emergency Management System ................. 38
7. General requirements .......................................................................................................... 38
7.1 Integration ...................................................................................................................... 38
7.2 Robustness and reliability .............................................................................................. 39
7.3 Duty level and duty transfer functions ........................................................................... 39
7.4 Access control and encryption ....................................................................................... 39
7.5 Automation degree in emergency management systems ............................................... 39
7.6 General use of display technology – multiple display types .......................................... 40
7.7 Type of GIS display ....................................................................................................... 41
7.8 Export and import of data............................................................................................... 42
7.9 System wide time stamping............................................................................................ 42
7.10 Multiple events and incidents ......................................................................................... 42
7.11 Support for exercises and training during normal operations ........................................ 42
7.12 Risk and statistics registration ........................................................................................ 42
7.13 Early detection of dangerous states ................................................................................ 42
7.14 VDR interface ................................................................................................................ 44
7.15 Engineering complexity and maintainability ................................................................. 44
8. References ......................................................................................................................... 45

7 of 48
 D-C1.1
FLAGSHIP 24.10.2012

1. Introduction

1.1 Scope
The main purpose of this document is to provide definitions of issues related to emergency
management that is of importance during the planning, design and implementation of emergency
management systems. The focus is on the ship side management, but issues related to shore side
emergency handling is also covered where there is significant overlap.
This document covers all types of ships, including general cargo, container ships, bulk carriers
etc. However, the more advanced aspects of emergency management will normally be more
applicable to passenger ships (e.g., cruise ships and ROPAX ferries). It does not cover additional
requirements for ships such as high speed crafts, dynamically supported crafts, ships for carriage
of nuclear material, oil or gas tankers or chemical carriers. Neither does the document cover
additional requirements related to dangerous cargo handling, except where it overlaps with the
more general emergency management requirements. Thus, the IMDG code is not discussed in this
document.
The document can in principle be used in conjunction with all types of emergencies. However,
some emergencies can not be handled effectively through a computerised system. Any complex
emergency involving several assets and, hence, requiring a significant coordination effort, is a
situation where an integrated emergency management system can be useful. To this extend, the
typical incident managed through a computerized system is fire and this has been extensively used
as the main paradigm in this document.
This document does not cover the construction of ships and processes related to that such as
stability, design related fire protection, evacuation calculations etc.
This document does not cover external liaison to actors outside organisations directly involved in
the emergency management. Thus, the document will not directly apply to functions related to
public media contacts etc.
The intended audience of this document are:
1. Ship owner/operator: Reference for analysis and specifications of emergency management
systems, including but not limited to electronic systems, procedures and organisational
aspects.
2. Manufacturer/yards: Reference for specification
3. Authorities: General reference for emergency management related procedures and
requirements
This document does not contain complete or very detailed requirements for the totality of various
functions that may be implemented in an emergency management system.

8 of 48
 D-C1.1
FLAGSHIP 24.10.2012

1.2 Contributions to the state of art

This document is the first and currently only systematic collection of requirements for ship board
emergency management equipment. As noted below, some of the results presented here are
collected from earlier work, but these results have not before been published in a complete and
systematic manner.

1.3 Background for document and contributors

This document has been produced through collaborative work in Flagship sub-project C1
“Cooperative decision support”. The contributors have been listed on the second page of the
document. In addition, specific documents and projects have served as basis for some parts of the
documents. These documents are listed below, approximately in order of importance.
The EU project ITEA-DS [ITEA-DS] carried out extensive work on a specific integrated
emergency management system, based on the integration of existing systems. This included
emergency preparedness (fire and stability), maintenance functions and ISM support. Many of the
general results were collected in the SWAN report [SWAN] and have been used as basis for the
functionality sections as well as additional material in other sections.
The EU project DSS_DC [DSS_DC] carried out more in depth work on stability, strength,
propulsion, manoeuvring and weather related issues. The project also developed a Web tool to
exchange information between shore and ship based entities. Many of the ideas and results of
DSS_DC have been incorporated, mainly in the organisation section and in specific function
definitions.
The U.S. Department of Justice, Office of Justice Programs and National Institute of Justice
published a report on crisis information management. Although this was mostly concerned with
civil authorities’ management of large scale emergencies and catastrophic situations, some of the
functional and general requirements have been incorporated in this document [CIMS].
Other contributions have been identified with references where appropriate.
In addition to these sources, the Flagship C1 sub-project team has through a number of workshops
and individual sessions added material to the above and systemized the information so that it is
suitable for publication. The participants are listed on the second page of the document.

2. Definitions

2.1 Accident
An accident is an event involving loss of or damage to life, health, property or environment.
Note that an accident does not necessarily require that an emergency has been recognized
beforehand. However, an accident will always represent an emergency.

9 of 48
 D-C1.1
FLAGSHIP 24.10.2012

2.2 Assembly Station

An area where passengers are assembled in the event of an emergency [MSC.846]. This document
will use term muster station for the same concept.

2.3 CAS – Crew Alerting System

CAS is a concept used within civil aeronautics and space industry. It is a system that determines
the overall functional capability of the aircraft.

2.4 DCT – Damage Control Teams

This is one or more teams trained and equipped to handle the on scene physical management of an
incident. This includes fire fighters, smoke divers, stretcher teams and/or others.

2.5 DSS – Decision Support System

SOLAS [SOLAS] Ch. 3, Sec. 29, defines a DSS as a checklist type system that is to be used by
the master of certain passenger ships to guide the emergency management operations.
In this document, the term decision support system or DSS can mean both a SOLAS type DSS or
a more general system to support decision making.

2.6 EAOS – Emergency Assistance to Other Ships

This is one of the emergencies that the ISM code requires that a ship is prepared to handle.

2.7 Embarkation station

A place from where a survival craft is boarded [MSC.846].

2.8 Emergency
An emergency is a situation which is deemed to pose an immediate risk to life, health, property or
environment.
Thus, an emergency – by this definition – requires that the situation has being recognized as
dangerous.

2.9 Emergency station

A place where crew members are assigned in the event of an emergency, as specified on the ship’s
muster list [MSC.846].

2.10 EMS – Emergency Management System

Generally, an EMS is defined as a system (written, electronic and/or other) that supports the
management of an emergency, i.e., helps the involved personnel to understand, evaluate, contain,
repair or in other ways handle the situation. Thus, the EMS is a support system for the ship’s
general Safety Management System (SMS).

10 of 48
 D-C1.1
FLAGSHIP 24.10.2012

This document defines ISEMS more specifically in sect. 6.4.6 as a technical system that has as its
primary purpose to reduce the cognitive load on the personnel while making emergency
management more effective.
Note: EMS is also often used as an abbreviation for “Environmental Management System”.

2.11 EMT – Emergency Management Team

This is the team, normally headed by the Master, which is responsible for overall management of
an emergency on board the ship.

2.12 ESD – Emergency Shut Down

ESD is used as a “last resort” safety system that shuts down a complete process segment when no
other safety measures can be expected or relied on to work. An ESD system will try to take the
system to a “safe state”. It is typically implemented to a very high safety integrity level to ensure
that It works when it is needed, but also to a very high robustness level to ensure no unwanted
trips.

For ships, one should reserve the term ESD for shutdown (to prevent breakage or major damages)
of plants/systems/machinery/functions that are essential for the safeguard of the ship’s integrity
or operational capabilities (Main Engine, Rudder , etc.) or that can evolve in danger for the crew
or passengers. A typical example is automatic shutdown systems for machinery or boilers that can
present an immediate threat to safety [IEC 60092]. One should also note that a ship requires
several continuously available systems, e.g., propulsion, power generation and steering. As these
have no safe state (except being available), the use of the term ESD may often be inappropriate.
ESD must be understood as a precautionary measure that must be taken in order to preserve the
integrity of the main essential systems onboard so as to ensure the overall safety of the ship Also
automatic shut down of all fire doors may be looked at as an ESD function as it may seriously
hamper evacuation. ESD functions will often have a manual override. For high integrity levels
one should also implement ESD functions outside high-level control systems, i.e., in a PLC
[DNV].

2.13 Event
Event is an occurrence of something. This document mainly deals with events that are classified
as incidents, i.e., events that may result in an emergency situation .

2.14 FMS – Fire Management System

See section 6.4.4.

2.15 GA
This may be an abbreviation for General Alarm (General Emergency Alarm). It may also be an
abbreviation for the General Arrangement drawing.

11 of 48
 D-C1.1
FLAGSHIP 24.10.2012

2.16 General Emergency Alarm

This is sometimes called General Alarm, but the correct term according to [A.830] is “General
Emergency Alarm”.

2.17 GIS – Geographic Information System

A system where a “geographic” background layer is used to display information (see also 7.6). A
display system based on the ship general arrangement drawing is of the GIS type.

2.18 Hazard
A condition with the potential to cause injury, illness, or death of personnel; environmental
pollution; damage to or loss of equipment or property; mission degradation.

2.19 Incident
Incident is an event that has a potential to escalate to an emergency situation.

2.20 ISEMS – Integrated Safety and Emergency Management System(s)

This is one or more computer based systems that implements (parts of) an emergency
management system, see 6.4.6.

2.21 IVHM – Integrated Vehicle Health Management

IVHM extends the capabilities of the CAS (Crew Alerting System) to also contain integrated
checklists and maintenance functions [IVHM]. On a ship, this function should also consider the
ship mode, i.e., port approach, at anchor, open sea etc [DSS_DC].

2.22 MRCC – Maritime Rescue Coordination Centre

Sometimes called Search and Rescue (SAR) centre.

2.23 Muster station

This has the same meaning as Assembly station [MSC.777].

2.24 OSC – On Scene Commander

This is the person responsible for the on scene management (on the ship). This may be the staff
captain or the chief navigation officer. OSC is also used to mean the ship in charge of the rescue
operation. However, in this document that is termed the OSC Ship.

2.25 OSC Ship

This is another ship going to the assistance of another ship in distress that has been assigned the
role as on scene commander by the MRCC.

12 of 48
 D-C1.1
FLAGSHIP 24.10.2012

2.26 PLC – Programmable Logic Controller

In this standard a PLC is defined as a stand alone device that implements a specific function. It
can be compared to hardwired logic, but is usually implemented as a special purpose
programmable input and output device. It has limited facilities for user input and programming
and will normally be considered to be safer than general purpose programmable computers due to
fewer failure modes and lower complexity.

2.27 Risk
Risk is a measure that can be assigned to a hazard and is defined as follows:

Risk = Likelihood of Occurrence (of hazard) x Seriousness of consequence (of occurrence)

2.28 Safety centre

Safety centre is a control station dedicated to the management of emergency situations. Safety
systems’ operation, control and/or monitoring are an integral part of the safety centre [MSC.216].

2.29 SERS – Specialist Emergency Response Service

A third party service that assists the owner’s emergency operation in various complex tasks
requiring specialist competence. This will typically include various services related to stability
and strength.

2.30 SAR – Search and Rescue

In this document, the term MRCC is used to identify the main responsible for the coastal or port
state emergency management organisation.
Note that SAR may also be an abbreviation for Synthetic Aperture Radar.

2.31 SMS – Safety Management System

The safety management system is the technical and organisational framework for ensuring safety
of operations. For ships, this will be implemented according to the [ISM] code. It is a system with
the following functions:

1. a safety and environmental protection policy;

2. instructions and procedures to ensure safe operation of ships and protection of the
environment in compliance with relevant international and flag state legislation;
3. defined levels of authority and lines of communication between, and amongst, shore and
shipboard personnel;
4. procedures for reporting accidents and non-conformities with the provisions of the ISM
Code;
5. procedures to prepare for and respond to emergency situations; and relating to and
affecting safety and pollution prevention.

13 of 48
 D-C1.1
FLAGSHIP 24.10.2012

For more information on content, see [A.852].

Note: SMS is sometimes used in a similar sense as EMS, ISEMS, FMS and/or SSD, but as the
term SMS is used by SOLAS, this alternate use is discouraged.

2.32 SSD – Safety Shutdown System

Less invasive form of ESD. See sect. 6.1.9.

2.33 VDR – Voyage Data Recorder

Mandatory equipment on most ships that records safety related data to a safe unit that can be
retrieved after an emergency.

3. Classification of incidents

3.1 Lloyds register classification

The following accident definitions are based on the definitions used by Lloyd’s Register Fairplay
database for incidents. These groups are intended for classification of ship losses or damage due
to an emergency. As will be shown in the enxt section, these codes can be looked at as final
outcome of a more detailed list of possible incidents.
Foundered: Includes ships which sank as a result of heavy weather, springing of leaks, breaking
in two etc. but not as a consequence of categories listed below.
Missing: After a reasonable period of time, no news having been received of a ship and its fate
being therefore undetermined, the ship is posted as “missing” at the Corporation of Lloyd’s or
reported as such from another reliable source.
Fire/Explosion: Includes ships lost as a results of fire and / or explosion where it is the first event
reported – it therefore follows that casualties including fire and / or explosion after collisions,
stranding, etc. would be categorised under “collision”, “wrecked/stranding”.
Collision: Includes ships lost as a result of striking or being struck by another ship, regardless of
whether under way, anchored or moored.
Contact: Includes ship lost as a result of striking an external substance – but not another ship
(collision) or the sea bottom (wrecked/stranding). This category includes striking drilling
rigs/platforms, regardless of whether in fixed position or in tow
Wrecked/stranding: Includes ships lost as a result of touching the sea bottom, sandbanks or
seashore etc, as a well as entanglement on underwater wrecks.
Other: Includes war loss (and encompassing loss occasioned to ships by hostile acts),
hull/machinery damage of failure which is not attributable to any other category, and losses
which, for want of sufficient reasons, cannot be classified.

14 of 48
 D-C1.1
FLAGSHIP 24.10.2012

3.2 Types of incidents/emergencies

Table 1 lists some common incident/emergency types. The first column lists the emergency
number as defined in SOLAS (see definition of DSS). The second column lists the corresponding
definitions from [A.852]. These codes are basically identical, but there are some differences in
detailed explanations that have been included in the table. Additional details have been added
through work on ISM documents from three different companies [DSS_DC-D2.1].
This table is not intended as an exhaustive list of all possible incident types or as the only possible
grouping. It is included as an example and a starting point for more specific analysis and
classification.

Table 1 – Incident/Emergency types

DSS A.852 Code Incident
1 1 1.0 Fire
1.1 Fire/explosion in port
1.2 Fire/explosion at sea (engine or accommodation)
2 2 2.0 Damage to ship
2.2 2.1 Stranding or grounding (powered, drift)
2.1 2.2 Collision with other ship or object
2.4 2.3 Flooding/hull leakage, structural failure
2.4 Main engine fails, emergency stop, blackout
2.5 Steering fails
2.3 2.6 Heavy weather damage (superstructure)
3 3 3.0 Pollution
3.1 Pollution on board/SOPEP
3.2 Pollution of environment
4 4 4.0 Unlawful acts (Security/ISPS)
4.1 Unlawful acts (assault etc.)
4.2 Hijack/Terrorism
4.3 Bomb threat/foreign object
4.4 Piracy/Robbery
5 5 5.0 Personnel accidents
5.1 Medical emergency (one or few person) on ship
5.2 Medical epidemic/multiple injuries on ship
5.3 Man overboard
6 6 6.0 Cargo related (see also group 3)
6.1 Leakage of flammable material
6.2 Physical movement of cargo, stability hazards
6.3 Dangerous change in cargo condition
6.4 Danger of loss of deck cargo
7 7 7.0 Emergency assistance to other ship
7.1 Assisting OSC Ship/MRCC
7.2 Acting as OSC Ship
n/a n/a 8.0 Heavy weather (see also group 2)
8.1 Heavy weather at sea
8.2 Heavy weather in port
n/a n/a 9.0 Other incidents

15 of 48
 D-C1.1
FLAGSHIP 24.10.2012

DSS A.852 Code Incident

9.1 Evacuation (common outcome of several)
9.2 Helicopter operations

Note: Foundering is normally defined as structural damage that leads to the sinking of the ship.
Thus, foundering is here a possible outcome of incident 2.0.

3.3 Classification of incidents

In 3.3.6 the incidents have been classified according to a selection of descriptive attributes. The
attributes are described in the following sub-sections.
This classification is not meant to be complete or fully accurate. It is included as a starting point
for a more detailed analysis involving particular ships and/or organizations. This can in turn serve
as a prioritization of most important functionality.
It is clear that not all emergencies or incidents are equally suitable for management and control
through an ISEMS. As an example, a fire requires coordinated effort and may be more suitable
than a propulsion problem in open sea where there is not much use for computerized ISEMS
support. Thus, the table can be used to do such an analysis. Also, the design of, e.g., check lists
can use some of the classification codes in the table.

3.3.1 Rank
This attributes specifies if the incident or emergency usually is the consequence of other
emergencies or if it is an incident itself or a direct consequence of an incident. The codes used are:
1. Result of initial event
2. Consequence of other emergency
3. Common outcome of more than one emergency

3.3.2 Primary objective

This column indicates the primary objective for emergency or incident management. Ultimately,
saving lives is always the primary concern, but for many emergencies the focus is initially on
more practical aspects. Codes used are:
- Life: Initial objective is life saving
- Ship: Initial objective is to save the ship from serious damage
- Env: Initial objective is to protect environment
- Ctrl: Initial objective is to regain control of ship
- Other: Other purpose

Where no code is inserted, the main objective is to handle the concrete situation as effectively as
possible.

16 of 48
 D-C1.1
FLAGSHIP 24.10.2012

3.3.3 Manageability
This attribute is a somewhat objective assessment of how easy it is to control the incident or
emergency. The codes used are:
1. It may be difficult to control the incident to limit the consequences.
2. The incident poses certain problems for effective management.
3. The incident will often be controllable with good management.

3.3.4 Time to react

This is also an objective measurement of how much time one will have available for control of the
incident before it has resulted in “worst case result”, e.g., evacuation or loss of life. Codes used
are:
1. Short reaction time is required, on the order of minutes in some cases.
2. A time window is available, may be to the order of an hour.
3. Time is not a very critical factor.

3.3.5 Shore or other ship assistance

This column indicates how important shore assistance is. The codes used are:
1. Most aspects of the situation can be handled on board.
2. Shore or ship assistance is important for providing background information and help
3. Shore or ship assistance is crucial.

3.3.6 Incident classification table

Table 1 – Incident classification

Code Incident Rank Obj. Mgm Rea Shore
1.1 Fire/explosion in port 1 Life 3 2 1
1.2 Fire/explosion at sea 1 Life 3 2 1
2.1 Stranding or grounding 2,1 Ship 2 2 2
2.2 Collision with other ship or object 1,2 Ship 2 1 1
2.3 Flooding/hull leakage 2,1 Ship 1 1 1-2
2.4 Main engine fails/blackout 1 Ctrl 3 3 1
2.5 Steering fails 1 Ctrl 3 3 1
2.6 Heavy weather damage 1 Ship 2 2 1
3.1 Pollution on board/SOPEP 2,1 Env 3 2 1
3.2 Pollution of environment 2,1 Env 2 2 2
4.1 Unlawful acts (assault etc.) 1 Life 2 3 1
4.2 Hijack/Terrorism 1 Life 1 2 3
4.3 Bomb threat/foreign object 1 Life 2 2 1
4.4 Piracy/Robbery 1 Life 2 2 2
5.1 Medical emergency 1,2 Life 3 2 2
5.2 Medical epidemic/multiple injuries 1,2 Life 3 3 3
5.3 Man overboard 1 Life 2 2 1
6.1 Leakage flammable material 2,1 Ship 3 2 1
6.2 Movement of cargo 2,1 Ship 1 1 2

17 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Code Incident Rank Obj. Mgm Rea Shore

6.3 Cargo condition 2,1 Ship 1 1 1
6.4 Loss of deck cargo 2,1 Env 1 2 1
7.1 Assisting OSC 1 Other 3 3 3
7.2 Acting as OSC 1 Other 3 3 3
8.1 Heavy weather at sea 1 Ship 2 3 1
8.2 Heavy weather in port 1 Ship 3 3 2
9.1 Evacuation 3 Life 1 2 3
9.2 Helicopter operations 1,2,3 Life 3 3 2

4. Processes of emergency management

The purpose of this section is to describe on a relatively high level all emergency management
processes that should be considered during the specification or design of an ISEMS.

4.1 General overview

IMO Resolution [A.852] gives guidance on emergency planning and responses. It shows initial
actions and subsequent responses as in Figure 1.
Damage to
Fire
ship ... EAOS

Initial actions
Sequence of priorities
- Alarm
- Identify nature of emergency
- Recruit and organize response teams, personnel and equipment
- Collect (additional) information
- Start/continue response actions
- Monitor response actions
- Activate reporting procedures/prepare situation report
- Initiate external response

Consideration of subsequent response

- Properties of cargos/substances carried
- Location and quantity of hazardous cargos/substances
- Medical aids
- Buoyancy, strength and stability calculations
- Engagement of rescue towage/salvage
- Keep a diary of events
- Inform adjacent ships

Figure 1 – A.852 Emergency preparedness

These actions have been extended into the process diagram shown in Figure 2. It shows some of
the main processes related to emergency management. Note that the horizontal axis indicates
temporal relationship, but does not accurately capture actual start and end points of processes.

18 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Testing,
Training
Inspection, Patrols Monitoring
Drills
Maintenance

EMT Monitoring, Prognosis

Detection
mustering Internal coordination, Internal communication

Normal logs Reporting Emergency logs

Passenger and crew tracking and accountability

Dangerous goods tracking

External coordination
External communication

Contain
Neutralize
Repair

Local Full Enter Launch Rescue

evacuation mustering lifeboats lifeboats operation

Figure 2 – Emergency and safety management processes

The figure shows a complete set of emergency management processes, seen from a case where an
emergency may require local evacuation. Normally, emergency management will be able to
contain or repair the problem before abandoning the ship becomes necessary and many
emergencies will not require local evacuation at all. Thus, the diagram may need to be modified
for particular emergency types.
The figure is divided into a number of horizontal groups:
1. Operation under normal conditions where the focus is on training, patrols, maintenance
and other normally scheduled operations.
2. Detection and monitoring that is associated with identifying problems, monitor
developments and assess the situation. Related to this is the coordination of the personnel
taking part in the incident or emergency management operation.
3. Reporting and log keeping. This includes registration of data during normal operations as
well as logging and reporting the development of the incident or emergency.
4. External coordination, reporting to authorities, coordination with shore resources and
other ships. This also includes tracking of passenger, crew and dangerous goods as well as
accountability for persons onboard throughout the rescue operation.
5. The containment or rectification process which may involve one or more persons working
in the actual area of the incident or emergency.
6. Evacuation, which is an incremental process starting with local evacuation and escalating
up to abandon ship.
An ISEMS should support as many functions as reasonably possible. This does in particular apply
to functions that are performed under normal conditions as this helps to familiarize users with the
tools.

19 of 48
 D-C1.1
FLAGSHIP 24.10.2012

4.2 Normal situations

4.2.1 Training and drills

Functions implemented to familiarise users with procedures and tools. Functions may also support
simulated situations or may be used to log responses to the situations being trained on.
This covers requirements in Module III of [A.852] that identifies some functions that belong in
this category:
1. Plans for emergency management in general, including coordination between entities on
the ship and on shore.
2. Plans for drills. These need to differentiate between full scale drills involving both shore
and ship parties and local exercises covering ship or shore alone.
3. Education and familiarization of personnel (see also [STCW])
4. Make records of all emergency drills and exercises on board and on shore, evaluation of
same. Feedback to participants and to plans.

4.2.2 Testing, inspection and maintenance

Technical systems will need maintenance and management systems may implement functions to
assist in this. This also includes functions to test functions, to log defects and to report on required
maintenance.
Individual legislation exists for certain safety related systems that cover the maintenance, testing
and inspection requirements. This is not further elaborated here.

4.2.3 Patrols
Safety management cannot only be implemented by automated systems. Support for patrols and
inspections in an emergency management system may be useful.

4.2.4 Monitoring
The main task of most current electronic safety management systems is monitoring. This includes,
e.g., fire detection systems or bilge alarm systems. This process includes day to day operation of
the system. Once an abnormal situation is detected, the processes changes to detection in group 2.
Note that manual registration of observations from inspections or patrols may also be defined as
belonging to this category.

4.3 Detection and incident management

4.3.1 Detection
Detection is closely related to monitoring, but does also include the assessment of the monitoring
results as altered (compared to the standard/regular condition/value) and as a potential hazard.
Thus, converting a smoke observation to a smoke alarm belongs in this category.

20 of 48
 D-C1.1
FLAGSHIP 24.10.2012

4.3.2 EMT mustering

The EMT must be mustered through PA systems or other means. This will normally also include
mustering of DCT and the on scene commander.

4.3.3 Monitor incident or emergency

This function is also related to monitoring in normal operations, but mainly refers to the constant
assessing of the developing risk in complex and multi-faceted situations.

4.3.4 Prognosis
Likely development and outcome of an evolving situation.

4.3.5 Internal coordination

An important function during an emergency is to coordinate the internal teams and persons
participating in the management of the situation.

4.3.6 Internal communication

Related to internal coordination is also the provision of information to persons not directly
participating in the management of the emergency. This includes information to passengers.

4.4 Reporting and logging

4.4.1 Normal logs

Training and drills as well as maintenance and other routine operations shall be logged.

4.4.2 Reporting
A ship board emergency requires reporting to various agencies, including coastal state, MRCC
and others.

4.4.3 Emergency logs

It is required to keep logs of important actions during emergency management. This can be
through the ISM check lists or other tools. This may also be very valuable information during
debriefing or analysis of the situation.

4.4.4 Passenger and crew tracking

It is critical that records are kept of persons on the ship, on muster stations, in life boats or rafts
and who has been rescued. This is an activity that typically extends also into the rescue phase.
Note that this process also includes keeping track of passenger with special requirements, e.g.,
disabilities, language problems, old or young age, special medical requirements etc. This
information is typically of a private nature and needs increased protection.

21 of 48
 D-C1.1
FLAGSHIP 24.10.2012

4.4.5 Dangerous goods tracking

It is also necessary to keep track of dangerous goods onboard, including particularly flammable or
explosive stores.

4.5 External coordination and communication

4.5.1 External coordination

The EMT must coordinate their actions with other external entities that assist in handling the
incident. This may include MRCC, other ship, OSC ship, owner’s office, SERS and others.

4.5.2 External communication

Communication from ship to external actors necessary to support emergency operations, general
information to shore offices, crew and passenger relatives and possibly other functions.

4.6 Containment and repair

4.6.1 Containment
Containment may include closing of fire doors or water tight doors. Containment includes all
these actions carried out in order to reduce the likelihood that the emergency situation will
escalate.

4.6.2 Neutralize
This may be to extinguish a fire. It refers to actions taken in order to eliminate the harmful effects
of an emergency situation under containment.

4.6.3 Repair
This includes actions to restore the situation to a state similar to the one before the occurrence of
the emergency condition.

4.7 Evacuation and rescue

4.7.1 Local evacuation

Evacuate people in the immediate vicinity of an escalating incident.

4.7.2 Full mustering

Call all passengers or relevant crew to their muster stations. This also includes providing life
support services to the mustered people.

4.7.3 Enter lifeboats

In serious incidents it may be necessary to command selected crew and passengers into the life
boats to reduce the time to abandon the ship.

22 of 48
 D-C1.1
FLAGSHIP 24.10.2012

4.7.4 Launch lifeboats

This is the final action before abandoning the ship. Crew may in some cases stay onboard to try to
salvage the ship.

4.7.5 Rescue
This is actions related to retrieving crew and passengers from the water.

5. Organization of emergency management

The purpose of this section is to define the actors involved in the management of an emergency,
both on the ship and elsewhere. This is focused on the on board and direct emergency
management and does not in any great detail describe stakeholders with more long term interests,
e.g., relatives of crew and passenger, media, environmental cleanup etc.

5.1 The general framework for emergency management

The circles in the below figure shows the different users or user groups (circles) that may have
individual access to an electronic emergency management system. The lines show how these
actors can be connected together.
Public Announcement (PA) System, UHF

On scene Damage Evacuation

commander control teams assistance
(OSC) (DCT) crew

Emergency UHF
management
team Ship WLAN

Bridge
Engine control
navigation Hotel team
team
team
Firewall
Ship LAN

Other ships Radio Firewall

Maritime
Shore Specialist
rescue
emergency emergency
coordination
management support
centre
team organisation
SAR OSC (MRCC) Firewall
ship
General ”Internet”

Figure 3 – Emergency management system users

The actors in this figure represent main responsibilities and that actual organizational structure
may be different, dependent on ship type. As an example, on a ship with unmanned engine room,
the Chief Officer may formally be part of the Emergency Management Team, but he or she will
still be responsible for the engine operation.
The following sub-sections briefly describe the groups. The material is to a large degree
summarized from the DSS_DC project [DSS_DC-D2.1]

23 of 48
 D-C1.1
FLAGSHIP 24.10.2012

5.1.1 Ship emergency management teams

5.1.1.1 Safety centre emergency management team

This group, typically consisting of the master, the chief engineer, the hotel manager as well as
additional persons responsible for internal and external communication, logs etc. represents the
main decision making group in an emergency. They are responsible for overall coordination and
prioritization.

5.1.1.2 On scene commander

This person, typically staff captain or chief officer is responsible for handling the emergency
locally where the situation occurred.

5.1.1.3 Damage control teams

A number of teams (stretchers, smoke divers, fire fighting) is at the disposal of the on scene
commander and/or the emergency management team.

5.1.1.4 Evacuation support crew

Additional crew, typically from hotel section, is used to aid passengers during evacuation and may
also be responsible for searching areas to ensure complete evacuation.

5.1.2 Ship operational support teams

5.1.2.1 Bridge navigation team

This group consists of the person or persons that are responsible for normal bridge duty while the
emergency lasts.

5.1.2.2 Engine control team

This group consists of the person or persons that are responsible for normal engine control room
duty while the emergency lasts

5.1.2.3 Hotel teams

This group consists of the person or persons that are responsible for additional hotel functions
while the emergency lasts. This may fully be covered by the safety centre emergency management
team.

5.1.3 Off-ship teams

5.1.3.1 Maritime rescue coordination centre

If an emergency has been reported via the GMDSS system, one of the costal MRCC’s will be
assigned the role as emergency manager from the coast state side. It will coordinate other
MRCC’s and ships in the area to help in evacuation and other assistance to the ship in distress.
24 of 48
 D-C1.1
FLAGSHIP 24.10.2012

5.1.3.2 On scene commander ship

One of the ships in the vicinity will normally be assigned the role of on scene commander for the
external support actions.

5.1.3.3 Other ships

Any number of other ships will participate in the support actions if necessary.

5.1.3.4 Ship emergency management organisation

The owner is required to establish an on shore emergency management group to assist the ship
during an emergency.

5.1.3.5 Specialist support organisation

Additional organisations may be used by the owner for more advanced support functions, e.g.,
stability or strength calculations.

5.2 System distribution requirements

Figure 3 shows the potential users of an ISEMS and where they are located. The following table
lists different requirements for access at the different locations.
Table 2 – Distribution requirements
Location Availability Multi-view Control
Ship safety centre and bridge R0 Yes Primary
Ship engine control room R0 No Secondary
Ship hotel offices R1 No Secondary
Ship additional backup R1 No Secondary
Owner’s office R2 Yes Comments
SERS R3 No Comments
MRCC R2 Yes Comments
Ship OSC R3 No Comments
Other ships R3 No Comments

The availability codes are:

- R0: Continuous availability, backup facilities for power, possibly redundant workstations
- R1: Immediate availability, may not require backups
- R2: Available after start-up (order of minutes)
- R3: Secondary to R2 (Pipes data from R2 station), no availability requirements
The multi-view indicates if there are one (No) or more (Yes) operators or viewers of the system.
The control codes are:

25 of 48
 D-C1.1
FLAGSHIP 24.10.2012

- Primary: Main workstation

- Secondary: Can normally take over primary role
- Comments: View only, no control. Have ability to send and receive information.
These requirements are guidelines only. They will normally vary between ships and systems.

6. Specific emergency and safety management functions

The following sections identify groups of safety and emergency management functions, where
appropriate with references to relevant legislation. The first section addresses mandatory functions
that need to be present in some form or other. The second section addresses additional “atomic”
functions, i.e., specific monitoring or control functions that may be used to enhance integrated
safety and emergency management. The third group addresses various forms of prognosis
functions that can be used to assess developments of an incident or an emergency. The fourth and
final section will address “integrated” systems and functions.

6.1 Mandatory safety and emergency management functions

The following sections identify some emergency management functions that are required by
legislation. These functions are elementary in the sense that the functions will not normally be
sub-divided before being implemented in a support tool.
Other mandatory functions, not discussed here, may also be appropriate for support in an ISEMS.

6.1.1 Fire control plan

The fire control plan is a general arrangement drawing showing the location of important safety
features on the ship. This will typically include fire zones, extinguishing equipment, special areas
etc. This plan can relatively easy be implemented electronically. Symbols are defined in [A.654]
or [A.952] for newer ships, see also [ISO 17631].
Note that integrated systems normally would use the fire control plan or a variant thereof as basis
for a GIS type display. Note also that elements on the plan can be associated with sensors so as to
change display status as the equipment change status.
Other regulations require various other plans to be available to those that handle emergencies, i.e.,
life saving appliances plans. This should include all muster stations and all embarkation stations.
Symbology is defined in [A.760].

6.1.2 Fire detection and alarm system

The construction of a fire detection and alarm system for marine application is regulated by
SOLAS Ch. II-2-7. Some functionality associated with smoke extraction and containment (e.g.,
damper or extraction control) is regulated by regulation 8 and 9. Additional functions related to
fire fighting (extinguishing systems) may require adhesion to regulation 10. Other parts of
SOLAS may also apply, e.g., with respect to special category spaces onboard.

26 of 48
 D-C1.1
FLAGSHIP 24.10.2012

The Fire Safety System code [FSS], Chapter 9.2, requires that fire detection systems “are not used
for any other purpose, except for closing of fire doors and similar functions”. This means that the
integrated system must have provisions to show that this requirement can be fulfilled. Some
possible approaches are:

 Hierarchical system where lower tiers implement pure fire related functions.

 Use of duty transfer/duty class system to limit functionality on workstations that are
allocated to fire alarms to show only that.
Note however that [FSS], Chapter 1.3, also opens up for use of “modern technology” if it provides
better results than traditional solutions.
Note that fire alarm systems normally use smoke detectors. Combined detectors able to show both
temperature and smoke density may give the operator easier access to data on fire spread (hot
areas) when smoke has spread over a larger area.

6.1.3 Extinguishing systems monitoring

Activation of automatic extinguishing systems [FSS] is often included as alarm points in the fire
alarm system. Also other aspects of extinguishing systems, such as fire pump status, require
indicators on the bridge. It may also be useful to indicate other aspects of these systems, such as
status of section valves.

6.1.4 Evacuation control (low location lights, directional sound and similar)
It may be necessary to have systems to control low location lights or similar indication devices. In
this case [MSC.752] applies.
Some systems allow directional control on the indication devices. These systems will normally
require more advanced decision support functions.
Note also that hotel staff often assists passengers with evacuation. In this case, one will normally
use the PA system to give any updated commands relating to changes in evacuation routes.

6.1.5 Passenger and crew accounting

A list off all passengers shall be kept on ship and on shore for SAR (SOLAS Ch. III-B Reg. 27).
It is also required to account for all passengers and crew at the mustering stations and try to locate
those who may be missing.
Electronic systems exist that can read various tag types (RFID, magnetic cards, bar codes,
biometry) to facilitate some of these functions. However, problems occur because:
1. Persons may have the wrong tag, one cannot 100% regard a tag read as correct.
2. Persons may not bring their tags, one need back up for manual registration
3. There are privacy issues

27 of 48
 D-C1.1
FLAGSHIP 24.10.2012

6.1.6 Cargo and passenger data registration systems

The registration of several data items is required by various legal provisions and regulations. An
ISEMS type system could be used for this and should be able to display:

 Details of passengers needing special assistance on the ship (shall be registered: SOLAS
III-B Reg. 27). This could also be integrated with mustering lists and general passenger
lists.

 Details of dangerous goods onboard (shall be registered: SOLAS VII – Part A, Reg 4.5).

6.1.7 Ventilation control

Control of ventilation in special spaces (engine, staircases, atrium, etc.), SOLAS II, Reg. 8, part 3,
MSC 1034. This may also include proactive use of HVAC to implement smoke extraction or
overpressure strategies, e.g., in stair cases or muster stations.

6.1.8 Fire door and damper control

It may also be useful to have facilities to only close doors in immediately affected areas until
evacuation has taken place. Closing the fire doors can delay evacuation.
Fire damper control may or may not be included.

6.1.9 SSD - Safety Shut-Down

Various requirements exist for automatic control of certain functions which result to the transition
to a reduced operational state in case of emergency. In this document, the term “Safety Shut-
Down” is used as a description of such functions. These are functions that have limited potential
for negative consequences (see 7.5).

6.1.10 Water tight and shell doors

Many ships are required or recommended to have a central monitoring and control station for
watertight doors at the bridge [SOLAS] Ch. II-1, Part B, reg. 15. This station should be integrated
in an emergency management system. Remote control of water tight doors may or may not be
included in an integrated system. There are special requirements for doors acting both as fire
doors and watertight doors.

6.1.11 Water ingress and bilge monitoring

Bulk carriers are required to carry water level indicators for holds and a selection of other spaces
[SOLAS] Ch XII, reg. 12. It is also recommended that passenger ships are fitted with similar
systems for compartments below deck [A.796]. Similar alarms may also be fitted in conjunction
with shell doors or other cargo spaces. Alarms of this type together with bilge alarms may be
useful during emergencies to assess water ingress or flooding.

28 of 48
 D-C1.1
FLAGSHIP 24.10.2012

6.1.12 Patrols
SOLAS requires fire patrols for certain ships and ship spaces. Some examples are:

 Some ships require patrols for special category spaces (SOLAS Ch.II-2, Reg. 20, 4.3.1).
This also applies to high speed crafts (HSC code).

 Passenger ships shall implement fire patrols (SOLAS Ch II-2, Reg. 7, Sec. 8). This also
sets requirements to radiotelephone communication.

 [MSC.847] goes on to specify that radiotelephones as mentioned above shall reach all parts
of a ship, minimum parts visited by fire patrolled.
Note that the ISPS code also requires security patrols to be used on security levels 2 and 3.

6.1.13 CCTV Control

Closed circuit television systems are required for various purposes in the ship. Some examples are
listed below. Note also that CCTV systems are now a normal part of ship systems and should be
included in the general safety and security management system.

 Stern and side shell doors and other shell doors (SOLAS II-1 Reg 23-2-2).

 Car-decks of RO-RO ferries (as alternative to patrol SOLAS II-1 Reg 23-2-3).

 Various special category spaces that are not patrolled (HSC code).

6.1.14 Alarm system integration

The code on alarms and indicators [A.830] lists a number of alarms and indicators that are
required on the bridge or in similar control positions. Many of these alarms are safety related and
will be of interest during an incident. In addition, other automation alarm system will provide
critical information from engine, power management, maneuvering and propulsion systems that
may be of use in an integrated emergency management system.
For safety and emergency management purposes, these alarms should be presented in a manner
that indicates the functional consequence of the alarm rather than the technical problem
underlying it.

6.1.15 Cargo condition monitoring systems

Different types of cargo have different requirements for monitoring to avoid dangerous situations
to occur. Cargo condition monitoring, if fitted, may be of interest in an emergency. This will
typically include temperatures or pressures.

29 of 48
 D-C1.1
FLAGSHIP 24.10.2012

6.1.16 Tank level monitoring

For stability calculations it is useful to have access to online measurements of relevant tank or
cargo hold levels. The levels in themselves may not be as useful as the overall stability or strength
information.

6.1.17 ISM checklists (SMS)

SOLAS [SOLAS] Ch. 3, Sec. 29, defines a DSS. Passenger ships of Classes I, II and II (A) are
required to have a decision support system for emergency management on the navigation bridge.
It can be printed on paper, or computer based, and must identify all foreseeable emergency
situations, establish emergency procedures for each situation, and provide decisive support to the
Master. All foreseeable emergency situations shall be identified in the emergency plan or plans,
including, but not limited to, the following main groups of emergencies:
1. fire;
2. damage to ship;
3. pollution;
4. unlawful acts threatening the safety of the ship and the security of its passengers and crew;
5. personnel accidents;
6. cargo-related accidents; and
7. emergency assistance to other ships.

Electronic checklists (ECL) are in use in many application areas today. Most applicable to our
case is possibly the use in modern aircraft and in medicine. In [ICAO56] some design decision for
the ECL in Boeing 777 crafts was discussed. Also some of the benefits of ECL are discussed.
For use in a ship, the ECL can have the following purposes:
1. As a tool to keep track of the procedures and steps to go through in rarely experienced or
particularly critical situations. This is typically a sequential list of actions that shall be
checked off as taken when appropriate. For ship use, one may not want to emphasize
sequencing too much, at least not when the system is used for emergency management.
Processes are slow and correct sequence is rarely of any significant importance.
2. As a recording tool, where number of mustered/accounted for passengers and crew are
registered, when and for long smoke divers use oxygen etc.
3. As a status display tool, where a selection of actions to be taken are indicated with colour
(e.g., red, yellow, green) dependent on if they are initiated or completed. This can be used
to give a snap-shot of the situation and how it is managed.
4. As a decision support tool where alternative paths can be shown, based on automatic or
manual selections. This has been used on aircrafts [ICAO56], but may be less appropriate
for ships where processes are slower.
5. As a historical recording of what actions was taken when. This can be used for debriefing
or for analysing of how situations developed. As such, it needs to be integrated with
normal FMS history.

30 of 48
 D-C1.1
FLAGSHIP 24.10.2012

The ECL discussed here will be focused on emergency management and for use by high level
decision makers. This means that it will not contain advanced decision support functions (as
discussed in item 3). Such functions are more appropriately implemented in the dedicated systems
for, e.g., machinery automation, fire management or ballasting.
The use of the checklist system was partly discussed in 4.4 and to some degree in the preceding
section. Some other issues are discussed in the following sections.

6.1.18 ISM support functions

The ISM code defines certain requirements to a safety management system that has to be
implemented on the ship. This has requirements related to logging of drills, non conformances and
other issues that are part of normal operations.
 The ISM Code [ISM] specifies that all non-conformities shall be registered and reported
(Part A-9).
 Logging of drills is discussed in the previous section.

6.1.19 Reporting systems

SOLAS Ch. VII and [A.852] contain provisions for reporting to authorities any incident that
involves dangerous goods. This function may be part of an ISEMS. One should also consider this
issue in conjunction with SAR cooperation.

6.1.20 SAR Cooperation

Passenger ships on fixed routes are required to have plans for cooperation with local SAR services
ready on the bridge. [MSC864] gives details on implementation of such plans. An ISEMS should
also take such guidelines into consideration.
Particular requirements also may arise when ship is in or near port. In such cases, port facilities
should be used to help out during an incident or emergency.

6.2 Additional basic functions

This section includes some additional functions that can be integrated in a safety and emergency
management systems.

6.2.1 Hull stress monitoring

Some ships will be equipped with special purpose hull stress monitoring systems. Data from these
systems may be relevant for emergency management.

6.2.2 Electronic plotting table

The concept of an electronic plotting table for onboard emergency management is not directly
mentioned in SOLAS and related documents. However, one could look at it as an electronic fire
control plan. A plotting table should in addition to the basic control plan show the following:
- Location and status of damage control teams and other assets
31 of 48
 D-C1.1
FLAGSHIP 24.10.2012

- Known damage data and location

- Persons requiring assistance
- Other issues that require attention for the coordinating staff
Various other functions can be included. Some examples follow:
1. Identification of escape paths. One should probably base this function on pre-analysed
escape paths and show primary and secondary path from a given location. This could be
part of the safety plan graphics, but possibly with “live” symbols.
2. Control of evacuation systems: Technically, this is a simple function, but there are various
legislative and liability considerations that need to be made.
3. Status of mustering positions. The checklist and object status must be coordinated.
4. Persons needing assistance in evacuating: Status data could be imported automatically
from passenger lists.
5. Indication of searched area: This can be implemented by import from checklists. However,
it is not clear if this is of particular usefulness as the checklist itself will give the same
information.

6.2.3 Evacuation monitoring

Some systems may supply mechanisms for monitoring the progress of evacuation. In its simplest
form this can be CCTV cameras. However, congestion detection systems have been suggested as
a means of automatically or manually operating directional evacuation control systems.

6.2.4 Messaging module

It may be useful to include functions to exchange written messages between actors in an
emergency without resorting to voice communication. This can significantly help to reduce load
on operators. This function could be integrated with ISM checklists or be a stand alone
application.
One benefit of this function is that it can significantly reduce vocal communication during the
emergency. Entries can be entered by any party and automatically be available to all actors.

6.2.5 Task tracking

A function to register tasks for actors and show the status of the task completion is a more
advanced form of a messaging module and could be a part of this. This should probably be
integrated with the duty roster display discussed in next section.

This function must be absolutely reliable and one should also consider the problem of keeping
track of rapidly developing situations through an electronic log.

32 of 48
 D-C1.1
FLAGSHIP 24.10.2012

6.2.6 Duty roster

It may be useful to have a display showing who are currently active in the emergency
management operation. This could be part of checklist functions or the status and messaging
module.

6.2.7 Logistics and resource management decision support

Land based emergency management systems [CIMS] will often supply decision support functions
related to use of resources and logistics for moving resources. This type of functionality is
probably not a high priority on board ships, but it may be very useful in the MRCC or in other
larger scale support organizations.

6.3 Prognosis functions

This section lists some functions that can be used to make a prognosis of the development of an
incident or emergency.
Prognosis functionality, if it is reliable and complete, can be an extremely important aspect of
integrated emergency management as it has the potential to give advice on the “best” time to
make critical decisions, e.g., to abandon the ship.

6.3.1 Stability calculator

The loading calculator is required for certain bulk ships [SOLAS] Ch. XII, reg 13. It is often fitted
on other ships, also passenger ships. It is not strictly speaking a prognosis tool, but will normally
have functions to be used as one.
Loading and stability calculators should also include functions for handling ships that have
stranded, in particular with relation to tide effects and the possibility of the ship capsizing due to
the tide difference.

6.3.2 Strength calculator

A loading calculator will also in many cases include strength assessment functions. These
functions may not be very relevant for passenger ships, but is an important issue for bulkers and
some other cargo ships. Again, the effects of tide when the ship is stranded should be considered.

6.3.3 Evacuation
Monitor and predict congestion and remaining evacuation times. Systems like this are currently
available as simulators and are mainly used during off-line analysis of evacuation. Given
instrumentation on where congestions occur and the current state of an evacuation, one can
probably design on-line systems that can give advice on the time left to complete an evacuation.
One could also collect data from a number of different analysis runs and use these as tabular
guidelines for remaining evacuation time. This gives a less detailed picture, but given
uncertainties in measurements and state in any case, such advice may be adequate.

33 of 48
 D-C1.1
FLAGSHIP 24.10.2012

6.3.4 Fire
Systems that can simulate fire propagation are available today and by integrating such systems by
the fire alarm system, fire door management and ventilation systems one may get a system that
can develop a prognosis on fire development. As for evacuation, it is not clear what quality one
can get from such systems.
Systems that can both show smoke and heat spread as well as indicating speed and direction could
probably also give useful prognosis of the progress of fire. This could probably also be integrated
with temperature measurements in adjacent spaces to indicate likelihood of fire barrier break
down.

6.3.5 Maneuvrability
Tools exist to check the ships maneuverability in normal and degraded conditions. This may be
particularly useful to check the feasibility of critical maneuvers in restricted waters in adverse
weather.

6.3.6 Constrained ship routing – weather routing

Systems are available that can predict ship responses at future route based, on weather prediction,
hull, machinery and maneuvering system condition.

6.4 Integrated functions and systems

This section lists some integrated systems that are commonly encountered on more advanced
ships.

6.4.1 Passenger ship safety centre

[MSC.982] proposes certain functions to be integrated in the workstation for safety on the bridge:
1. fire alarm for areas machinery, superstructure/accommodations, cargo
2. remote control and monitoring of fire extinguishing system
3. remote control and monitoring of watertight doors/fire doors (open/closed)
4. emergency stop for air condition, ventilation and refrigerating installations
5. controls for anti-rolling device
6. indicator for further systems
7. clinometer
8. keys and control-elements for lights and signals (navigation lights, signal lamps, bridge
lighting, deck lighting searchlights, as well as all fuses)
9. internal communication system, in particular to muster stations
10. adjustment of watch alarm system and acknowledgement button
11. status indication for bow-, rearflap
12. controls/indications for ballast water handling
13. tools for documentation
14. main station for two-way VHF radiotelephone (walkie-talkie)

34 of 48
 D-C1.1
FLAGSHIP 24.10.2012

SOLAS Ch. II reg 23 specifies the need for a safety centre on newer passenger ships, with the
following functions available:
.1. all powered ventilation systems;
.2. fire doors;
.3. general emergency alarm system;
.4. public address system;
.5. electrically powered evacuation guidance systems;
.6. watertight and semi-watertight doors;
.7. indicators for shell doors, loading doors and other closing appliances;
.8. water leakage of inner/outer bow doors, stern doors and any other shell door;
.9. television surveillance system;
.10. fire detection and alarm system;
.11. fixed fire-fighting local application system(s);
.12. sprinkler and equivalent systems;
.13. water-based systems for machinery spaces;
.14. alarm to summon the crew;
.15. atrium smoke extraction system;
.16. flooding detection systems; and
.17. fire pumps and emergency fire pumps.

6.4.2 Monitoring of systems for safe return to port

[MSC.1214] specifies a number of systems that needs to be available for a passenger ship to be
able to return to port:
- Propulsion systems and their necessary auxiliaries and control systems
- Ship’s electrical-generation systems and their auxiliaries vital to the vessel’s survivability
and safety
- Steering systems and steering-control systems
- Systems for fill, transfer and service of fuel oil
- Internal communications system
- External communications system
- Fire main system
- Fixed fire-extinguishing systems (gaseous and water)
- Fire and smoke detection systems
- Bilge and ballast systems
- Power-operated watertight and semi-watertight doors
- Navigation systems
- Basic services to safe areas (SOLAS Ch. II-2/21)

35 of 48
 D-C1.1
FLAGSHIP 24.10.2012

- sanitation
- water
- food
- alternate space for medical care
- shelter from the weather
- means of preventing heat stress and hypothermia
- light
- ventilation
- Flooding detection system
- Other systems vital to damage control efforts

6.4.3 Integrated monitoring system

[A.796] defines the concept of an integrated monitoring system. Such a system shall provide
information and guidance on the following types of measurements:
1. Draught, trim and heel (low pass filtered signals should be derived in order to facilitate
trend detection);
2. Liquid/water level indicators in all compartments below the main deck;
3. Water level indications in all compartments on the main deck at positions, where water
might be trapped in case of flooding (e.g. space between bow door and inner ramp, corners
of a subdivided Ro-ro cargo space etc.);
4. Status of all watertight and fire doors;
5. Status of bow doors and any other shell doors;
6. Status of shell door locking devices;
7. Stress levels in bow door locking devices;
8. Temperature and smoke concentrations in all compartments;
9. Status of all control devices or emergency management (pumps, valves, doors, ventilators
and dampers); and
10. Water depth.

Shell doors and watertight doors that are part of the set of fire doors can directly be indicated on
the fire alarm system mimic. It should also normally be acceptable to indicate other doors of this
type.
Note that remote control of watertight doors is only allowed from bridge (SOLAS II-1, Regulation
15).
[IEC 60092] contains provisions that apply to general alarm systems with some extensions as
compared to SOLAS regulations. The standard does in principle contain requirements related to
the code on alarm and indicators [A.830].

36 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Basically this may mean that there are some requirements to list of alarms, acknowledgement and
reset of alarms and similar that needs to be satisfied. These functions are most important on
workstations that are dedicated to fire alarms, but should be displayed also on other.

6.4.4 FMS – Fire Management System

In this document an FMS is defined as a high level system for management of a fire incident, i.e.,
monitoring of fire alarms and control of fire protection equipment such as fire doors, fire dampers
etc.

An FMS should be constructed so that it satisfies the same requirements as the fire detection and
alarm system. This will normally require that the FMS is an integrated part of the fire alarm. This
also implies that the system must be built to tolerate certain failures in power, data networks or in
system hardware. Again, this normally implies some degree of redundancy, both with regards to
screens and computers [IEC 60092].
The same rules as are mentioned in the two above sections do in part apply for many other fire
related functions. The below table identifies some of these.

Table 3 – Functions of an FMS

Function Applicable legislation
Fire Control Plan SOLAS Ch. II-2/20, Symbols in A654 or A952
for newer ships (ISO 17631).
Control of ventilation in special SOLAS II, Reg. 8, part 3, MSC 1034.
spaces (engine, staircases, atrium,
etc.)
Fire door remote control and A830, SOLAS Ch. II, FSS. MSC 850 for
indication maintenance.
Fire damper remote control and As above
indication
Evacuation control As above

6.4.5 EMS – Emergency Management System

An emergency management system is a high-level decision support system that shall give the
operator (typically someone in charge of the coordination of the handling of an emergency)
information/ instructions/suggestions about how to best handle the situation. This will normally be
based on a GIS type display and the system will typically give an overview of:
1. Status of the situation in terms of severity, position and spatial extent.
2. Status of physical units or persons that can be used in the management of the situation.
3. Decision support in terms of checklists, advice, prognosis etc.
4. Other information (e.g. trends or history) that can be helpful.

37 of 48
 D-C1.1
FLAGSHIP 24.10.2012

The concept of EMS is not directly defined in SOLAS, but some functionality requirements can
be derived from discussions of SMS and DSS.

An EMS need not be implemented as an electronic system or as an integrated system. It represents

a combination of technical and organizational measures for effectively handling emergencies.

6.4.6 ISEMS – Integrated Safety and Emergency Management System

An ISEMS is a system that implements parts of or the complete EMS in an electronic system. The
system includes functions as listed under EMS as well as other functions, such as:
1. Fire management (FMS: detailed views, silence/reset and control of fire protection
equipment)
2. SSD functions, interface to ESD where applicable
3. General DSS functions (checklists etc.)
4. Evacuation and evacuation related functions
5. Plotting table, including general damage control

Exactly what functions are included will depend on the system at hand. Evacuation, fire and
plotting table functions would normally be a minimum.
[MSC887] makes reference to SOLAS Regulation III/50 where the term “strategic points” for
emergency alarm activation is used. The above mentioned circular goes on to define such points,
which may also be the position of an emergency management system. This may include fire
control positions and cargo control positions.
For the main safety centre, this can be located on the bridge or in a separate room. For location on
the bridge, one should note guidelines in [ISO 14612] and in [MSC982].

Note that an ISEMS that is used as the main computer assistance tool for handling emergencies
should in principle be designed as a continuous availability system, e.g., according to rules for fire
alarm systems (see, e.g., [IEC 60092]). This can include measures such as dual screens and
computers with independent connections to power supplies and data networks. See also definition
of FMS.

7. General requirements
This section lists some non-functional requirements that may be relevant for an ISEMS. This is
not a complete list nor need al requirements be applicable to all systems. However, it is intended
as a basis for developing more specific requirements dependent on ship and functions covered.

7.1 Integration
An ISEMS requires a high degree of integration and this may be very costly if not supported by
the systems the ISEMS exchange data with. One should also consider the possibility of making
use of integration already implemented in, e.g., VDR (see 7.14).

38 of 48
 D-C1.1
FLAGSHIP 24.10.2012

7.2 Robustness and reliability

ISEMS will to different degrees require robust system solutions, e.g., if continuous availability is
a design goal. Also, if safety critical functions are implemented, robustness must be ensured at
least to the degree mandated by relevant legislation and rules. This may require the provision of
redundant cabling, workstations or power supplies as well as other measures to ensure the relevant
degree of survivability.
Note in particular that some functions will require very high accuracy in data management and
display, e.g., for task tracking.

7.3 Duty level and duty transfer functions

An emergency management system will be operated by different people at different locations on
board. The system will require functions for safe transfer of, e.g., alarm reset and
acknowledgment functions.
Operators should have different access or duty levels according to location and responsibilities. It
should be possible to transfer between works stations dynamically.

7.4 Access control and encryption

This concerns the protection of critical data from being manipulated by unauthorized persons and
also, to some degree, that unauthorized persons get access to critical system data. This may
require encryption of data links, access control for external users and physical protection of data
networks.

7.5 Automation degree in emergency management systems

Integrated emergency management will usually allow control of certain external systems like fire
fighting equipment, passenger and crew notification systems, alarm signals and other. When
looking at this together with the monitoring functions, we can make a table that shows some of the
decision making possibilities that exist.

Table 4 – Passive or automatic responses

Degree Mode Examples

Passive presentation of status Presentation of state information Fire detection, safety plan, equipment
status

Passive presentation of status Presentation of available resources Available pumps, failures in fire
fighting equipment

Direct manual control Allow operator to control Close fire doors or dampers, control
equipment pumps.

Status aggregation Assessment of risk margins Stability condition, extent of fire

Response options for incident Presentation of response options Prioritised tasks, check lists

39 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Decision support Advice on best option Optimal procedure for stability

improvement, safest evacuation path.

Execution sequence Start a sequence of actions Tank transfer sequence, fire

containment sequence.

Automatic with override Automatic response where Automatic fire door close, PA
response is time delayed activation.

Automatic without override Emergency shut down (ESD) Sprinkler release.

The table actually represents three different dimensions as shown in the below figure. The axes
are Control consequence: How dangerous an operation is; Assessment complexity: How difficult it
is to present the correct information; and Automation degree: How little control the operator has
over the activation of the function.
Control
consequence

Auto with override

Decision support

Execution sequence

Assessment
ESD complexity
Automation degree

Figure 4 – Automatic control and decision support

An important problem in systems that automate decision support and control functions is to make
sure that the correct advice or control commands are given. Unless extensive verification activities
have been undertaken, it is normally a good idea not to allow integrated functions that extend the
state of art on more than one axis at a time. This is consistent with the KISS principle: Keep it
simple and stupid.
This also applies to normal control functions in that one should make sure that sufficient safety
interlocks are implemented on manual functions if these can have dangerous side effects. In an
integrated system it is possible to make the interlocks dependent on additional state information so
that context dependent dangers can be taken into account. One example of this is to warn against
closing fire screen doors in areas where it can significantly increase evacuation times.

7.6 General use of display technology – multiple display types

In [SWAN] the issue of display technology is discussed and one of the conclusions is that
different types of technology should be used for different purposes:

40 of 48
 D-C1.1
FLAGSHIP 24.10.2012

 GIS type software shall be used for information that has an important association to spatial
location, e.g., fire alarms, plotting table, fire patrols supervision etc.

 Process diagrams can be used where the displayed status does not have a geographic
association but still is best represented in a graphic display. Typical examples are
functional relationship between different control and monitoring system where the purpose
is to show faults or other abnormal states. Also overall HVAC or sprinkler functionality
can be represented in this manner.

 Tables and frames are best used when information has a high degree of details and no
strong relationship that is suitable for graphic presentations. The typical example is
checklists or historical reports. This display form also gives the most convenient way to
perform more complex monitoring and control functions as for example in a patrol
monitoring and control display.
An ISEMS should use different display formats for different functions. This means that the
operator must have an easy to use means for switching between the displays..

7.7 Type of GIS display

It is obvious that an ISEMS or even a fire safety system should be based on a GIS type display
[SWAN]. The discussion in that document concludes that the most appropriate display format is
one based on the two-dimensional general arrangement (GA) plan.
The use of three-dimensional (3D) or Virtual reality (VR) representations was also considered in
[SWAN], but a basic problem with 3D presentation is that it is fairly easy to get lost in the picture
when one has to zoom in on details or pan or in other ways readjust the viewpoint. Enabling 3D
rendering also requires significantly more resources during the engineering phase, which again
increases the cost of the system. It is therefore believed that the acceptance of a general 3D
situation display is still some years away.
One should also consider that current research seem to indicate that VR/3D is best suited to
applications where the operator relies on a spatial and stimuli-filled perception of the problem that
is investigated. For typical ISEMS applications, the main purpose is to give a high level overview
instead of a more detailed and life like representation of the environment. Thus, a GA type display
may actually be better than a VR/3D display for these applications.
It may be appropriate to consider a function that allows 3D detail representation of a limited area,
with a 2D overview. It may be a simpler and more efficient to use 3D technology in certain areas,
e.g., for assisting in finding certain equipment or in maintenance related applications. However, a
problem will be the substantial increase in engineering costs.
Finally, one should keep in mind that the fire control plans (SOLAS II-2-15, 2.4.1) in principle
shall be based on the GA drawings. The ISEMS should be able to display the fire control plans in
its native representation.

41 of 48
 D-C1.1
FLAGSHIP 24.10.2012

7.8 Export and import of data

One should perhaps also consider integration with other external systems, e.g., for export of
checklist data, drill logs etc., but also for import of ISM checklists, updated drawing or tag lists
etc.
XML is an efficient format for exchange of information which is supported by a significant
number of software vendors including Microsoft. Consider also Subproject D1.

7.9 System wide time stamping

For later use of logs and reports, the system needs to support consistent time stamping of all
events. Note also possible change of time zone onboard the ship during the incident. Time
information should probably include local as well as GMT/UTC times, both for shore and local
events.

7.10 Multiple events and incidents

The system need to support a number of concurrent events or incidents. Note in particular that this
may require special handling of resources assigned to specific incident types, e.g., damage control
teams.

7.11 Support for exercises and training during normal operations

The system, if it supports training, will still require basic detection functions to work as expected
during a training session. This can be handled with duty level functions.
Note that familiarization and training is different from drills and exercises.

7.12 Risk and statistics registration

The tool should, as far as practically possible, support the export of data to support more detailed
risk analysis. This may be relevant for types of incidents/alarms and the general response to them.
It may also be relevant for any registration of ISM non-conformances.

7.13 Early detection of dangerous states

General emergency management, being it related to a fire or other type of incident, typically
evolves as shown in the below figure. Note in particular that there is rarely one single event that
triggers a dangerous situation. A serious fire incident will, e.g., typically depend on a fire source,
a significant collection of combustible material and lack of fire containment facilities. The typical
need for some precondition before the dangerous situation develops is illustrated as the “hidden”
dangerous state before the potential problem is detected [SWAN].

42 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Event Event

Dangerous Detectable
Normal Information
state situation

Event

Information
Incident Information

Management Event

Emergency Information
Report

Event

Accident Information

Figure 5 – Emergency development

In the general case, the task of the crew is to assess and manage the situation as early as possible,
and preferably before the situation can be defined as an incident or emergency. The management
part can be looked at as two issues:
 Prevention: Contain the problem so that new events do not move the system to a more dangerous state.
 Correction: Remedy the problem so that it goes back to an inherently safe (normal) state.
To assist the crew, the emergency management system must present all significant information
about the current state. It is important to get the correct information at an early stage so that the
correct preventive and corrective actions can be taken before the situation escalates. The
management system can be helpful in this by being able to supply more information in a wider
context than a collection of de-coupled monitoring and control systems.
The emergency management system will also assist in handling the situation by giving access to
control functions close to the position where the situation assessment takes place.
Note also that the ISM code requires certain types of reports when incidents have occurred.
Usually these are generated manually after the incident, either through an ISM report program or
by filling in predefined forms. However, it is also possible to generate these reports automatically
from an emergency management system. By integrating more data sources in the system, more
complete reports can be generated.
The ISM code is, among other thing, designed to aid in the detection of “non-conformances” that
can create a dangerous situation as illustrated in the previous section. Typical such non-
conformances are lack of maintenance, technical problems in emergency handling equipment or
breach of routines that leave obstacles in escape paths or combustible material in corridors or
accommodation spaces. One central issue in integrated emergency management is early detection
of such situations. This is illustrated below.

43 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Event Event

Dangerous
Normal
state

Additional
data

Detectable
Information
situation

Management

Report

Figure 6 – Early detection

Basically, early detection is done by using, e.g., additional information from ISM non-
conformance reports, watch patrol reports or from the periodic maintenance system. This can be
achieved without a safety and emergency management system by following all ISM procedures
and generally have a high awareness of any safety problems on the ship. This is also how this
problem is handled today and with a fairly high degree of success. However, human errors occur
and a manual and fairly complex system is more susceptible to human errors than an automatic
system.
To reduce the potential for human errors, it can be useful to connect an ISM management system,
the periodic maintenance systems and the watch patrol systems to the integrated emergency
management system.

7.14 VDR interface

It will be very useful to record data from the ISEMS on the VDR. However, this may not be
required by current legislation.
One should also note that the VDR in practical terms is an integration hub for all safety critical
systems on the ship. Where possible, one should try to make use of this integration facility,
perhaps as a means of secondary data back up.

7.15 Engineering complexity and maintainability

Systems like ISEMS may be very complex to engineer if this is not done in conjunction with other
ship design activities. Normally, one will have to configure in all relevant safety elements, e.g.,
fire detection points, fire and water tight doors, fire fighting equipment, water level alarms and so
on. These must be “geocoded” to a general arrangement plan that will be the base layer GIS type
display. Each graphical object will also have to be associated to the relevant measurement tag and
facilities for history and possibly VCR recording may also have to be added. Thus, engineering
may be a significant cost associated with the installation of an ISEMS.
44 of 48
 D-C1.1
FLAGSHIP 24.10.2012

Likewise, due to the relatively high complexity, maintainability is also an issue. There are several
different types of maintenance that may be necessary:
- Changes in spatially attributed safety element, i.e., adding new water level detectors. This
requires changes in connection to actual measurement system, e.g., the automation system
as well as a “geocoding” of the new sensors on the GA layer.
- Changes in ship layout or, e.g., safety plan objects. An example could be the installation of
a new type of fire extinguishing equipment. This will normally not require changes in
automation or other connected systems, but requires updates in graphical presentation.
- Changes in checklists or procedures that are in some way supported by the ISEMS or other
types of object lists, e.g., lists of dangerous goods locations.
Ideally one should get ISEMS units that support automatic reconfiguration through import of data
object lists or similar functions. If this is not possible the manual performance of these functions
will certainly increase the costs of maintenance and updating of the system.

8. References
[A.760] IMO Resolution A.760(18) - Symbols Related to Life-Saving Appliances and
Arrangements - (adopted on 4 November 1993) Amended by Resolution MSC.82(70)
[A.796] IMO Resolution A.796(19) Recommendations on a decision support system for masters
on passenger ships. November 23. 1995.
[A.830] Alarms and Indicators - Code on Alarms and Indicators, 1995 Resolution A.830(19)
[A.851] IMO Resolution A.851(20) - General Principles for Ship Reporting Systems and Ship
Reporting Requirements Including Guidelines for Reporting Incidents Involving Dangerous
Goods, Harmful Substances and/or Marine Pollutants - (adopted on 27 November 1997)
[A.852] Guidelines for a structure of an integrated system of contingency planning for shipboard
emergencies adopted by the Organization by resolution A.852 (20). November 27 1997.
[A.864] MSC/Circular.864 - Guidelines for Preparing Plans for Co-operation between Search and
Rescue Services and Passenger Ships on Fixed Routes.
[A.952] IMO Resolution A.952(23) - Graphical Symbols for Shipboard Fire Control Plans -
(adopted on 5 December 2003)
[CAP] Common Alerting Protocol, v. 1.1, OASIS Standard CAP-V1.1, October 2005 Document
Identifier: CAP-V1.1.
[CIMS] Crisis Information Management Software (CIMS), Feature Comparison Report, U.S.
Department of Justice, Office of Justice Programs, National Institute of Justice - NCJ 197065,
October 2002.
[DNV] DNV Rules for Classification, Part 4, Chapter 5: Instrumentation and automation (January
1999).
[DNV01] DNV Report 2003-0277, Formal Safety Assessment Large Passenger Ships Navigation.
45 of 48
 D-C1.1
FLAGSHIP 24.10.2012

[DSS_DC] Decision Support Systems for Ships in Degraded Condition, EU Contract TCT3-CT-
2003-506354.
[DSS_DC-D2.1] Deliverable D2.1: Description of onboard and onshore processes, decision
makers, actions, information requirements and presentation format. 2005-02-10, REV. 1.4 –
FINAL (Confidential – contact authors).
[FSS] The International Code for Fire Safety Systems (FSS Code) was adopted by resolution
MSC.98(73). The Code is made mandatory under SOLAS by amendments to the Convention
adopted by the MSC at the same session (resolution MSC.99(73)).
[ICAO56] Today’s electronic checklists reduce likelihood of crew errors and help prevent
mishaps, Daniel Boorman, ICAO Journal, Volume 56, No. 1 2001.
[IEC 60092] IEC 60092-504, Ed. 3: Electrical installations in ships - Part 504: Special features -
Control and instrumentation.
[IEC61209] IEC 61209 Ed. 1.0 Maritime navigation and radiocommunication equipment and
systems -Integrated bridge systems (IBS) - Operational and performance requirements, methods
of testing and required test results.
[ISM] ISM Code, Annex to IMO Resolution A.741 (18) Adopted on 4 November 1993.
International management code for the safe operation of ships and for pollution.
[ISO 14612] Ships and marine technology — Ship's bridge layout and associated equipment —
Requirements and guidelines for centralized and integrated bridge functions. First edition 2004-
07-01.
[ISO 15713] Ships and marine technology - Low location lighting on passenger ships –
arrangement. First edition 2001-04-15.
[ISO 17631] Ships and marine technology -- Shipboard plans for fire protection, life-saving
appliances and means of escape. First edition 2002-02-28.
[ISO 17894] Ships and marine technology — Computer applications — General principles for the
development and use of programmable electronic systems in marine applications (Draft
international standard 2004).
[ISPS] International Code for the Security of Ships and of Port Facilities.
[ITEA-DS] Intelligent Tools for Emergency Applications & Decision Support, EU Contract IST-
1999-20254.
[IVHM] A unified system to provide crew alerting, electronic checklists and maintenance using
IVHM, PA Scandura Jr, C Garcia-Galan - Digital Avionics Systems Conference, 2004. DASC 04.
The 23rd, 2004.
[MARPOL] MARPOL - International Convention for the Prevention of Pollution from Ships.
[MSC.216] Resolution MSC.216(82), MSC.217(82), NSC.218(82) - Adoption of Amendments to
the International Convention for the Safety of Life at Sea, 1974 as Amended - (Adopted on 8
December 2006)
46 of 48
 D-C1.1
FLAGSHIP 24.10.2012

[MSC.681] MSC/Circular.681 - Guidelines for Passenger Safety Instruction on Ro-Ro Passenger

Ships - (adopted on 31 May 1995) - Annex - Guidelines for Passenger Safety Instructions on Ro-
Ro Passenger Ships - 6 Providing emergency instructions to passengers.
[MSC.752] IMO Resolution A.752(18) - Guidelines for the Evaluation, Testing and Application
of Low-Location Lighting on Passenger Ships - (adopted on 4 November 1993).
[MSC.760] MSC/Circular.760 - Guidelines for a Structure of an Integrated System of
Contingency Planning for Shipboard Emergencies - (adopted on 11 July 1996).
[MSC.777] MSC/Circular.777 - Indication of the Assembly Station in Passenger Ships.
[MSC.846] MSC/Circular.846 - Guidelines on Human Element Considerations for the Design and
Management of Emergency Escape Arrangements on Passenger Ships - (adopted on 8 June 1998).
[MSC.847] MSC/Circular.847 - Interpretations of Vague Expressions and other Vague Wording
in SOLAS Chapter II-2.
[MSC.850] MSC/Circular.850 - Guidelines for the Maintenance and Inspection of Fire-Protection
Systems and Appliances - (adopted on 8 June 1998)
[MSC.864] MSC/Circular.864 - Guidelines for Preparing Plans for Co-operation between Search
and Rescue Services and Passenger Ships on Fixed Routes (in accordance with SOLAS
Regulation V/15(c)) - (adopted on 22 May 1998).
[MSC.982] MSC/Circular.982 - Guidelines on Ergonomic Criteria for Bridge Equipment and
Layout - (adopted on 20 December 2000).
[MSC.1002] MSC/Circular.1002 - Guidelines on Alternative Design and Arrangements for Fire
Safety - (adopted 26 June 2001).
[MSC.1061] MSC/Circular.1061 - Guidance for the Operational Use of Integrated Bridge
Systems (IBS) - (adopted on 6 January 2003) - Annex - Guidance for the Operational Use of
Integrated Bridge Systems.
[MSC.1079] MSC/Circular.1079 - Guidelines for Preparing Plans for Co-operation between
Search and Rescue Services and Passenger Ships - (in accordance with SOLAS regulation V/7.3)
- (adopted on 10 July 2003)
[MSC.1167] MSC/Circular.1167 - Functional Requirements and Performance Standards for the
Assessment of Evacuation Guidance Systems - (1 June 2005).
[MSC.1214] MSC.1/Circular.1214 - Performance Standards for the Systems and Services to
Remain Operational on Passenger Ships for Safe Return to Port and Orderly Evacuation and
Abandonment After a Casualty - (15 December 2006).
[Smith, 2005] Managing major Incident Risks, D. Smith, V. Zijlker, SPE Asia pacific Health,
Safety and Environment Conference, Kuala Lumpur, September 2005.
[SOLAS] International Convention for the Safety of Life at Sea, 1974 with amendments, up to
and including Resolution MSC.194(80).

47 of 48
 D-C1.1
FLAGSHIP 24.10.2012

[SMPEP] SMPEP - Guidelines for the Development of Shipboard Marine Pollution Emergency
Plans for Oil and/or Noxious Liquid Substances - (adopted on 13 March 2000) Resolution
MEPC.85(44).
[SOPEP] SOPEP - Guidelines for the Development of Shipboard Oil Pollution Emergency Plans
Resolution MEPC.54(32) Amended by Resolution MEPC.86(44).
[STCW] STCW Code - Seafarers’ Training, Certification and Watchkeeping Amended by
Resolution MSC.156(78).
[SWAN] IST-1999-14124/SWAN - Deliverable D02.3: Interconnection and Decision Support
Systems - State of the art and proposed functionality, 04/10/02.

48 of 48