Assurance Case Maintenance

Throughout the operational life of any system, changing regulatory requirements, additional assurance evidence and a changing design can challenge the corresponding assurance case. In order to maintain an accurate account of the assurance of the system, all such challenges must be assessed for their impact on the original assurance argument.

Why do we need maintenance?

An assurance case consists of many inter-dependent parts: requirements, argument, evidence, design and process information. As a result, a single change to an assurance case may necessitate many other consequential changes - creating a 'ripple effect'. It is significant to recognize the importance of every challenge to an assurance case. Furthermore, the indirect impact is crucial and one of the biggest challenges. Any of these challenges imply the re-generation of the system's assurance case of a system. The construction and maintenance of assurance case arguments is expensive and tedious, as it is mainly a manual process that requires a considerable amount of time. Therefore, ExplicitCase provides safety engineers with tool-supported Assurance Case Maintenance.

Assurance Case Maintenance (CIA) for assurance cases

The Assurance Case Maintenance includes the handling of challenges regarding the following different argument elements.

If the challenged item is a Goal, it challenges its relationship to both the parent Goal and to the supporting evidence provided. It also challenges the solutions that support the Goal.
If the challenged item is a Solution, it challenges its role as a solution to all goals relying upon it through the SupportedBy relationship.
If the challenged item is a Context, it challenges the relationship with all goals previously expressed in the context of that item using the InContextOf relationship. More specifically, changing a Context challenges all goals, strategies and solutions that introduce this Context. In addition, it challenges all goals, strategies and solutions which inherit this Context.

Potential vs. actual change effect

The rules described above constitute the potential change effect and not necessarily the actual change. There is a significant difference between actual and potential change. The nodes to which the impact of the challenge in a connected GSN node propagates are called impacted nodes. The potential change includes further analysis of the possible effects on the rest of GSN nodes after one element is challenged. A safety engineer has to review all the potential challenges and decide upon them. ExplicitCase implements as a starting point, the potential change effect.

Assurance Case Maintenance in ExplicitCase

The assurance case maintenance in ExplicitCase requires the participation of different entities and stakeholders (see Fig. 8). The system modeling is done by the system engineer and the GSN modeling of the assurance cases by the safety engineer. The safety engineer has also responsibilities such as hyperlinking GSN with System Models and annotating GSN assurance cases with maintainability information. ExplicitCase recognizes challenges to validity of GSN assurance cases and identifies the impact of a GSN node challenge. Finally, the safety engineer gives input to the system engineer regarding the reasons why, after a change in one system model element, other system model elements, should be reviewed.

Consistency Checks between System and Safety Case Models.

Steps

Create an assurance case module;

Select an argument element in the Model Navigator View and right-click on it. Select the Set to Challenged button from the opened Context Menu;

The challenged solution has changed its color to red;

Right-click again on the challenged argument element in the Model Navigator View. Select the Show Potential Change Impact button from the opened Context Menu;

The potentially impacted argument elements, by the challenged element, have turned their color to yellow;