Safety case risk analysis

Risk Analysis Another group of methods used in system safety involve risk analysis. In many cases, the hazards are charted into a risk decision table or risk assessment matrix (see Figure 6.5). The severity of hazards is rated and charted on one axis of the chart. The probability of occurrence is on the other axis. Then severity-probability cells are marked for the kind of action required, such as risk reduction required, management approval, or that the operation is permissible. 

A complete analysis of dense gas dispersion is much beyond the scope of this treatise. More detailed references are available (Britter and McQuaid, Workbook on the Dispersion of Dense Gases, Health and Safety Executive Report No. 17/1988, England, 1988 Lees, 1986, pp. 455 61 Hanna and Drivas, 1987 Workbook of Test Cases for Vapor Cloud Source Dispersion Models, AlChE, 1989 Guidelines for Chemical Process Quantitative Risk Analysis, 1989, pp. 96-103). 

A Safety Case is a narrative that literally makes the case that an adequate level of safety has been reached for an installation. It requires looking at all potential hazards which could lead to a loss of the installation, a loss of life, or a major pollution event. A risk analysis is performed on each hazard evaluating the probability of the event occurring and describing the magnitude of the consequences. A discussion is then given of the measure undertaken to lower the probability of occurrence or to mitigate the consequences and a case is made that the risk for the installation meets the ALARP safety criteria. 

Controlling health risks from rosin (colophony) based solder fluxes How HSE assesses offshore safety cases WASP - Quality assmance for chemical analysis... 

Deciding which risk-reduction method to use maybe difficult. In many instances, appropriate decisions can be made without resorting to quantitative techniques. However, in some cases, particularly when the options are costly, quantitative risk analysis (QRA) and risk-based decision-making approaches may be an effective basis for measuring the improvement in safety arising from the proposed options. These approaches can also be used in prioritizing safety improvements and balancing cost and production issues. 

The comprehensive and detailed assessment of the risks required for a safety-case can only be satisfactorily carried out for major installations with the aid of computer software. Suites of programmes for quantitative risk analysis have been developed over the past decade by consulting firms specializing in safety and environmental protection. Typical of the software available is the SAFETI (Suite for Assessment of Flammability Explosion and Toxic Impact) suite of programs developed by DNV Technica Ltd. These programs were initially developed for the authorities in the Netherlands, as a response to the Seveso Directives of the EU (which requires the development of safety cases and hazard reviews). The programs have subsequently been developed further and extended, and are widely used in the preparation of safety cases see Pitblado el al. (1990). 

In this section, a safety dataset, resulting from over 20 years of practical experience with risk analysis of chemical processes, is presented. These data build the base of risk analysis in the fine chemicals and pharmaceutical industries, essentially in multi-purpose plants. Therefore, the dataset introduces plant considerations only at its end. This allows exchanging them without any need for recollecting the whole dataset, in cases where the process is transferred from one plant unit to another. Moreover, this dataset may be used in the frame of different risk analysis methods. 

FMEA is focused on safety consequences of component failures. Identified failure modes of a component are analyzed case by case. The analysis process results in an explicit and documented decisions that take into account the risk associated with a given failure mode. The decision can be just the acceptance (supported by a convincing justification) of the consequences of the failure or it can suggest necessary design changes to remove (or mitigate) the consequences or causes of the failures. Documentation is an important output of FMEA. This documentation can be then referred to by a safety case for the considered system. 

The application of standards in crop protection machines is an in rortant contribution to the availability of well performing equipment thus improving the safety of the operators, environmental protection and, at the same time, the quality of agricultural products. Standards offer the highest benefits when there are national regulations such as is the case of the EU Machine Directive. This Directive could be a first important step and may offer protection to farmers ffom cheap, low quality machinery carrying a CE stamp based only on approximate risk analysis. 

These represent a simplification over a true LCA methodology, and include also aspects related to safety and risk, and economics. They thus could be a basis, which can be adapted for specific cases, for a sustainable chemical production metric, which should be integrated with other assessment tools such as LCA, Sustainable Process Index, and Risk Analysis and evaluation. 

While security is presented separately in Chapter 6, many of the risk definihons and concepts for safety and security ate similar. One difference is that security incidents ate intenhonal, rather than accidental. This difference is the basis for understanding the hazards, potenhal consequences, and likelihood of a security scenario. Table 3.3 compares the basic elements of safety and security risk analysis for the listed risk factors. The potenhal range of incidents and the resulting consequences have similarihes and differences. The incident in both cases is the... 

Finally ALARP introdnces a basis for justifying risks, to make a case for them being present but tolerable. To justify something in this way reqnires carefnl analysis and logic set out as an evidence-based argument. The vehicle for this jnstifica-tion is a document known as a safety case. 

Any risk-benefit analysis should be clearly set out in the safety case with the appropriate justification, rationale and supporting evidence. The complexity of the arguments involved warrant close cooperation between manufacturers, users and regulators. In most cases the inclusion of potential benefits in the safety case is simply not required in HIT CRM and, if anything, introduces subjective noise into an otherwise objective methodology. 

Where extension of use is conducted as part of a controlled roll out it should be subject to the usual change management procedures which will have been established in the in SMS. Essentially a set of safety activities will need to take place on the product to determine whether the new operating environment introduces any new hazards and the safety case updated accordingly. The analysis will need to be able to justify operating the system outside of the intended purpose and set out the evidence to support the claim that the risk remains acceptable. 

The evaluation of clinical risk requires the careful application of judgement based on a sound knowledge of the system under consideration and the domain in which it is deployed. Similarly, the effective formulation and implementation of an SMS is a complex task which requires skill and expertise. It follows therefore that the accuracy of a CRM analysis is significantly dependent on the competency of the stakeholders involved. Those challenging the claims of a safety case might be quite justified in bringing into question its validity where the capabihties and proficiency of its authors is questionable. It is therefore wise for a rigorous CRM system to be backed up by pro-active evidence of a personnel competency assessment for project stakeholders. 

At an early stage in the project planning it is necessary to carefully define the scope of the system or module under examination. Limiting and articulating the scope is necessary to define the boundaries that have been applied to the analysis. More importantly, this formalises those system entities which have not been subject to analysis. The safety case will therefore say nothing about the clinical risk associated with those components outside of that defined boundary. By instituting boundaries early on in a project one is able to more accurately size the target and define the resources and timescales necessary to complete the task. 

On occasion one encounters a situation where information is simply not known and no practicable assumptions can be made. In this case we may have an opportunity to undertake a part-assessment perhaps until a time when the information becomes unavailable. This is a perfectly reasonable approach so long as this limitation is formally documented as a constraint on the analysis and the project generally. It may even be appropriate to document which areas of the analysis have potential to change once more information does become available. Clearly it is important to monitor the provision of the information on which the safety case is dependent and build this into the project plan. If one believes that the information may not be available or forthcoming then this should represent a risk to the project and be documented and escalated accordingly. 

---