- Written by Andy
- Category: Reflections
- Hits: 1847
Management of Alarms
Alarms continue to cause problems. But I am pleased to see that most companies have started recognise the need to modify their systems to reduce the frequency of nuisance alarms during normal operations and floods of alarms when things go wrong. And it is clear that improvements are being made.
I have assisted clients with setting up their alarm rationalisation programs and procedures; and I have been teaching a one day awareness course (based on EEMUA 191). From this I have made the following observations:
- Although it makes sense to focus on alarms, having a clear definition for an ‘alert’ can be a real enabler for people to see how they can improve their system. Whether it is a fear factor or some other concern, people find it difficult to say “that alarm can be removed.” However, they are happier to say “that alarm can be converted to an alert.” Of course we need to make sure that we don’t transfer a problem with alarms to a problem with alerts. But, we have a lot more flexibility with alerts, including how they are notified. For example, we can show them on separate summary pages, direct them to non-operational teams or automatically create daily alert reports. The result is that operators are not distracted by these lesser events if they are dealing with more important situations and ‘real’ alarms.
- EEMUA 191 introduces the concept of the “safety related” alarm (ISA 18.2 refers to them as “highly managed”). I find this term a bit confusing; and I think a lot of other people have struggled to identify which of their alarms fall into this priority. The reality is that many plants/sites will not have any alarms that satisfy the EEMUA definition of “safety related” and it is not just another priority. They are alarms that fill a gap where, in an ideal world, an automated response would be provided but this is deemed inappropriate. This means that the operator response to an alarm is considered to be a layer of protection. If credit is taken for this operator response the alarm is then considered “safety related” and it needs to be handled differently from all the other process alarms. If there is an automated protection device, the associated alarms will not be “safety related” and should be prioritised in the ‘normal’ way.
- We still have some disconnect between what the guidance says about alarms and what operators want. I think this is because, over the years, we have forced people to operate on alarms because they receive so many they don’t have the time to do anything else. When we suggest that alarm rates will be significantly reduced, operators cannot image how they will operate the plant if the alarms are not telling them about every little event that occurs.
- A solution to the concerns about reduced alarm frequency is to improve the quality of graphics on our control systems. This would make events more visible so that the operator does not feel they need an alarm. I think we quickly need to start looking at alarms and graphics together, which makes sense as together they make up the Human Machine Interface (HMI).
This has been a hobby horse of mine for a while. In fact a number of people have contacted me this year having read my paper on the subject titled “process isolation – it’s more complicated than you think.”
I have had the chance to carry out task analysis for some process isolation activities during the year. This has led to some heated debate at times. Everyone is aware of the guidance from HSE (HSG 253) but is finding it difficult to apply in practice. My observations include:
- A lot of designers (and other non-operators) simply do not understand how isolations occur in practice. This was illustrated to me on a project where double block and bleed arrangements were provided. Whilst the block valves had been identified as requiring frequent access the bleeds were not and had been positioned out of reach. Clearly the designers did not recognise that the valves and bleed points were used together to form an isolation.
- It is quite common (especially on older plants) to require multiple points of isolation to perform relatively simple jobs. If every isolation needs to be proven via a bleed, there will be multiple breaks of containment to remove the blanks from each bleed point. It is not uncommon to be creating significantly more breaks of containment to prove an isolation than are involved in the job to be performed. Each break involves risk at the time of the break and on return to service. Also, it creates very high workload. Unfortunately, the guidance currently available does not provide a method of weighing up the overall risks so that sensible strategy can be selected.
- Overall, it is appears that my paper from 2013 is still very valid. The last paragraph makes the point that “companies and individuals have accepted the guidance as relevant and correct but have not checked whether they can be applied in practice and/or whether the requirements are being followed. The concern is that this creates a large disconnect between theory and practice, which could result in risks being underestimated and hence improperly controlled. The solution is not simple, but being open about when the guidance cannot be followed will at least ensure alternative methods are developed that achieve similar levels of risk control.
Human Factors in Projects
I believe it is a very positive development that human factors are now being given more consideration during the design of new process plant. I am convinced that this will result in better designs of process plant that will be easier to operate and maintain; with reduced risk of major accidents. Having been involved in quite a number of projects over recent years my observations include:
- You cannot start to consider human factors too early. There has been a perception by some people that it can only be done once a project reaches detailed design. I have never agreed with this and have been involved in two projects this year at the “Select” phase (pre-FEED). We have been very successful at identifying human factors issues that need to be addressed during the project, and by doing this early we have been able to make sure the solution is covered by the design rather than through softer controls (procedures, training and competence), which is often your only option if you do this later on.
- On the other hand, it is never too late. Whilst the preference must always be to start human factors input as early as possible, if this has not happened it is still worth doing something. Earlier this year I had to complete a human factors study on a project where the plant had already been built, although it had not been operated. By bringing together the designers, vendors and operators together to discuss the potential human factors issues we identified a significant disconnect between what the plant had been designed to do and what the operator was expecting. Whilst it was too late to change anything, at least the operator knew what they had to do before start-up instead of having to learn everything on a live plant.
- We need to be careful that human factors in projects does not become an overly bureaucratic exercise. Unfortunately, on some of my projects I seem to spend more time ‘discussing’ specific details of what a standard may require instead of working towards the optimum solution for the project. I think this occurs partly because of the way some standards are written. Also, because of a general lack of knowledge amongst project personnel about what human factors is all about. Starting early and developing integration plans that are clear, concise and focussed on developing optimum solutions are the best ways, I think, of making sure human factors makes a valuable contribution.
Task Analysis and HAZOP
I wrote a paper a little while ago saying that we needed to create better linkages between the various safety studied carried out in the process industry. My view was that we are tending to do these things in isolation and missing something as a result. As an example, I felt that there must be useful links between task analysis performed as part of human factors and HAZOP performed as part of the process safety scope. I have had the opportunity to explore this idea a number of times this year. My observations include:
- HAZOP does often identify human errors within the causes of hazardous scenarios; and also procedures or training as risk controls. As a minimum, we have to make sure that we can demonstrate that the human factors associated with these causes and controls have been addressed. Task analysis is the obvious way of doing this.
- HAZOP usually differentiates between major accidents and lesser outcomes in a systematic and defensible way. Cross referencing these with our task analyses allows us to build a stronger case for the findings of our analyses and acceptance of the subsequent recommendations. I guess it helps us change perceptions of human factors so that it is not seen so ‘abstract’ (wishy washy) and is more routed in ‘proper’ engineering.
- Building these links between task analysis and HAZOP requires human factors people to start reading HAZOP reports. This is quite an undertaking. In fact, the size of many HAZOP reports makes it impossible for anyone to seriously sit and read them from front to back. Careful use of the ‘find’ function on Word or PDF; and a clear understanding of how the report is structured around nodes can help enormously. It is still not something to be taken lightly, but I do think this is a big part of making human factors more relevant and valuable.
- There is a big variation in the quality of HAZOP reports. One of the main problems is when similar issues are dealt with inconsistently throughout the report. The software available to assist with HAZOP seems to be starting to help in this regard. I don’t think there is much benefit in human factors people sitting through full HAZOPs, but they can work with the HAZOP leader at the start of study to make sure there is a common understanding of what needs to be done to improve the links between HAZOP and human factors (particularly task analysis).
I have had shift handover on my agenda for many years, ever since I studied the Piper Alpha accident as part of my PhD. I have been generally disappointed that industry has not taken the issue more seriously, especially as it has been cited as making a contribution to several other major accidents. I have suspected that it has generally fallen into the ‘too difficult’ category, largely because it is totally reliant on the behaviours of the people involved. However, I have worked with one of my clients this year to improve their procedures for shift handover and in developing a short training course and presenting it to shift teams. My observations from this include:
- Communication at shift handover is far more difficult than most people think it is; and most people are not nearly as good at communicating as they think they are. The circumstances surrounding shift handover create particular challenges. In particular, the person finishing their shift will have just finished working 8 or 12 hours and is understandably keen to get home. However, the person receiving the handover, and who needs the information, does not know what they don’t know. Neither of these is conducive to effective communication.
- Individual personalities make a big difference. The shift teams I spoke to all complained about colleagues who gave poor handovers or did not appear interested when receiving a handover. It is easy to get in to a ‘why bother’ frame of mind in these circumstances. But it was clear that people were often reluctant to challenge their colleagues because they did not want to create any tension given that they had to work together. I believe in a number of these cases the individuals involved had not realised that their behaviour was so critical simply because no one had ever told them.
- Preparation for the handover is absolutely crucial, and time has to be made available to do this well. Management has a very important role in making sure they communicate very clearly that this is a critical part of a shift worker’s job. Also, by making sure they do not ask for (or expect without asking) things to be done towards the end of shift that will limit the time available to prepare.
- A well-structured log sheet and end of shift handover report can make a great difference to the quality of shift handover. I am surprised at how many companies are using blank pieces of paper for these. Also, how many only use a chronological log or end of shift report during handover; as these two documents perform different purposes and are both needed. There is software available that can support shift handover, but it is of no value if the appropriate systems and behaviours are not in place.
I showed a couple of videos on the shift handover courses. The look on some of the operators’ faces and the “oh sh*t – that could have been us” comments highlighted to me that we all become complacent to risk. It is a natural human reaction and coping strategy. This is why we have to keep working to reduce risks, and I am sure that human factors working more closely with other elements of process safety provides us with the means of driving improvement
Page 2 of 2