-
Carmen Carlan authoredIssue-ref: 3950 Signed-off-by:
Carmen Carlan <carlan@fortiss.org>Carmen Carlan authoredIssue-ref: 3950 Signed-off-by:Carmen Carlan <carlan@fortiss.org>
maintenance.html 5.70 KiB
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<title></title>
<style type="text/css">
h1 {
text-decoration: underline;
}
h1, h2, h3, h4 {
color: #336699;
}
span.bold {
font-weight: bold;
}
span.italic {
font-style: italic;
}</style>
</head>
<body>
<h1>Support for Assurance Case Maintenance</h1>
<p> 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.</p>
<!--##################### Need for maintenance-->
<h2>Why do we need maintenance? </h2>
<p>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 change impact analysis.</p>
<!--##################### CIA for assurance cases-->
<h2>Change Impact Analysis (CIA) for assurance cases</h2>
<p>The change impact analysis includes the handling of challenges regarding
the following different argument elements.</p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>If the challenged item is a Solution, it challenges its role as a
solution to all goals relying upon it through the SupportedBy
relationship.</p>
</li>
<li>
<p>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.</p>
</li>
</ul>
<!--##################### Potential vs actual change effect-->
<h3>Potential vs. actual change effect</h3>
<p>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.</p>
<!--##################### CIA in ExplicitCase-->
<h3>Change impact analysis in ExplicitCase</h3>
<p> 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.</p>
<figure> <img src="./pictures/maintenance-process.PNG"> <figcaption>Consistency Checks between System and Safety Case Models.</figcaption> </figure>
<!--##################### CIA steps-->
<h3>Steps</h3>
<ol>
<li> Create an assurance case module; </li>
<p> <img src="./pictures/maintenance1.PNG"></p>
<li> Select an argument element in the <span class="italic">Model Navigator View</span> and right-click on it.
Select the <span class="bold">Set to Challenged</span> button from the opened
<span class="italic">Context Menu</span>; </li>
<p> <img src="./pictures/maintenance2.PNG"></p>
<li> The challenged solution has changed its color to red; </li>
<p> <img src="./pictures/maintenance3.PNG"></p>
<li> Right-click again on the challenged argument element in the <span class="italic">Model Navigator View</span>.
Select the <span class="bold">Show Potential Change Impact</span> button from the opened
<span class="italic">Context Menu</span>; </li>
<p> <img src="./pictures/maintenance4.PNG"></p>
<li> The potentially impacted argument elements, by the challenged
element, have turned their color to yellow; </li>
<p> <img src="./pictures/maintenance5.PNG"></p>
</ol>
</body>
</html>