Skip to content
Snippets Groups Projects
Commit 1afc2724 authored by Tiziano Munaro's avatar Tiziano Munaro
Browse files

Merge remote-tracking branch 'origin/master' into 3948

parents 6ee9866e d98a1781
No related branches found
No related tags found
1 merge request!25[3948] Adapt help pages for Component Modeling
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 205 additions and 319 deletions
org.fortiss.af3.rcp.help/html/.ratings
+ 1
− 1
View file @ 1afc2724
......@@ -6,7 +6,7 @@ code_specification.html 6abb0c1e49b2545e5b3d81444481689ca5bbd611 RED
component_architecture.html 07026f0362ee3afa6f9e90223a04d429e1430aa1 YELLOW
cosimulation_with_af3.html a2daa6bb9a39083cf2498df26df54572f69c38da RED
data_dictionary.html 1cfdcfe5879e210456f78095a8b7b4790ab409af RED
getting_started.html 0a0a2f68bda7f69787169714c140c265db0c7bbe RED
getting_started.html 6e6cfc36a1c621f4a5740aaa155bd8a067790c1f YELLOW
hierarchical_state_automaton.html cebd924f514cd50f229c7745e173f76bd0c0038b RED
loading_standard_examples.html a2693477f0afb902f2899d12b3166f01378f6d8d RED
mode_automaton.html dc395eab03cb6920580f54e317c3d203e64cb496 RED
......
org.fortiss.af3.rcp.help/html/assuranceCases/.ratings
+ 3
− 4
View file @ 1afc2724
assessment.html dca019e58a7231bc5d4fd24c6817bbea6bac5242 GREEN
creation.html 83b2abc791928b79d6ac7b6f4659974db13ce411 GREEN
maintenance.html eabfbf0e6f1932d19e4be3701e481607bed9088d GREEN
reports.html 20e9ab816448b33ff09fcd2ccbd531d2a4caeeb7 GREEN
assessment.html a292feefc28c2c5932e914c0cec6e8db6075647d GREEN
creation.html 6d9e8424fcf3d0c1cbcdb8d2e92f6ae59b29f8e7 GREEN
maintenance.html e9285908f57070eead1444316405873284cf67ed GREEN
org.fortiss.af3.rcp.help/html/assuranceCases/assessment.html
+ 7
− 114
View file @ 1afc2724
......@@ -19,122 +19,12 @@ 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>
<h1>Support for Quantitative Assessment of Assurance Cases</h1>
<P> We implemented in AutoFOCUS the approached proposed by <a href="https://ieeexplore.ieee.org/document/7423138">Duan et al.</a>, which computes the belief, disbelief and uncertainty of a GSN-argument based on the 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>
<figcaption>Displaying the quantitative assessment on the GSN structure.</figcaption>
</figure>
<P>
......@@ -145,11 +35,12 @@ GSN goal is annotated with the number of defeaters outruled and the total number
<figure>
<img src="./pictures/quant-properties.png" /img>
<figcaption>The property view where the GSN nodes'attributes specific to quantitative assessment can be set.</figcaption>
</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.
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 <a href="https://ieeexplore.ieee.org/document/7423138">Duan et al.</a> on how exactly these values are computed.
</P>
<P>
......@@ -158,6 +49,8 @@ The belief, disbelief and uncertainty for the top most goal of GSN depicted in t
<figure>
<img src="./pictures/belief-disbelief-uncertainty.png" /img>
<figcaption>Displaying belief, disbelief and uncertainty attributes for a GSN node.</figcaption>
</figure>
</body>
</html>
\ No newline at end of file
org.fortiss.af3.rcp.help/html/assuranceCases/creation.html
+ 158
− 178
View file @ 1afc2724
This diff is collapsed.
org.fortiss.af3.rcp.help/html/assuranceCases/maintenance.html
+ 36
− 22
View file @ 1afc2724
......@@ -25,6 +25,9 @@ font-style: italic;
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
......@@ -32,12 +35,15 @@ font-style: italic;
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>
<h2>Change Impact Analysis for Assurance Cases</h2>
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>
......@@ -60,6 +66,9 @@ font-style: italic;
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
......@@ -69,7 +78,10 @@ font-style: italic;
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>Change Impact Analysis in ExplicitCase</h3>
<!--##################### 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
......@@ -81,25 +93,27 @@ font-style: italic;
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>
<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> 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> 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 solution. Click 'Show potential
change impact'; </li>
<p> <img src="./pictures/Maintenance4.PNG"></p>
<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
solution, have turned their color to yellow; </li>
<p> <img src="./pictures/Maintenance5.PNG"></p>
element, have turned their color to yellow; </li>
<p> <img src="./pictures/maintenance5.PNG"></p>
</ol>
</body>
</html>
\ No newline at end of file
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance1.PNG deleted 100644 → 0
+ 0
− 0
View file @ 6ee9866e
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance1.PNG

23.8 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance2.PNG deleted 100644 → 0
+ 0
− 0
View file @ 6ee9866e
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance2.PNG

53.8 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance3.PNG deleted 100644 → 0
+ 0
− 0
View file @ 6ee9866e
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance3.PNG

23.5 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance4.PNG deleted 100644 → 0
+ 0
− 0
View file @ 6ee9866e
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance4.PNG

60.4 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance5.PNG deleted 100644 → 0
+ 0
− 0
View file @ 6ee9866e
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/Maintenance5.PNG

23.6 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/add-argument-elements.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/add-argument-elements.png

72.6 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/add-relationships.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/add-relationships.png

50.2 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-coloring.PNG 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-coloring.PNG

8.78 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-properties.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-properties.png

81.8 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-states-raw.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-states-raw.png

55.1 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-states.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argument-element-states.png

129 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argumentation-modules.PNG 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/argumentation-modules.PNG

7.02 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/away-entity.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/away-entity.png

129 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/create-assurance-case.png 0 → 100644
+ 0
− 0
View file @ 1afc2724
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/create-assurance-case.png

24.4 KiB

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment