Safety cases objectives

A safety case approach along the lines of the Seveso63 requirements is another possible alternative for determining regulatory coverage. The safety case requires a detailed explanation of why a process is safe to operate. Again, objective criteria such as NAICS codes, thermodynamic properties, or some combination of those criteria previously discussed are used to establish coverage. 

The objective of a safety case is to demonstrate to the regulatory authority that a company is fully aware of the hazards associated with its operations and that they are conducted in a safe manner, such that employees and the public are not exposed to undue risks. The regulatory authority must examine the safety case and communicate the results of its examination to the facility, usually within a reasonable period of time. ... 

This definition is widely accepted within the safety critical systems community. Safety case can be considered as a special case of the trust case where focus is on a specific trust objective, i.e., safety, and highly demanding requirements are needed to be met by the base supporting the 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. 

Goal-based methods are preferable to prescriptive approaches. They allow risk to be objectively justified and explained in the form of a safety case. 

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. 

Developing an objective approach to risk management is as much about the language we use as it is the processes we put in place. Those who have the authority to undertake a safety assessment have a responsibility to wield that power carefully and shrewdly and this can quickly be undermined when one resorts to emotive and reactive language. This is as true for the language of the safety case as it is in the corridor conversations with colleagues. Those who operate in CRM have a duty to propagate objectivity by example and to communicate in a way that drives a safety culture which is not rash but considered. 

Objectivity is the order of the day in writing the safety case content. The more measured and facmal the writing style, the greater its impact. 

The objective of this stage is to obtain, as per the provisions of 9(l)f) of the Atomic Act, the permission (license) to implement the refurbishment of the plant l C systems important to safety. The safety case of this stage is based on the results of the basic design of the refurbished l C systems important to safety performed by the supplier contracted for the implementation of the projeet and by its subcontractors. The documentation submitted to the SUJB for licensing assessment eonsists of ... 

The objective of this stage is to obtain the SUJB permission for the reactor start-up after refueling as per the provisions of 9(l)e) of the Atomic Act, which at the same time will include the SUJB consent to the operation of the refurbished I C systems important to safety implemented during the current implementation phase. Hence, this phase will also be repeated as many times as is the number of outages necessary for the completion of the refurbishment at the subject plant unit. The safety case will again be a kind of an update of the preceding phase 3B safety case, and will in addition include ... 

The safety case procedures must define the objections of the program and must identify which procedures and standards are in place. 

Considerable effort has been concentrated on the development of a plant design which has an acceptable criticality safety case, but which is not constrained in terms of its flexibility to process a wide variety of feed material and manufacture a wide range of fuel assemblies. The principal objective of the design was to make the plant inherently safe where practicable for normal operations and potential fault conditions. Only where this objective is not practicable are additional safety protection systems provided. This enhances the robustness of the safety of the plant and reduces the requirement for potentially complex safety protection systems. 

B9.1 Configuration Management Recall from Section 9.3.4.3 that one of the objectives of SAV assurance was configuration consistency. Essentially, does the evidence produced throughout the SAV lifecycle have traceability to the delivered SAV product For example, what is the relevance of a safety case claim made from SAV lifecycle data that cannot be traced or be shown to be consistent with the version of SAV being delivered Clearly the relevance is low, and would not form a robust argument in the safety case. 

The chapter Scope details the principal objectives of the safety case, the key requirements and standards, possible relationships to other safety cases, e.g. software and system safety case and high level assun tions and limits. 

Difficulty in recognising the importance of changes to the safety case In conventional cases it can be difficult to discern the objectives, the evidences and the contexts. 

As the main objective of safety regulation is to ensure that those who are accountable for safety discharge their responsibilities properly, then it follows that a safety case which serves the above primary purpose should also provide an adequate means of obtaining regulatory approval for the service or project concerned. 

Stating Safety Objectives at the beginning of the Safety Case, proving they are addressed within the safety argument, then showing compliance in a summary at the end. 

Safety eases entered the UK safety world as a result of the Control of Industrial Major Aeeidents Hazards regulations (CIMAH regulations) in 1984. Safety case principles were further examined and developed by Lord Cullen in his report into the Piper Alpha disaster (Cullen 1990) in which a major accident in an offshore oil facility in the North Sea resulted in 167 deaths. As a result of this report, the approach to offshore safety shifted from compliance to achievement of safety objectives. A safety case would demonstrate through argument and evidence that the required safety objectives would be met. Regulations laid down what must be addressed in a safety case. 

CAP 670/SW01 (CAA 2003) sets regulatory objectives for software assurance in ATS (air traffic service) equipment. As well as giving the objectives themselves, SWOl provides non-mandatory guidance on how compliance with the (mandatory) safety objectives may be demonstrated. While limited in scope to software, SWOl notes fliat demonstration of satisfaction of its requirements (i.e. safety objectives) may be used in support of a system safety case. 

The process summary document then identifies the extent to which the outputs of that process have met the safety objectives. Did all of the tests pass If not, what was the pass rate and where are the failures recorded and analyzed Were all of the tests carried out exactly as specified If not what were the deviations and what are the consequences for the safety objectives Were all of the tests completed If not where is it stated which parts of the software are not tested Since this part of the assessment of evidence is concerned with process compliance, additional backing evidence for the safety case can be provided through quality auditing to check that processes are being properly carried out. 

The title of this paper is accounting for evidence since this reflects that what should occur is systematic recording and objective assessment. Moreover all of the limitations with evidence should be recorded so that the overall presentation of the evidence shows transparently exactly what has been achieved, and what still remains unproven. As the processes continue up the right hand side of the V model, more safety judgment is required in assessing the impact on the safety case of the individual faults and limitations uncovered in the detailed evidence. 

The safety management system should have specific objectives to manage the identification, assessment and mitigation of assurance deficits and counterevidence. The ouQmt of that activity will be recorded in the safety case evidence report. 

---