Applying Risk Models to Formulation of Safety Cases

Importance measures have been useful in the process of extracting insights from risk analyses. Importance measures have also been suggested for use in component classification. However, there are difficulties of interpretation associated with component classification based on importance measures. This paper briefly reviews an alternative method, “Top Event Prevention Analysis,” and, based on a simple example, compares its key characteristics to those of conventional applications of importance measures. The methods are compared with respect to the task of formulating a safety case for a complex and potentially hazardous facility, in which component classification plays an important role. A key subtask is identification of a collection of design elements that is necessary and sufficient to achieve the desired level of protection of the public, the workers, and the environment. At the design stage, identifying this set helps to determine what elements to include in the final design. Separately, a similar selection process could be used in order to justify limiting the scope of regulatory oversight to a subset of design elements, on which a safety case is to be based. This step could be taken during initial review of a design, or later as part of an effort to justify relief from regulatory requirements that are burdensome but provide little actual risk reduction. SUMMARY A safety case should arguably be based on a collection of design elements that combine to provide satisfactory plant response to important safety challenges, and provide this response with the desired reliability (achieved through redundancy and diversity in design, and programmatic support activities as necessary in implementation). The key property of such a collection resides in the set as a whole, and not in any single element: the implications of including or not including any given design element in the collection depend strongly on what other design elements are included. Given a logic model that comprehensively addresses plant response, reflecting all components under consideration, and a defense‐in‐depth safety standard of the kind discussed above, TEPA is capable of choosing prevention sets: subsets of components that have the desired defense‐in‐depth property, and are suitable candidates for serving as the nucleus of a safety case. Single‐event importance measures cannot capture considerations like this, except perhaps as part of an arduous iterative reformulation of a logic model to successively remove and restore combinations of events in a trial‐and‐error approach to a self‐consistent design solution. No method of applying conventional importance measures has been shown to produce solutions that are feasible in the sense of completing pathsets, nor is one expected. Interpreting the upper portion of a ranked list of components as a safety case would therefore be a misapplication of the importance measure concept. However, given a prevention set, one could apply importance measures to fine‐tune the allocation of resources within this set. That is, one could compute importances within a model that took credit only for elements of the prevention set, and reason from there. Even in this case, some iteration might be required in order to achieve a self‐consistent allocation (one for which the reliability credit taken for each component is commensurate with the resources allocated to it). In order to draw valid conclusions in an application of this type, one must recall that all importance measures are predicated on credit for all modeled components; it is invalid to infer that components can be dropped from a safety case on grounds of low calculated importance. In short, application of importance measures is valid when (a) the selection problem has been solved by other means, (b) the importances are calculated with credit only for selected components, and (c) the resources allocated to each component are commensurate with the level of credit taken for the component (e.g., credit for a component's availability is backed up by an appropriate test schedule.). A byproduct of this work is the observation that whether or not TEPA itself is applied to choose prevention sets, a useful litmus test to be applied to a safety case is simply whether it is based on a union of complete success paths. As discussed above, thinking of the safety case in this way has other benefits, in helping to identify unmodeled components and in helping to specify the demands that must be met by each component, so that programmatic activities necessary to ensure its function can be identified and carried out. This formulation of the safety case helps in thinking about the relationship between component performance and resources allocated to that component. Understanding this relationship is essential to optimizing the use of safety resources. The number of combinations (possible prevention sets) that must be examined grows very rapidly as the number of design elements and minimal cutsets increases. Therefore, many realistic problems will be very demanding computationally. To some extent, this could be considered a drawback of TEPA, but it should be understood that the underlying problem is combinatorially very difficult, and actual solutions to it should not be expected to come easily in all cases. Fortunately, as illustrated by the practical applications summarized above, many real large‐scale problems have specific features that permit their solution by adaptations of the general approach.