Formal Foundations for Hierarchical Safety Cases

Abstract

Safety cases are increasingly being required in many safety-critical domains to assure, using structured argumentation and evidence, that a system is acceptably safe. However, comprehensive system-wide safety arguments present appreciable challenges to develop, understand, evaluate, and manage, partly due to the volume of information that they aggregate, such as the results of hazard analysis, requirements analysis, testing, formal verification, and other engineering activities. Previously, we have proposed hierarchical safety cases, hicases, to aid the comprehension of safety case argument structures. In this paper, we build on a formal notion of safety case to formalise the use of hierarchy as a structuring technique, and show that hicases satisfy several desirable properties. Our aim is to provide a formal, theoretical foundation for safety cases. In particular, we believe that tools for high assurance systems should be granted similar assurance to the systems to which they are applied. To this end, we formally specify and prove the correctness of key operations for constructing and managing hicases, which gives the specification for implementing hicases in AdvoCATE, our toolset for safety case automation. We motivate and explain the theory with the help of a simple running example, extracted from a real safety case and developed using AdvoCATE.

Tool support for assurance case development

“…Lastly, we have applied modular structuring to specify an argument architecture, together with modular arguments, for the safety assurance of a ground-based detect and avoid capability used in UAS transit operations. Subsequently, we have applied hierarchical structuring to abstract argument fragments of the same system [27].…”

“…However, we are interested in using formal methods to create (fragments of) arguments, as opposed to simply evidence nodes. The idea is to use the reasoning underlying the formal method/tool itself to create an argument for the suitability of the results produced and to provide additional insight into the analysis beyond the existence of the evidence 27 . We also want to be able to invoke the formal methods tool from within AdvoCATE while constructing the argument.…”

“…Hierarchical nodes can be open, so that the argument structure that they contain is visible, or can be closed, and can be viewed simply as a (hierarchical) safety case node. 18 There are conditions on which fragments can be abstracted [27].…”

“…Finally, we impose several conditions on the interaction between the two relations ! and  (omitted here; see [27] for details)…”

“…22) into the hierarchical goal HG2 (HG1), which has been shown in the open view, i.e., the contents are visible. In AdvoCATE, we achieve this result by simply selecting the node that will form the local root of the hinode to be created, e.g., G8 (G9), and invoking a hierarchize operation that automatically determines the contents of the hinode based upon the well-formedness rules for hierarchization [27]. In this case, since no nodes are selected to delimit the outputs of the hinodes, the hinodes will extend to the leaves.…”