Arguing from Hazard Analysis in Safety Cases: A Modular Argument Pattern

TL;DR

This paper introduces a modular argument pattern that integrates hazard analysis techniques like FTA, FMEA, and STPA to improve the clarity and confidence of safety cases by making reasoning more traceable and concrete.

Contribution

It presents a novel argument pattern combining multiple hazard analysis methods and their results to enhance safety argument confidence and traceability.

Findings

Pattern effectively integrates hazard analysis techniques.

Improves traceability and confidence in safety arguments.

Facilitates formal analysis and computer-assisted safety case construction.

Abstract

We observed that safety arguments are prone to stay too abstract, e.g. solutions refer to large packages, argument strategies to complex reasoning steps, contexts and assumptions lack traceability. These issues can reduce the confidence we require of such arguments. In this paper, we investigate the construction of confident arguments from (i) hazard analysis (HA) results and (ii) the design of safety measures, i.e., both used for confidence evaluation. We present an argument pattern integrating three HA techniques, i.e., FTA, FMEA, and STPA, as well as the reactions on the results of these analyses, i.e., safety requirements and design increments. We provide an example of how our pattern can help in argument construction and discuss steps towards using our pattern in formal analysis and computer-assisted construction of safety cases.

Figures

b](#S2.F1.sf2) therefor contains a multiplicity over the parameter HC (hazard category). Furthermore, the parameter CMT ranges over the terms *countermeasure (universal), design revision (universal), safety constraint (STPA)*, *corrective action (FMEA)*, and *process-based measure (FMEA)*. [Figs. 3a](#S2.F3.sf1) and [3b](#S2.F3.sf2) refine module $M$ via HC.

a](#S2.F3.sf1), we consider system-level events $E$ as top-level events of an FTA.

b](#S3.F13.sf2) indicates how FMEA enriches our argument. For Goal 2.1, we pick the failure mode “door controller calculates wrong door position” whose reduction is argued by two strategies: Strategy 2 builds on correct identification of this failure mode (Goal 2.1.1) and on two design revisions $RS$ and $FDC$ (Goals 2.1.2a and b). Strategy 3 builds on measures in the system integration process, i.e., a “check for correct wiring and sensor application” (Goal 2.1.3). Again, we only consider one failure mode.

b](#S3.F14.sf2) shows an argument to mitigate the failure mode identified in [Fig. 13b](#S3.F13.sf2): The requirement “controller detects data inconsistencies” specifies a task to build a “fault-detection for the controller (FDC)” which is (i) conducted when we gain evidence for Goal 2.1.2.2 by Solution 4, and (ii) verified as soon as we get evidence for Goal 2.1.2.3 by Solution 5.

Equations

$$(1)\to (2)\to (3)\text{mbox}or(2)\to (1)\to (3).$$

Full text

I Introduction

We give a short introduction into safety cases, safety arguments, goal structures, and hazard analysis (HA), point out one important problem we perceive when building safety cases, and, finally, provide an approach to solve this problem.

I-A Background and Terminology

According to Bishop and Bloomfield [1], a safety case111The discussion of how our approach relates to the more general concepts of assurance case and dependability case is out of scope of this paper. should comprehensibly convey a valid argument that a specific system is acceptably safe in a specific operational context. Hereby, the safety argument captures the reasoning from basic facts—the evidence—towards the claims to be established—the safety goals. Graphs called goal structures represent and document such an argument [2]. To make the process of safety case construction more systematic, several authors [3, 4] propose argument patterns and provide a structure for developing lower level patterns.

Hazard identification relies on expert knowledge, e.g. in terms of guide words or defect classifications, identifying types of component failures [5, 6], defects in software processes [7], accident causal factors [8], and destructive goals for software tests [9]. Hazard analysis as an activity in any safety engineering life cycle deals with causal reasoning, i.e., establishing causal relationships between events. Causal reasoning can be inductive, i.e., from causal events up to their effect events, or deductive, i.e., from effect events down to their causal events. We focus on three widely used techniques:

• •

fault-tree analysis (FTA), which looks at critical paths, i.e., combinations of causal factors leading to an undesired event with high probability [10],

• •

failure-mode-effects-analysis (FMEA), which helps identify failure modes of items and their propagation towards hazardous system-level effects [10], and

• •

system-theoretic process analysis (STPA), one of the most recently developed techniques, which applies control structure models and control action guide words to determine causal factors [11].

For a detailed description of FTA and FMEA techniques see [10] and for STPA see [11]. In Sec. II-C, we provide descriptions for the non-expert reader to gain a further understanding.

I-B Motivation and Challenges

Fenelon et al. [12] discuss a method where they intertwine software HA with design increments as countermeasures for identified hazards. Hawkins et al. [13] elaborate a tool chain for constructing safety cases from modeled design increments.

Safety arguments are required to be valid with high confidence [14, 15]. The achievement of this depends on the amount of details an argument should have [16]. Staying too abstract is among the many obstacles to the achievement of high confidence. We point at several problems, e.g. solutions based on FTA can refer to large packages [2, pp. 319f,136], argumentation strategies can encompass fairly complex reasoning steps [4, pp. 17ff][17, p. 102], context and assumption statements can lack fine-granular traceability [17, p. 111]. These examples show that it is difficult to build up a comprehensible and traceable safety argument from the HA results and the corresponding reactions. These problems can

• •

significantly reduce the confidence we are able to associate with such an argument and, consequently,

• •

hinder systematic reuse of proven arguments.

Related issues were recognized by, e.g. Yuan and Xu [18].

I-C Contributions

In this paper, we seek to reduce the mentioned issues and improve safety case methodology. Argument patterns based on evidence from FTA and FMEA have been discussed in [19, 4]. Confidence arguments have to provide insight on how this evidence was generated [16]. In addition to these patterns, we discuss a pattern that zooms into the evidence mentioned by the existing approaches by using causal reasoning evidence and the evidence from developing mitigations of identified hazards. Our pattern helps at collecting more evidence on how the analysis is performed. Instead of creating an argument from error-prone experience, we propose a systematic way of guiding the argument from well understood steps performed in HA to increase the trustworthiness of the evidence. Hence, the structure of our pattern resembles the causal reasoning of HA. Moreover, the pattern adds value to HA results by integrating these results with the additional steps required in the construction of confident safety cases. We provide reusable argument modules for different assurance concerns, particularly, arguing for a system redesign based on the identified hazards.

Outline

Sec. II describes a pattern using goal structures to represent safety arguments from FTA, FMEA, and STPA to substantiate safety cases. In Sec. III, we provide an example of a train door control system as a basis for applying this pattern. Sec. IV discusses several aspects of the pattern. We close our paper with an analysis of related work (Sec. V) and conclusions in Sec. VI.

II A Modular Argument Pattern

Fig. 1a describes an argument pattern in three modules: A Module M describing the part of a safety argument based on mitigating hazards from various categories, a Module CR depicting the part of an argument underlying a specific HA technique, and a Module HC to form detailed arguments from the reactions after applying a specific technique.

II-A Concepts, Notation, and Assumptions

Concepts

All modules are built around the concepts of

• •

hazard, e.g. failure mode or effect in FMEA; minimum cutset, critical path, or top-level event in FTA; causal factor or unsafe control action in STPA; and

• •

countermeasure, e.g. corrective action in FMEA or safety constraint in STPA (see Sec. II-B for further concepts).

Countermeasures can range from

1. a specification document containing functional or quality requirements and design constraints (to be implemented by hardware, software, the human machine interface or the operator), over

2. corresponding design changes based on system models or implementation artifacts such as the application of dependability design patterns, to

3. process requirementsspecifying work steps such as design review, verification, test, or maintenance to be conducted at certain points in the system life cycle.

Notation

The notation, we use in Figs. 1b to 14b, complies with the Goal Structuring Notation (GSN, [19]) and is described in Fig. 2. We distinguish between parameters for pattern refinement (indicated by square brackets “[]”) and for pattern instantiation (indicated by curly brackets “{}”). GSN is one way of visualizing argumentation in safety cases. However, the following approach should, in principle, work with any means used to visualize assurance argumentation.

Assumptions

Similar to Hawkins et al. [13], we assume model-based development to be a basis for constructing the parts of the argument referring to system design increments. Hence, these increments refer to a system model describing design-related safety measures to be implemented. The implementation then needs to be verified against the model and the requirements to complete the argument.

II-B Module M: Arguing from Hazard Mitigation

Module $M$ describes an argument pattern which aims at coverage of two main categories of hazards we focus222Motivated from Sec. I-A, these two categories cover a large subclass of identifiable and important hazards. on, i.e., hazardous single-point333For sake of simplicity, we do not discuss common cause failures which, however, can be covered by specific variants of FMEA and FTA. failures (objective of FMEA) and hazardous system-level events (objective of FTA and STPA). The goal structure in Fig. 1b therefor contains a multiplicity over the parameter HC (hazard category). Furthermore, the parameter CMT ranges over the terms countermeasure (universal), design revision (universal), safety constraint (STPA), corrective action (FMEA), and process-based measure (FMEA). Figs. 3a and 3b refine module $M$ via HC.

II-C Module CR: Arguing from Causal Reasoning

Here, we provide three argument patterns incorporating the type of causal reasoning underlying FTA, STPA, and FMEA.

II-C1 Commonalities among the Techniques

By the “1-out-of-2” choice in Figs. 4, 5 and 6, the pattern allows to complement design revisions with process-based measures, e.g. unit tests, material quality checks, reviews. This distinction allows us to construct an argument along these two commonly used lines of argumentation (see, e.g. [20]).

II-C2 Argument based on FTA

The main part of the argument in Fig. 4 contains the elimination of all critical paths (Strategy 2), i.e., the minimum cutsets $C$ with comparably high probabilities, leading to an undesired system-level event $E$. Strategy 2 can be used to construct arguments over the (i) elimination of critical paths, or (ii) the reduction of failure rates of these critical paths below an acceptable maximum. Both approaches, (i) and (ii), are associated with a design revision $DR$. The multiplicity helps to argue over arbitrarily many relevant pairs $(C,DR)$. By C2 in Fig. 3a, we consider system-level events $E$ as top-level events of an FTA.

Notes on Construction

As opposed to the fault-tree evidence pattern described in [2, pp. 186f] and following FTA deductive causal reasoning, we consider this pattern being used to construct an argument top-down from Goal 2.1.

II-C3 Argument based on FMEA

The main part of the argument shown in Fig. 5 pertains Strategy 2 which argues over a correctly identified failure mode $FM$ with high risk priority number (RPN) and a corresponding design revision $DR$ taken to mitigate $FM$. The multiplicity allows $FM$ to be mitigated by arbitrarily many recorded design revisions.

Notes on Construction

We consider this pattern being used to construct an argument top-down from Goal 2.1. This $CR$ pattern, particularly Strategy 2, inverts the FMEA inductive causal reasoning in the sense that the elimination of hazardous failure effects (Goal 2) from failure modes is established by building up the goal structure in a top-down manner, i.e., descending from Goal 2 towards Goal 2.1.1.

II-C4 Argument based on STPA

To reuse Module $M$ from $FTA$, we use the concepts hazard $H$ and accident $A$ to form the hazardous system-level event $E$. In the context of STPA, Goal 2.1 can be interpreted as a reduction of the probabilities of the identified accidents $A$ by mitigation of their corresponding hazards $H$.

The CR pattern for STPA (Fig. 6) works similar to the one for FTA (Fig. 4). However, it is more elaborate in terms of the concepts used to decompose the chain of evidence in causal reasoning and the goals. Based on an identified accident $A$, Strategy 2 argues over the elimination of all unsafe control actions $UCA$ and corresponding hazards $H$ (Goals 2.1.2 to 2.1.4) by design measures (Goal 2.1.5).

Notes on Construction

Similar to the FTA deductive causal reasoning, we consider this pattern mainly being applicable in top-down argumentation from Goal 2.1. However, the Goals 2.1.1 to 2.1.4 might be elaborated

from left to right, e.g. if we want to follow STPA starting with accident analysis, or 2. 2.

from right to left, e.g. if we want to study the causal factors resulting from a former safety case or a former accident investigation and follow the course of events.

II-D Module HC: Arguing from Hazard Countermeasures

The goal structures of this module argue over evidence from results of the applied (i) HA techniques, i.e., hazards, and (ii) assurance techniques, i.e., countermeasures (see Sec. II-A). Now, we describe a generic argument pattern for module HC followed by three refinements for FTA, FMEA, and STPA.

II-D1 Generic Argument

In Fig. 7, the Goal 2.1.x mentions the parameter $CT$ which denotes the type of cause to be mitigated, treated, or eliminated together with a specifier $\mathit{Refs}$ as explained below. Furthermore, the parameter $AT$ refers to the analysis technique from which the corresponding evidence (i.e., solutions) can be collected. The requirements $R$ identified for the design revision $DR$ according to Goal 2.1.x.1 are implemented by Goal 2.1.x.2 and verified after Goal 2.1.x.3.

II-D2 Argument based on FTA

Fig. 8 refines the argument of Fig. 7: The parameter $CT$ is substituted by “eliminating minimum cutset (MCS)” and $\mathit{Refs}$ by a parameter $\{C\}$ to specify a minimum cutset. $AT$ is set to FTA.

II-D3 Argument based on FMEA

Fig. 9 refines the argument of Fig. 7: The parameter $CT$ is substituted by “mitigating failure mode” and $\mathit{Refs}$ by a parameter $\{FM\}$ to specify a failure mode. $AT$ is substituted by FMEA.

II-D4 Argument based on STPA

In STPA, safety constraints are requirements which constrain the control system structure and behavior such that unsafe control actions and, in turn, hazards are mitigated at specification level. Fig. 10 refines the argument of Fig. 7 by setting the parameter $CT$ to “mitigation of unsafe control action and hazard” and $\mathit{Refs}$ to $\{UCA\}$ and $\{H\}$. Specific to the work steps in STPA, we propose a “1-out-of-2” choice depending on whether the safety constraints (i.e., specific requirements) have been derived from an unsafe control action $UCA$ (instantiating the parameter $SCA$), from a hazard $H$ (instantiating the parameter $SCH$), or from both. Finally, $AT$ is substituted by STPA.

III Application: Train Door Control System

In this section, we discuss a simplified train door control system (TDCS) as an example of a safety-critical software-based system in the public train systems domain.

III-A Information about the System

Features

Our TDCS is responsible for operating a single door unit, i.e., opening doors according to passengers’ or train conductor’s requests, closing doors according to train conductor’s requests, both only in appropriate situations.

System-level Safety Requirements (SR)

After train-level hazard identification, a TDCS has to particularly fulfill train-level safety requirements such as, e.g.

SR1

locking the doors closed while the train is moving,

SR2

preventing the train from moving while the doors are not locked,

SR3

not harming humans residing in the doorway,

SR4

allowing manual opening after the train stopped in case of an emergency.

System Structure

Fig. 11 shows a simplified control loop with the main components of the TDCS.

III-B Application of Module M

We applied FTA and FMEA to our TDCS. Hence, our goal structure is complete in the sense of capturing both causal reasoning directions, inductive and deductive.

Fig. 12 applies module M by substituting $S$ for TDCS, using the refined patterns for FMEA and FTA for the two hazardous system-level events “door remains closed in case of emergency” (derived from SR4) and “train departs with open doors” (derived from SR1 and SR2), and the two failure modes “door controller calculates wrong door position” and “lack of power supply for H-bridge.” For sake of brevity, we left most context, assumption, and justification elements away. Please, consider the pattern description in Sec. II.

III-C Application of Module CR

Module CR-FTA

In Fig. 13a, we show a breakdown of the goal structure for the event “train departs with open doors.” We show the cutset “optical encoder broken or faulty, additional infrared sensors faulty” as an example. This cutset was determined a as critical path by FTA. We only consider one critical path in this example. Goal 2.1.2 requires a design revision identified by “robust sensors (RS)” to be successfully conducted. We discuss this in Sec. III-D.

Module CR-FMEA

Fig. 13b indicates how FMEA enriches our argument. For Goal 2.1, we pick the failure mode “door controller calculates wrong door position” whose reduction is argued by two strategies: Strategy 2 builds on correct identification of this failure mode (Goal 2.1.1) and on two design revisions $RS$ and $FDC$ (Goals 2.1.2a and b). Strategy 3 builds on measures in the system integration process, i.e., a “check for correct wiring and sensor application” (Goal 2.1.3). Again, we only consider one failure mode.

III-D Application of Module HC

According to Sec. III-C and Fig. 13a, Fig. 14a shows the breakdown of Goal 2.1.2 by which we get an argument for having eliminated this specific critical path.

Fig. 14b shows an argument to mitigate the failure mode identified in Fig. 13b: The requirement “controller detects data inconsistencies” specifies a task to build a “fault-detection for the controller (FDC)” which is (i) conducted when we gain evidence for Goal 2.1.2.2 by Solution 4, and (ii) verified as soon as we get evidence for Goal 2.1.2.3 by Solution 5.

IV Discussion

In this section, we reflect on the presented argument pattern and its application to the TDCS.

IV-A Preliminary Evaluation in the Student Lab

We developed our pattern for a practical course in safety analysis with 18 master students.444See http://www4.in.tum.de/~gleirsch/safety/index.shtml. This course was combined with an experiment on the comparison of the effectiveness of FTA, FMEA, and STPA.555Detailed results will be published apart from this paper. After being trained in these techniques, the students worked in groups of three to perform HA for three different systems, an automotive anti-lock braking system, an air traffic collision avoidance system, and a TDCS.

Next, the students (i) developed safety measures for the hazards they identified by using the three techniques and (ii) constructed a safety argument. In an extra tutorial on safety cases, we showed them a first version of our pattern to help them structure their arguments. This way, we could determine whether trained students were able to apply our pattern in their assurance tasks. The submissions showed that 4 out of the 6 groups were able to directly use our pattern to create an argument from their previous analysis. Finally, this approach helped us to understand and refine our pattern before evaluating it in a more critical practical context.

IV-B Structuring the Argument

Here, we discuss insights from applying our pattern in the course assignments. From the construction notes in Sec. II, we conclude that our argument is to be built top-down. The structuring is difficult because of the many criteria and ways available to do this. We found the following classification criteria and steps helpful to keep the argument compact:

1. (1)

Breakdown of items (i.e., system functions, components), 2. (2a)

hazard analysis technique, 3. (2b)

hazards and measures common across the techniques, 4. (3a)

requirement types (i.e., functional, quality, constraint, process, see Sec. II-A) and clusters, 5. (3b)

solution clusters.

For (1), item-related structuring

• determines analysis granularity in FTA, FMEA, and STPA,

• structures requirements derived from the identified hazards, and

• scopes design revisions implementing (functional) requirements.

For (3), requirements (Goal 2.1.2.1) motivating design revisions (e.g. Goal 2.1.2 in Fig. 14a) can be clustered according to their (i) type, and (ii) the class and severity rating of the hazard they were associated with (e.g. intermittent failure mode in highest RPN range).

We found that these criteria can be used in two sequences:

[TABLE]

IV-C Commonalities and Relationships among the Modules

The modules M and HC have commonalities in their goal structures. Particularly, the FTA and STPA modules are both deductive in their causal reasoning which, unsurprisingly, leads to similarities in their structure. The mitigation of a system-level event $E$ might be argued from two different directions: by module CR mitigating a critical path to $E$, or by module CR mitigating a failure mode having $E$ among its effects.

IV-D Evidence for Safety Arguments and Level of Detail

Our pattern is built on evidence from FTA, FMEA, and STPA results. We refer to evidence on

• hazardsto argue over their proper identification, and on

• countermeasuresto argue over their validity, proper implementation, and verification.

Semantic Traceability

Our modules represent separate concerns facilitating traceability between complementary evidence (e.g. Why/Is the argument complete?). State-of-the-art patterns pinpoint that hazards have been mitigated without clearly demonstrating why and how they have been properly mitigated [21]. Hence, it is important to refer to the causal chain of what exactly triggers the hazards and to how that causal chain is to be modified to eliminate hazard sources.

Deductive Argumentation based on Good Practice

Gaining confidence in an argument is more of a technical problem, whereas gaining confidence in the evidence stems from technical, social and philosophical issues [22]. We focus on increasing confidence in the argument by an optimal way of constructing it and zooming into (trustworthy) evidence. The adequacy of evidence itself is out of scope here. Our pattern allows constructing arguments directly from techniques recommended by standards, e.g. ISO 61508 and 26262.

Our pattern supports deductive argumentation to reduce doubt. Enhanced FTA and FMEA variants might increase the confidence in the evidence. The pattern employs basic versions of HA techniques, making it applicable in safety cases of any system, e.g. independent of whether we use enhanced FMEA.

Reducing Confirmation Bias

We address the problem of confirmation bias as the “tendency for people to favor information that confirms their preconceptions or hypotheses, regardless of whether the information is true” [20]. This bias due to the goal “to show that the system is safe” is reduced because previously conducted FTA, FMEA, and STPA use tactics to collect evidence for the goal “to show that there are hazards.” This way, our pattern supports two-staged arguments, the first stage to be constructed already during the design stage as required by, e.g. Leveson [20] and Yuan and Xu [18].

Using Specific Terminology

Our pattern contains claims based on HA terminology. Any person reviewing the safety case has to know HA. However, the module structure supports exploring technical details, it is complementary to existing patterns, and helps strengthen arguments to be assessed by certification engineers.

IV-E Applicability, Soundness, and Relative Completeness

We informally investigate three criteria to argue for the usability of the discussed pattern:

Applicability

Hawkins et al. [23] offer attributes against which argument quality can be scrutinized. Based on Sec. IV-A, we believe that our pattern is (i) easy to understand and apply by software engineers and (ii) flexible enough to be applicable to many safety-critical systems, as it has been applied to three control systems in fairly different domains by a group of 18 students.

Soundness

Does any instantiation of the pattern form a sound safety argument based on FTA, FMEA, and STPA? First, the module $CR$ resembles not only the causal reasoning direction, but can also directly use any result of these analyses, i.e., any identified hazard. Second, module $HC$ provides a response to this hazard in terms of an identified and taken countermeasure whose verification is part of $HC$. A further discussion of this question is out of scope here (Fig. 15).

Relative Completeness

Can the pattern be instantiated to the most relevant situations where safety cases are based on FTA, FMEA, and STPA? Here, we elaborate on applicability aspect (ii): The described modules capture core concepts of the three techniques, such that to each case where one of these techniques is applicable we can also expect to be able to instantiate our pattern (Fig. 15).

Assessing Hazard Analysis Techniques

Some principles to be followed by good techniques [21] are embedded in our pattern: Method is more important than notation emphasizes clear description of the capabilities of a technique, specification of information sources and the analysis procedure. Techniques should use familiar concepts and models implies that trustworthy results should be derived from HA, using combinations of events and conditions to model causes and effects. Our pattern incorporates HA steps (see Sec. IV-D). Trying to use our pattern with a new HA technique may unveil problems if this technique violates this principle. By refining the modules for a new technique, we can assess whether this technique matches at least as good as the existing ones.

V Related Work

Alexander et al. [4] present patterns arguing for safe control software by using adaptation mechanisms for improving or maintaining safe states. Our three modules (M, CR, and HC) are similar to their core patterns but use fewer argumentation steps. They focus on FMEA, e.g. arguing over adaptation as a design measure ($DR$) which goes beyond Solution 4 in our countermeasure module ($HC$). We integrate FTA, FMEA, and STPA and capture how safety requirements were motivated. We aim at a compact pattern and use HA results more directly. Their argument depicts that an identified risk structure (i.e., failure modes as hazards and their causal factors) is acceptable and, by adaptations as countermeasures, how this structure got acceptable. We do not presume adaptation as a countermeasure. Moreover, we allow the goal structure to be built during FTA, FMEA, or STPA whereas they concentrate on an a-posteriori construction.

Kelly [2, pp. 317ff] and the GSN standard [19] describe a “fault tree evidence” pattern where a fault tree as a whole serves as an evidence to derive basic safety goals. We go more in-depth into fault tree analysis and make the argument more precise. Similar to an application of our causal reasoning module ($CR$) for FTA, [2, p. 76f] describes an argument that includes cutsets at the level of solutions in the goal structure, however, not elaborated as a pattern.

Hawkins and Kelly [24] present patterns for mitigation of software-based hazards, identification and realization of software safety requirements, and avoidance of software-based mistakes. While their “software contribution safety argument” module is similar to our HC module, they do not elaborate on causal reasoning based on a specific HA and mitigation technique. Their article does not discuss system models.

Palin and Habli [25] propose safety case pattern catalogs for the construction of a vehicle safety case in accordance with ISO 26262. One of the proposed catalogs, namely the Architecture for the Argument pattern catalog, confirms the necessity of an FMEA Argument pattern. Their paper does not elaborate on this pattern.

For a truck information and control system, Dardar [17] constructs an ISO 26262-compliant safety case using GSN and SysML. He argues from a trustworthy process based on coarse evidence from several HA and quality assurance techniques. However, for FTA he shows a goal structure that can be seen as an instance of our CR and HC modules for FTA.

Wagner [26] sketches an argument pattern based on STPA. Our CR module for STPA indicates more clearly how STPA results can be integrated into the argument. Beyond our M, CR, and HC modules, Wagner proposes modules to capture process- and environment-based arguments [27].

Research has been done on assurance deficits due to limitations of FTA and FMEA [28, 29]. Our goal is not to tackle these problems, but to construct confident arguments in case of proper HA. However, these deficits need to be addressed.

VI Conclusions and Future Work

We presented argumentation from the contribution of HA techniques to a system’s safety generalized by a modular argument pattern. We showed by an example and by discussion that this pattern (i) captures the structure of these causal reasoning techniques and (ii) extracts commonalities in reasoning and evidence among the three techniques. Furthermore, we broke down the evidence argument based on the solutions by using the causal reasoning and mitigation structure coming with the HA and prepared our pattern to be integrated with system models. Next, we asked trained master students in a practical course to apply a preliminary version of our pattern to construct their safety cases of real-life applications. Finally, we added value to HA by (i) integrating results scattered across several specialty HA techniques and (ii) integrating these results with the additional steps required in the construction of balanced, complete, and confident safety cases.

Future Work

After having interviewed our students, we can evaluate the usefulness of our pattern in an experiment with safety compliance practitioners. Confidence is increased by the fact that the argument structure mirrors the steps and the causal reasoning of an HA technique. Elaborating on arguing that an application of an HA technique is trustworthy is, however, an important direction to be investigated. Moreover, we plan to work on a formalization for an automated pattern instantiation. Finally, we consider a manual for using our pattern as important for the transfer to practice.

Acknowledgments

We thank our students of the advanced practical course for applying the argument pattern in their course assignments.