Setting a Safety Boundary

Setting a Safety Boundary What is a Safety Boundary? The safety boundary defines all the processes, products and people that are going to be part of the safety analyses. This section will contain many of the assumptions about the system – how it operates, who uses it, where it will be used etc. The boundary of the things that may need protection from harm extends from a person, or groups of persons, to the local buildings, nationally or even throughout the world, to the natural environment, to information and public image, and to equipment and production output. All these things may be described as being 'valuable assets'. It is essential to gain customer agreement on the boundary around the system, information, equipment and personnel to be included in, and excluded from the safety work. The interfaces with neighbouring systems and platforms will need to be acknowledged, as these will certainly effect your item of interest. This agreement should be recorded in the safety case report. Specific scenarios and general ways in which the item will be operated can be used to give a richer picture for the safety assessment, again these should be agreed up front – they may even be specified for you. Any limitations of the safety assessment must be clearly stated, for example, areas where there is unclear information, limited experience or where operating conditions have not been assessed. Historical Incident [Wears 2005] As detailed in a case study on automation, complexity and failure from the department of emergency medicine at the University of Florida, an incident occurred causing great debate concerning system boundary. The incident was a patient needing emergency medication from an automated dispensing unit which had a number of software controlled safety interlocks. By coincidence on the day that the patient was rushed to the emergency room, the software interlocks were being re-enabled after a software upgrade process. This caused a storm of messages (one message for each medicine type) which slowed the system response to the extent of a complete stop. The human operators eventually were able to interpret the interface of the software and identify the failure mode, even though the screen message was unhelpful as “Printer not available”. Runners were used to obtain the required drugs for the patient, and others were sourced from return bins next to the dispensing units. The capture and correction of the problem did take time, it was due to human

problem solving capabilities and a fortunate set of medical circumstances, that catastrophe was averted. The medical practitioners that had to work through this stressful situation were very critical of the reliability and safety of the system because the patient had nearly been lost. Hospital managers, who had the responsibility for purchasing the software system and hiring the staff, were full of praise for the system because the patient had been saved. The medical staff were considering the reliability of the system excluding themselves, and with that as the safety boundary, many would agree to its apparent unreliability and lack of safety. The managerial staff were looking at both components of the system being inside the boundary, and as such, many might also agree to its apparent safety and reliability. It should be noted from the above example, that in neither boundary situation was it expressly said where the patient was considered to be either inside or outside of the system. You might have the opinion that for the purposes of assessing the drug dispensing system, the patient need not be considered at all. This is reasonably sensible, but how many of you would have even thought about the position of the patient, without this note being here ? Deriving the Safety Boundary In order for the safety case and the safety management system to exist, there has to be something or some system in place that has an amount of risk associated with it. For the safety case and safety management system to be effective, the ‘thing’ has to be defined. There is no prescribed methodology for deriving or defining the extent or content of a safety boundary, I am afraid it has to be figured out for each entity under consideration. However techniques such as Problem Frames can be very helpful in explicitly identifying domains and interdependencies between them to help define and communicate the safety boundary. Sometimes it may be more obvious, for example when the entity is a new product being developed, or a new assembly line or manufacturing process. However, the boundaries always throw up a number of concerns that do need to be settled early on in the safety process. A series of questions can help – even just to get the thinking process working correctly. The first question you should ask concerns the level of the entity you are considering, is it a small component, a self-contained item, or the whole business stream? The question is this; 1. Is this thing a SYSTEM, SUB-SYSTEM or SUPER SYSTEM? This may seem a trivial question, but the answer has ramifications to the whole safety process. The larger the entity under consideration, the more effort (and therefore resources – time, people and money) are going to be necessary. Alternatively, if the resource is fixed, then the size of the project dictates how thinly those resources are going to be spread. The two next questions are equally fundamental to the safety analysis of the entity.