Skip to content
Snippets Groups Projects
Select Git revision
  • 4450
  • master default protected
  • 4259_requirementsTraceability
  • 4227
  • 4276_1
  • 4241
  • 4228
  • 3417
  • 3805-ScDocu
  • 3922
  • Testing-Disable-JFX
  • 3157-ScDocu
  • 3767
  • 3949
  • 3642
  • 3712
  • practical-course
  • 3640
  • 3482
  • 2.26
  • 2.25
  • 2.24
  • 2.22
  • 2.20
  • 2.16
25 results
Blame Permalink
assessment.html 9.51 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 Assessment of Assurance Cases</h1>
    <h2>Built-in Assurance Case Model Constraints.</h2>
    <p> Model constraints define semantic conditions that cannot be defined in
      the syntactic structure of a metamodel. Since different stakeholders may
      have different interpretations and the underlying assumptions may be
      overlooked, ExplicitCase requires to document goal decompositions via
      strategies. Therefore, a constraint on the assurance case model enforces
      the existence of a strategy node whenever the user wants to connect two
      goals. ExplicitCase checks many more constraints to ensure the integrity
      of assurance cases (e.g., to prevent the creation of invalid
      relationships). For example, another constraint to ensure the integrity of
      assurance cases is that only GSN connections permitted by the GSN standard
      can be modeled (e.g., a context node cannot be connected to a
      justification node). Avoidance of circular argumentation is another
      built-in constraint on the semantic level. </p>
    <h2>Status Notifications</h2>
    <p> ExplicitCase offers on-the-fly checks of arbitrary complexity. We define
      two types of notifications: warnings and errors. Errors signal missing or
      erroneous information, whereas warnings indicate assurance case nodes that
      need to be given further consideration. The type of notifications to be
      get may be manually selected by the user. For example, an error is
      signaled when a goal is changed and the supporting solution should be
      reconsider (see Fig. 6). Warnings are, for instance, raised for option
      entities that cannot be left in the final version of the assurance case,
      but must be appropriately resolved (see Fig. 7).</p>
    <figure> <img src="./pictures/sc_error.png"> <figcaption>Fig. 6 - Error
        reports in ExplicitCase.</figcaption> </figure>
    <figure> <img src="./pictures/sc_warning.png"> <figcaption>Fig. 7 -
        Warning reports in ExplicitCase.</figcaption> </figure>
    <h2> Feature 7: Change Impact Analysis</h2>
    <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>
    <h3>Why do we need maintenance? </h3>
    <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 re-certification and by extension re-generation of the
      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, offering safety
      engineers tool-supported re-evaluation is a big step forward.</p>
    <h3>What is the algorithm for maintenance? </h3>
    <p>The maintenance algorithm 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>
    <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>
    <h3>Assurance Case maintenance 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/MaintenanceExplicitCase.PNG"> <figcaption>Fig.
        8 - Stakeholders in ExplicitCase.</figcaption> </figure>
    <h3>Steps to maintenance in ExplicitCase</h3>
    <ol>
      <li> Follow the steps in the section <span class="italic"><span class="bold">"Steps
            to specify the contained elements of a assurance case module"</span></span>
        and build an assurance case module; </li>
      <p> <img src="./pictures/Maintenance1.PNG"></p>
      <li> Select the Solution Argument Element and right-click on it. Click 'Is
        Challenged'; </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 solution. Click 'Show potential
        change impact'; </li>
      <p> <img src="./pictures/Maintenance4.PNG"></p>
      <li> The potentially impacted argument elements, by the challenged
        solution, have turned their color to yellow; </li>
      <p> <img src="./pictures/Maintenance5.PNG"></p>
    </ol>
    <H2> Support for quantitative assessment of Assurance cases </H2>
<P> We implemented in AutoFOCUS the approached proposed by Duan et al. HASE 16, which computes the belief, disbelief and uncertainty of a GSN-argument based on the \emph{safety defeaters}. A safety defeater is anything that can reduce the confidence on the argument, such as, a software bug. </P>

<figure>
<img src="./pictures/quantitative-gsn.png" /img>
 </figure>

<P>
Consider the GSN-argument depicted in the figure above. It contains a main hazard which is broken down into two hazard sub-goals. Each 
GSN goal is annotated with the number of defeaters outruled and the total number of defeaters. In the tool, this is shown by the pair of numbers on the top left corner of GSN goals. For example, the top goal in the figure above is annotated with 15/29 denoting that 15 out of 29 safety defeaters have been outruled. Users can only enter these numbers for the leaf goals by editing their property sections, as illustrated by the figure below. Moreover, a weight is associated to all GSN nodes denoting the importance of these goal. From this data on the leaves of the GSN tree, the values of outruled and total defeaters for the remaining GSN nodes is computed by a weight sum. 
</P>


<figure>
<img src="./pictures/quant-properties.png" /img>
 </figure>

<P>
Intuitively, the greater the total number of defeaters, the lower the uncertainty is. Moreover, the greater the number of outruled defeaters the greater the belief on the GSN-argument and the lower the disbelief. 
The exact values for belief, disbelief and uncertainty can be computed from the values of outruled and total number of defeaters. We refer to the work Duan et al. HASE 16 on how exactly these values are computed. 
</P>

<P>
The belief, disbelief and uncertainty for the top most goal of GSN depicted in the figure above is shown by simply hovering the mouse over the goal as illustrated by the figure below. It is also available in the property section of the node. Moreover, the color of the numbers shown in the goal reflect the level of confidence. Red colors indicating a higher disbelief, while a green color a higher belief.
</P>

<figure>
<img src="./pictures/belief-disbelief-uncertainty.png" /img>
 </figure>
  </body>
</html>