FIRE-EXIT : Formulation of Immediate Response and Evacuation Strategies through Intelligent Simulation Assessment and large-scale Testing
This is an EU funded project under Framework 5 Growth Programme (contract GRD2-2001-50055) which runs from 2001-2005.
Maritime safety is one of the central concerns of the European
Commission’s transport policy. This notes the extent of losses at sea (currently
on average 230 vessels and over 1,000 lives every year), the additional impact
on marine pollution and its international dimension.
Council Directive 98/18/EC of 17 March 1998 on safety rules and standards for
passenger ships (Official Journal L 144 , 15/5/1998, pp.1-115) aimed to
introduce a uniform level of safety of life and property on new and existing
passenger ships and high-speed passenger craft, when both categories of ships
and craft are engaged on domestic voyages, and to lay down procedures for
negotiation at international level with a view to a harmonisation of the rules
for passenger ships engaged on international voyages. Specifically, this
Directive sets out requirements applicable to new ro-ro passenger ships
constructed on or after 1 July 1999. For new Class B, C and D ro-ro passenger
ships constructed on or after 1 July 1999, escape routes shall be evaluated by
an evacuation analysis early in the design process.
The analysis shall be used to identify and eliminate, as far as practicable,
congestion which may develop during an abandonment, due to normal movement of
passengers and crew along escape routes. Including the possibility that crew may
need to move along these routes in a direction opposite to the movement of the
passengers. In addition, the analysis shall be used to demonstrate that escape
arrangements are sufficiently flexible to provide for the possibility that
certain escape routes, assembly stations, embarkation stations or survival craft
may not be available as a result of a casualty.
FIRE EXIT proposes to equip the marine
industry with a Ship Evacuation Simulator that is a quantum leap in the level of
reliability, realism and design utility of today’s ship evacuation software. The
FIRE EXIT ship evacuation simulator
(maritimeEXODUS) will be capable of addressing issues of mustering, ship
motions, fire and abandonment. In achieving these aims the
FIRE EXIT
project does not intend to re-invent existing technology. Rather, it will take
as its starting point the very leading edge of the current state-of-the-art in
ship evacuation simulation (maritimeEXODUS), fire simulation (SMARTFIRE) and
large-scale experimental facilities (SHEBA, amongst others) and significantly
enhance these capabilities. FIRE EXIT fits
squarely into the objectives of 3.2.1: Efficient, safe, and environmentally
friendly ships and vessels.
The results and deliverables of FIRE EXIT
address six principal areas of investigation
-
the development of probabilistic design methods in the fire risk area consistent with the Safety Case approach and the new fire protection regulations, which specify how safety equivalence may be achieved,
-
the development of an interface to CFD software predicting the spread of fire and the creation of a module to derive from there the pattern of smoke spreading during the evacuation and its impact on evacuation and abandonment,
-
the creation of the physical mechanisms to enable realistic and valid large-scale test facilities to simulate ship motions and smoke spreading in real-time, and to establish performance data for Life Saving Appliances,
-
the development of AI-based software which
will convert the output of the simulation runs into a reduced set of human-intelligible figures of merit, and
will be able to trace back to its source any failure to achieve a sufficiently high assessment recommend improvements leading to a higher assessment
-
the development of Concept Design software with:
-
an XML based interface to the simulation module, enabling conceptual designs to be tested at an early stage, and
-
a Safety Assessment module which will take the results of simulation runs, the assessment provided by the AI module and the Classification Society Fire Safety Rules and create in a principled way an evacuation-safe design.
-
FIRE EXIT will be created by
a Consortium derived from a number of different countries which will include:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The idea behind the development comes from the final end-users of the system:
a ship operator, a shipyard, a classification society and a ship designer. Apart
from the end-users, the consortium also includes a CAD vendor and major research
organisations which will both carry out theoretical development and a
comprehensive experimental programme comprising model tests, large-scale tests
and full scale ship trials.
The scientific and technological output from FIRE EXIT
(by way of the maritimeEXODUS model) will be used by ship designers during the
concept phase, shipping regulators for the certification of ship design and by
ship operators for training on shore and at sea. In the early stages of the
design process FIRE EXIT (by way of the
maritimeEXODUS model) will bring important issues of safety, evacuation,
staffing and procedures to the fore of ship design in a manner that will be
quantifiable and reproducible. In a similar process, ship regulators will be
able to quickly assess a proposed design, including the crew procedures and
determine whether proposed designs meet acceptable standards. Finally, ship
operators will be able to assess safety provision on-board as conditions
including number, type and location of passengers, number of crew etc., change.
On-board versions of the software running in real time will allow ship operators
to train crews and even re- direct fire fighting and passenger evacuation
activities in response to the on- board situation.
The project is separated into six core work packages, each of which contributes
significantly to the overall success of the project:
WorkPackage 1 - Accident Scenario Definition - DNV
Goals - to identify and generate a prioritised list of potential risks that need
to be addressed by maritimeEXODUS; to identify the distribution of risk, thus
allowing attention to be focused upon high risk areas; to propose effective and
practical risk control options that the optimisation and design software should
be able to analyse; to identify benefits and costs associated with the
implementation of the risk control options; recommendation on how software could
be used in design and design approval.
|
|
WorkPackage 2 - Simulation – University of Greenwich
Goals - define in detail what the project requires from the simulation module
and what changes must be made to existing software; create and implement
mechanism to allow fire hazard data to be seamlessly imported into the
maritimeEXODUS from SMARTFIRE; create behaviour model to simulate individual and
group behaviour under smoke and list conditions within maritimeEXODUS; create
model to simulate individual and group behaviour under dynamic motion conditions
within maritimeEXODUS; create behaviour model to simulate behaviour under both
smoke and dynamic motion conditions within maritimeEXODUS; modify present
abandonment model within maritimeEXODUS to incorporate data from trials.
 |
WorkPackage 3 – Large-Scale Rig – FTL Goals - develop the performance and technical specifications for the changes required to SHEBA to allow motions and smoke to be introduced; design and implement and test the system changes on SHEBA for smoke introduction and dispersion; design, acquire components and install the revised hydraulics system and associated structural changes to permit motions on SHEBA; engineer and implement the changes to the SHEBA infrastructure to permit the full range of SHEBA motions; design and develop and implement the control system required to provide full SHEBA motions. |
| WorkPackage 4 – Interpretation & Optimisation
– BMT Goals - definition of the requirements and specification of the interpretation & optimisation module; design of the interpretation and optimisation module; develop the prototype interpretation module; design & develop the final optimisation module. |
 |
WorkPackage 5 – Concept Design – TRIBON Goals - define requirements and specifications for a seamless bi-directional link between concept design and evacuation simulation; design of the annotation facility in concept design; creation of the annotation facility; integration with both the remainder of the concept design software and with the simulation and interpretation & optimisation modules. |
 |
WorkPackage 6 – Testing & Trials – FTL Goals - To collect data on the behaviour and mobility capability of passengers of all ages and mobility, under conditions of smoke and static list; to collect data on the mobility and behaviour of passengers of all ages and mobility under conditions of ship motion and to validate the program; to collect data on the limiting sea conditions for successful launch of Lifesaving Appliances and on the increased times for settling LSAs when there are waves; to collect data on the times for the various components of abandoning via a variety of LSAs using a full scale rig; to execute ship evacuation trials to validate the FIRE EXIT model (maritimeEXODUS); testing of software and evaluation by end-users. |
These packages interact in order to address key components in the use, application and result analysis during the application of an evacuation model. These components can be represented by a number of key questions:
- What scenarios should be modelled?
- What data is required to perform the necessary simulations?
- Is this data available and if not provide it where possible?
- How easy is it for the engineer to configure the model for use? Provide a mechanism to simplify this process – in this case a method by which to simplify importing the general arrangement of the vessel into the simulation model.
- Is the simulation model able to represent the behaviours expected during an evacuation? Modify the simulation in order to better represent the evacuation process and to incorporate the data generated within the model.
- Is the simulation model able to accurately simulate the environmental conditions to which an evacuee might be exposed? Modify the simulation in order to better represent the environmental conditions, by providing direct access to results produced using a sophisticated CFD model.
- What type of results would the user require? Is the model currently able to produce such results? If not, produce a module to configure the results produced into a format that is readily understood.
- Does the model perform satisfactorily? Generate a data-set that provides sufficient detail for a number of the components within the model to examined.
The main FSEG contribution to FIRE EXIT is presented below. This contribution
can be broken down according to the sub-tasks associated with Workpackage 2.
| T2.1 | UOG, in collaboration with the end-users, defined in detail the modifications required in the software to allow it to accommodate smoke and dynamic motions and to streamline the process of input and output of data. |
| T2.2 | A Volume Averaging module was created by UOG, which took 3D discretized data from SMARTFIRE and constructed the zone input required by maritimeEXODUS. |
Several examples have been produced in order to demonstrate the
progress that has been made during this task.
Results
produced by SMARTFIRE model.
Results produced by the maritimeEXODUS model
once the configured SMARTFIRE data has been imported.
| T2.3 | This task incorporated the data from the smoke and list trials, after the video data had been analyzed and the impact that the list and smoke had on the behaviour of individuals and groups had been determined. A Behaviour Model component has been prototyped in order to simulate the observed behaviour. |
| Quantitative Behavioural Model | Qualitative Behavioural Model |
 |
 |
Effectively, the data has been analyzed to determine the impact of static
heel and smoke upon the travel speeds that were attained and the behaviours that
were evident during the trial. This has then been incorporated into the
evacuation model in order to better represent the behaviour observed.
Example of smoke
trial footage
Incorporation of this data within
maritimeEXODUS- example 1
Incorporation of this data within
maritimeEXODUS- example 2
| T2.4 | This task will run in two discrete time lapses. In the first
phase, the basic capabilities were developed in the software allowing
dynamic motions to be modelled in maritimeEXODUS. Development of model within maritimeEXODUS Then in the second phase, after the first large-scale trials are concluded, a more detailed representation of the behaviour evident and the quantitative results produced will be implemented. Example of the type of data that has been collected. The video data will then be analyzed and the impact of dynamic motions on passengers (both on individuals and on groups) will be modeled. Software will be created to encapsulate the models abstracted from this analysis. |
| T2.5 | Similarly to T2.4, this task will also run in two discrete
time lapses. In the first period, the basic capabilities will be developed
in the software which will allow smoke plus dynamic motions to be
accommodated in the simulation software. In the second period, after the
first large-scale evacuation trials (T5.2) are concluded, the video data
will be analysed and the impact of smoke in addition to dynamic motions on
passengers (both on individuals and on groups) will be modelled. Software
will be created to encapsulate the models defined by this analysis. UOG will
lead and FTL will ensure the work is compatible with the development in WP3. Development of model within maritimeEXODUS |
| T2.6 | After the conclusion of the Model and Full-Scale Abandonment Trials at facilities of IMD and MI the data will be analyzed and used to modify the abandonment model to take into account individual and group behavior. UOG will conduct the work. |
To demonstrate the type of process that is expected of this project, a simple
example has been produced. This has involved a number of stages, each involving
a different partner in order to exemplify the advances that have been made
within the project.
Normally the general arrangement of the vessel would be provided to the engineer
in a format that includes a vast amount of information that would not be
required for the simulation process to take place. Not only is this information
redundant, it precludes the accurate representation of the space available for
the passengers during an evacuation.
|
|
|
As is apparent from the picture below, the description of the cabin section contains far too much detail for the deck to be represented accurately. |
|
|
|
Before this could be used, the extraneous lines would have to be removed manually in order for the occupiable space to be meshed accurately. |
 |
 |
| Lines have been deleted from the GA | Space now available for the geometry to be meshed accuarately |
The manipulation of overly cluttered drawings such as that shown, would delay the modelling of the vessel by potentially several days. The TRIBON package has now been modified so that it now produces EXODUS-ready general arrangements with the information that is not required, already removed from the file.
 |
 |
| Standard Tribon view | General Arrangement of the file |
 |
 |
| 3-dimensional view of stripped file | 2-dimensional view of stripped file |
This file, produced by TRIBON, can then be exported directly to
maritimeEXODUS and then used directly in the simulation process.
|
|
Once the file has been imported into the model, the geometry can be meshed,
the scenario defined and the simulations performed.
maritimeEXODUS produces a vast set of data, enabling the user to understand the
conditions that developed during the simulation. A software module has been
developed by BMT to filter this information and produce and XML report allowing
the user to interrogate the data in a more ‘human-friendly’ format.
|
|
This module is able to read the data exported from the EXODUS model into the
ASCII-based *.sim file. This file (or a set of such files) is converted into an
XML report which can then be read via an internet browser (such as Mozilla).
This module has converted the raw data produced by EXODUS into a report that
presents judgements based on the results produced. the XML format allows the
user to interrogate the judgements made in order to get more information.
For instance the assumptions on which the judgements are made can be viewed;
|
|
the data can be presented in a graphical format;
|
|
or the values being described can be viewed in a more traditional manner.
|
|
See publications # 166, 165, 164, 152, 145.
