Safety analyses rationale

The modified FMEA approach has been used by the API to develop RP14C. In this document ten different process components have been analyzed and a Safety Analysis Table (SAT) has been developed for each component. A sample SAT for a pressure vessel is shown in Table 14-4. The fact that Tables 14-3 and 14-4 are not identical is due to both the subjective natures of a Hazard Analysis and FMEA, and to the fact that RP14C is a consensus standard. However, although the rationale differs somewhat, the devices required are identical. (The gas make-up system in Table 14-4 is not really required by RP14C, as we shall see.)... 

As part of the overall process leading to an acceptable design, its evolution and the supporting rationale should be clearly and adequately documented and kept readily available for future reference. The exact content of this documentation, which is likely to be of particular interest to all those involved in the construction, licensing, operation and eventual decommissioning of the facility, may vary somewhat due to facility specific factors. The supporting documentation shall include a full Safety Analysis Report (SAR). 

Care needs to be taken in combining individual events in analysing accidents to ensure that there is some rationale for the particular combinatioa A random combination of events may represent an extremely unlikely scenario that should be shown in the probabilistic safety analysis to be sufficiently rare as to be discounted rather than being taken as a postulated accident. In probabilistic safety analysis, an approach using best estimate analysis is adopted for severe accidents while conservatism should be applied in the analytical approach for postulated accidents that have a relatively higher likelihood of occurrence. 

Develop rationale for safety and clinical benefit (risk-benefit analysis)... 

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. 

Figure 12.1 shows the interactions between development and operations. At the end of the development process, the safety constraints, the results of the hazard analyses, as well as documentation of the safety-related design features and design rationale, should be passed on to those responsible for the maintenance and evolution of the system. This information forms the baseline for safe operations. For example, the identification of safety-critical items in the hazard analysis should be used as input to the maintenance process for prioritization of effort. 

Before any planned changes are made, including organizational and safety control structure changes, their impact on safety must be evaluated. Whether this process is expensive depends on how the original hazard analysis was performed and particularly how it was documented. Part of the rationale behind the design of intent specifications was to make it possible to retrieve the information needed. 

Case studies were seen to promote better understanding of the rationale of current safety culture, the development need and obstacles. Based on the information gained throngh case studies, occupational physician s questionnaire snrvey as well as review and analysis of the literature drawing from several databases, authors stated the development of model system for safety culture. 

The PHA (Figure 6.2) is perhaps the most critical analysis that will be performed because it is usually the first in-depth attempt to isolate the hazards of a new or, in some cases, modified system. The PHA will also provide rationale for hazard control and indicate the need for further, more detailed analyses, such as the subsystem hazard analysis (SSHA) and the system hazard analysis (SHA). The PHA is usually developed using the system safety techniques known as failure mode and effect analysis (FMEA) (Chapter 9) and/or the ETBA. Data required to complete... 

Critical items List The purpose of the FMEA is to identify and evaluate failure modes and the possible system effects of those failures. Since the potential for undesirable effects must be eliminated or controlled, the FMEA also provides recommended actions that must be taken to accomplish this goal. As part of this analysis process, the FMEA identifies any and all items within the system that, if a failure were to occur, would have a critical effect on the operation of that system. Therefore, to facilitate evaluation and analysis of these system effects, a critical items list is developed. The list provides detailed descriptive information on each item. It will explain its overall function within the system, as well as the function of any components that may make up that item. The failure mode determined as critical is then listed along with the potential effect(s) of such a failure. If an item on the critical items list is to be accepted as is, then acceptance rationale must be provided. Such rationale may include an explanation of any existing or planned design limitations that will prevent the failure during actual system operations, or the provision of excessive factors of safety that will render such fail-ure(s) extremely improbable. Another area for evaluating acceptance is the history, or lack thereof, and any known failures of systems similar in nature and operation. 

Case analysis Identify underlying causal variables and conditions that contributed to the event, and describe how they combined through a sequence of events. Describe resolving actions to mitigate risk and reduce the probability of recurrence of a similar event, with supporting rationale from safety science. 

There is not a one-size-fits-all SSP, and tailoring may be needed to account for differences in program size, cost, complexity, and safety-criticality. SSP tailoring should be done judiciously with the appropriate analysis, justification, and rationale to support the tailoring decisions. 

The rationale of our technique is to determine, for each component, the allowed range for a certain parameter within which a component may change before it compromises a certain system property (e.g., safety, reliability, etc ). To this end, we use the sensitivity analysis as a method to determine the range of failure probabihty parameter for each component. Hence, the technique assumes the existence of a probabilistic FTA where each event in the tree is specified by an actual (i.e., current) failure probabihty FPActuai event(,x)- U addition, the technique assmnes the existence of the required failure probabihty for... 

Typically, a company would document the failure modes of the concept in an analysis report, e.g. using Failure Mode and Effects Analysis (FMEA), and manage safety goal and functional safety requirements in a requirements database. It would also have vehicle test reports or simulations demonstrating that the safety goals had been met. However, the rationale explaining how this evidence fits together is not often... 

---