Changed rules for alert management on the bridge

Transcription

1 Changed rules for alert management on the bridge P.G.M. van der Klugt, PhD, MSc Imtech Marine Netherlands BV, NL S.M. Kransse, BSc Imtech Marine Netherlands BV, NL; chair NEC80 SYNOPSIS July 1 st, 2014, Resolution MSC.302(87) on the performance standard for Bridge Alert Management (BAM) has entered into force. This standard addresses the need to, quote, harmonize the priority, classification, handling, distribution and presentation of alerts, to enable the bridge team to devote full attention to the safe operation of the ship and to immediately identify any alert situation requiring action to maintain the safe operation of the ship. The 11 th amendment of the Marine Equipment Directive makes MSC.302(87) mandatory for all navigation equipment as per April 30 th, Also in 2014, IEC TC80 workgroup PT62923 on BAM started to transform MSC.302(87) into a generic test standard for bridge equipment. This paper discusses both properties of BAM and consequences for the design and integration of bridge equipment (including ship automation equipment with extensions on the bridge). In addition, it gives a preliminary, insider s, view on the creation of the future generic test standard for BAM equipment and as such a better understanding on what BAM compliancy is about and guidance on how to apply BAM. INTRODUCTION Today s high-end ships are characterised by the many automation systems that intend to make life easier for the mariner. Where manual steering was the norm on most naval ships in the eighties of the previous century, few ships today sail without an autopilot; some advanced versions are even able to sail the ship autonomously from port to port over a planned route. For the navigator, the Integrated Bridge has become familiar technology just like many engineers have learned to use platform automation systems. The main idea behind such automation systems is that by bringing information and controls to one central operator workstation, the resulting better system overview will allow a single operator to do multiple tasks more efficiently and better than several operators that have to address individual workstations without such a centralised overview. While that may be true in normal conditions, in case of equipment problems the drawbacks become quickly apparent: More integration implies more problem causes (IT components themselves are a potential source of problems) and a larger chance on many alarms simultaneously. With the increasing amount of software, it becomes easier to monitor many variables, which increases the amount of alerts because it is possible. Important alarms can be hidden in long alarm lists on alarm displays and, after a time of many spurious alarms, an operator may even fail to identify there is a serious problem. Potential interaction between systems may also lead to complex relations between problem cause, problem consequences and associated alarms, making it difficult for the operator to identify the real problem and determine the action to take. The consequences are apparent on bridges of modern ships. Integrated in Integrated Bridge System does not necessarily imply a wide standardisation of visual and audible alarm indications nor minimizing the number of alarms; a single problem can cause multiple alarms from multiple different locations with different visual and Authors Biographies Dr.Ir. Peter van der Klugt has been employed by Imtech Marine Netherlands BV since 1982, presently as Sr. Consultant Innovation & Knowledge Management at Imtech Marine Netherlands BV to initiate and execute the development of high-end ship automation systems such as Rudder-roll stabilization, Dynamic Positioning, Integrated Bridge, Propulsion Control, etc. He is/was member of various IEC-TC80 working groups. Ing. Steven Kransse, a trained mariner, has been employed by Imtech Marine Netherlands BV since 2000, initially as Product Manager ECDIS and assistant Product Manager UniMACS Digital Bridge Systems. Since 2007 he is responsible for product certification and for application of the Marine Equipment Directive. He is appointed chairman of Dutch National Committee 80 on Maritime Navigation and Radio-communication Equipment and Systems and member of various IEC-TC80/ISO-TC8 working groups.

2 audible properties and varying information. It is up to the navigator to identify first the alarm of the highest priority, 2 nd the actual cause and/or the source and 3 rd to identify how best to act. He eventually experiences many alarms as spurious, e.g. because very-often occurring, because a system is not in use, because his ship is moored, because of redundancy and because of many other reasons that cause an alert to actually be of lowpriority. Even worse, he may endanger his ship when he starts to assume that most alarms are spurious alarms, even those alerts that actually require action. The same can be said for the engineer; while crew fatigue is the root cause of most human errors, spurious engine alerts are a potentially dangerous reason to wake him up at night. Of course, these problems can also be experienced on ships with little integration. However, one may expect, rightfully so, that a more modern, integrated, system will meet higher standards on alerting than a conventional collection of stand-alone equipment. Integration enables equipment to share information and thus to come with advice to the bridge team that goes beyond the local knowledge of a single piece of equipment; better advice will help the bridge team to recognise faster how to respond to potentially dangerous situations. Resolution MSC.302(87) on the performance standard of Bridge Alert Management (BAM) recognizes, quote, the need to prepare performance standards harmonizing the priority, classification, handling, distribution and presentation of alerts, to enable the bridge team to devote full attention to the safe operation of the ship and to immediately identify any alert situation requiring action to maintain the safe operation of the ship, unquote. The critical words in this quote are operation, identify and action : the presentation of an alert should already give guidance to the best mitigating operational action. In addition, this resolution poses performance standards that, quote, should apply for all alerts presented on, and transferred to, the bridge, unquote. Moreover, this resolution applies for, quote, relevant equipment on the bridge presenting alerts, unquote. Simply put, ALL bridge equipment that may present alerts has to comply with this standard as of 1 July Whether the alerts originate in emergency systems, navigation systems or machinery systems, if alerts are presented to the bridge team they have to comply with this standard. As the extensions of machinery systems to the bridge are affected, eventually this may well cause all ship equipment that may present alerts to eventually follow the lead of the BAM standard. This is at least true for SOLAS ships, but also for naval ships that are expected to comply with civil/class rules or that want to improve their performance. The first sign of that is already there; the new Code on Alerts and Indicators using the BAM alert definitions. At the moment of writing this paper, there is no generic IEC test standard that specifies how to test the BAM compliancy of bridge equipment. IEC (on Integrated Navigation Systems) has been the first performance standard to give guidance how to meet the MSC.302(87) requirements on BAM. Other individual equipment standards (on ECDIS, Trackpilot, RADAR, etc.) have been modified using that guidance and others will soon follow. However, IEC is limited to INS functionality; it covers only a subset of the equipment that may be found on a modern bridge. IEC TC80 Workgroup PT62923 on BAM intends to close that gap and to give testable guidance for ALL equipment on the bridge, while being suitable for use all over the vessel (i.e. taking into account ref. [3] and the use of alert Category C ). This paper discusses a variety of properties of BAM such as the inherent task-oriented approach and the consequences of causing task-oriented alerts rather than symptom alarms. It uses inside knowledge of TC80 Workgroup PT62923 on BAM to give preliminary guidance on BAM-compliancy and on how to deal with non- BAM compliant components encountered in case of a retrofit with a, BAM-compliant, Central Alert Management (CAM) system.

3 BAM AS RESOLVER OF ALERT MANAGEMENT PROBLEMS In a bridge environment, the navigator may be confronted with many different alarm sounds and messages coming from different places: different manufacturers have different ways to announce and to display alarms. The priority of an alarm is often determined by how annoying the sound is; it is not always clear to the operator how/where and in what order to act on alarms. So, let us see how some of the properties of BAM contribute to resolve these problems. Priority of an alert First of all it should be mentioned, that the A in BAM is about Alerts and not about Alarms. BAM [1] identifies 4 Alert priorities to indicate to the operator the relevance of an alert i.e. indicating how quickly action is required.with that, BAM intends to help the operator to achieve as quickly as possible a proper understanding of the situation and the corresponding action: 1. Emergency alarm (highest priority), indicates that immediate danger to human life or to the ship and its machinery exists and that immediate action must to be taken by the bridge team. An emergency alarm should give guidance such that the bridge team can recognise, and act on, the danger immediately. 2. Alarm (priority high), indicates either conditions requiring immediate attention and action by the bridge team to avoid any kind of hazardous situation and to maintain the safe operation of the ship. An alarm should give guidance such that the bridge team can recognise, and act on, the situation immediately, before it could become any worse. 3. Warning (priority medium), indicates a condition or situation that requires immediate attention for precautionary reasons (without requiring immediate action), to make the bridge team aware of conditions which are not immediately hazardous, but may become so if no action is taken. A warning should give guidance such that the bridge team, once it has finished activities with a higher priority, can quickly recognise the potentially hazardous situation as well as the best course of action. 4. Caution (lowest priority), indicates necessary awareness of a condition which does not warrant an alarm or warning condition, but that still requires attention for an out of the ordinary consideration of the situation or of given information by the bridge team but that does neither warrant immediate attention, nor immediate action. There may be reasons for the operator not to give immediate attention to new alerts. For that reason, BAM includes provisions to temporarily silence all active alert sounds on the bridge by means of a single silence command via a CAM-HMI if installed (except that of the emergency sound, see also [3]). However, an individual equipment standard may specify conditions where a further delay is no longer acceptable and where another silence command should be ignored. Also important to notice is that the priority of alerts may depend on operational conditions. Alerts that have priority Alarm when the ship is sailing may have a lower priority when the ship is moored. Alerts of equipment that has been switched off will even disappear from the bridge. Finally, one should be aware that the benefits of BAM will be achieved only if all potential alerts on a bridge have the proper priority and guidance. Too many alarms on a bridge is a sure sign that either the operator has set his system to be too vigilant (e.g. RADAR monitors a large area while in dense traffic conditions) or that the system design does not properly cope with all operational conditions (e.g. minimum monitor area of ECDIS too large for river conditions). Category of an Alert For some type of problems, a simple line of text suffices to assess the situation and to know what should be done. Such alerts may be reported on, and handled from, a Central Alert Management Human-Machine Interface (CAM-HMI). For other alerts contextual information is necessary to decide upon what to do. Such alerts can only be handled from a display that has the required contextual information. Also machinery alerts (alerts not generated by bridge equipment) have special properties. It is a type of alert that is important for a navigator as it informs him of operational restrictions while the navigator (bridge operator) cannot deal with the alert himself. It is the responsibility of the engineer supervising the machinery generating the alert to acknowledge such an alert. To inform an operator on how and where he could/should address a specific alert, BAM distinguishes 3 alert categories:

4 1. Category A alerts are specified [1] as alerts where information at a task station directly assigned to the function generating the alert is necessary, as decision support for the evaluation of the alert-related condition. As these alerts require contextual information, only systems that provide that information should cause sound to attract the operators attention and should have provisions to acknowledge the alert. Additionally, BAM allows visual presentation of the alert (e.g. for a complete alert history presentation) and a silence all function (to gain clear thinking time). 2. Category B alerts are specified [1] as alerts where no additional information for decision support is necessary besides the information which can be presented at the CAM-HMI. Therefore, there may be more than one place that generates sound, indicating it has adequate information and provisions for the user to acknowledge the alert on that place device. 3. Category C alerts are specified [1] as alerts that cannot be acknowledged on the bridge but for which information is required about the status and treatment of the alerts. Within BAM, this, for the bridge cluster, is mainly about engineering-cluster alerts. Like with Category B alerts, there may be more than one place to generate sound. However, the bridge operator can only silence the sound and depends on his engineering counterpart to address the problem and acknowledge the alert. BAM demands alerts giving operator guidance Audible alerts are annoying only when the bridge team perceives that they are not as important as they sound, or incorrect/false. However, even when a manufacturer has followed the rules with respect to priority, he cannot know the conditions of the ship when his system identifies a problem so he is forced to select a priority suited for the worst case. The test standard on BAM currently in development will help by introducing methods that effectively reduce the number of high-priority alerts reported to the operator. It goes beyond the requirements posed in [2] as it takes into account ALL equipment on the bridge that is a potential source of alerts. With route monitoring, collision avoidance and alert management, [2] introduced a task-oriented approach as alternative for the conventional system approach with ECDIS, RADAR and Alarm system. A task-oriented approach appears to be a good starting point to define alerts that give good operator guidance. [1] takes this up and specifies that aids for decision making should be added to each alert. Implicitly, [1] assumes that alerts are always associated to a task given by the operator to the system; thus in principle an alert should be regarded as a defined system response to the operator to inform him about a problem experienced by the system while conducting that task. This translates for the alert priorities as: Priority Caution: the system notices something peculiar with respect to a task, something that should be brought to the attention of the operator, but that doesn t substantially affect the functioning of the delegated task. Priority Warning: the system detects that there is something going on that may affect the task in a negative manner, something the operator should know about and that may escalate when not attended to. Priority Alarm: the system determines that it can no longer execute the task and that the operator has to select another mode of operation. Priority Emergency Alarm: the system detects a condition with immediate danger for human life on which the operator needs to act immediately. There is only one additional reason for the system to generate an alert and that is in case some operational condition comes true and the operator (or legislation on his behalf) has demanded the system to generate an alert (Caution, Warning or (Emergency) Alarm) as soon as that condition becomes true (e.g. cross-track error or heading deviation larger than a certain limit, (T)CPA limits crossed, etc., fire detector activated). Associating alerts with some operator task delegated to a system, or with a condition defined by that operator in support of his task, has an important advantage; it makes it much easier to define an appropriate alert message (title and text) to the operator, one that gives guidance on how to act. An operator, in his role, isn t interested in the cause or the solution, at least not at first. Rather he is interested in the effect and in how to deal with the problem operationally).

5 TESTING FOR BAM COMPLIANCY Bridge Alert Management (BAM) is not a system; rather it is a concept to properly inform a navigator when systems experience problems. A Central Alert Management (CAM) system is the (optional) part of the concept to monitor all bridge alerts from a common (central) position at the bridge of the ship; a CAM system provides the functionality to manage all allowed alerts from that single position. Fig. 1 BAM concept Figure 2 is a generic representation of the BAM concept. It depicts: a hierarchy of 3 (groups) of BAM-compliant equipment where equipment of the second and third group can evaluate (one of the means introduced in [2] to reduce high-priority alerts) inputs in order to reduce the priority of alerts that are reported to the operator responsible. Such equipment may range from simple equipment (with a single HMI), to complex equipment (with multiple HMI s); a BAM-compliant CAM system. It has at least one HMI with acknowledge and central silencing provisions. It contains a database to maintain an alert history to be shown on demand; a BAM-compliant VDR, as individual equipment may have to be able to provide alert information to a VDR for storage; IEC and IEC interfaces to transmit BAM-compliant messages. For BAM compliancy, equipment should use at least one type of these interfaces. A BAM-compliant CAM-system should support both; characters A-D referring to modules of the BAM standard under development; inputs and functionality to handle inputs from legacy sources i.e. sources that cause alerts but that cannot comply BAM. This functionality is optional for BAM-compliant equipment but mandatory for application of legacy sources on the bridge so at least one BAM-compliant system on a bridge should have such functionality (e.g. the CAM system). From this figure, one may deduce that there are 4 types of BAM-compliant equipment, each demanding a different test-set up when testing for BAM-compliancy. However, it is better to see the figure as merely giving guidance on how to devise a test-setup for any (set of) equipment that has to be tested for BAM-compliancy. The figure also indicates how BAM intends to interface with legacy alert sources for retrofit purposes: in principle, any BAM-compliant equipment may have conversion modules that transform alerts from legacy alert sources to BAM-compliant alerts. This transformation includes alert classification (priority and category) and the management of the state of a (BAM-compliant) alert that will replace the (not BAM-compliant) alert of the legacy alert source.

6 BAM IMPLEMENTATION EXAMPLE A manufacturer of e.g. a heading sensor like a Gyro does not know how other systems deal with its output in case of some encountered problem. As a consequence, a gyro failure may cause alarms both by this sensor and also by its users (Heading Control System, ECDIS, Radar, etc.). Implementing BAM could reduce the audible alerts as will be shown by the example of a ship control system shown in the figure to the right. The figure depicts a steering wheel that allows the operator to manually steer the ship, an ECDIS using two heading sources, one as backup of the other, a HCS that can be asked to automatically steer the ship, that has functionality to optimally derive the best heading from multiple heading sources, and that applies a dry contact to indicate system down, three heading sensors that provide heading information of different qualities and a Follow-Up Control system that can be ordered by 2 different sources (HCS and Steering wheel) to realise a desired rudder position. Fig. 2 Redundant autopilot configuration Subsequently, four conditions will be regarded to compare a bridge with all BAM-compliant equipment (including CAM system and including functionality that evaluates alerts) and a bridge with conventional equipment. Condition 1: the ship is not sailing With the indicated systems powered down, there still will be the alarm on the bridge indicating that the HCS is down. In the conventional situation, even when the ship is moored and systems are electrically switched off or in standby, there will be alerts. Condition 2: the ship is sailing in manual control, gyro 1 fails The operator executes heading control using the wheel and the HCS is standby. He demands one sensor to give the heading, he uses another one to validate the first one and he delegates the task positioning of the rudder to the Follow-Up Control (FUC) system. A problem in a gyro 1 will be regarded as an operational problem by each of the users of that gyro including (in case of manual steering) the operator. In case such a problem, Gyro 1 sensor will report an alarm to the operator. This is by design, as the gyro does not know how systems and operator should deal with a gyro problem and a gyro manufacturer feels forced to assume the worse-case (i.e. only one gyro available and it is essential for manual steering). Each additional sensor that fails will cause an additional alarm. Systems that require the gyro input (HCS and ECDIS) cause also an alert as soon as they recognise the gyro problem. For such systems too, the manufacturer usually assumes a worse-case operational situation (the operator has to be alerted about a potential jump in the heading or a serious loss of quality) and chooses the priority Alarm. Each alarm has to be handled (acknowledged) at the source and each additional sensor that fails will at least cause one additional alarm Condition 3: the ship is sailing in automatic control, gyro 1 fails There is no difference with the previous situation. At best, the HCS reports a slightly different alarm if it distinguishes between being active and being standby. Condition 4: the ship is sailing in automatic control, gyro 1 has failed, and the compass fails also The compass failure will result in another alarm. ECDIS has no heading input left; it will report one alarm indicating the loss of the last heading input and possible others, e.g. about the loss of functionality. HCS likely will report a new alarm about the missing input and possibly another one indicating that the integrity of the remaining heading input cannot be checked. Again, each alarm has to be handled at the source.

7 BAM will change this, amongst others by prioritising alerts and by demanding aids for decision support. A further means is the principle of responsibility transfer, first technically/practically introduced in [2]. This principle resembles an automatic acknowledgement of audible alerts of an alert source by a system with more operational knowledge while that system gives another alert better suited for the bridge team (usually of a lower priority). This mechanism origins from BAM requirements formally introduced by [1], when referring to functionality to reduce the number of high-priority alerts, and has been fully implemented in [2] (to be used as option). Applying BAM, with the strict application of the various alert definitions and with the installation of a BAM-compliant CAM-system will, together with this principle and the principle of removing alerts from functions not in use, result in behaviour that may change with the operational conditions: Condition 1: the ship is not sailing BAM compliancy implies that a bridge will be mostly (and in case all equipment has been switched off, completely) quiet and it does so automatically. Condition 2: the ship is sailing in manual control, gyro 1 fails Assuming there is no system active that evaluates the loss of gyro 1 (HCS, in this example having such functionality, is in standby), Gyro 1 will report an alarm. BAM implies that the ECDIS gives at most an alert of priority Caution and that the HCS gives an alert of priority Caution (indicating a loss of heading input). All alerts can be handled at the CAM-HMI and BAM-compliancy implies that the presentation helps the operator what to address first (in this simple example, the acknowledgement of gyro 1). Condition 3: the ship is sailing in automatic heading control, gyro 1 fails From a task-oriented perspective, the operator has delegated the task Heading control to the Heading Control System, and in this example that HCS has functionality to evaluate heading sensors. In return, the HCS has delegated the task positioning of the rudder to the FUC system. As soon as Gyro 1 fails and raises an alarm, HCS will evaluate the situation, recognise that it has sufficient knowledge to decide that the problem does not warrant an alarm and requests Gyro 1 to transfer the responsibility. It will report a Caution to the bridge team regarding the consequences of the sensor problem. Assuming that Gyro 1 supports the mechanism, Gyro 1 changes the state of the alert to responsibility transferred and will report this alarm state. This state does not warrant presentation accompanied by audible or visible (flashing) means to attract the attention of the operator. With respect to ECDIS, this is similar as in condition 2 (indication only or a Caution). Condition 4: the ship is sailing in automatic heading control, gyro 1 has failed, and the compass fails also Like in the previous condition, the sensor, in this case the Compass, starts raising an alarm. However, the HCS will evaluate the situation and recognise that it has sufficient knowledge to decide that the problem does not warrant an alarm, but that it affects the possibility to check the integrity of the remaining sensor. It request the Compass to transfer the responsibility and that will adjust the state of its alert. The HCS reports a Warning as alternative to indicate the consequences of the sensor problem. ECDIS, having no heading input left, will report a Warning to indicate that it has no valid heading input left and that it has lost some functionality. The following table summarises the results of the comparison Conventional BAM-compliant + CAM-HMI + revaluation Alarm alarm warning caution (Sensors+ECDIS+HCS) Condition Condition /1+1 Condition * /1+1 Condition * Table 1 Comparing conventional and BAM-compliant conditions Off course, the exact behaviour on alerts of components like a conventional ECDIS and HCS will depend on, amongst others, the version of the individual equipment standard against which they have been certified and choices made by the manufacturer. However, such difference will not seriously affect the following conclusions with respect to application of BAM. 1. One should not assume that BAM will reduce the number of alerts; it reduces the number of high-priority alerts. In this example, that goes from 6 alarms that have to be acknowledged each to only one warning that has to be acknowledged.

8 2. The advantages of BAM in particular become apparent when installing an (optional) CAM system and when applying the (optional) mechanism of responsibility transfer. The first will bring a central HMI for managing most alerts (the exceptions are the alerts that demand additional information on the display e.g. alerts about dangerous targets). The other is a powerful mechanism to reduce the presentation of audible alert states. 3. Additional benefits have to do with how and where alerts are actually presented, the attention for a proper selection of priority and category, the principle of aggregation to reduce the number of displayed alerts of the same kind, and more. MACHINERY AUTOMATION BAM introduces Category C alerts as machinery alerts that give essential information for the task navigational control, but for which the bridge team is not responsible. The bridge team can silence such alerts, but cannot acknowledge such alerts nor resolve the underlying problems. Category C alerts are provided to enable a system to provide operationally necessary alert information to another cluster (examples of clusters are engineering, bridge, dredging, combat, etc.), whilst not bothering the user from the other cluster with resolution of an alert for which he cannot control the source. With naming the possibility of clusters, IMO has set the stage for the use of BAM in other domains besides the bridge of a ship. Engineers in the machinery control room are responsible on board for the engineering cluster. They will be provided with the source alerts and they are expected to address the problems. On most ships, they perform their work not at the bridge. However, many (modern) vessels have an AMCS extension on the bridge and BAMcompliancy is a requirement for that extension too. If that serves only to provide Category C alerts to the navigator, the impact of BAM on the underlying machinery automation will be limited. However, a full monitoring & control extension with provisions to handle (e.g. acknowledge) machinery alerts may change that completely. Unless ship owners have reasons to oppose that, modern ship designs are likely to gradually follow the path previously gone by aircraft designs. On this path, the bridge is becoming THE control centre of the ship, also for monitoring & control of the ship s machinery systems. As a consequence, engineers and navigators will have to merge to a single bridge team responsible for all. Today, there are ships sailing with machinery monitoring & control at the bridge, with dredging monitoring & control at the bridge and with a combat bridge. As BAM does not exempt any system presenting alerts on the bridge, this change will have consequences also for such systems with extensions to the bridge and thus more in general for monitoring & control of machinery systems: eventually these have to comply with BAM requirements. That warrants the question is that a good thing or a bad thing? With respect to monitoring of control of machinery systems, is there (freely interpreting MSC.302(87)) a need to harmonize the priority, classification, handling, distribution and presentation of alerts, to enable the engineers to devote full attention to the safe operation of the machinery systems and to immediately identify any alert situation requiring action to maintain the safe operation of the machinery system?. The answer is apparent from the figure 3.

9 Fig. 3 Alarm screen examples One has only to conduct a quick Internet search or to talk with a ship s engineer with experience on different ships to find the answer to be yes. Yes, for the ship s engineer there is certainly a need, even more so than for a mariner working in the bridge domain. For the mariner, BAM will force a development for the better, in particular for those situations where a simple problem causes a waterfall of other problems and where there is need to identify the most important problem first and determine the proper cause and associated action. Some of the worst consequences of the tendency to reduce manning levels (the lack of time to think in complex situations, the fatigue caused by machinery alarms that unnecessarily call a mariner when he was allowed to sleep) will be mitigated. This certainly will have a positive impact on the number of human-error related incidents. Manufacturers of ship equipment, in particular integrators providing extensive monitoring & control functionality, probably have a different opinion. They usually provide solutions that report any detected symptom to the operator of his system and that rely on that operator to let him ponder on the consequences and, if necessary, take action. Systems give alarms because a temperature is high, the pressure over an oil filter is high, a generator trips, a network load is high, etc. Only training and experience gives an operator insight in how important the alarm is, how fast he has to respond and what the appropriate action is. But even the most experienced operator has a serious problem to quickly find the root cause of a problem on displays flooded with alarms. BAM forces manufacturers of bridge equipment to define alerts using a task-oriented approach. Applying BAM principles fill force manufacturers of machinery equipment towards the same (difficult) path. The facts that the variety of machinery systems is much larger than the variety of bridge systems and that manufacturers are so used to the freedom allowed by minimum equipment standards make their plight not any easier (not that their systems are so bad, but from the perspective of the end user, they are often so different). But the most difficult challenge to overcome is that designers need a thorough operational understanding of the context in which their system is used. Rather than reporting a problem to the operator and letting him think about what to do, their system has to be able to deal with the consequences and alert the operator with implicit advice on how, and how fast, to act. Once a proper alert has been defined, the other BAM aspects are relatively easy. They are mainly about standardisation of communication between equipment and of presentation of alerts. Human error, and not operator error, is at the root of most fatigue-related incidents encountered on board of ships. Manufacturers should take responsibility for how problems detected by their systems are resolved and no longer claim that their responsibility stops after having alerted the operator of a symptom.

10 CONCLUSIONS Introducing BAM in bridge automation has the potential to be a great relief for the navigator if properly applied to its full extend. The bridge becomes quieter: there will be fewer (if any) high-priority alarms that will have to be immediately regarded by the bridge team. BAM-compliancy implies that equipment manufacturers have to reconsider their systems response to encountered problems. Just by selecting the proper priority, they will improve the conditions on the bridge of the ship: quieter, no unnecessary audible annunciation of alerts. The second improvement introduced by BAM has to do with standardisation of alert sound and of alert state presentation to support a quick recognition of the importance of an alert; BAM-compliancy includes requirements that enable systems to indicate clearly which problems to handle first, and even at which operator position. Evaluation (by systems with more knowledge than the source of an alert) and a task-oriented approach (to define alerts and alert information) are further options to give the operator guidance rather than an overview of problems. It is correct to regard human error as being at the root of most incidents encountered on board of ships. However, one should not confuse human error with operator error. More often than not, human made system designs are flawed such that a system fails to give a proper, quick and usable assessment of a hazardous situation; the error was already made while designing the system. Manufacturers should take responsibility for how problems detected by their systems are handled by their systems. They should no longer claim that their responsibility stops after having alerted the operator about a symptom. They should embrace BAM with all its possibilities and use that as guidance for how their own systems should deal with problems. The reasons to implement BAM on the bridge of a ship are equally true for the engineering domain, as already initiated by IMO in [3] and [1]. There is no reason why application of the ideas of BAM should not bring similar improvements in that other domain, or in other clusters. The presented principle scheme (Figure 1) can be regarded by manufacturers of bridge equipment as a first guidance on what BAM is and on how BAM-compliancy could be tested in the future. However, it will take time before IEC TC80 workgroup PT62923 on BAM will have concluded their work. In the meantime, one may use Ref. [2] (Module C and the associated Annexes) for some preliminary guidance about presentation and handling of alerts and about alert communication. REFERENCES 1. IMO Resolution MSC.302(87), Adoption of performance standards for Bridge Alert Management ( ), with Annex Performance standards for Bridge Alert Management. 2. IEC , Maritime navigation and radiocommunication equipment and systems - Integrated navigation systems - Part 2: Modular structure for INS - Operational and performance requirements, methods of testing and required test results (2012). 3. IMO Resolution A.1021(26), Code on Alerts and Indicators ( ).