Emergency Control in Shipyard Safety Systems∗

Augusto Celentano, Fabio FurlanUniversita Ca’ Foscari Venezia

auce@dsi.unive.it, fabiofurlan@iol.it

Stefano BurcovichFincantieri SpA

stefano.burcovich@fincantieri.it

Abstract

Large shipyards for gigantic cruise ships require a spe-cial attention to safety due to the huge number of workersinvolved and to the complex structure of spaces. A criti-cal issue of such environments is to keep the environmentunder control to avoid a disordered evacuation in case ofan emergency. After introducing the basic issues related tosafety in shipyards, we discuss the design of an informationsystem for checking the shipyard safety status, supportingsynthetic information visualization techniques about escaperoutes and dynamic evacuation plans. We discuss also theproblems of communicating with workers in case of evacu-ation using visual cues to signal the correct escape routes.

1. Introduction

Large shipyards for gigantic cruise ships require a specialattention to safety due to the huge number of workers in-volved, the complex structure of spaces, the large range ofactivities performed inside, and the spread in people abilityto react to adverse situations. One of the most critical prob-lems to be faced in case of an adverse event is the evacua-tion of workers. Any satisfactory solution to this problem isbased on the possibility to drive the evacuation in an orderedway. Conversely, the most critical situation is to face a dis-ordered evacuation, defined as a type of evacuation whichadds damages and injuries to people beyond those due tothe disaster.

At the Computer Science Department of Ca’ FoscariUniversity in Venice, Italy, we have developed a study aboutshipyard safety systems with Fincantieri SpA, the largestItalian shipbuilding company. The study aimed to design:(a) a comprehensive information system for monitoring theshipyard in normal and emergency situations; (b) a set ofvisual interfaces helping persons in charge of safety to get

0Part of the content of this paper has been presented in a preliminaryform at theHCI for Emergencyworkshop, in conjunction withCHI 2008Conference, Florence, Italy. This work has been supported by FincantieriSpA.

a synthesis of the escape routes situation; (c) algorithms forcomputing dynamic evacuation plans; (d) personal devicesand visual cues to drive workers to safe places in case ofemergency. From the perspective of the emergency respon-sible, the main goal of a safety system is to overcome thelimits of current practices, based on static evacuation plansand large signboards, whose size and content is defined bya set of official regulations, but that do not adapt well to theshipyard dynamics. During the building of an environmentwide and complex like a cruise ship plans must be changeddynamically with the evolution of the environment itself andthe degree of completion.

In this paper we focus on the issues related to the designand management of information about the ship status duringits building, and to the the visual representation of criticalsituations that could lead to emergency problems.

2. Regulations about shipyard safety

The prevention of emergency situation is ruled in Italy byLaw 626 [1], which has introduced professional roles de-voted to safety control and environmental requirements tar-geted to risk protection. Among the duties of the emer-gency responsibles, the most important are risk evaluation,the adoption of suitable measures to protect the yard and thepeople working in it, and the continuous monitoring of thework places. To achieve their goal, emergency responsiblesand emergency workers must be supported by informationmanagement systems specifically targeted to the yard envi-ronment.

In case of emergency, Law 626 defines a number of con-cepts and procedures targeted to evacuate the workers bydriving them through safe escape paths under any adversecondition. To this end, qualitative as well as quantitativeparameters are associated to the escape paths and must bemonitored to assure a continuous and up-to-date assistanceto the workers in danger. The parameters describe featuressuch as the level of risk of the places, the number of differ-ent escape routes, the width and capacity of the doors, pas-sages and stairs (calledcheckpoints, their features are dis-cussed in Section 5); they also constrain the presence of oc-

clusions due to work progress and define the size and shapeof the signboards used to signal the escape routes. Suchregulations apply during ship building in order to guaranteethat suitable escape routes exist from any place, sized on thepresence of workers. At the same time, they allow a safetyresponsible to check if some limit is trespassed, providingthe means for restoring a safe configuration.

Law 626 applies to every type of building. As a shipyardpresents specific problems due to the pervasive use of metalas building material, and to the high risk of fire caused byfuel operated tools, a set of international regulations alsoapply, called SOLAS (Safety Of Life At Sea) [2]. SOLASregulations define primarily parameters related to fire resis-tance, which evolve as a deck environment, initially empty,is progressively populated with halls, cabins, rooms, replac-ing a large open space with small closed ambients. SOLASrules therefore progressively overlap the rules defined byLaw 626 as building progresses. This situation, if not prop-erly driven, may cause conflicts rather then reinforce safety,also because the risk evaluation made at design time mustbe continuously compared with the actual work progress.

3. Safety constraints

Besides architectural issues deriving from the frequentchanges in the spatial configuration, three classes of con-straints are relevant to safety.

Technical constraints. Deploying communication andsensing infrastructures is difficult due to the dynamics ofthe environment. Large spaces being progressively splitinto small closed environments, cables and sensors cannotbe placed freely; moreover, the large amount of metal usedlimits radio communication.

Human constraints. Workers in a shipyard are very hetero-geneous, coming from many countries, with different basecultures and different skills. As many as 70 different lan-guages have been counted, English being often unknown;emergency messages might be misunderstood, or not un-derstood at all.

Organization constraints. Changes in the environment arerecorded with variable delays, thus leading to inconsistencybetween the ship state known by the persons in charge ofsafety and the real state, possibly suggesting emergency ac-tions that refer to an outdated ship configuration. The mostcritical concern is that workers often do not know the realdanger level to which they can be exposed, possibly takingwrong decisions in case of emergency.

Figure 1 shows four views of a shipyard illustrating typ-ical cases that can affect safety. The four pictures refer tonormal, allowed situations, not to exceptional or incorrectsituations. The top left picture shows one of the staircasesexternal to the ship hull, giving access to the decks. The

Figure 1. Views of a shipyard

stairs are not connected to every deck, resulting in more ar-ticulated routes to escape on ground. The top right pictureshows a deck hosting the passenger cabins before walls’ in-stallation: the environment is easy to walk, but lacks pre-cise reference points. The bottom left picture shows thesame deck after cabins’ mounting: places and routes areclearly identifiable, but the narrow passage can be difficultto traverse in emergency due to partial occlusion caused bycarts and building materials. Finally, the bottom right pic-ture shows a staircase passage closed by a safety ribbon,hence not usable.

4. Evacuation management

The main goals of a correct evacuation are to be fast and or-dered, to give correct information to people in danger, andto keep control over the environment. They are achievedby a correct mix of prevention and intervention. Preven-tion mainly requires the analysis of the potential sources ofemergency problems, through a network of sensors moni-toring the state of the ship [3]. Intervention requires fastdelivering of correct information, as well as the limitationof damage propagation with physical and organizationalmeans.

Therefore, an evacuation management system operatesin two distinct phases: observation time and emergencytime.

Observation time. During the normal work informationabout the ship state is collected and processed, generatingknowledge about the workers flows and the rooms occupa-tion. This phase prepares the system to plan an evacuationin case of emergency.

Emergency time. The system delivers reliable informationabout how to leave the ship in safety, providing both on-

2

Figure 2. The emergency management sys-tem architecture

board emergency workers and rescue teams with detailedinformation on the state of the ship, on the evacuationprogress and on the number of saved people.

Both phases rely on the management and the deliveryof critical information, hence depend on how the informa-tion is presented, since an emergency situation benefits frompre-attentive stimuli and unbiased signals universally inter-preted.

5. The emergency management system

A ship is spatially organized in a three level hierarchy [4]:decks, which mark a vertical decomposition,main verticalzones(MVZ) corresponding to the longitudinal watertightcompartments, androoms, like halls and cabins, which arethe areas in a MVZ which can be traversed in case of anemergency, if free from temporary occlusions. Locations ina ship are thus identified by three coordinates related to thedeck, the longitudinal frame (counted onward and backwardfrom the rudder), and the ship side (left, center, right).

Two other elements are of primary importance for mon-itoring the environment and guiding the workers in case ofemergency: thecheckpointsand thewell known points. Thesimplified concept of communication passage between twoenvironments used in buildings, e.g., a door, is unsuitableina shipyard, due to the large number of types: doors, open-ings, stairs, steps, etc.. The concept of checkpoint (CKP) isintroduced to define any passage in the environment throughwhich the number of persons crossing at the same time islimited and can be measured. Well known points (WKP) are

Figure 3. Information flow among the systemcomponents

environments with special architectural and functional clueslike theaters, halls, restaurants, lift lobbies, suites, shops,panoramic walks etc., that can easily identified by everyoneonboard.

A database is built around such a ship structure. It hasa fixed content, describing the ship structure, and a variablecontent defined by data collected from sensors monitoringthe ship areas during building, which change according tothe actual ship state.

5.1. The system architecture

The emergency management system architecture is shownin Figure 2. Thesensor layermanages the hardwareand software (drivers) infrastructure needed to store in thedatabase the information on the ship status.

The statistics subsystemis part of the service layerand manages a data structure containing information aboutworkers occupation and flow through the different shiprooms. Raw data are read from the database and processedto inizialize the statistics subsystem. Thepresentation sub-systemuses information from the statistics subsystem andfrom sensors to create visual maps about the ship and work-ers situation.

The evacuation plan creatorcomputes the best escapeways, storing the information in a data structure that will beused by theemergency workers subsystem.

In case of emergency, the emergency workers subsystemuses the data provided by the evacuation plan creator to sig-nal the best escape ways through the environment devices

3

Figure 4. The control center

located in proper places along the escape routes, and possi-bly through the portable devices worn by the ship workers.

5.2. The information flow

Figure 3 illustrates the information flow between the sen-sor, database and service layers. The numbers in the fol-lowing description match the numeric labels on the arcs ofthe figure. (1) The sensors monitor the workers’ locationinside the environment. (2) Signals coming from the sen-sors are processed and converted into usable information;(3) sensors can be configured according to the progressionof the building. (4) Sensors send updated information tothe database. (5) The database is constantly updated to re-flect the current ship situation both in normal situation andin an emergency situation, concerning ship workers, on-board emergency workers and rescue teams involved. (6)The statistics subsystem creates and stores the data struc-tures containing raw information related to people’s flow,overcrowding and ship status. (7) The raw statistic data arecombined and interpreted to provide meaningful and reli-able information to the onboard emergency workers. (8)Collected statistic data are also used to create an evacuationplan, dynamically updated as the workers flow changes. (9)Visual information is presented on the personal devices ofthe onboard emergency workers. (10) If the ship must beevacuated, visual information about the safe escape routesis sent to the emergency subsystem that manages the emer-gency panels and the workers personal displays. (11) Feed-back is sent to the emergency database in order to identifycritical points such as persisting overcrowding, occlusionsand changes in the escape routes due to the emergency evo-lution.

5.3. The emergency control center

Figure 4 shows the control center operations. The emer-gency responsible queries the system about the status of a

Figure 5. The evacuation plan creation

specific ship area. A control servlet receives the request andactivates two components that manage the occupation in-dices of the ship areas (Ship beancomponent), as describedin Section 6, and the ship planimetry (XML beancompo-nent) expressed in a XML dialect and stored in the DB.An Addercomponent superimposes the two information bymodifying the ship planimetry to add visual informationabout the current workers occupation and flow [5]. The re-sult is translated to SVG graphics, visualized in a browserwindow in the control center.

Emergency plans are maintained starting from initialplans defined according to the official safety regulations.They are periodically updated as the ship building proceedsand the occupation of the shipyard areas evolves. Figure 5shows a fragment of the system devoted to plan update. In-formation about the current ship status is extracted from theDB and passed to an emergency plan creator, an algorithmthat builds a network of connections among nodes repre-senting the locations that can be traversed in emergency.The arcs are labeled with cost values that are function ofseveral variables: the most important are the properties ofmaterial as defined by the SOLAS regulations, biased by theknowledge about the current emergency dynamics and thepeople flow. Due to space limitations we do not elaborateon this algorithm, but it’s worth to note that, since it must befast and it must converge to a solution, euristics are adoptedto speed up the computation, even if they do not provideoptimal solutions.

6. Checking occupation and people flow

Two synthetic features are able to anticipate critical situ-ations if kept under continuous control:congestion indexand flow index, respectively measuring the ratio betweenpeople and environment size and capacity (showing over-crowding), and between people flowing through passagesand passage capacity (showing critical situations due to es-

4

Figure 6. The interface for occupation control

caping persons congestion). In most cases the capacity ofenvironments and passages is fixed by safety regulations,but the presence of temporary occlusions due to buildingmaterial and the reaction of persons to an emergency situ-ation might reduce the capacity and cause the limits to besurpassed.

To display the ship environment visual information pro-cessed by the sensor level is overlapped to the ship map.Visualization is thus linked to the ship structure, and mayconcern a bridge, a MVZ across all the bridges, a MVZ ofa single bridge, or the whole environment of a bridge (leastlevel of granularity).

Information about occupation is represented using col-ors; each color represents a different level of occupation,asdefined by a legend on the right side of the display. Warmcolors represent high workers concentration, cold colorsrepresent low workers concentration. In Figure 6 the roomsof a MVZ are colored and every room displays the numberof persons inside. In such a way both qualitative and quanti-tative information is displayed, highlighting the real dangerlevel.

The representation of workers flow is based on thecheckpoints. Every checkpoint has a theoretical capacity:the number of persons that can cross it in a unit period oftime without danger. Work tools and materials laying inthe environment can reduce the checkpoint capacity, so wemust know which is the real capacity and how much it is re-duced with respect to the theoretical capacity. Both must bedisplayed to identify situations where the current state ofanenvironment or of a checkpoint could increase the risk leveland lessen the evacuation speed. A similar concept is thecomparison between the current persons flow and the sup-ported flow as defined by the actual capacity, to identify sit-uations where the dynamics of workers moving could createbottlenecks.

Figure 7. The interface for people flow control

These two pairs of measures are represented usingflames, two overlapped triangles of different color: blue forthe theoretical capacity, red for the real capacity (Figure7).In a similar way, green and red flames visualize the ratiobetween the actual flow and the real capacity. Flames aredrawn on the ship map, aligned with the checkpoints. Thetriangle vertex represents the flow direction. The theoreticalcapacity is represented in the background since it is alwaygreater or equal to the real capacity, and the overlap betweenthe triangles immediately shows their relationship.

7. Communicating with workers

Most of the information about the ship actual configurationcollected during the prevention phase is used to computeand communicate to workers the escape routes in case ofemergency. Such information, and the way of presentingit, depends on technical radio communication limits and onsome non technical issues.

Workers usually do not know the whole ship but only thepart in which they work. Suggesting them a path throughunknown ship areas increases the risk; longer escape pathscan be safer if they cross only areas to which workers areaccustomed, where they can find known visual cues.

Different ship areas are exposed to different risk levels.Normative institutions have issued a classification of dan-ger in different environments. A good escape route crossesareas with decreasing danger level.

Since people work in groups, the evacuation procedure issafer if during the escape the cohesion of the group is main-tained. This principle is very important because the abilityto help each other is increased by people being used to worktogether, by speaking the same language, by being used tounderstand each other, and by being able to integrate theirpartial knowledge of the environment into a more complete

5

view of the situation.To signal the escape routes three issues are important:

(1) to take care of the changes in the environment due tothe building progress, from a skeleton of wide spaces to acomplex structure of small rooms, requiring to adapt thegranularity and the range of the signals; (2) to differentiatethe stimuli used to signal escape routes and wrong paths,using visual signs for positive stimuli and auditory signsfor negative stimuli; (3) to avoid the use of text in favor ofgraphics and symbols independent from specific languagesand cultures.

According to these issues, we have proposed two ap-proaches: a weak approach and a strong approach, differ-entiated by the spatial granularity of signs and informationdelivery. A strong approach requires positioning a largernumber of visual escape signs, and such positioning cannotbe done in a highly dynamic and highly incomplete environ-ment. A weak approach is based on fuzzy cues which referto a few well known locations, easy to identify accordingto their function. From a general point of view, during thebuilding of a ship the system should evolve from a weak toa strong approach. During a simulation it was evident thatdue to the little detail present in initial phases of ship build-ing, environments are poorly distinguishable unless they arefocal points in the ship (e.g., a hall, which can be easilyrecognized even if incomplete), or are connection nodes,such as stairs and elevators. Such environments are gener-ally known by all workers, and being a few (with respectto cabins and corridors) are easily identifiable, thereforearemarked as well known points.

8. Discussion

The evolution of an event like a fire is not impulsive or in-stantaneous. It starts in a localized area and may extendpotentially to all the ship. But its speed allows people incharge of safety to adopt local strategies and to follow itsevolution, starting with the evacuation of a limited numberof people close to the fire center, and proceeding to a totalevacuation only if the event cannot be controlled. A plausi-ble strategy can be based on three elements: (1) An evac-uation signal (visual and/or acoustic) must be forwardedonly to people inside the area subject to an immediate risk,through the personal device and the signs in the focal loca-tions. (2) A feedback signal must be received by the peoplein charge of the emergency management, by monitoring theposition of people at risk, checking that they are moving inthe right direction. (3) In case the feedback shows immobi-lized persons, personal devices should be used as beaconsto guide the rescue squad.

The work presented here has focused mainly on the de-sign of the information system able to provide timely in-formation for knowing (and managing) the risks due to an

emergency, and on the visual aspects of emergency informa-tion management. Future work will explore in details thedynamics of emergency and the communication betweenthe control center and the workers. We can anticipate somethemes that deserve attention.

Sensor reliability. Sensors measuring the workers pres-ence and flow could be damaged by a fire, creating criticalholes in the monitoring of the evacuation process. Damagecould prevent data to be read, but could also cause the trans-mission of altered data. Hence, diagnostic functions mustcheck if the sensors work correctly. Besides using redun-dancy and transmission channels devoted to check the sen-sor availability, the shipyard environment is equipped withmany types of sensors, among which the fire and smoke de-tectors are the most reliable due to their primary importancein detecting emergencies. They can be used to circumscribethe areas whose sensing information requires further checkin case of a fire.

Signboards, public displays and personal devices. Whilelarge electronic displays could be useful for delivering pub-lic information during normal operations, their use is notadvisable in emergency because they violate two importantrequirements: (1) since the environment changes continu-ously, there is a high risk to damage devices devoted toemergency information, whose position must change withthe building progress; (2) during an evacuation visual stim-uli (and audio stimuli, which are not described here but havebeen considered in our work) are very simple, e.g., basedon colors matching the escape routes, and personalized ac-cording the path the worker is following. They are betteridentified through personal devices and simple color marks,e.g., with laser-like light that can be seen also in presenceof smoke.

References

[1] DECRETO LEGISLATIVO 19 Settembre 1994, n. 626. At-tuazione delle direttive CEE riguardanti il miglioramentodella sicurezza e della salute dei lavoratori sul luogo di la-voro, 1994 (in Italian). http://www.oftal.it/legge626.htm.

[2] International Maritime Organization.SOLAS, Safety of Lifeat Sea. London. UK, 2004.

[3] L.M.Ni, Y.Liu, Yiu Cho Lau, A.P.Patil.LANDMARC: In-door Location Sensing Using Active RFID. Kluwer aca-demic Publisher, 2004.

[4] Holland America Line. Hull.6079,General ArrangementPlan. Fincantieri, 2005.

[5] Ben Shneiderman.Designing the user interface: strategiesfor effective human-computer interaction. Addison-Wesley,2004

6