Argument generation

The manual creation of a safety case is a costly and time-consuming process, thus automation can be used to generate parts of the process and product-based arguments.

The generated argument fragments can be then composed to obtain the complete safety case, with the possibility of customised tailoring of the links between the generated fragments. The two prerequisites for the argument fragments generation are: a) the source of information for the content of the arguments; and b) the target argument structure and format.

The SDaaS architecture captures provenance data related to the safety process and stores the artefacts used and produced during the process. The benefit of such data and artefacts is that it can be the foundation for safety cases. However, manual extraction of safety cases from this raw data is an expensive, time-consuming and error prone task.

Consequently, we take a step further and automate the generation of safety argument fragments arguing about both the product and the process aspects of safety.

5.3.1.1 Product-based argument

The product-based argument aims at showing that the product behaves as it should.

To automate the generation of such argument, the analysis and verification results can be exploited. We build on top of previous study [102] and we extract information about the failure behaviour of the system from the FPTC analysis results.

FPTC analysis results calculate the failure behaviour of a safety-critical system (see Appendix D for details about FPTC). Further analysis of these results can determine if certain failures/hazardous events (HEs) occur or not. This allows us to argue about how the system handles HEs. If an HE is present in the system, we produce a counter-evidence in the form of a trace to the source(s) of the HE. If it is not, we find the

Chapter 5: A Case Study on Cloud-Based Engineering of Safety-Critical Systems

component(s) that mitigated it. Mitigation can be partial or full. Full mitigation is when the failure does not propagate from a component’s input to its output while partial mitigation is when the failure is present on the output, but at least one of the input causes of the output failure has been mitigated by the component. The analysis for product-based argument fragment generation starts by parsing the FPTC results and following the pseudo code in Figure 5.3. Then the argument is formulated by constructing Claims and Strategies and supporting them by Evidences/Counter-Evidences following the rules in Figure 5.4. These rules are adapted from [102] where arguments were generated from safety contracts. Representations of safety arguments are discussed in Appendix E.

S: the set of system components;

HE: the set of undesired hazardous events M: list of mitigators;

PM: list of partial mitigators for each he in HE

{

if(he.criticality > negligible)

if(he exists on the system output) trace_failure_to_the_source();

else

for each component s in S if(he is present on s.input) if(he is not on s.output){

M.add(s);

find_the_mitigating_rule(); } else

if(the source of he on s.output != s.input) PM.add(s);

}

Figure 5.3: The pseudo code for analysing the FPTC results

5.3.1.2 Process-based argument

The process-based argument fragment aims at showing that the process mandated by the corresponding standard has been followed. The MDSafeCer (Model-driven Safety Certification) method [56] can be used to automate the generation of such arguments.

Via MDSafeCer, process models compliant with e.g., SPEM2.0 are transformed into composable process-based argumentation models compliant with e.g., SACM and pre-sented via e.g., GSN goal structures (see Appendix E for details about safety cases

R1: Make CLAIM "All causes of hazardous Failure Modes are acceptable"

R2: For each hazardous event {he} in the set HE, apply the following:

R2.1: If {he} is negligible, make a CLAIM "Hazardous Failure Mode {he}

is negligible"

R2.2: If {he} is not negligible, make a CLAIM "Hazardous Failure Mode of type {he} absent in contributory software functionality" and attach CONTEXT "Known causes of {he} failure mode"

R2.2.1: If {he} is present on the output, make COUNTER-EVIDENCE "The {he} Hazardous Failure Mode present in the contributory software functionality. Check traces."

R2.2.2: If {he} is not present on the system output, make a STRATEGY

"Argument over failure mechanisms" and attach a JUSTIFICATION "

Identified failure mechanisms describe all known causes of {he}

hazardous Failure Mode"

R2.2.2.1: make a CLAIM "The known causes of secondary failures of other components are acceptably handled" and leave it

undeveloped.

R2.2.2.2: make a CLAIM about the mitigators "Hazardous event {he}

has been mitigated by {mitigators}" and attach an EVIDENCE "

Mitigation details in the textual argument"

Figure 5.4: Rules for product-based argument construction

representation). This method supports compositional argumentation and reuse. Some of the aspects that should be covered in such an argument are the tools and techniques used as well as the qualification of both the tools and the persons using those tools and techniques. A model of such a process is needed as the source of information for the process-based argument generation. SPEM2.0 is a modelling language that can be used to model such a process, which can then be used as the source model for generation of the target process argument fragments [56]. Therefore, we can use our extended version of SPEM2.0 models; EXE-SPEM models as a source model for generating process-based argument fragments.

MDSafeCer provides rules for mapping a subset of SPEM2.0 elements into GSN and SACM concepts [57]. These rules are shown in Table 5.2. Using these rules, pro-cess model elements (expressed in SPEM2.0) can be mapped into a safety argument represented in either GSN or SACM.

MDSafeCer also presents a set of rules for structuring the process-related safety argu-ment. It starts with a top claim arguing that the process has been compliant with the standards. This claim is then decomposed further until it reaches an atomic

process-Chapter 5: A Case Study on Cloud-Based Engineering of Safety-Critical Systems Table 5.2: Concept mapping as proposed by MDSafeCer [56]

SPEM2.0 GSN SACM

Task ta Goal Claim

Role ro Solution InformationElement

Work product wp Solution InformationElement

Tool to Solution InformationElement

Guidance gu Solution InformationElement

Relationship between ta and ro/to/wp/gu supportedby AssertedEvidence

related unit [57]. The detailed rules for structuring a GSN process-based safety argu-ment fragargu-ment [57] are shown below. These rules are applied for each activity in the process model.

1. Create the top-level goal ID:G1 and statement: “The task ta has been carried out”. Create the context to be associated to G1. Context ID:C1 and statement:

“Standard x”, where x is a variable. Create an inContextOf link to relate G1 and C1. Develop the goal G1 further by creating four strategies and for each strategy a set of sub-goals.

(a) S1: “Argument over roles R”.

(b) S2: “Argument over work products W”.

(c) S3: “Argument over tools T”.

(d) S4: “Argument over guidance G”.

2. Further develop strategy S1 and for every role ro in R: create a goal G1.ro “ro is certified” and develop this goal further by creating the corresponding solution E.ro “ro’s certifications” and the supportedBy links necessary to link S1 with G1.ro and G1.ro with E.ro.

3. Further develop strategy S2 and for every work product wp in W: create a goal G1.wp “wp is available” and develop this goal further by creating the correspond-ing solution E.wp “ wp-related name” and the supportedBy links necessary to link S2 with G1.wp and G1.wp with E.wp.

4. Further develop strategy S3 and for every tool to in T: create a goal G1.to “to is qualified” and develop this goal further by creating the corresponding solution E.to “to’s qualifications” and the supportedBy links necessary to link S3 with G1.to and G1.to with E.to.

5. Further develop strategy S4 and for every guidance gu in G: create a goal G1.gu

“Guidance gu has been followed” and develop this goal further by creating the corresponding solution E.gu “ gu where and how” and the supportedBy links necessary to link S4 with G1.gu and G1.gu with E.gu.