d1.1 scenario models & adaptive bridge requirements v5 · d1.1 scenario models & adaptive...

CASCADe Model-based Cooperative and

Adaptive Ship-based Context Aware Design

D1.1 Scenario Models & Adaptive Bridge Requirements Project Number: 314352 Nature: Working Document Classification: Confidential Version: Parts & Classifications: Main document (Confidential)

Appendix I (Confidential) ...

Work Package(s): 1 Document Timescale: Project Start Date: January 1, 2013 Start of Document: T0+2 Final version due to: T0+4 Time now: T0+5 Issue Date (dd/mm/yyyy): 5/6/2013

Compiled: Dr Gary Randall, BMT Group

Authors:

Gary Randall, Philipp Lohrmann, David Griffiths BMT Group

Christian Denker, OFFIS, Denis Javaux, SYMBIO, Paul Allen, UoC, Tommy Guldhammer Mikkelsen, MAR,

Thomas Lehman, RAY, Eugen Adami, MSM

Technical Approval:

Issue Authorisation:

All rights reserved by CASCADe consortium This document is supplied by the specific CASCADe work package quoted above on the express condition that it is treated as confidential to those specifically mentioned on the distribution list. No use may be made thereof other than expressly authorised by that work package leader.



06/06/2013 Named Distribution Only Proj. No: 314352

of 77

DISTRIBUTION LIST

Copy type1 Company and Location Recipient

T CASCADe consortium All CASCADe Partners

1 Copy types: M = Master copy, E = Email, C = Controlled copy (paper), D = Electronic copy on disk, T = TeamSite (REDMINE)




of 77

RECORD OF REVISION

Version Date (dd/mm/yyyy) Status Description Author

1 19/2/2013 Table Of Contents BMT

2 27/3/13 Added content to chapters 3,4,5,7,8 BMT

3 28/3/13 Added appendix 1 BMT

4 9/5/13 Added content to chapters 6,9,10, 11,12 OFF/SYM/MSM/BMT/MAR

5 5/6/13 Introduction, final editing BMT




of 77

Table of Contents 1 Introduction ........................................................................................... 5

1.1 Motivation for scenario use ................................................................... 5 2 How Accidents are Reported .................................................................. 9

2.1 Major accident types involving the bridge .............................................. 11 3 Scenario Selection Methodology ........................................................... 13 4 Operating Modes of The Bridge & Display Requirements ...................... 14 5 Grounding ............................................................................................ 18

5.1 Accident Reports ................................................................................ 19 5.2 Analysis ............................................................................................ 25

6 Collision ............................................................................................... 27 6.1 Accident Reports ................................................................................ 27 6.2 Analysis ............................................................................................ 34

7 Full Passage Scenarios ......................................................................... 36 7.1 Passage Plans .................................................................................... 36 7.2 Bridge Settings .................................................................................. 36

7.2.1 Emden to Leopoldok – normal voyage ............................................. 36 7.2.2 Felixstowe to Ostende – collision .................................................... 39 7.2.3 Felixstowe to Ostende – grounding ................................................. 42

8 Generic Scenario Models in UML ........................................................... 45 8.1 Normal voyage .................................................................................. 46 8.2 Collision ............................................................................................ 48 8.3 Grounding ......................................................................................... 50

9 Cognitive Aspects of Scenario Selection ............................................... 52 10 Linking Generic Scenarios to WP2, WP3 ............................................... 57 11 Seafarer Requirements ........................................................................ 58 12 Appendix 1. Collision scenarios. .......................................................... 60 13 Appendix 2. Passage Plans. ................................................................. 63

13.1.1 Emden to Leopoldok - normal voyage ............................................. 63 13.1.2 Felixstowe to Ostende – collision .................................................... 69 13.1.3 Felixstowe to Ostende – grounding ................................................. 75

14 Appendix 3 Abbreviations and Definitions ............................................ 76




of 77

1 Introduction This deliverable gives background information on our use of scenarios in CASCADe and provides some requirements for the project as a whole. We explain our motivation for using scenarios per se, as well as giving an overview of major accident types directly involving the bridge, or more specifically some malfunction of bridge team management. An informal analysis of the major contributing factors to the accidents is made. The report describes the major operating modes of the bridge and then gives detailed passage plans augmented by descriptions of typical bridge settings in each mode in each passage plan. Each voyage is then modelled in UML to support future analysis within CASCADe. We further give some theoretical details of cognitive aspects of scenario selection since it is our contention that many accidents are caused by a lack of distributed situation awareness amongst the bridge team and this obviously is a cognitive process. Finally we show how WP1 connects to future workpackages. Explicit requirements are given in Chapter 4 (by equipment manufacturers) and Chapter 11 (by maritime professionals).

1.1 Motivation for scenario use CASCADe defines scenarios as being non-trivial sequences of events and tasks carried out by multiple agents. We think in terms of normal, hazardous and emergency scenarios, any of which are more than, for example, the allocation of a task to a single crewmember, or an isolated session of radio communication. Scenarios may vary in length from just a few minutes to, theoretically, the full length of a voyage. In all cases, there will be some element of safety management that the scenario will seek to address, and since this is largely human-centred activity, we will describe scenarios from a human factors perspective. This is opposed to descriptions at the purely abstract level of vessels or systems. These scenarios do not describe the outcomes of the project. Rather, they describe normal activities whose execution will be improved by the application of CASCADe results. Both the training of bridge crews and the ways in which maritime accidents are recorded deal with ‘clustered’ activity in which behaviour of individuals and the intention of the whole system is categorised into well-known concepts. For instance, typical voyage segments might include: -

• Preparing for departure • Leaving port




of 77

• Plain sailing • Arriving at port • Berthing

This segmentation motivates the use of scenarios, or perhaps multiple scenarios, that are embedded into a longer simulation. These scenarios may have decision points that affect the narrative of the larger simulation and provide a framework from which experimental results can be derived. With the carefully controlled use of fatigue levels in seafarers and of cognitive load, we aim to replicate conditions on a real bridge. This is an environment in which certain well-established and accepted facts are known about what the contributory are factors in shipping incidents and accidents. These are our guiding assumptions and they include 1. For the majority of time when plain sailing, activity levels are low on the bridge and manning levels may be low 2. In general, the vessel is likely to have minimal manning levels 3. Crew may be fatigued due to the cumulative effects of sleep deprivation given their shift patterns. It should be made clear that the scenarios and experiments in CASCADe will not be designed to directly address these economic and cultural issues. CASCADe is not a political exercise. Rather, given the well-known factors, CASCADe will try to determine how to modify bridge design and usage so as to minimise the effects of these factors over which we have no direct control. In other words, the scope of scenario choice in the project centres only on technological and cultural matters, in terms of how bridge crew function as a team and how they interact with their instruments. The project could base its scenarios around any of the aforementioned major voyage segments, although clearly some are more relevant with regard to safety and risk than others. It is a fact that most incidents in the EU happen in high-density traffic areas where navigation demands are high. This can be seen in Fig. 1. below,




of 77

Figure 1. Distribution of the shipping incidents around the EU European Maritime Safety

Agency (EMSA) – Maritime Accident Review, 2010) It therefore makes sense that scenarios should involve coastal navigation, pilotage areas, port approaches, berthing, equipment failure etc. and not just simply plain sailing, except as a means of inducing fatigue. As previously mentioned, certain situations are so well established in maritime culture that they define accident categories as well as procedural guides of how to act at certain times. The accident categories are reported in Chapter 4. Here, in Fig. 2, we give just one example of a bridge procedure guide that describes how to act as a result of e.g. a fire on board ship.




of 77

Figure 2 International Chamber of Shipping (ICS): Bridge procedure guide for Fire.

This type of guide will contain a subset of activities that clearly involve the bridge and so any scenario may have to take these in to account. In addition, there are several possible levels of rules and regulations that may be in play in a given context, these include the ships own operating manual, the shipping company’s rules, local port or sea area restrictions, and of course the applicable IMO regulations (COLREGS, SOLAS etc.). All of this contextual knowledge can be in play as well as that captured in best practise check lists, such as that shown Fig. 3 of the ICS guide for pilotage, which details multi-agent interaction and communications.




of 77

Figure 3. An extract of the ICS check list for pilotage

All of these factors above motivate the use of pre-defined scenarios covering well-known phenomena. Rather than just replicate situations, using scenarios will allow CASCADe to address two critical questions, 1. At what point does automatic adaption of information presentation or customisation by the user either increase or decrease the level of safety on-board ship? 2. What happens in extremis at the point at which co-operative systems break down? To this end it is important to examine how routine operations become hazardous, what types of error arise and what type of decision-making is carried out. Using scenarios embedded in simulations will facilitate this.

2 How Accidents are Reported There are two significant international regulation sets giving guidance on how maritime accidents should be reported, categorised and analysed: -

• The IMO’s circular MSC-MEPC.3/Circ.3, 18 December 2008, Revised harmonized reporting procedures – Reports required under SOLAS regulation I/21 and MARPOL, articles 8 and 12;




of 77

• EU Directive 2009/18/EC, establishing the fundamental principles governing the investigation of accidents in the maritime transport sector and amending Council Directive 1999/35/EC and Directive 2002/59/EC of the European Parliament and of the Council.

The IMO maintains the Global Integrated Shipping Information System (GISIS), which contains data on marine casualties and incidents, as defined by circulars MSC-MEPC.3/Circ.3. The IMO also issues Performance Indicators, which cover various indicators, including safe shipping, secure shipping, environmentally sound shipping etc., and which are regularly published in an IMO Council Document which can be accessed via IMODOCS. For the European Union, the entry into force on 17 June 2011 of Directive 2009/18/EC has created new obligations for Member States, namely: to ensure proper safety-focused investigation systems, to investigate very serious marine casualties and decide on the investigation of others, as well as to send commonly structured investigation reports and to populate the European Marine Casualty Information Platform (EMCIP), maintained by the European Maritime Safety Agency (EMSA). EMSA has the following responsibilities in this area: -

• Supporting the Commission in the implementation of Directive 2009/18/EC. • Running and enhancing the Marine Casualty Information Platform (EMCIP). • Managing access to the EMCIP database. • Checking EMCIP data quality through acceptance procedure. • Analysis of marine casualty data. • Supporting the setting up and functioning of a permanent cooperation

framework as foreseen by Directive 2009/18/EC. • Supporting Member States through development and promotion of training

activities. • Setting-up, maintaining and managing a pool of investigators.

EMSA also publishes periodic Maritime Accident Reviews (the latest being for 2010). Most national administrations of major maritime countries undertake marine casualty investigations. For example, the UK Marine Accident Investigation Branch (MAIB) examines and investigates all types of marine accidents to or on board UK ships worldwide, and other ships in UK territorial waters. An insight into the MAIB’s approach was given in an article2 in Lloyd’s List in May 2012.

2 How the UK’s MAIB investigates vessel accidents. Lloyd’s List, 2 May 2012




of 77

Many of these administrations also issue their own marine casualty data and reviews; some examples include: - •Australian Transport Safety Bureau (ATSB) •Canada: Transportation Safety Board of Canada (TSBC) •France - The Bureau d'enquêtes sur les événements de mer (French Marine Accident Investigation Office) - BEAmer •Hong Kong, China: Summary of major accidents investigations •Netherlands - Dutch Transport Safety Board •New Zealand: Transport Accident Investigation Commission (TAIC) •Sweden: Swedish Accident Investigation Board (SHK) •UK Marine Accident Investigation Branch (MAIB) •USA: US National Transportation Safety Board (NTSB) In addition, a number of other surveys of marine casualties and accident data are published by industry bodies, classification societies, protection and indemnity (P&I) clubs and commercial marine information services. Examples of these include: - •Lloyd's Casualty Returns (July 1890 to date) available from Lloyd's Register Library •LMIU Casualty Reports •IHS Fairplay World Casualty Statistics •International Union of Marine Insurers (IUMI) Casualty and World Fleet Statistics •European Maritime Safety Agency: Annual Maritime Accident Review •ShipPax Information • Lloyd’s List Intelligence Marine Casualty Profiles: International Maritime Statistics Forum •UK Nautical Institute: Marine Accident Reporting Scheme (MARS) •Allianz Global Corporate & Specialty (Safety and Shipping Review 2013) Although the European Union directive referred to above requires each member state to create its own independent maritime accident investigation unit, and to publish the reports and share them with other countries, this isn’t yet universal practice. This shortcoming was discussed in an article3 in Lloyd’s List, also in May 2012.

2.1 Major accident types involving the bridge Some common categories of accidents/incidents are as follows: -

• MAIN PROPULSION MACHINERY FAILURE • STEERING GEAR FAILURE

3 Why are states reluctant to share casualty reports? Lloyd’s List, 2 May 2012




of 77

• GYROCOMPASS FAILURE • BRIDGE CONTROL SYSTEM FAILURE • COLLISION • STRANDING • FIRE • FLOODING OF COMPARTMENTS • UNEXPECTED LIST OF THE SHIP • BREAK AWAY FROM JETTY • MAN OVERBOARD

All of these will have some impact on bridge activity, but some, such as collision, have more relevance than for example, man overboard. These accident types happen in most areas of the shipping industry and with many types of vessel. The European Maritime Safety Agency (EMSA) report for 2010 lists accidents in cargo ships, tankers, container ships, passenger ships, fishing vessels, and ‘others’. The types of accidents are listed as sinkings, groundings, collisions/contacts, fires/explosions and ‘others’. Fig. 4 gives the breakdown of accident type per vessel category over a 3-year period.

Figure 4. EMSA (2010) Number of vessels involved in accidents by type

Collision and grounding accidents arguably have the most direct connection with any failings of the bridge team and so our scenarios will concentrate on these two issues.




of 77

3 Scenario Selection Methodology The following flowchart will be used to determine scenario generation and selection in CASCADe. They are generic steps and broadly describe the flow of work in T1.1.

Figure 5. Steps in the scenario selection methodology

Previous chapters have described our sources of scenarios. Now we list what are our selection criteria in order for us to choose from all the possible areas of activity we could cover. In essence, scenarios must be: -

1. Model friendly –> capable of being modelled by existing formalisms 2. Of interest to partners -> reflecting the industrial aims and research interests

of the consortium 3. Improvable -> there must be room for optimisation 4. Sufficiently detailed -> especially with regard to cognitive activity 5. Multi-agent -> i.e. involve co-operation at a level greater than one person

working alone on a single activity 6. Suitable for experimentation 7. Repeatable 8. Implementable in our simulators

Further, we must delineate when and how the scenario starts and ends; what interactions the agents have in the scenario; what data is used in the scenario; what is the normal sequence of events in the scenario. An important question for

Sources of Scenarios

Evalua0on/Selec0on criteria

Final Scenarios

Descrip0ons/Models




of 77

experimentation and evaluation reasons is to record what are the normal, alternate or exceptional flows of behaviour in a given context. This means in addition to highlighted decision points, we must be aware of behaviour that happens only under certain conditions i.e. after the triggering an alarm, and of behaviour that varies based upon an agent’s action at a decision point. Since WP1 does not sit alone but feeds into future work packages, we have to think of the influence of scenario selection on them. Given that WP4 will run experiments, does it make sense to distinguish between ‘fatigue’ accidents and ‘data overload’ accidents? Is it as simple as using relatively long or short scenarios to test each accident type? Heavily connected to this is the need for us to be aware of the possible dependent and dependent variables in each scenario (although this is not strictly an issue for WP1). Nonetheless, scenarios must support examination of some of the following factors from this non-exhaustive list: - Dependent variables = error rate on tasks, reaction times, level of situational awareness (an objective measure of who knows what and when), distribution level of data, level of co-operation between agents, Independent variables = console layout, information layout, time spent on the bridge. Only if a scenario fits all these criteria can we use it to drive developments in CASCADe.

4 Operating Modes of The Bridge & Display Requirements A ship’s bridge generally operates in two modes. The first is for for point-to-point navigation and the second for operations. Operations are defined as navigation of confined waterways, entering ports and locks, berthing, etc. The main difference between the two modes is mainly the manning of the bridge. When performing operations the captain is on the bridge supervising or commanding the operation. Normally there is also a duty officer present. For point-to-point navigation, only the duty officer is present. Presently the difference in modes is not reflected in the bridge instrumentation. This means that the same information and amount of information is present regardless of the scenario. There are, however, modern bridge systems with conning displays that present information for a specific operation such as docking, but this is not the standard. We envisage splitting up the operation modes for different scenarios. The justification is to increase safety by presenting the required data in a suitable manner and to avoid information overload. We have identified several scenarios, as described below.




of 77

Docking:

On the final approach the crew does not need updates on location, or the water depth, or any other chart information. They need to know what the tugs are doing in real time, distance and speed to the fender line and the forward speed. Lock:

During lock operations the crew needs information related to approaching the lock and to position themselves in the lock. During the approach they need information about distance and angle to center line of the lock and the distance from shoulders to the lock gate/sides. Inside the lock they need only information distance to lock gates/ sides and forward speed. In some cases information about the tension in the mooring ropes might be applicable. River:




of 77

During river navigation you need both the bigger picture of the voyage at hand but also information about what is happening close to you. So a split screen setup would be preferable. Also during river navigation meeting points would be of usage. Indicating where you will meet a specific vessel and when, based on prediction. Turning basin:

In harbors spaces is restricted and there is not space enough for the vessels to turn. So specially designed turning basins are located in the harbor where there is enough space (x,y,z) enough to turn the vessel. During this turn it is important to know the distance to the basin edges, how many degrees to go before the exit location is reached and the speed over ground. Here also information about the tugs location is of value. Navigation:




of 77

When navigating in non-confined waters, the navigator needs the normal instrumentation of the ship. This was what they where designed for. However you could add several layers of information, and remove redundant information from this layout. To summarize the navigator needs speed over ground, rate of turn, heading, course over ground, engine power, rudder. We could add to that, route navigation (ETA, XTE), prediction, AIS targets, predicted path of targets, electronic bearing line, variable range marker, safety contours, range rings, etc. Planning:

Before any operation there is some amount of planning involved. This planning is done by several people, including the crew onboard, the pilot, VTS operators etc. The details being planned are waypoints, reporting points, pilot pick up location, planned berth, ETA’s, tug rendezvous, etc. When adapting the bridge to the different contexts the requirements change on what to display. This is summarized in the table below:




of 77

Table 1. Display requirements of data on the bridge depending on context.

5 Grounding The grounding of a vessel involves the (usually) unintended impact of that vessel with the seabed. Grounding may or may not lead to loss of the vessel through actual sinking and the vessel may or may not become stranded after initial impact.




of 77

An informal survey by BMT of grounding reports taken from Marine Accident Investigation Branch (MAIB), the French Marine Accident Investigation Office (BEAmer), Transportation Safety Board of Canada (TSBC) and marinecasualty.com, was carried out to highlight prominent common factors in the accidents. We now report summaries of 22 such incidents followed by an analysis of the factors. The incidents were chosen because the mention failings of the bridge or bridge team. Pertinent comments are bolded.

5.1 Accident Reports Monarch of the Seas (Maritime Investigator, Oslo, Norway, and United States Coast Guard, 2003) On 15 December 1998, the 3,000-passenger cruise ship “Monarch of the Seas” grazed a reef while departing Great Bay, St. Maarten, Netherlands Antilles. The vessel had previously evacuated a sick passenger. Subsequently, the vessel departed the bay and grazed the reef without becoming stranded. As the “Monarch” started taking in considerable amounts of water, the master decided to intentionally ground her in a nearby sandbar. The following causes contributed to the accident:

-‐ Lack of adequate communication between bridge crew concerning the vessel’s manoeuvres; the bridge crew failed to “effectively work together”. There was no double checking or critical assessment of the master’s decisions. In particular, the navigational chart was not crosschecked against other means of navigation.

-‐ The master was perceived by his crew as “unapproachable”; no one dared question his decisions;

-‐ The OOW only relied on ARPA when navigating out of the port. This was partly due to the poor design of the bridge wing: “The layout of navigational equipment on the bridge failed to allow easy access to the chart table or the output information of other electronic navigational instruments such as the GPS receiver and thus would serve to hamper a navigator’s efforts to verify and plot the vessel’s position by other navigational means. All navigational charts and navigational instruments were located to the rear of the bridge and required a navigational watch officer to physically step around the vast chart table and move to the aft end or rear of the bridge away from the ARPA.”

-‐ The vessel’s chart was not up to date; the position of a key lighted buoy was incorrect;

-‐ The master was under time pressure due to the unforeseen stop;




of 77

-‐ The master was affected by fatigue, a head cold and diarrhoea. At the time of the accident, he was desperate to use the bathroom;

-‐ The master was very familiar with the port, potentially leading to overconfidence;

-‐ The OOW was jet lagged after having flown from Norway to Puerto Rico. In addition, it was his first nighttime transit of the area. Furthermore, the OOW was distracted by a phone call during a critical phase of the navigation;

Norcape (Marine Accident Investigation Branch, 2012) The Ro-Ro ferry “Norcape” ran aground on 27 November 2011 while attempting to berth at Troon harbour, Scotland. As the wind was too strong, the berthing manoeuvre was aborted, but the vessel grounded on attempting to return to sea. The vessel suffered a serious of accidents that were mainly attributed to equipment failure and bad weather. However, an analysis of the events revealed that more effective contingency and abort planning procedures (in particular for entering ports in adverse weather conditions) some of the accidents may have been prevented. In addition, the investigators remarked that “There was no electronic positional information available to the bridge team at the port console. Consequently, when Norcape was manoeuvring close to the berth in Troon, the mooring parties had to report a constant stream of positional information to the bridge team to enable them to retain spatial awareness. This information, relayed via radios, caused the bridge team to become overloaded at times during the manoeuvres. Had the electronic information, available at the centre console, been replicated at the port console, the bridge team would have been better able to monitor the vessel’s position relative to the berth and navigational hazards. This would have enabled them to put the position reports from the mooring stations into clearer context.”. Karin Schepers (Marine Accident Investigation Branch, 2012) The container vessel “Karin Schepers” grounded off the coast of Cornwall on 3 August 2011. Two hours earlier, the master, apparently intoxicated, relieved the OOW and remained as the only person on the bridge. Shortly after, he fell asleep. A bridge navigational watch alarm system was in place, but it was switched off. Clonlee (Marine Accident Investigation Branch, 2012) The feeder container vessel “Clonlee” grounded on 16 March 2011. The ship had previously been hit by an electrical blackout. The management of the blackout was negatively affected by a breakdown of communication between the bridge and the




of 77

engineers. In particular, the master became “cognitively overloaded” and did not communicate effectively with the rest of the crew. The bridge was routinely understaffed. CSL Thames (Marine Accident Investigation Branch, 2012) The bulk carrier “CSL Thames” grounded in the Sound of Mull on 9 August 2011. The third officer turned the vessel to starboard to avoid collision with another ship, not noticing that this would bring the vessel into shallow water. The audio alarm on the ECDIS did not work. In addition, the ECDIS monitor was positioned to the starboard side; however the third officer was mainly focussing on avoiding a collision by looking ahead through the bridge windows. To quote from the accident report: “Had the ECDIS display been located in front of him, he would have been more likely to routinely consult it when monitoring the navigational situation.”. Antari (Marine Accident Investigation Branch, 2009) The cargo vessel “Antari” grounded on the coast of Northern Ireland on 29 June 2008. The OOW (who was the only person on the bridge) fell asleep shortly after midnight, and the vessel continued its journey for another three hours before running aground. There was no lookout on the bridge and the watch alarm was switched off. The two bridge watchkeeping officers (the master and the chief officer) worked 6 on/6 off shifts, which appears to have led to fatigue. Pride of Canterbury (Marine Accident Investigation Branch, 2009) On 31 January 2008, the Ro-Ro ferry “Pride of Canterbury” grounded on a charted wreck while sheltering from heavy weather near Deal, Kent, UK. At the time of the accident the bridge crew was distracted by a fire alarm and various phone calls not related to navigation. The OOW was using an electronic chart system that contained the position of the wreck, but it was not displayed in the setting used at the time. The OOW had not undergone thorough ECDIS training. A paper chart was available showing the position of the wreck, but it was not consulted in a systematic fashion. In addition, the master did not formally share his intentions for the operation to shelter from heavy weather. Furthermore, the master failed to make it clear when he took over control of the ship and when he handed it back to the OOW, causing a certain level of confusion as to who was in charge of navigation. The handovers of the watch personnel were not done in a structured fashion, and not all relevant information was passed on. Fatigue may have affected some members of the bridge crew. Kathrin (Marine Accident Investigation Branch, 2006) The combi freighter “Kathrin” grounded in the Dover Strait on 12 February 2006. The accident was caused by the master (who was the OOW and only person on the bridge) falling asleep. The master was under the influence of alcohol and affected by




of 77

fatigue after having spent several months on board. The bridge watch alarm was not used; the master was unaware that it existed. MV Lerrix (Marine Accident Investigation Branch, 2005) On 10 October 2005, the cargo vessel “Lerrix” ran aground in the Baltic Sea. The master was on watch during the time of the accident; after allowing the lookout to stand down he remained as the only person on the bridge. Subsequently he fell asleep. A bridge alarm system was in place but was inoperative. Fatigue was the main contributing factor to the accident; the master’s rest during his previous 6 on/6 off watch period had been disturbed several times. Sardinia Vera (Marine Accident Investigation Branch, 2005) The Ro-Ro ferry “Sardinia Vera”, operated by Transmanche Ferries, grounded in the approach channel to the port of Newhaven on 11 January 2005. The vessel and her sister ship “Dieppe” were involved in no less than ten groundings or near groundings in four years. Due to insufficient surveying undertaken by the port authorities, accurate information about depths in the channel was frequently unavailable. The channel is prone to silting and lacks sufficient fixed aids for navigation. Jackie Moon (Marine Accident Investigation Branch, 2005) On 1 September 2004, the cargo vessel “Jackie Moon” ran aground in the Firth of Clyde, Scotland. The accident was caused by the chief officer, who was the only person on the bridge, falling asleep. The chief officer was fatigued due to lack of sufficient rest, and he was under the influence of alcohol. A bridge alarm system was in place, but nobody knew how to use it. Attilio Ievoli (Marine Accident Investigation Branch, 2005) The double hulled chemical tanker “Attilio Ievoli” grounded off Southampton on 3 June 2004. When leaving port, the master decided to use the more hazardous west Solent route, as opposed to the prescribed east Solent passage. The master was navigating the vessel; however he was distracted through speaking on the mobile phone. Present on the bridge were also the second officer and a cadet, but they were unsure about their responsibilities. As a result, nobody was plotting the exact position of the vessel. Cultural differences may have contributed to preventing the 2/O from questioning the master’s actions. The echo sounder had an alarm function, but it was switched off. Jambo (Marine Accident Investigation Branch, 2003) On 29 June 2003, the cargo vessel “Jambo” grounded and sank off the west coast of Scotland. While the lookout was absent from the bridge, the chief officer (who was




of 77

the only person on the bridge) fell asleep. No watch alarm was installed. The chief officer was suffering from fatigue caused by extended 6 on/6 off watch patterns and several interruptions of his rest periods due to port visits. Algomarine (Transportation Safety Board of Canada, 2008) On 28 May 2008, the bulk carrier “Algomarine” ran aground on a charted shoal near Ontario, Canada. On approach of the port, the master deviated from the voyage plan but did not communicate this with the bridge team. The vessel was conned visually and the position was not confirmed using other means of navigation. The shoal was visible on the electronic chart system, but the crew were unfamiliar with this functionality. A depth sounder gave an acoustic alarm, but the crew did not understand it’s meaning and ignored it. At the time of the accident, the master suffered from fatigue due to disturbed sleep. He had recently quit smoking and was taking a prescription drug to lessen the effects of the withdrawal symptoms, which may have had a further negative effect on his ability to sleep. Michipicoten (Transportation Safety Board of Canada, 2005) On 28 October 2005, the bulk carrier “Michipicoten” ran aground in the St. Mary’s River in Ontario, Canada. The accident was caused by the wheelsman mishearing the master’s order “20 degrees starboard” as “20 degrees port”. The master did not notice this mistake as he did not check the vessels position against the electronic navigation aids. The master may have been affected by fatigue due to lack of rest. The bridge arrangement may have contributed to the accident as the master “had to lean back and look over his right shoulder to see the ECS unit” from his position in the pilot’s chair. Horizon (Transportation Safety Board of Canada) On 24 July 2004, the container vessel “Horizon” grounded off Saint-Anne-de-Sorel, Quebec, Canada while being guided by a river pilot. The pilot not ordering a cause alteration in time caused the accident. The pilot’s performance may have been affected by fatigue due to irregular working patterns. None of the other members of the bridge team were aware of the vessel’s exact position; communication among the team was minimal. The bridge layout led to the team being spread out, which made collaborating harder. Musketier (French Marine Accident Investigation Office , 2011) The general cargo vessel “Musketier” stranded at Ambleteuse, France, on 8 February 2011. The accident was caused by the master falling asleep while being the only person on the bridge. He was affected by fatigue due to the watchkeeping schedule that allowed him only four hours rest between two consecutive watches. Both the ECDIS waypoint alarm and the bridge watch alarm systems were switched off.




of 77

Gunay 2 (French Marine Accident Investigation Office, 2009) On 21 January 2009, the cargo vessel “Gunay 2” ran aground on Planier Island near Marseille, France. The accident was caused by human error during navigation on behalf of the master. At the time of the accident, the vessel’s owner was suffering from serious economical problems, which led to the crew not receiving their pay and the vessel being understaffed. The crew even had to buy their own food. Before departure, the master and chief officer had been involved in negotiations with the owner. The lack of personnel led to prolonged watches, which resulted in fatigue for the bridge crew. The preoccupation with all these factors and the resulting stress is considered the main reason for the accident. Paterson (Transportation Safety Board of Canada, 1999) The bulk carrier “Paterson” ran aground in the Lac Saint-Francois, Canada, on 5 April 1999. The accident was caused by the OOW initiating a turn in the channel too late. At the time of the accident, the OOW was also acting as pilot, i.e. he was the only person involved in the navigation of the vessel. Shortly before the grounding, the OOW had a brief personal conversation with an acquaintance on a passing vessel. Some buoys in the area had been moved, which may have caused the OOW a moment of confusion. He may have become “overloaded” which may have contributed to him missing the appropriate moment to initiate the turn. In addition, “The night navigation display used for the electronic chart system did not allow all the information on the chart to be easily recognizable.”. Raven Arrow (Transportation Safety Board of Canada (TSB), 1997) On 24 September 1997, the bulk carrier “Raven Arrow” grounded in the Johnstone Strait, British Columbia, Canada. At the time of the accident, the vessel was guided by a pilot, with the OOW and a helmsman present on the bridge. The grounding occurred when the pilot misinterpreted a radar image, thus reaching a false conclusion concerning the vessel’s position, and ordered an inappropriate change of course. Visibility was reduced by fog. Just before the accident, the pilot had undertaken various manoeuvres to avoid collisions with other vessels, which may have contributed to his loss of situational awareness. The OOW had been plotting the ship’s position, but there was poor communication and little teamwork between them, so the position was not crosschecked. In addition, the pilot was affected by fatigue due to lack of sleep. Fifi (Transportation Safety Board of Canada, 1995) On 21 January 1995, the tanker “Fifi” ran aground in Comeau, Quebec, Canada. While waiting in the bay to take on board two pilots, the ship was pushed onto a shoal by the tidal current. The OOW failed to notice the drifting of the vessel in time; there were no large-scale maps of the area on board, and the ARPA was not used to check the vessels exact position. Algolake (Transportation Safety Board of Canada)




of 77

The bulk carrier “Algolake” grounded in Lake Erie, Ontario, on 14 October 1998. The accident was due to a course alteration point being missed. At the time of the event, there was confusion on the bridge as to who was navigating the vessel; the master had come to the bridge before the beginning of his watch but had not formally taken over the command. In addition, the position of the vessel was not checked with sufficient frequency, and neither the ECDIS nor the depth sounder was operational.

5.2 Analysis The following is an overview of factors that contributed to the above listed grounding events and may be relevant for CASCADe. Note that this is not a statistical analysis of marine accidents.

-‐ Fatigue: One or more of the people involved in the navigation suffer performance deterioration due to fatigue.

-‐ Alcohol/Substances: One or more of the people involved in the navigation are under the influence of alcohol or other substances that may affect performance.

-‐ Illness: One or more of the people involved in the navigation are unwell. -‐ Uncertainty about Responsibilities: At the time of the accident, there was

confusion among the bridge team as to who was in charge of navigation and/or which duty each person was to perform.

-‐ Poor Communication: Vital information is not shared (or misunderstood) between the crew navigating the vessel.

-‐ Communication Barriers: Language barriers, cultural differences, personal animosities or a clash of personalities can hamper communication between bridge team members.

-‐ Distraction: During a crucial phase of navigation, one or more members of the bridge team become preoccupied with matters unrelated to navigation.

-‐ Poor Bridge Design: The navigation of the vessel is negatively affected by a less than optimal bridge layout or positioning of displays.

-‐ Inadequate means of navigation: One or more means of navigation are dysfunctional or absent (e.g. lack of adequate charts, malfunctioning radar, lack of acoustic alarms etc.)

-‐ Inadequate use of navigational aids: The crew are making incorrect/insufficient use of the means of navigation (e.g. by not using an




of 77

available ARPA or by choosing an inappropriate mode of display on the ECDIS).

-‐ Overload: The person navigating the vessel becomes “cognitively overloaded” and loses situational awareness as a consequence. This differs from “Distraction” in the sense that the person is exclusively occupied with navigation.

-‐ Alarms suppressed/ignored/misinterpreted: Acoustic alarms are in place and functional, but they are either switched off or ignored or misunderstood.

-‐ Lack of personnel: The vessel and/or bridge team is understaffed. -‐ External pressures: The crew is preoccupied with (and potentially

distracted by) problems not related to navigation. This differs from “Distraction” in that the external issues were pre-existing, causing a “background” level of stress for the crew.

References Allianz Global Corporate & Specialty. (2013). Safety and Shipping Review 2013.

French Marine Accident Investigation Office . (2011). Report of safety investigation - Stranding of the General Cargo Vessel Musketier.

French Marine Accident Investigation Office. (2009). Grounding of the Cargo Vessel Gunay 2 on 21 January 2009 on Planier Island, off Marseille.

Marine Accident Investigation Branch reports 2/2009, 10/2012, 14/2006, 19/2005, 2/2005, 2/2012,24/2006, 27/2003, 28/2012,5/2005, 6/2012, 7/2009.

Marine Accident Investigation Branch. (2012). Report on the investigation of windlass damage, grounding and accident to person on the ro-ro ferry Norcape.

Maritime Investigator, Oslo, Norway, and United States Coast Guard. (2003). Report of Investigation into the Circumstances Surrounding the Grounding of the Monarch of the Seas.

Transportation Safety Board of Canada (TSB). (1997). MARINE OCCURRENCE REPORT M97W0197.

Transportation Safety Board of Canada reports . Report Number M04L0092, M05C0063, M08C0024, M95L0001, M98C0066, M99C0003.




of 77

6 Collision Collision can be defined as the act of two navigable things coming into contact. Typically, both will be moving vessels, whose variety of movements relative to each other were described succinctly by Smeaton & Coenen (1990) as being either head-on, overtaking or crossing situations.

Figure 6. Types of situation with a risk of collision, from Smeaton & Coenen (1990)

As with grounding, BMT has conducted an informal survey of collision accident reports, with data this time coming from the UK’s Marine Accident Investigation Board (MAIB). The following summaries of 22 accidents are followed by some analysis highlighting common, major contributory factors.

6.1 Accident Reports The following information is taken from the Marine Accident Investigation Branch (MAIB). Stena Feronia/Union Moon (Marine Accident Investigation Branch, 2012) On 7 March 2012, the ROPAX ferry “Stena Feronia” collided with the general cargo vessel “Union Moon” outside Belfast Harbour. The accident occurred because the “Union Moon” changed course unexpectedly, bringing her into a collision course with the other vessel. Evasive action by the “Stena Feronia” proved unsuccessful. The master of the “Union Moon” was under the influence of alcohol and alone on the bridge when the collision occurred. The “Stena Feronia” was piloted by an officer of the company whose role in the hierarchy was not entirely clear, leading to some




of 77

uncertainty about responsibilities of navigation. The bridge team could have avoided the accident with earlier evasive action. There was insufficient communication between the ships and between the ships and the port authorities; language barriers may have contributed. The master had left the bridge shortly before the incident to see to an administrative matter. Spring Bok/Gas Arctic (Marine Accident Investigation Branch, 2012) On 24 March 2012, the cargo vessel “Spring Bok” (SB) tried to overtake and collided with the liquefied gas tanker “Gas Arctic” (GA) in the Dover Strait. Visibility was reduced due to fog, however, both vessels had stood down their lookouts. The SB’s master was plotting the other vessel’s position on the ARPA, but the settings chosen were not ideal for determining the ships’ relative positions. The visibility from the radar position was restricted by the wheelhouse window frame and the cargo cranes, creating a “blind sector” that prevented the master from spotting the other vessel in time. In addition, the SB’s master was distracted by a conversation with relatives who were passengers on the ship. He was also affected by fatigue due to reduced rest periods. The GA’s ARPA was inoperable at the time of the accident. Clipper Point (Marine Accident Investigation Branch, 2012) The RoRo cargo ferry “Clipper Point” collided with the quay and two other ferries while berthing in Heysham, UK on 24 May 2011. The wind was too strong to allow the vessel to turn inside the port. One of the ship’s two bow thrusters was inoperative; this loss could not be compensated by the assistance of a tug. In addition, there was poor communication between the two vessels. The master was operating the ship from the bridge wing, which did not allow for the display of all relevant data like speed, heading and rate of turn. The displays on the bridge wing were small and hard to read. Cosco Hong Kong/Zhe Ling Yu Yun (Marine Accident Investigation Branch, 2011) On 6 March 2011, the container vessel “Cosco Hong Kong” (CHK) collided with the fish transportation vessel “Zhe Ling Yu Yun” (ZLYY) off the coast of Zhejiang Province, China. The latter ship sank with the loss of 11 lives. The crew of the CHK did not even realise that the collision had occurred. At the time of the accident, the CHK’s bridge was manned by the OOW only; the lookout had been allowed to stand down, in spite of a decrease in visibility due to heavy rain. The OOW used the S band radar (which was negatively affected by the rain) to watch for other vessels; he did not monitor the AIS receiver. In order to avoid a collision, the OOW changed course to port, effectively making matters worse. He also did not reduce speed and gave an incorrect acoustic signal, which may have confused the other vessel. Philipp/Lynn Marie (Marine Accident Investigation Branch, 2011)




of 77

On 9 April 2011, the container feeder “Philipp” (P) collided with the fishing vessel “Lynn Marie” (LM) off the Isle of Man, UK. P’s bridge was manned by the OOW and a lookout at the time of the accident. The OOW relied on AIS and ECS for his navigation; he remained seated in the starboard seat of the bridge console where the ARPA was not available. Several fishing vessels were sailing near the P, so the OOW appears to have lost his situational awareness and altered course towards the LM. Boxford/Admiral Blake (Marine Accident Investigation Branch, 2011) On 11 February 2011, the container ship “Boxford” (B) collided with the fishing vessel “Admiral Blake” (AB) in the English Channel. The B’s bridge was manned by the master and a lookout at the time of the accident. The master spotted the AB, but could not locate her on the radar screen. He misinterpreted the other vessel’s position and ordered an alteration of course that caused the position. The radar was found to be functional, so it is possible that the crew was using an inappropriate setting. The AB was not emitting AIS messages. The B’s master suffered from fatigue as he had been unable to get any rest for 38 hours. In addition, he was seeing to operational matters unrelated to navigation immediately before the collision that may have distracted his attention. Skandi Foula (Marine Accident Investigation Branch, 2011) On 29 May 2010, the platform supply vessel “Skandi Foula” collided with a moored vessel in Victoria Dock, Aberdeen, UK. The ship was handled by the chief officer, who was new to the vessel and unfamiliar with the manual controls. He may also have suffered from “sleep inertia”, as he had been called from his bed at very short notice. There was little communication among the bridge team about how the manoeuvre was to be performed. The master remained at the aft controls, which made it difficult to monitor the overall progress of the vessel and to oversee the chief officer. Scottish Viking/Homeland (Marine Accident Investigation Branch, 2011) On 5 August 2010, the RoRo passenger ferry “Scottish Viking” (SV) collided with the fishing vessel “Homeland” (H) off St Abb’s Head, UK, resulting in the sinking of the latter ship and one of its two crew members being lost. The H’s crew did not continuously man the wheelhouse and were distracted by other tasks; they did not keep a sufficient lookout and hence were unable to take timely action to avoid a collision. The SV’s bridge was manned by the OOW and a lookout at the time of the accident. The bridge team noticed three fishing vessels shortly before they collision, one of them being the H. The targets were visually observed, but not plotted on the radar. The OOW failed to take early action to avoid a collision. Alam Pintar/Etoile des Ondes (Marine Accident Investigation Branch, 2010)




of 77

On 20 December 2009, the bulk carrier “Alam Pintar” (AP) collided with the fishing vessel “Etoile des Ondes” (EO) off the Cherbourg peninsula, France, leading to a crew member of the EO being lost. At the time of the accident, the AP’s bridge was manned by an inexperienced 4th officer as OOW and a deck cadet as lookout. The AP changed course to avoid the EO dead ahead, however the fishing vessel also changed course, which brought it back in front of the AP’s bow. In total, the AP’s actions to avoid collision were insufficient, given the “erratic” manoeuvres of a vessel engaged in fishing. The EO’s skipper had spotted the AP on the radar, but did not plot it or assess a risk of collision. He was distracted by overseeing the shooting of crab pots. Vallermosa (Marine Accident Investigation Branch, 2009) On 25 February 2009, the tanker “Vallermosa” made contact with two other tankers at Fawley Marine Terminal, Solent, UK. The vessel’s berthing manoeuvre was aborted for administrative reasons during a challenging turn. The pilot, who was navigating the vessel at the time of the accident, got increasingly frustrated and overloaded by this decision; he was distracted by discussing the change of plan with the master and by communicating with the tugs and the terminal. As a consequence, he did not reduce the vessel’s speed sufficiently for the next turn. He subsequently lost control of the ship. The bridge team took a rather passive role and did not sufficiently support or communicate with the pilot. Scot Isles/Wadi Halfa (Marine Accident Investigation Branch, 2009) On 29 October 2009, the general cargo vessel “Scot Isles” (SI) collided with the bulk carrier “Wadi Halfa” (WH) in the Dover Strait. The SI’s OOW did not plot any of the visible radar targets with ARPA, nor did he consult the AIS display. The SI’s lookout spotted the WH, but the OOW did not register this observation; the lookout then left the bridge for a safety round, leaving the OOW as the only person on the bridge. There was insufficient communication between the two. The WH’s OOW did also not plot the radar targets to check for a risk of collision; at the time of the accident he also was alone on the bridge as the lookout was taking a toilet break. When he spotted the SI, he attempted to take evasive action, but it was too late to avoid a collision. Both OOWs displayed a “complacent” attitude towards watchkeeping. Sichem Melbourne (Marine Accident Investigation Branch, 2008) On 25 February 2008, the product carrier “Sichem Melbourne” hit the mooring structures as she departed the Coryton Oil Refinery in the River Thames estuary. The accident was caused by insufficient communication between the pilot and the bridge team, leading to misunderstandings during manoeuvring. The bridge team communicated in Russian, which effectively excluded the pilot. Ursine/Pride of Bruges (Marine Accident Investigation Branch, 2008)




of 77

On 13 November 2007, the RoRo ferry “Ursine” made contact with the passenger ferry “Pride of Bruges” while berthing in King George Dock, Hull, UK. The ship was navigated by a PEC holder employed by the ferry company and the master; neither had sufficient experience in handling RoRo ferries. It was not clear who was in control of the vessel, as either man relied on the other to take charge. Audacity/Leonis (Marine Accident Investigation Branch, 2008) On 14 April 2007, the product tanker “Audacity” (A) collided with the general cargo vessel “Leonis” (L) in the entrance to the River Humber, UK. Visibility was poor, and there was insufficient guidance from the VTS operators, who may have been unaware of the reduced visibility. The L’s bridge team did not plot the A’s position on ARPA; the pilot had just embarked the L and had no time to fully grasp the situation by himself. As for the A, there was insufficient communication and allocation of responsibilities between the pilot and the master; in particular, both assumed that the other was plotting other vessels on the ARPA. In addition, the pilot became distracted by discussing his disembarkation with the coxswain just before the collision. Sea Express 1/Alaska Rainbow (Marine Accident Investigation Branch, 2007) On 3 February 2007, the high-speed ferry “Sea Express 1” (SE) collided with the general cargo vessel “Alaska Rainbow” (AR) on the River Mersey. Visibility was reduced by thick fog. The SE’s bridge team used their radar in a sea-stabilised setting, which created “true trails” for all detected objects (including land masses), which caused the radar screen to become cluttered. In addition, the master was distracted by teaching a trainee captain. The AR was waiting for its scheduled docking time; pilot relied on other vessels to take avoiding action. He noticed the SE but did not call her to confirm this until it was too late. He was monitoring the AR’s position, tracking other vessels and communicating with the tugs, without sufficient support from the bridge team. Samskip Courier/Skagern (Marine Accident Investigation Branch, 2007) On 7 June 2006, the general cargo vessel “Skagern” (S) and the container ship “Samskip Courier” (SC) collided in the Humber estuary, UK. The visibility was reduced due to dense fog. The neither ship’s bridge team used the ARPA functionality of their radar to plot other vessels. The SC did not keep to the starboard side of the channel as demanded by regulations; in addition, both ships were going too fast. The pilot of the SC lost situational awareness right before the collision and turned the ship in the wrong direction. The masters of both vessels did not closely monitor the pilots’ actions, nor did they communicate effectively with them. Both ships’ bridges were inadequately manned. Harvester/Strilmøy (Marine Accident Investigation Branch, 2006)




of 77

On 4 November 2005, the supply and standby vessel “Strilmøy” (S) collided with the fishing vessel “Harvester” (H) which subsequently sank. The visibility was reduced by fog. At the time of the accident, the OOW was alone on the bridge of the S; the lookout was engaged elsewhere. The H and her sister vessel were tracked on S’s ARPA. However, the OOW did not notice the vessels until it was too late to avoid a collision; it appears that he was distracted from navigation by other tasks. In addition, it was found that he had poor eyesight and had difficulties recognising radar contacts. On the other hand, the S was noticed on the radar of the fishing vessels at the same time. Although they established a risk of collision, no avoiding action was taken. They contacted the S shortly before the collision on VHF but did not receive a response. Subsequently, the H changed course but it was too late to avoid a collision. Amenity/Tor Dania (Marine Accident Investigation Branch, 2005) On 23 January 2005, the tanker “Amenity” (A) collided with the RoRo cargo vessel “Tor Dania” (TD) in the River Humber, UK. A’s bridge was manned by the master and a lookout at the time of the accident; the former was monitoring other vessels on the radar, but he did not overlay the radar with the ECS, nor was he using AIS. Misinterpreting a manoeuvre of the TD, he put his engines on full astern, which caused the bow to swing around and collide with the other vessel. The A’s master may have been distracted by completing his logbook at the time of the accident, thus becoming “overloaded”. The collision could have been avoided had the master read the rate of turn from the AIS. There was little communication between the master and his lookout. The masters of both vessels were holding PECs. Hyundai Dominion/Sky Hope (Marine Accident Investigation Branch, 2005) On 21 June 2004, the container vessels “Hyundai Dominion” (HD) and “Sky Hope” (SH) collided in the East China Sea. The accident was caused by a disagreement between the OOWs over the maritime situation; SH considered the other vessel to be “overtaking”, whereas HD considered the other ship to be “crossing”. There was poor communication between the ships; the HD’s OOW used the free text facility of the AIS system to advise the other ship to “stay clear”, which may have gone unnoticed. Avoiding action was taken too late and was not clearly communicated between the vessels. Both OOWs may have been affected by fatigue; both did not inform their vessel’s master about the situation. Lykes Voyager/Washington Senator (Marine Accident Investigation Branch and German Federal Bureau of Maritime Casualty Investigation, 2006) On 8 April 2005, the container vessels “Lykes Voyager” (LV) and “Washington Senator” (WS) collided in the Taiwan Strait. The crew of the WS was following a passing arrangement that they assumed had been made with the LV; however, this arrangement had been made with another, unidentified vessel, which led to both ships heading straight towards one another. The visibility was less than 200m due




of 77

to fog, and there was a large concentration of fishing vessels in the area. Both vessels’ bridges were manned by the master, the OOW and a lookout. The LV’s master may have been affected by fatigue; he may not have given enough support to his very inexperienced OOW. As for the WS, there was poor communication between the master and the OOW, leading to ambiguity as to who was conning the vessel. Better use of AIS might have led to avoiding action being initiated earlier. Scot Explorer/Dorthe Dalsoe (Marine Accident Investigation Branch, 2005) On 2 November 2004, the cargo vessel “Scot Explorer” (SE) collided with the fishing vessel “Dorthe Dalsoe” (DD) in the Kattegat. The DD was on autopilot, with its crew engaged in other work, so there was no continuous lookout. The master was affected by fatigue (which may or may not have contributed to the accident). The DD was also displaying confusing navigation lights, intended to indicate “not under command”; the crew assumed that other vessels would stay out of their way. The SE’s master (who was the only person on the bridge) did not accurately determine the other vessel’s course, partly due to its confusing navigation lights. Right before the collision, he got distracted by updating the official logbook, thus not paying attention to collision avoidance. The SE’s master did not take advantage of the radar plotting functionality. The nominated lookout was sent to work in the galleys instead. Reno/Ocean Rose (Marine Accident Investigation Branch, 2004) On 6 March 2004, the chemical tanker “Reno” (R) collided with the fishing vessel “Ocean Rose” (OR) near Whitby, UK. The OR was under autopilot and engaged in fishing; they noticed and tried to contact the R by VHF but received no answer. Avoiding action was taken too late. The bridge of the R was manned by the OOW and a lookout; however, the OOW appears to have left the bridge to get changed. With the fishing vessel approaching, the lookout tried to contact the OOW, even briefly leaving the bridge to do so. He did not try to contact the master, possibly due to a culturally ingrained adherence to hierarchy. Eventually, the lookout unsuccessfully tried to take avoiding action by himself. P&O Nedlloyd Vespucci/Wahkuna (Marine Accident Investigation Branch, 2003) On 28 May 2003, the container ship “P&O Nedlloyd Vespucci” (PO) collided with the yacht “Wahkuna” (W) in the English Channel. The visibility was reduced to 50m due to fog. The vessels detected each other on radar when about 6 miles apart. Both vessels took avoiding action which cancelled each other out: the W slowed down, incorrectly assuming that the PO would pass in front of its bow; the PO turned to starboard, assuming that the W would maintain its speed. The PO’s bridge was manned by the master, the OOW and a lookout. The W was plotted on the ARPA, but the crew relied too much on the system’s accuracy; in addition, they were confused by the yacht’s manoeuvring. They never noticed the collision. The PO’s master may have been affected by fatigue.




of 77

Ash/Dutch Aquamarine (Marine Accident Investigation Branch, 2003) On 9 October 2001, the general cargo vessel “Ash” (A) collided with the chemical tanker “Dutch Aquamarine” (DA). The former subsequently foundered and its master was lost. At the time of the accident, DA’s bridge was manned by the OOW and a cadet. Both failed to notice the other vessel right ahead of them. The OOW did not use the ARPA as it had had faults in the past. The A’s OOW (the sole watchkeeper) had seen the other vessel approaching, but then got distracted by a phone call right until the collision.

6.2 Analysis The following is an overview of factors that contributed to the above listed collision events and may be relevant for CASCADe. Note that this is not a statistical analysis of marine accidents.

-‐ Reduced Visibility: Reduced visibility due to fog, rain or other factors has contributed to the development of the accident.

-‐ Fatigue: One or more of the people involved in the navigation suffer performance deterioration due to fatigue.

-‐ Alcohol/Substances: One or more of the people involved in navigation are under the influence of alcohol or other substances that may affect performance.

-‐ Uncertainty about Responsibilities: At the time of the accident, there was confusion among the bridge team as to who was in charge of navigation and/or which duty each person was to perform.

-‐ Poor Communication among crew: Vital information is not shared (or misunderstood) between the crew navigating the vessel.

-‐ Communication Barriers among crew: Language barriers, cultural differences, personal animosities or a clash of personalities can hamper communication between bridge team members.

-‐ Poor Communication between ships and/or authorities: Relevant navigational information is either not shared between vessels or it is




of 77

misunderstood; this includes the inadequate/confusing use of optical or acoustic signals.

-‐ Distraction: During a crucial phase of navigation, one or more members of the bridge team become preoccupied with matters unrelated to navigation.

-‐ Lack of personnel on the bridge: The bridge team is understaffed, the lookout and/or OOW are absent from the bridge in the crucial moments leading up to the accident.

-‐ Inadequate means of collision avoidance: One or more means of collision avoidance are dysfunctional or absent (e.g. malfunctioning ARPA).

-‐ Inadequate use of collision avoidance aids: The crew are making incorrect/insufficient use of the means of collision avoidance (e.g. by not using available AIS information or by choosing an inappropriate mode of display on the ARPA).

-‐ Poor Bridge Design: The navigation of the vessel is negatively affected by a less than optimal bridge layout and/or positioning of displays.

-‐ Overload: The person navigating the vessel becomes “cognitively overloaded” and loses situational awareness as a consequence. This differs from “Distraction” in the sense that the person is exclusively occupied with navigation.

References Marine Accident Investigation Branch and German Federal Bureau of Maritime Casualty Investigation. (2006). Report No 4/2006.

Marine Accident Investigation Branch reports 2/2009, 10/2005, 10/2008, 10/2009, 10/2012, 11/2010,13/2004, 14/2006, 15/2006, 15/2011, 16/2012, 17/2005, 17/2011, 18/2008, 19/2005, 2/2005,2/2008, 2/2012, 20/2005, 20/2011, 22/2007, 23/2009, 24/2006, 24/2012, 26/2012, 27/2003,27/2011, 28/2003, 28/2012, 4/2011,5/2005, 6/2007, 6/2012, 7/2003, 7/2009.

Smeaton, G.P & Coenen, F.P (1990): Developing an intelligent marine navigation system: Computing & Control Engineering Journal March 1990.




of 77

7 Full Passage Scenarios

7.1 Passage Plans Images depicting the various passage plans are now shown in Appendix 2 for better readability. The bridge settings for each passage plan are given in the following section.

7.2 Bridge Settings For each of the previous voyages we have determined what the most likely bridge settings and activities of the seafarers would be for those voyages.

7.2.1 Emden to Leopoldok – normal voyage Bridge Settings / Bridge Visualization / Bridge Alarms Preparation in Emden

• Plan Routes in ECDIS (incl. radiuses for each WPT) o 1. Emden dock - EMS pilot station, o 2. EMS pilot station - Stenbk pilot station o 3. Stenbk pilot station – Leopolddok

• Check route

• Configure ECDIS for start situation

o Range 0,5 nm o Depth contour alarm 10 m o Route monitoring on o XTD limit none o Anti Grounding searchlight set to 6 min = 1,2 nm, but keep

deactivated o AIS target display on

• Configure Radar for start situation

o Display Range 0,5 nm




of 77

o AIS Activation Range 6 nm o CPA alarm limit 0,5 nm o ARPA acquisition zone prepared in forward sector, range 6 min, but

deactivated o Chart radar on

Ship departure in Emden Waypoint 1:

• Start with manual steering

Waypoint 4: • Set radar range to 3 nm • Change to autopilot (heading control) • Activate anti-grounding search light (6 min = 1,2 nm)

After waypoint 8: • CPA alert from AIS (alert notification in Central alert management (CAM)

Conning also in Radar alert panel and ECDIS alert panel) OOW acknowledge

• Set radar range to 6 nm

After waypoint 16: • CPA alert from AIS (alert notification in Central alert management (CAM)

Conning also in Radar alert panel and ECDIS alert panel) OOW acknowledge the alert (other ship is pilot tug boat awaiting our pilot)

Waypoint 17: • Change to manual steering • Stop engine • Pilot tug comes alongside, pilot leaves • Active 2. Route on ECDIS • Set radar and ECDIS range to 12 nm • Activate collision alert (CPA < 3 nm, TCPA ) • Start engine again, continue voyage • Change to autopilot, heading control

Waypoint 18:




of 77

• Change to autopilot track control

Waypoint 19- 25 • Several CPA alerts arise from AIS, OOW evaluate and acknowledge alerts • Some radar targets are without AIS targets. OOW occasionally makes manual

radar plot for evaluation.

Shortly before Waypoint 25: • Reduce speed • Change to manual steering • Display ranges for Radar and ECDIS to 3 nm • CPA to 1 nm • CPA alert from AIS (alert notification in Central alert management (CAM)

Conning also in Radar alert panel and ECDIS alert panel) OOW acknowledge the alert (other ship is pilot tug boat awaiting with our pilot)

• Stop engine • Pilot tug comes alongside, pilot come onboard • Active 3. Route on ECDIS • Start engine

After Waypoint 25 • Change to autopilot heading control

Waypoint 33: • Activate collision alert (CPA < 1 nm, TCPA ), • Set radar range to 3 nm

Waypoint 60:

• Continuous anti-grounding alarms because of many course changes on the narrow Schelde river. OOW switches the anti-grounding searchlight off.

Waypoint 63: • OOW changes over to manual steering according to pilot recommendation.

Waypoint 75:




of 77

• Several AIS CPA alerts due to ship traffic on the river. • Change range of radar and ECDIS displays to 0,5 nm • Change CPA to 0,5 nm

Waypoint 77: • Berthing

7.2.2 Felixstowe to Ostende – collision Bridge Settings / Bridge Visualization / Bridge Alarms Preparation in Felixstowe harbour

• Plan Route in ECDIS (incl. radiuses for each WPT) consisting of 3 sections: o 1. Felixstowe Dock - Sunken pilot station, o 2. Sunken pilot station – Wandelaar pilot station o 3. Wandelaar pilot station – Oostende Dock

• Check route

• Configure ECDIS settings for start from harbor

o Range 0,75 nm o Depth contour alarm 10 m o Set ECDIS depth alarm off o Route monitoring on o WPT approach alarm to 5 min o XTD limit 0,25 nm o Anti Grounding searchlight set to 6 min = 1,2 nm o AIS target display on o ECDIS buzzer “on”

• Configure Radar settings for start from harbour

o Display Range 0,75 nm o AIS Activation Range 6 nm o CPA alarm limit 0,5 nm




of 77

o ARPA acquisition zone prepared in forward sector, range 6 min, but deactivated

o Chart radar on o Radar buzzer “on”

Ship departure from Felixstowe (Leaving Sequence) Activate manual steering, position a helmsman at the handwheel

• Start engine • Leave pier • Steer manually according to pilot instructions

Waypoint 3: • Set radar range to 1,5 nm • Change over to autopilot (heading control), helmsman on standby

Waypoint 6: • Set radar range to 3 nm • Set CPA limit to 3 nm • Set ECDIS depth alarm to 5 m • Several CPA alerts initiated by other ships that pass the fairway. Alert

notification in Central alert management (CAM) Conning also in Radar alert panel and ECDIS alert panel. Central muting, but acknowledgment only locally in the radar.

Shortly before Waypoint 14: (approaching pilot) • CPA alert from radar (pilot boat at pilot station). Also visible by binocular. • OOW acknowledges at radar display. • Change to manual steering • Reduce speed, stop engine.

Waypoint 14: • Pilot tug comes alongside, pilot leaves • Start engine (Underway) • Manual steering • After speed reached 5 kts, change over to autopilot heading control • Prepare for North Sea passage: • Select next route on ECDIS • Set ECDIS depth alarm to 10 m • Set radar range to 12 nm




of 77

• Set CPA / TCPA limit to 3 nm • Set AIS activation range to 6 nm • Activate automatic ARPA acquisition

Waypoint 14: • Helmsman serves as lookout • OOW activates track control • OOW mainly concentrates on lookout and radar

Waypoint 14-19: • Several CPA alerts arise in Radar and in CAM (conning display). OOW

evaluate and acknowledge alerts at radar display • Several radar echoes arise, without AIS indication. OOW makes manual radar

plots and finds targets not dangerous

About 1 nm after passing Waypoint 19: Collision • Radar shows AIS target of 6 nm on port bow. Position very close to

separation zone and heading vector critical.

About 2,3 nm after passing Waypoint 19: • The critical target is now 3 nm away and enters the CPA limit (dangerous

target alarm at radar and CAM). It has crossed the separation zone. • OOW calls the Captain. Captain identifies the immediate danger and calls

other ship by VHF, but too late • Captain changed to manual steering, rudder hard starboard,

but too late

Ships collided




of 77

Figure 7. A chart of the final positions of the colliding vessels

7.2.3 Felixstowe to Ostende – grounding Bridge Settings / Bridge Visualization / Bridge Alarms Preparation in Felixstowe harbour

• Plan Route in ECDIS (incl. radiuses for each WPT) consisting of 3 sections: o 1. Felixstowe Dock - Sunken pilot station, o 2. Sunken pilot station – Wandelaar pilot station o 3. Wandelaar pilot station – Oostende Dock

• Check route

• Configure ECDIS settings for start from harbor

o Range 0,75 nm o Depth contour alarm 10 m o Set ECDIS depth alarm off o Route monitoring on o WPT approach alarm to 5 min o XTD limit 0,25 nm




of 77

o Anti Grounding searchlight set to 6 min = 1,2 nm o AIS target display in ECDIS “on” o ECDIS alarm buzzer “off”

• Configure Radar settings for start from harbour

o Display Range 0,75 nm o AIS Activation Range 6 nm o CPA alarm limit 0,5 nm o ARPA acquisition zone prepared in forward sector, range 6 min, but

deactivated o Chart radar “off” o Radar alarm buzzer “off”

Ship departure from Felixstowe (Leaving Sequence) • Activate manual steering, position a helmsman at the handwheel • Start engine • Leave pier • Steer manually according to pilot instructions

Waypoint 3: (leaving harbor) • Set radar range to 1,5 nm • Change over to autopilot (heading control), helmsman on standby

Waypoint 6: • Set radar range to 3 nm • Set ECDIS depth alarm to 5 m • Change to autopilot (Heading control). Helmsman on standby • Activate anti-grounding searchlight • Several CPA alerts initiated by other ships that pass the fairway. Alert

notification in Central alert management (CAM) Conning also in Radar alert panel and ECDIS alert panel. Central muting, but acknowledgement only locally in the radar.

Shortly before Waypoint 14: (approaching pilot) • CPA alert from radar (pilot boat at pilot station). Also visible by binocular. • OOW acknowledges at radar display. • Change to manual steering • Reduce speed, stop engine.




of 77

Waypoint 14: • Pilot tug comes alongside, pilot leaves • Start engine. Underway • Manual steering • After speed reached 5 kts, change over to autopilot (heading control) • Prepare for North Sea passage: • Select next route on ECDIS • Set ECDIS depth alarm to 10 m • Set radar range to 12 nm • Set CPA / TCPA limit to 3 nm • Set AIS activation range to 12 nm • Activate automatic ARPA acquisition

Waypoint 14: • Helmsman serves as lookout • OOW mainly concentrates on lookout and radar

Waypoint 14-19: • Several CPA alerts arise in Radar and in CAM (conning display). OOW

evaluate and acknowledge alerts at radar display • Several radar echoes arise, without AIS indication. OOW makes manual radar

plots and finds targets not dangerous

5 min (1 nm) before WPT 19: Grounding • “Waypoint approach alarm” at ECDIS and at CAM (Conning Display) • Does not recognize this alarm. He is busy on the radar and does not look into

ECDIS or CAM at this moment. He can not hear the ECDIS alarm because the ECDIS alarm buzzer is switched “off”

• He hears the CAM alarm, but ignores it at the moment, there are always too many alarms on CAM

0,3 nm before WPT 19: • ECDIS warning “Wheel over point” (short beep) • OOW did not hear the warning, because buzzer is switched “off”

0,5 nm after passing WPT 19: • Alarm “XTD greater than 0,25 nm” on ECDIS and on CAM

OOW did not hear the ECDIS warning, because buzzer is switched off • He hears the CAM alarm, but there are always too many and he ignores them

for the moment




of 77

2,3 nm after passing Waypoint 19: • Anti-grounding searchlight identifies shallow water ahead.

Alarm “shallow water” on ECDIS and on CAM. • OOW still concentrates on radar and lookout. • He does not recognize the dangerous situation, as displayed on ECDIS and

CAM

4,2 nm after passing Waypoint 19: • Alarm “depth alarm” at ECDIS and CAM, initiated from Echosounder

OOW recognized the danger and stopped engine but too late

Ship run aground

Figure 8. Chart showing the grounding position

8 Generic Scenario Models in UML In order to connect real-world activities to our simulations, it is necessary to model the scenarios we have developed. The following models are written in UML and serve to start to connect WP1 to subsequent workpackages. They highlight agents,




of 77

tasks, resources, and the sequential interactions between them. Importantly, they also denote the broad classes of activity that the bridge may be in. We refer to these as situations. At the level of the whole passage they might include route preparation, leaving port, collect pilot, deposit pilot, plain sailing, manoeuvre, approach port, berthing etc. The models might look superficially similar across the 3 scenarios, and indeed they contain some common situations as expected. The differences that lead to the eventual grounding and collision are largely in the configuration of equipment during voyage phases. This is deliberate on our part because these errors are potentially reproducible in a simulator, unlike errors such as e.g. misunderstandings due to seafarers not having a common native language. There are 3 scenarios

• Full passage • Collision • Grounding

Each scenario is split into 4 modes of operation of the whole vessel (as distinct from situations that the bridge team might be in). The modes differ slightly for each scenario and are as follows: -

8.1 Normal voyage

Fig. 9 Preparation




of 77

Fig. 10 Leave Port

Fig. 11 Underway




of 77

Fig. 12 Port Approach

8.2 Collision

Fig. 13 Preparation




of 77

Fig. 14 Leave Port

Fig. 15 Underway




of 77

Fig. 16 Collision Event

8.3 Grounding

Fig. 17 Preparation




of 77

Fig. 18 Leave Port

Fig. 19 Underway




of 77

Fig. 20 Grounding Event

9 Cognitive Aspects of Scenario Selection

In CASCADe the ship bridge is seen as a cooperative system. The system has a control loop of “Perceiving”, “Evaluation”, “Decision-Making”, “Planning”, and “Action-Implementation” (see Figure ). In a cooperative system all steps in the control loop can either be performed by human operators, automated systems or a combination of both. In that case the tasks associated with the step are shared. For example, if some conditions about the value of some parameters are violated and an automated system is in charge of monitoring (i.e., perceiving & evaluating steps) these parameters, then the system should share this information with human operators (i.e., provide the information to the operators in charge with further evaluating & decision-making, next steps in the control loop). Consequently CASCADe should guarantee that the bridge works as a distributed cooperative system by distributing information in a different way than today, for example where information like alarms is distributed and given to the right person at the right time.




of 77

Figure 21: control loop of a cooperative ship bridge system

Within the control loop, the tasks “Perception” and “Evaluation” are processes which are crucial for “Decision Making”. Without being able to perceive information about the current situation operators cannot perform an appropriate evaluation. An evaluation made under wrong or missing information can lead to unqualified assumptions of the situation at hand. CASCADe tries to impede such defective conditions by taking the cooperative bridge systems’ situation awareness into account. According to Endsley (1995: 36) situation awareness is the “perception of the elements in the environment within a volume of time and space, the comprehension of their meaning and the projection of their status in the near future”.4 Baumann & Krems (2009:193) propose the “three functions of Situation Awareness” which comply with Endsley’s approach:

• Perception of the status, the attributes, and the dynamics of the relevant situation elements

• Integration of different situation elements into a holistic picture of the situation, resulting in the comprehension of the meaning of the different elements

• Anticipation of future developments of the current situation to be prepared for these developments, based on the mental representation of situation constructed

These three functions are basically cognitive and are also inherited in the control loop within the perception and evaluation processes. By executing these functions

4 http://www.cse.buffalo.edu/~peter/refs/DataFusion%5E~Learning/ endsley_1995.pdf

Decision Making

Planning

Ac0on/Imple-‐menta0on

Percep0on (Human + Machine)

Evalua0on




of 77

operators form a mental representation of the current situation. This representation is the basis for the selection of new actions and strategies, yet it is dynamically changing and is continually updated.5 Due to bridge system’s cooperative nature situation awareness needs to be considered as a cooperative function as well. Therefore CASCADe builds up on the concept of Distributed Situation Awareness (Salmon, 2007). In contrast to Situation Awareness, which focuses on individuals, Distributed Situation Awareness considers the whole bridge system. This includes Agents and Artefacts as system units and their interaction with each other and within the environment. In CASCADe Agents are human operators working on the ships bridge. Artefacts are systems which are used by Agents to perform their task. Artefacts are enabled to communicate with other Artefacts and Agents of the system. The same applies to Agents. Examples for Artefacts are radar, Alert-Systems or generally displays. Out of the Distributed Situation Awareness perspective cognition is seen as a function of the whole bridge system: Cognition is achieved through coordination between system units. Within the system cognitive processes emerge and are distributed. The Situation Awareness of the system units is an emergent property of the collaborative system. Especially collaboration enables agents and artefacts to compensate situation awareness deficits through interaction with each other. System units perform their tasks according to the three functions of Situation Awareness. Depending on individual, task, system and team factors decisions are made and actions are planned and implemented on a system-level. System units, both agents and artefacts, build up mental models containing their internal representation of the situation at a time. Furthermore CASCADe distinguishes between the actual mental model and the normative mental model. A normative mental model consists of information a specific system unit should be aware of. The content of a normative mental model is also task, system and team dependent. The actual mental model represents the information of a system unit at a specific time. The content of an actual mental model may change over time. The actual representation consists of known normative information and non-relevant information. Information that is within the normative mental model, but not covered by the actual mental model is unknown normative information. Multiple system units working on the cooperative bridge system can have the same information in their mental models. The overlap of multiple mental models is called Compatible SA (Salmon, 2009). Figure 21 illustrates the description.

5 http://link.springer.com/content/pdf/10.1007%2F978-3-642-02809-0_21




of 77

Figure 21: Distributed Situation Awareness and its mental and normative representation

For scenario selection there are some requirements to consider out of the perspective of cognitive modelling. As we see ship bridges from the cooperative system perspective, it would be important, that the selected scenarios actually cover a cooperative system including at least two seafarers on the bridge. Furthermore it should be guaranteed that in the selected scenarios the collision/grounding occurs due to insufficient situation awareness of the seafarers, i.e. that the collision occurred due to a human error (in contrast to a technical error of the radar itself). To develop cognitive models of virtual seafarers it is necessary to analyze the selected scenarios with respect to Agents and Artefacts as well as interactions between these within a task analysis. This includes also different specific bridge configurations for different operation modes of the bridge (see further Chapter 4). This would allow for task analysis to identify also the specific bridge configuration for each step: who does what, who needs which information, who communicates with whom. (Agents and Artefacts) This would afford to partition scenarios into tasks and/or steps, whereas the overall tasks of the bridge are seen as a whole cooperative system and define the roles of human and machine agents. References Baumann, M.R.K & Krems, J.K (2009) A Comprehension Based Cognitive Model of Situation Awareness, in Digital Human Modelling, Springer.




of 77

Endsley, M. R.; (1995) Toward a theory of situation awareness in dynamic systems; Human Factors; 37, pp. 32–64 Salmon, P. M.; Stanton, N. A.; Walker, G. H.; Jenkins, D. P.; (2009) Distributed Situation Awareness - Theory, Measurement and Application to Teamwork; pp. 35-56, 183-204




of 77

10 Linking Generic Scenarios to WP2, WP3

Generic scenarios from WP1 will be one of the main inputs for WP2 and WP3. In both WPs the bridge as a whole is seen as a distributed cooperative system. A system that takes information, processes it and reacts appropriately. That system will for example be modelled in functional and actual terms in T3.1 and T3.3 respectively. In WP2 we will develop cognitive seafarer models (T2.3), and develop a virtual (T2.4) and physical (T2.5) simulation platform. To link the generic scenarios of WP1 to WP2 and WP3, we will rely on a technique that segments the scenarios into disjoint sub-steps. For each step the bridge will be analysed, at the functional and actual level, in WP3, with the tools and techniques developed in WP2, including both virtual and simulation platforms. The criteria for segmenting the scenarios into disjoint steps will be directly derived from the cooperative system perspective transverse to the whole CASCADe project. The bridge as a whole is processing information and adapting in real time to current circumstances, including unexpected ones, while attempting to achieve its main goals (typically reaching the final destination). At any time, the bridge as a whole is attempting to achieve specific tasks and solving specific problems. Those "global", bridge-level tasks depend very much from the phase of the voyage for example. The global tasks in open sea differ significantly from those during berthing for example. And how these tasks are achieved on the bridge, by whom, how (i.e., how they are distributed between the different bridge agents) also significantly changes during the different phases of the voyage. Different persons become active or inactive, get different tasks or roles assigned, different information or automated systems are used. The criteria for segmenting the scenarios into disjoint steps will therefore be directly based on the notion of global, bridge-level tasks assigned to the bridge as a whole: whenever these tasks changes (e.g., because the voyage enters a new phase, because something unexpected happens on the ship, for example system or engine failure, or because something unexpected happens outside the ship, such as another vessel potentially on a collision course, or bad weather to avoid), the scenario enters a different sub-step. The scenarios will therefore be split into a finite




of 77

number of such sub-steps (typically between 5 and 10 steps per scenario) and then each step will be analysed in details in WP3. For each step we will for example determine what are the global tasks assigned to the bridge, who is active on the bridge, doing what and for which purpose (task analysis and distribution - human agents level), who's communicating with whom (communication analysis), which systems are used (human-machine interactions) and for what (task analysis and distribution - machine agents level). We will determine which information is needed by whom, as well as who needs to communicate with whom, to yield requirements for the bridge seen as a cooperative information processing system. These requirements will then be used in T3.2 and 3.4 to improve the bridge, at both the functional and actual levels. Such analysis process will be repeated in WP3 (T3.1 and T3.3) for each step of WP1's scenarios. The requirements will then be aggregated into more general requirements common or specific to the different scenarios. This will drive the ship bridge design phases in T3.2 and T3.4. To support the analysis and modelling of WP1 scenarios sub-steps in WP3, various methods, tools and techniques (MTTs) will be needed. They will be developed in WP2. Thus the requirements from these MTTs will be directly derived from the needs of WP3, themselves strongly dependent to the nature and content of WP1 scenarios. These tools will need to allow modelling and analysing the different scenario sub-steps, both in an abstract way as well as more practically on both the virtual and physical simulation platforms.

11 Seafarer Requirements BMT and Univ. Cardiff jointly visited Warsash Maritime Academy in Southampton on May 23/4th in order to support, amongst several things, some requirements gathering for the project. The visit will be described in detail elsewhere but briefly, we held 3 focus groups sessions with senior lecturers, junior cadets and intermediate level cadets. In these we talked them through several bridge scenarios and asked questions about safety related matters. In total we spoke to approximately 35 people who were extremely engaged with the CASCADe project and our ideas. All responses were recorded and are currently being transcribed for use throughout the project. We also spent time in the control room of the Warsash simulator suite where we were able to view training sessions with cadets covering pilot interaction, collision avoidance and watch handover. Finally, we showed a




of 77

video of some very early possible new tools to all participants and recorded their feedback. Some key themes emerged throughout the visit and they can be summarised in these 5 key generic requirements as follows: - Note: ‘tools’ in this table is shorthand for any bridge tools, or adaptations to existing bridge solutions, or any way of making the bridge adaptive. Requirement Explanation Importance 1. Customisable / Switchable Seafarers are known to

have preferences for colour and layout of information. Tools should support this and the easy changing from one individuals profile to another.

Highly desirable

2. Over-ride Any customised or filtered information displays must support immediate over-ride to a default state where all data is shown.

Critical

3. No extra work Using the new tools must not add to the over workload of users

Desirable

4. Not encourage extra reliance on instrumentation

The new tools must not further increase the trend of relying on bridge data instead of looking out of the window at the real world.

Critical

5. Group based explanation Tools that support dissemination of knowledge about the current situation across the whole bridge management team are welcome.

Desirable

Table 2. Seafarer requirements for an Adaptive Bridge




of 77

12 Appendix 1. Collision scenarios. The following 4 collision scenarios will be used to inspire events replicated in the bridge simulator experiments in CASCADe. They are re-phrasings of common situations found in the maritime literature. Scenario 1 – Target fixation A container ship is steering east at 10 knots, with a radar display scaled to show 5 nautical miles ahead and 2 nautical miles astern. The OOW is closely observing a group of pleasure vessels on the port side. The OOW is unaware that a bulk carrier is overtaking from his starboard quarter with a closest point of approach of 0.4 nautical miles on his starboard side. The container ship changes course to starboard to increase its distance from the trawlers. The bulk carrier does not notice this change until it is too late and the vessels collide.

Scenario 2 – Inappropriate manoeuvres Vessel A was steering northeast at 14 knots and vessel B was steering southwest at 22 knots. Both vessels were in open water and closing at full speed. Calculated from position A, the closest point of approach was 0.40 nautical miles. At position B, 4 nautical miles apart vessel A altered 5° to starboard and vessel B altered 4° to port. At position C , 2.1 nautical miles apart vessel A altered a further 5° to starboard and vessel B altered a further 8° to port. At position D, just before the collision, vessel A altered 16° to starboard vessel B altered 52° to port.




of 77

Scenario 3 – Establishing priority You are in charge of a container ship rounding a headland and approaching a waypoint for a manoeuvre to starboard. A cargo ship is approaching the headland from the opposite direction. This is position A. As you make the manouevre, the cargo ship sees your starboard aspect and alters course to port. You are unaware of its alteration and so you continue to change course to starboard to follow your passage plan. The vessels are now in position B and on collision course.

Scenario 4 – Indecision when communicating A container ship is heading northwest at 10 knots. A bulk carrier is to starboard at a distance of 4 nautical miles making a speed of 16 knots on course to pass 0.3 nautical miles ahead of you. The container ship OOW thinks this CPA is too small and at 2.5 nautical miles apart calls the bulk carrier by VHF radio to ask its




of 77

intentions. The bulk carrier watchkeeper says he will pass ahead but the container ship request that he pass astern by altering course to port. Within a few minutes the container ship calls again and insists the bulk carrier alters course to port. The watchkeeper on the bulk carrier changes his mind and begins to alter course to port and thereby puts the vessels on collision course.




of 77

13 Appendix 2. Passage Plans. Each plan is a series of 9 images showing an overview, waypoint locations and selected significant chart areas.

13.1.1 Emden to Leopoldok - normal voyage




of 77




of 77

13.1.2 Felixstowe to Ostende – collision




of 77




of 77

13.1.3 Felixstowe to Ostende – grounding This scenario is largely similar to the previous collision plan except that the vessel fails to change course at waypoint 20 and runs aground as shown below.




of 77

14 Appendix 3 Abbreviations and Definitions

Abbreviation Definition

AIS Automatic Identification System

ARPA Automatic Radar Plotting Aid

CAM Central alarm management

CCRS Consistent Common Reference System

COLREGS Collision Regulations

CPA Closest time of approach

DSA Distributed Situation Awareness

ECDIS Electronic Chart Display and Information System

EMSA European Maritime Safety Agency

ETA Estimated time of arrival

GISIS Global Integrated Shipping Information System

ICS International Chamber of Shipping

IMO International Maritime Organisation

INS Integrated Navigation System

MAIB Marine Accident & Investigation Board

MARPOL “Marine Pollution” regulations e.g. International Convention for the Prevention of Pollution From Ships

MTT Methods, techniques and tools

OOW Officer of the watch

PPI Plan Position Indicator

SA Situation Awareness

SOLAS Safety-of-life-at-sea

TCPA Time to closest time of approach

TSS Traffic Separation Scheme




of 77

VTS Vessel Traffic Service

WPT Waypoint

XTD Cross track distance

XTE Cross track error

d1.1 scenario models & adaptive bridge requirements v5 · d1.1 scenario models & adaptive...

Documents