Safety argument

False. Fireworks do cause a large number of fires and injury accidents every year. However, if the user follows the Firework Code it is possible to enjoy them with an acceptable level of safety. A non-safety argument for banning them could be made on the grounds that their use often frightens animals and annoys nearby residents. 

An evidence-based approach, without precluding the use of existing standards, is defended by [R. A. Weaver, (2003)], where arguments to reflect the contribution of software to system safety are required. The software safety arguments are based on categorization of evidence, which is largely independent of the development process. 

Once the safety argument has been constructed and documented, it is analyzed for flaws according to whatever regulatory or assessment criteria happen to be in place in the application domain (whether the system is suitable for use). To support the assessor s reasoning an Assessment Plan is to be developed and maintained, which includes a Safety Claim Structure to be completed (compare section 5 of this presentation). 

In HIT there are practical difficulties using a risk / benefit analysis as the basis for a safety argument. 

Contaminating this sound safety argument with expressions of frustration, failure to meet project milestones and product reputation can lessen the safety argument s impact. 

A key danger in the retrospective approach is to fall into the trap of conveniently building the safety argument around selective evidence which happens to be at hand. To do so runs the risk of forcing the safety case to articulate an artificially rosy picture of the world. It can be easy to assume that a much-loved system that has been in operation for many years must be intrinsically safe. That is not to say that it is unsafe but one should actively question whether the data which happens to be available can truly and objectively substantiate the safety case s claims. In some circumstances it may be appropriate to undertake the hazard assessment in a virtual vacuum of operational knowledge perhaps involving personnel who are somewhat removed from its day-to-day business. In this way appropriate controls can be developed and more objectively be tested to determine whether they can be traly validated. 

Secondly, stracture provides the reader with a means of evaluating completeness. The goal-based assessment methodology and a number of common risk assessment techniques can occasionally be criticised for their inability to clearly demonstrate completeness. A convincing safety argument may be set out based on the evident facts but how can one be reassured that all credible hazards have been considered The application of structure to an argument facilitates the reader in determining this and perhaps invites their welcome criticism. 

The hazard register contains the fundamental building blocks of the safety argument and acts as an on-going repository of CRM knowledge for stakeholders to consume. 

Controls are entities which attempt to mitigate risk and arguably form the most important component of the hazard register. Without documented controls, one would be faced with a one-sided safety argument for which the risk would be difficult to justify. 

The difficulty here is that without a logical relationship between the causes and controls, how can one ascertain that each cause has been appropriately controlled Ultimately, the reader is forced to loosely evaluate the set of causes against the controls and make a judgement on whether or not that represents a complete analysis. This can at times lead to some subjectivity with an opportunity for critics to poke holes in the safety argument. 

Clinicians tend to be remarkably resourceful in their ability to continue care delivery in the absence of information and this should not be forgotten in the evaluation of risk and the development of the safety argument. Given a lack of information a clinician might telephone his colleagues, the patient s General... 

As risk practitioners we may fool ourselves into thinking that we are all capable of setting out a rational and logical safety argument uninfluenced by softer, less objective factors. And yet, often the first step to tackling potential bias is the recognition that our decisions are always susceptible to outside influences, either consciously or subconsciously. 

Software testing is a common control in many hazard registers but for the safety argument to be valid, this must be backed up by solid test evidence. 

Writing a coherent and concise safety case is an art and requires skills that only come through experience. Structure is vital as without this it is impossible to fluently articulate the safety argument in a logical manner. It is a good idea to draft out the structure first formulating section headings which flow and tell a story. Ultimately tlie report should draw some clear conclusions on risk acceptability and make recommendations on next steps. 

In many ways the safety argument can be visualised as a hierarchy with detailed evidence at the bottom and the key claims at the top. Claims represent the ultimate goal of the safety project, simple statements that set out what it is that one is striving to achieve. For example, we may choose to claim that ... 

The evidence to support the safety argument is complex, indirect or lacks transparency... 

The power of the safety argument comes from one of objectivity rather than subjectivity. So what do these two terms mean ... 

Objectivity is often conveyed through the writing style used to document a safety argument. If one is not careful it is quite easy to communicate a completely objective assessment in a manner that appears to be, at least partly, subjective. 

The safety case should bring out the salient parts of the safety argument using narrative and description rather than be a rehash of the entire hazard register. 

The monitoring system acts during specified operation of the plant beyond the range of operational setpoints but below the tolerable fault limit. It signals permissible faulty states of the plant. There are no safety arguments for not continuing plant operation however, increased attention is necessary (assigned to level 2 of Table 4.1). 

Any safety argument must be made with reference to the system level under consideration. Therefore, by using the system levels set out in the example Fig. 1.1 ... 

Conducting a Goal Structuring Notation safety argument ... 

The GSN safety argument can be formulated by following the process summarised in Fig. 2.2 (tailored from the six-step method (Kelly, 1999)). Each step is explained in Sections 2.2.3-2.2.9. 

Figure 2.2 Formulating a Goal Stmcturing Notation safety argument.

The high-level safety argument must be developed as early as possible as it provides a clear picture of the methodology by which safety will be substantiated. If agreed with the applicable customer/authority, this argument will scope aU future safety-related... 

Kelly, T, Weaver R. The Goal Strncturing Notation - a Safety Argument Notation, Department of Compnter Science and Department of Management Studies, University of York, YOlO 5DD UK. https //www-nsers.cs.york.ac.nk/tpk/dsn2004.pdf... 

The application of GSN in the safety environment has been developed and refined by Dr Tim Kelly, whose doctoral research at the University of York focnsed upon safety argument presentation, maintenance and rense. For more information, see http //safetyengineering. wordpress.eom/2008/04/04/the-goal-shncturing-notation-gsn/. 

In Chapter 2 we defined a case study for the upgraded Attitude and Altitude Display System in which one safety argument (i.e. Strategy S7) in Fig. 2.4 looked as shown in Fig. 6.2. 

Goldsmith D, Covic A. Time to Reconsider Evidence for Anaemia Treatment (TREAT) = Essential Safety Arguments (ESA). Nephrol Dial Transplant 2010 25 (6) 1734-7. 

---