Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • af3/af3-rcp
1 result
Show changes
Showing
with 811 additions and 941 deletions
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Further Resources</title>
</head>
<body>
<h2><u><font color="#336699">Further Resources</font></u></h2>
<h3>Resources for Users</h3>
<ul>
<li><a class="email" href="mailto:af_user@lists.fortiss.org">Users Mailing List</a>: subscribe <a href="https://af3-developer.fortiss.org/projects/autofocus3/wiki/MailinglistSubscription%23" target="_blank">here</a></li>
<li><a href="https://af3.fortiss.org/" target="_blank">AF3 Website</a></li>
<li><a href="https://af3.fortiss.org/docs/screencasts/" target="_blank">Screencasts</a></li>
<li><a href="https://af3.fortiss.org/docs/tutorials/" target="_blank">Tutorials</a></li>
<li><a href="https://af3.fortiss.org/research/">Research Papers</a></li>
</ul>
<h3>Resources for Developers</h3>
<ul>
<li><a class="email" href="mailto:af_devel@lists.fortiss.org">Developers Mailing List</a>: subscribe <a href="https://af3-developer.fortiss.org/projects/autofocus3/wiki/MailinglistSubscription%23" target="_blank">here</a></li>
<li><a href="https://af3-developer.fortiss.org/projects/autofocus3/wiki/Developers_documentation" target="_blank">Developers Documentation Overview</a></li>
<li><a href="https://af3-developer.fortiss.org/projects/autofocus3/wiki/AF3_Developer_Installation" target="_blank">AF3 Developer Installation</a></li>
</ul>
</body>
</html>
\ No newline at end of file
assessment.html a292feefc28c2c5932e914c0cec6e8db6075647d GREEN
creation.html 6d9e8424fcf3d0c1cbcdb8d2e92f6ae59b29f8e7 GREEN
maintenance.html e9285908f57070eead1444316405873284cf67ed GREEN
ac.MainPage.html d6af9e80c775991c355f03d64065716fe7c9167d GREEN
assessment.html f71d2d444e00bef3209cf363029ce4571cf37eff GREEN
creation.html ff97fd2003013963cd490f4bb5c185d8d05739d9 GREEN
maintenance.html c31991029cde2ae71ccbb25deaa1df6a34d04593 GREEN
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- Documentation of MIRA - Model-based Integrated Requirements. -->
<html>
<head>
<link rel="stylesheet" type="text/css" href="../layout/stylesheet.css"/>
<title>Assurance Cases Main-Page</title>
<style>
.center {
margin: auto;
width: 60%;
padding: 10px;
}
</style>
</head>
<body>
<div class="header">
<div class="box">
<div class="navbar">
<div class="dropdown">
<a href="../getting_started.html" style="padding:0;">
<button class="btn" id="hamburger" onclick="javascript:window.location.href='../getting_started.html'">
<label for="hamburger" class="hamburger">
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
</label>
</button>
</a>
<div class="dropdown-content">
<a href=".././rcphelp.gettingstarted.MainPage.html">Getting Started</a>
<a href="../requirements/MIRA.requirements.MainPage.html">Requirements Engineering</a>
<a href="../ModandSim/ModandSim.MainPage.html">Modeling and Simulation</a>
<a href="../ta/DepandCodGen.MainPage.html">Deployment and Code Generation</a>
<a href="../dse/dse.MainPage.html">Design Space Exploration (DSE)</a>
<a style="background-color:#f2f2f2;">Assurance Case Modeling</a>
</div>
</div>
<div class="topnav-right">
<a href="mailto:af_user@lists.fortiss.org?subject=Reporting 'ac.MainPage.html' Documentation Problem!&body= Dear AutoFOCUS3 team, I am reporting an issue related to Assurance Cases Main Page.
{Please specify the problem precisely here.}.">Report a Problem?</a>
</div>
</div>
</div>
</div>
<div class="box">
<button onclick="topFunction()" id="upBtn" title="Go to top">Top</button>
<div class="row center">
<div class="column">
<div class="mainfeature">
<h2>Assurance Case Modeling</h2>
<img src="../assuranceCases/pictures/sc_overview.png"/>
<ul>
<li><a href="creation.html">Modeling GSN-based Assurance Cases</a></li>
<li><a href="assessment.html">Quantitative Assessment of Assurance Cases</a></li>
<li><a href="maintenance.html">Assurance Case Maintenance</a></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</div>
<script src="../layout/jsscript/topBtn.js">
</script>
<div class="footer">
<p>
&copy; 2020 <a href="https://www.fortiss.org/">fortiss GmbH</a> &nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/publications/software/autofocus-3#c2007">Contact</a>&nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/imprint">Imprint</a>
</p>
</div>
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- Documentation on Support for Quantitative Assessment of Assurance Cases. -->
<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 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>
<head>
<link rel="stylesheet" type="text/css" href="../layout/stylesheet.css"/>
<title>Quantitative Assessment of Assurance Cases</title>
</head>
<body>
<div class="header">
<div class="box">
<div class="navbar">
<div class="dropdown">
<a href="../getting_started.html" style="padding:0;">
<button class="btn" id="hamburger" onclick="javascript:window.location.href='../getting_started.html'">
<label for="hamburger" class="hamburger">
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
</label>
</button>
</a>
<div class="dropdown-content">
<button class="dropdown-btn">Getting Started<i class="caret-down"></i></button>
<div class="dropdown-container">
<button class="dropdown-btn">Resources for Users<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href=".././managing_projects.html">Managing AutoFOCUS3 Projects</a>
<a href=".././examples.MainPage.html">Examples</a>
<a href=".././tipsAndTricks.html">Tips &amp; Tricks</a>
<a href=".././af3_faq.html">FAQs</a>
</div>
<a href=".././rcphelp.gettingstarted.MainPage.html">Resources for Developers</a>
<a href=".././rcphelp.gettingstarted.MainPage.html">Contact</a>
</div>
<button class="dropdown-btn">Requirements Engineering<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../requirements/MIRA.requirements_analysis.html"> Requirements Analysis Node</a>
<a href="../requirements/MIRA.glossary.html">Glossary</a>
<a href="../requirements/MIRA.requirements.html">Requirements</a>
</div>
<button class="dropdown-btn">Modeling and Simulation<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/model_element_attributes.html" >Introduction to Graphical Modeling Interface</a>
<a href="../ModandSim/component_architecture.html">Component Architecture Modeling</a>
<a href="../ModandSim/data_dictionary.html">Data Dictionary: Types and Functions</a>
<a href="../ModandSim/refactoring.html">Refactoring</a>
<a href="../ModandSim/model_markers_view.html">On-the-fly Checks</a>
<button class="dropdown-btn">Behavior Modeling<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/code_specification.html">Code Specification</a>
<a href="../ModandSim/state_automaton.html">State Automata</a>
<a href="../ModandSim/hierarchical_state_automaton.html">Hierarchical State Automata</a>
<a href="../ModandSim/mode_automaton.html"> Mode Automata</a>
</div>
<button class="dropdown-btn">Simulation<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/simulation_with_af3.html">Simulation</a>
<a href="../ModandSim/operatorpanels.html">Operator Panels</a>
<a href="../ModandSim/operatorpanels_advanced.html">Advanced Operator Panels</a>
<a href="../ModandSim/cosimulation_with_af3.html"> Co-Simulation and FMI Support</a>
</div>
</div>
<button class="dropdown-btn">Deployment and Code Generation<i class="caret-down"></i></button>
<div class="dropdown-container">
<button class="dropdown-btn">Modeling Technical Architectures<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ta/platform_architecture.html">Platform Architecture</a>
<button class="dropdown-btn">Supported Platform Architectures<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ta/platform_architecture_generic.html">Generic Platform Architecture</a>
<a href="../ta/platform_architecture_hierarchical.html">Hierarchical Platform Architecture</a>
<a href="../ta/platform_architecture_raspberrypi.html">RaspberryPi Platform Architecture</a>
</div>
<a href="../ta/task_architecture.html">Task Architecture</a>
<a href="../ta/partition_architecture.html"> Partition Architecture</a>
<a href="../ta/allocations.html"> Deployments/Allocations</a>
<a href="../ta/system_schedule.html"> System Schedule</a>
</div>
<a href="../ta/code_generation.html">Code Generation</a>
</div>
<button class="dropdown-btn">Design Space Exploration (DSE)<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../dse/dse_perspective.html">DSE Perspective Overview</a>
<a href="../dse/dse_dashboard.html">DSE Dashboard</a>
<a href="../dse/constraints.html">Constraint Modeling</a>
<a href="../dse/objectives.html">Objective Modeling</a>
<a href="../dse/synthesis.html">Deployment/Schedule Synthesis (Exploration)</a>
<a href="../dse/visualization.html">Solution Visualization</a>
</div>
<button class="dropdown-btn">Assurance Case Modeling<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="creation.html">Modeling GSN-based Assurance Cases</a>
<a style="background-color:#f2f2f2;">Quantitative Assessment of Assurance Cases</a>
<a href="maintenance.html">Assurance Case Maintenance</a>
</div>
</div>
</div>
<div class="topnav-right">
<a href="mailto:af_user@lists.fortiss.org?subject=Reporting 'assessment.html' Documentation Problem!&body= Dear AutoFOCUS3 team, I am reporting an issue related to Assurance Case Modeling.
{Please specify the problem precisely here.}.">Report a Problem?</a>
</div>
</div>
</div>
</div>
<div class="box">
<button onclick="topFunction()" id="upBtn" title="Go to top">Top</button>
<h1>Quantitative Assessment of Assurance Cases</h1>
<P> We implemented in AutoFOCUS the approached proposed by <a target="_blank" rel="noopener noreferrer" href="https://doi.org/10.1109/HASE.2016.52">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"/>
<figcaption>Displaying the quantitative assessment on the GSN structure.</figcaption>
</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>
</P>
<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>
<figure>
<img src="./pictures/quant-properties.png"/>
<figcaption>The property view where the GSN nodes'attributes specific to quantitative assessment can be set.</figcaption>
</figure>
<P>
<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 <a href="https://ieeexplore.ieee.org/document/7423138">Duan et al.</a> on how exactly these values are computed.
</P>
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 target="_blank" rel="noopener noreferrer" href="https://doi.org/10.1109/HASE.2016.52">Duan et al.</a> on how exactly these values are computed.
</P>
<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>
<figcaption>Displaying belief, disbelief and uncertainty attributes for a GSN node.</figcaption>
</P>
</figure>
</body>
<figure>
<img src="./pictures/belief-disbelief-uncertainty.png"/>
<figcaption>Displaying belief, disbelief and uncertainty attributes for a GSN node.</figcaption>
</figure>
</div>
<script src="../layout/jsscript/topBtn.js"></script>
<script src="../layout/jsscript/submenuScript.js"></script>
<div class="footer">
<p>
&copy; 2020 <a href="https://www.fortiss.org/">fortiss GmbH</a> &nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/publications/software/autofocus-3#c2007">Contact</a>&nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/imprint">Imprint</a>
</p>
</div>
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- Documentation on Modeling GSN-based Assurance Cases. -->
<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> ExplicitCase - An Assurance Case Editor in AF3</h1>
<p>AutoFOCUS3 contains an editor, named ExplicitCase, which supports the
construction of modular assurance cases, in compliance with the <a href="https://www.goalstructuringnotation.info/">Goal
Structuring Notation (GSN) standard</a>.</p>
<h2>Support for Assurance Case Creation</h2>
<p> Assurance cases constitute a proven technique to systematically
demonstrate the safety/security/reliability of such systems using existing
information about the system, its environment and development context,
facilitating the bridging of the regulatory gap. Three parts can be
identified as part of an assurance case. First, the <span class="bold">goal</span>
that has to be achieved. Second, the <span class="bold">evidence</span>
for achieving this goal and third, the structured argument constituting
the <span class="bold"> systematic relationship between the goal the
evidence</span>. Assurance cases can be designed in a modular approach,
by subdividing complex assurance cases into interconnected modules of
assurance arguments and evidence.</p>
<h3>What is the Goal Structuring Notation (GSN)?</h3>
<p> The Goal Structuring Notation (GSN) is a well-known description
technique for the development of engineering arguments to construct
assurance cases. GSN uses a graphical argument notation to explicitly
document the elements and structure of an argument and the argument's
relationship of this evidence. An argument, based on GSN, may consists of
several elements: <span class="italic">Goals</span> are the claims of an
argument, whereas items of evidences are captured under <span class="italic">Solutions</span>.
When documenting how claims are said to be supported by sub-claims, the <span
class="italic">Strategy</span>-element is used and can be linked to <span
class="italic">Goals</span>. A <span class="italic">Context</span>
element captures and enables citation of information that is relevant to
the argument. Rationale for a strategy can be described by a <span class="italic">Justification</span>
element. GSN provides two types of linkage between elements: <span class="italic">SupportedBy</span>
and <span class="italic">InContextOf</span>. <span class="italic">SupportedBy</span>
relationships indicate inferential or evidential relationships between
elements. <span class="italic">InContextOf</span> relationships declare
contextual relationships. The benefit of having a structured graphical
notation for assurance cases is that it supports the presentation of
assurance cases to non-safety experts in a comprehensive manner.</p>
<h4> GSN-based assurance cases in AF3</h4>
<p> ExplictCase is based on a metamodel derived from the
<a href="https://www.goalstructuringnotation.info/">GSN standard</a> and
offers a graphical editor facilitating the model-based development of
assurance cases. An overview of the editor is shown in Fig. 1. The editor
allows the user to build assurance cases via GSN, as follows:</p>
<ul>
<li> GSN defined node elements (i.e., Goal, Strategy, Solution,
Assumption, Context, Justification);</li>
<li> GSN defined relationships between node elements (i.e., SupportedBy
and InContextOf);</li>
</ul>
<h3>Steps to create an assurance case for your project</h3>
<ol>
<li> Go to an AF3 project, in the Model
Navigator View and right-click on it;</li>
<li> Select the Assurance Package item from the <span class="italic">Context Menu</span>;</li>
<p> <img src="./pictures/create-assurance-package.png"></p>
<li> Go to the newly created assurance package in the
Model Navigator View, and right-click on it;</li>
<li> Select the Assurance Case item from the <span class="italic">Context Menu</span>;</li>
<p> <img src="./pictures/create-assurance-case.png"></p>
<li> Go to the newly created assurance case, in the Model
Navigator View, and double-click on it, so that the
editor (Modeling Diagram) in which you can model the assurance case opens.</li>
</ol>
<h2>Tool-based Support for Handling Large Arguments: Modular Assurance Cases</h2>
<h3> What are modular assurance cases? Why shall assurance cases be modular?</h3>
<p> One way of designing assurance cases is by following the modular
approach. In GSN, an assurance case module contains the objectives,
evidence, argument and context associated with one aspect of the assurance
case. In addition to the GSN argument elements presented in the previous
paragraph, a module may contain away entities such as <span class="italic">away
goals</span>, <span class="italic">away solutions</span> and <span class="italic">away
context</span> elements. Away entities are references to goals,
solutions or context elements in another module. Away goals cannot be
(hierarchically) decomposed and further supported by sub-entities within
the current module; rather, decomposition needs to occur within the
referenced module. Inter-modular relationships are of two types: namely <span
class="italic"> supported by</span> and <span class="italic">in context
of</span> relationships. A supported by relationship denotes that
support for the claim presented by the away goal or away solution in one
module is intended to be provided from an argument in another module. When
there is an away context element in a module, that module is connected to
another module by an in context of relationship; relationship that
indicates that the context of a certain claim will be presented in details
in another module.</p>
<p>Modularity of assurance cases has various advantages, namely:</p>
<ul>
<li> Separation of concerns, as modules usually correspond to sub-systems;</li>
<li> Improved comprehensibility;</li>
<li> Minimization of the impact of required changes to an assurance case;</li>
</ul>
<h3> Modular assurance cases in ExplicitCase</h3>
<p> ExplicitCase enables the user to model an assurance case containing
several modules which are connected to each other through intra-module
connections. Each such module contains an assurance
argumentation structure, build up by GSN-defined elements specific to
modularity in assurance cases (i.e., Away Goals, Away
Solutions, Away Contexts, Contracts) connected to each other by
GSN-defined relationships. Each argumentation node within a module has a
public indicator, which determines whether the element may be referenced
in another module, or not.</p>
<figure> <img src="./pictures/argumentation-modules.png"> <figcaption>
Assurance case modules.</figcaption> </figure>
<h3> Steps to create an assurance case module</h3>
<p> </p>
<ol>
<li> After creating your assurance case, you can specify the contained
assurance case modules. To add an assurance case module, drag and drop an
Argument Module from the <span class="italic">Model Elements View</span> on the right side to your diagram;
<li> To specify properties of the module, go to the <span class="italic">Properties View</span>.
There you can assign the
assurance case module an id (in the Element Identifier text box), a comment and a name.
All other text box may not be filled in;</li>
<p> <img src="./pictures/module-creation.png"></p>
<li> To generate intra-module connections, based on the away entities, go
to your assurance case, in the <span class="italic">Model Elements View</span> and right-click on it. Select the
"Generate Module Connections" item from the <span class="italic">Context Menu</span>. Do consider that, if you do not have any
away entities in your assurance case modules, you will not have any
relationship between your modules.</li>
<p> <img src="./pictures/generate-module-connections.png"></p>
</ol>
<h3>Steps to add argument elements in modules</h3>
<p> Once you are done with specifying the modules of your assurance case,
you can describe the assurance argument structure contained by these
modules by adding argumentation elements.</p>
<ol>
<li> Go to one of your assurance case modules from the <span class="italic">Model Elements View</span> and double-click on
it, so that the editor (a Modeling Diagram) in which you can model the assurance case
module appears;</li>
<li> To add an argument element,
drag and drop a goal/away goal/strategy/solution/away solution/strategy/justification/assumption/context/away context
from the <span class="italic">Model Elements View</span> on the right side to your diagram;
<p> <img src="./pictures/add-argument-elements.png"></p>
<li> In order to create relationships between your argument elements,
namely SupportedBy and InContextOf relationships, as specified in the
<a href="https://www.goalstructuringnotation.info/">GSN standard</a>,
add exit and entry points to the elements correspondingly and then connect the points with each other.
The tool constraints the user to only be able to create valid relationships (as described in the standard). </li>
<p> <img src="./pictures/add-relationships.png"></p>
</ol>
<h3> Setting properties of assurance argumentation elements</h3>
<p> Properties of assurance argumentation elements can be set in the
<span class="italic">Properties View</span>. There are two types of
properties, namely general properties, which may be set to all types of
GSN elements and specific properties, which may be set only to particular
types of GSN elements. The following properties can be set to any type of GSN node:</p>
<ol>
<li> Name of the GSN element in the <span class="bold">Name</span>
text box;</li>
<li> Comment regarding the GSN element in the <span class="bold">Comment</span>
text box;</li>
<li> Element identifier of the argumentation element in the <span class="bold">ID</span> text box;</li>
<li> Claim of the GSN element in the <span class="bold">Claim</span>
text box. This text may and should be filled in for all types of GSN
elements, except for solution elements.
Furthermore, you cannot set claims to away entities, as they have the
same claim as the assurance argument element they point to;</li>
<li> Add a reference to a document to the GSN element by pressing the <span class="bold">Add document</span> button. A
file browser will open and you can select any file of type
pdf/Word/Excel;</li>
<li> To delete a reference, press the <span class="bold">Remove
document</span> button;</li>
<li> To give some further explanation of the reference to a certain
document, use the <span class="bold">Reference
Explanation</span> text box;</li>
</ol>
<p><img src="./pictures/argument-element-properties.png"></p>
<h3> Setting particular properties of <span class="italic">Away Entities</span></h3>
<p> Away entities act as interface of argument modules. An away entity references an argument element
in another module. Right-click on the away entity in the Model Navigator View. A <span class="italic">Context Menu</span> will appear.
Click on the
<span class="bold">Connect to Goal/Solution/Context</span>
menu item and a wizard will appear. Select from the assurance argument elements
that appear in the wizard one to which you want your away entity to point
to. If the selected node was set as private, you will be asked if you want
to change the visibility of the node. If you do not that, the reference will not be
done. Only public elements may be referenced by away entities.
In the <span class="italic">Properties View</span>, in the
<span class="bold">Referenced module ID</span>
the ID of the module containing the node referenced by the away entity
node is automatically filled in. After setting a reference to an entity,
you can go again in the <span class="italic">Model Navigator View</span>
and right-click on the away entity and select "Go To Refenced ..." button from
the <span class="italic">Context Menu</span>.</p>
<p> </p>
<p> <img src="./pictures/away-entity.png"></p>
<h3>Setting states to GSN elements</h3>
<p>According to the <a href="https://www.goalstructuringnotation.info/">GSN standard</a>,
an argument element may take different states in the
course of the assurance case development. One can right-click on a GSN
element in the <span class="italic">Model Navigator View</span>
and select the following states: <span class="italic">private/public</span>,
<span class="italic">instantiated/uninstantiated</span>,
<span class="italic">developed/undeveloped</span> and <span class="italic">supported by
contract</span>. </p>
<p><img src="./pictures/argument-element-states.png"></p>
<h2>Visual aids</h2>
<p> Different coloring of GSN elements raises the assurance case developer's
awareness about the existence of undeveloped or uninstantiated entities
(see Fig. 5). In addition, contract modules have a distinct coloring in
order to distinguish them from regular argumentation modules. We do not
allow users to color elements by themselves, in order to keep a certain
meaning of each coloring so that anyone can easily "read" the coloring.
This is motivated, by the fact that the
<a href="https://www.goalstructuringnotation.info/">GSN standard</a>
says that, <span class="italic">In
cases where the elements defined in these sections are used in the
development of instantiations of the patterns to produce individual
assurance arguments, it is important to ensure that they are all
removed, or instantiated, in the final, delivered, version of the
argument</span>. </p>
<figure> <img src="./pictures/argument-element-coloring.png"> <figcaption>
Different coloring for different node properties.</figcaption> </figure>
<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
<a href="https://www.goalstructuringnotation.info/">GSN standard</a>
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>
</body>
<head>
<link rel="stylesheet" type="text/css" href="../layout/stylesheet.css"/>
<title>ExplicitCase Assurance Case Editor</title>
</head>
<body>
<div class="header">
<div class="box">
<div class="navbar">
<div class="dropdown">
<a href="../getting_started.html" style="padding:0;">
<button class="btn" id="hamburger" onclick="javascript:window.location.href='../getting_started.html'">
<label for="hamburger" class="hamburger">
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
</label>
</button>
</a>
<div class="dropdown-content">
<button class="dropdown-btn">Getting Started<i class="caret-down"></i></button>
<div class="dropdown-container">
<button class="dropdown-btn">Resources for Users<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href=".././managing_projects.html">Managing AutoFOCUS3 Projects</a>
<a href=".././examples.MainPage.html">Examples</a>
<a href=".././tipsAndTricks.html">Tips &amp; Tricks</a>
<a href=".././af3_faq.html">FAQs</a>
</div>
<a href=".././rcphelp.gettingstarted.MainPage.html">Resources for Developers</a>
<a href=".././rcphelp.gettingstarted.MainPage.html">Contact</a>
</div>
<button class="dropdown-btn">Requirements Engineering<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../requirements/MIRA.requirements_analysis.html"> Requirements Analysis Node</a>
<a href="../requirements/MIRA.glossary.html">Glossary</a>
<a href="../requirements/MIRA.requirements.html">Requirements</a>
</div>
<button class="dropdown-btn">Modeling and Simulation<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/model_element_attributes.html" >Introduction to Graphical Modeling Interface</a>
<a href="../ModandSim/component_architecture.html">Component Architecture Modeling</a>
<a href="../ModandSim/data_dictionary.html">Data Dictionary: Types and Functions</a>
<a href="../ModandSim/refactoring.html">Refactoring</a>
<a href="../ModandSim/model_markers_view.html">On-the-fly Checks</a>
<button class="dropdown-btn">Behavior Modeling<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/code_specification.html">Code Specification</a>
<a href="../ModandSim/state_automaton.html">State Automata</a>
<a href="../ModandSim/hierarchical_state_automaton.html">Hierarchical State Automata</a>
<a href="../ModandSim/mode_automaton.html"> Mode Automata</a>
</div>
<button class="dropdown-btn">Simulation<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/simulation_with_af3.html">Simulation</a>
<a href="../ModandSim/operatorpanels.html">Operator Panels</a>
<a href="../ModandSim/operatorpanels_advanced.html">Advanced Operator Panels</a>
<a href="../ModandSim/cosimulation_with_af3.html"> Co-Simulation and FMI Support</a>
</div>
</div>
<button class="dropdown-btn">Deployment and Code Generation<i class="caret-down"></i></button>
<div class="dropdown-container">
<button class="dropdown-btn">Modeling Technical Architectures<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ta/platform_architecture.html">Platform Architecture</a>
<button class="dropdown-btn">Supported Platform Architectures<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ta/platform_architecture_generic.html">Generic Platform Architecture</a>
<a href="../ta/platform_architecture_hierarchical.html">Hierarchical Platform Architecture</a>
<a href="../ta/platform_architecture_raspberrypi.html">RaspberryPi Platform Architecture</a>
</div>
<a href="../ta/task_architecture.html">Task Architecture</a>
<a href="../ta/partition_architecture.html"> Partition Architecture</a>
<a href="../ta/allocations.html"> Deployments/Allocations</a>
<a href="../ta/system_schedule.html"> System Schedule</a>
</div>
<a href="../ta/code_generation.html">Code Generation</a>
</div>
<button class="dropdown-btn">Design Space Exploration (DSE)<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../dse/dse_perspective.html">DSE Perspective Overview</a>
<a href="../dse/dse_dashboard.html">DSE Dashboard</a>
<a href="../dse/constraints.html">Constraint Modeling</a>
<a href="../dse/objectives.html">Objective Modeling</a>
<a href="../dse/synthesis.html">Deployment/Schedule Synthesis (Exploration)</a>
<a href="../dse/visualization.html">Solution Visualization</a>
</div>
<button class="dropdown-btn">Assurance Case Modeling<i class="caret-down"></i></button>
<div class="dropdown-container">
<a style="background-color:#f2f2f2;">Modeling GSN-based Assurance Cases</a>
<a href="assessment.html">Quantitative Assessment of Assurance Cases</a>
<a href="maintenance.html">Assurance Case Maintenance</a>
</div>
</div>
</div>
<div class="topnav-right">
<a href="mailto:af_user@lists.fortiss.org?subject=Reporting 'creation.html' Documentation Problem!&body= Dear AutoFOCUS3 team, I am reporting an issue related to Glossary Creation Page.
{Please specify the problem precisely here.}.">Report a Problem?</a>
</div>
</div>
</div>
</div>
<div class="box">
<h1>ExplicitCase Assurance Case Editor</h1>
<p>AutoFOCUS3 contains an editor, named ExplicitCase, which supports the
construction of modular assurance cases, in compliance with the <a target="_blank" rel="noopener noreferrer" href="https://www.goalstructuringnotation.info/">Goal
Structuring Notation (GSN) standard</a>.</p>
<h2>Support for Assurance Case Creation</h2>
<p> Assurance cases constitute a proven technique to systematically
demonstrate the safety/security/reliability of such systems using existing
information about the system, its environment and development context,
facilitating the bridging of the regulatory gap. Three parts can be
identified as part of an assurance case. First, the <span class="bold">goal</span>
that has to be achieved. Second, the <span class="bold">evidence</span>
for achieving this goal and third, the structured argument constituting
the <span class="bold"> systematic relationship between the goal the
evidence</span>. Assurance cases can be designed in a modular approach,
by subdividing complex assurance cases into interconnected modules of
assurance arguments and evidence.</p>
<h3>What is the Goal Structuring Notation (GSN)?</h2>
<p> The Goal Structuring Notation (GSN) is a well-known description
technique for the development of engineering arguments to construct
assurance cases. GSN uses a graphical argument notation to explicitly
document the elements and structure of an argument and the argument's
relationship of this evidence. An argument, based on GSN, may consists of
several elements: <span class="italic">Goals</span> are the claims of an
argument, whereas items of evidences are captured under <span class="italic">Solutions</span>.
When documenting how claims are said to be supported by sub-claims, the <span
class="italic">Strategy</span>-element is used and can be linked to <span
class="italic">Goals</span>. A <span class="italic">Context</span>
element captures and enables citation of information that is relevant to
the argument. Rationale for a strategy can be described by a <span class="italic">Justification</span>
element. GSN provides two types of linkage between elements: <span class="italic">SupportedBy</span>
and <span class="italic">InContextOf</span>. <span class="italic">SupportedBy</span>
relationships indicate inferential or evidential relationships between
elements. <span class="italic">InContextOf</span> relationships declare
contextual relationships. The benefit of having a structured graphical
notation for assurance cases is that it supports the presentation of
assurance cases to non-safety experts in a comprehensive manner.</p>
<h3> GSN-based Assurance Cases in AF3</h3>
<p> ExplictCase is based on a metamodel derived from the
<a target="_blank" rel="noopener noreferrer" href="https://www.goalstructuringnotation.info/">GSN standard</a> and
offers a graphical editor facilitating the model-based development of
assurance cases. An overview of the editor is shown in Fig. 1. The editor
allows the user to build assurance cases via GSN, as follows:</p>
<ul>
<li> GSN defined node elements (i.e., Goal, Strategy, Solution,
Assumption, Context, Justification);</li>
<li> GSN defined relationships between node elements (i.e., SupportedBy
and InContextOf);</li>
</ul>
<h2>Steps to create an assurance case for your project</h2>
<ol>
<li> Go to an AF3 project, in the Model
Navigator View and right-click on it;</li>
<li> Select the Assurance Package item from the <span class="italic">Context Menu</span>;</li>
<p> <img src="./pictures/create-assurance-package.png"/></p>
<li> Go to the newly created assurance package in the
Model Navigator View, and right-click on it;</li>
<li> Select the Assurance Case item from the <span class="italic">Context Menu</span>;</li>
<p> <img src="./pictures/create-assurance-case.png"/></p>
<li> Go to the newly created assurance case, in the Model
Navigator View, and double-click on it, so that the
editor (Modeling Diagram) in which you can model the assurance case opens.</li>
</ol>
<h2>Tool-based Support for Handling Large Arguments: Modular Assurance Cases</h2>
<h2> What are modular assurance cases? Why shall assurance cases be modular?</h2>
<p> One way of designing assurance cases is by following the modular
approach. In GSN, an assurance case module contains the objectives,
evidence, argument and context associated with one aspect of the assurance
case. In addition to the GSN argument elements presented in the previous
paragraph, a module may contain away entities such as <span class="italic">away
goals</span>, <span class="italic">away solutions</span> and <span class="italic">away
context</span> elements. Away entities are references to goals,
solutions or context elements in another module. Away goals cannot be
(hierarchically) decomposed and further supported by sub-entities within
the current module; rather, decomposition needs to occur within the
referenced module. Inter-modular relationships are of two types: namely <span
class="italic"> supported by</span> and <span class="italic">in context
of</span> relationships. A supported by relationship denotes that
support for the claim presented by the away goal or away solution in one
module is intended to be provided from an argument in another module. When
there is an away context element in a module, that module is connected to
another module by an in context of relationship; relationship that
indicates that the context of a certain claim will be presented in details
in another module.</p>
<p>Modularity of assurance cases has various advantages, namely:</p>
<ul>
<li> Separation of concerns, as modules usually correspond to sub-systems;</li>
<li> Improved comprehensibility;</li>
<li> Minimization of the impact of required changes to an assurance case;</li>
</ul>
<h2> Modular assurance cases in ExplicitCase</h2>
<p> ExplicitCase enables the user to model an assurance case containing
several modules which are connected to each other through intra-module
connections. Each such module contains an assurance
argumentation structure, build up by GSN-defined elements specific to
modularity in assurance cases (i.e., Away Goals, Away
Solutions, Away Contexts, Contracts) connected to each other by
GSN-defined relationships. Each argumentation node within a module has a
public indicator, which determines whether the element may be referenced
in another module, or not.</p>
<figure> <img src="./pictures/argumentation-modules.png"/> <figcaption>
Assurance case modules.</figcaption> </figure>
<h2> Steps to create an assurance case module</h2>
<ol>
<li> After creating your assurance case, you can specify the contained
assurance case modules. To add an assurance case module, drag and drop an
Argument Module from the <span class="italic">Model Elements View</span> on the right side to your diagram; </li>
<li> To specify properties of the module, go to the <span class="italic">Properties View</span>.
There you can assign the
assurance case module an id (in the Element Identifier text box), a comment and a name.
All other text box may not be filled in;</li>
<p> <img src="./pictures/module-creation.png"/></p>
<li> To generate intra-module connections, based on the away entities, go
to your assurance case, in the <span class="italic">Model Elements View</span> and right-click on it. Select the
"Generate Module Connections" item from the <span class="italic">Context Menu</span>. Do consider that, if you do not have any
away entities in your assurance case modules, you will not have any
relationship between your modules.</li>
<p> <img src="./pictures/generate-module-connections.png"/></p>
</ol>
<h2>Steps to add argument elements in modules</h2>
<p> Once you are done with specifying the modules of your assurance case,
you can describe the assurance argument structure contained by these
modules by adding argumentation elements.</p>
<ol>
<li> Go to one of your assurance case modules from the <span class="italic">Model Elements View</span> and double-click on
it, so that the editor (a Modeling Diagram) in which you can model the assurance case
module appears;</li>
<li> To add an argument element,
drag and drop a goal/away goal/strategy/solution/away solution/strategy/justification/assumption/context/away context
from the <span class="italic">Model Elements View</span> on the right side to your diagram;
<p> <img src="./pictures/add-argument-elements.png"/></p></li>
<li> In order to create relationships between your argument elements,
namely SupportedBy and InContextOf relationships, as specified in the
<a target="_blank" rel="noopener noreferrer" href="https://www.goalstructuringnotation.info/">GSN standard</a>,
add exit and entry points to the elements correspondingly and then connect the points with each other.
The tool constraints the user to only be able to create valid relationships (as described in the standard).
<p> <img src="./pictures/add-relationships.png"/></p> </li>
</ol>
<h2> Setting properties of assurance argumentation elements</h2>
<p> Properties of assurance argumentation elements can be set in the
<span class="italic">Properties View</span>. There are two types of
properties, namely general properties, which may be set to all types of
GSN elements and specific properties, which may be set only to particular
types of GSN elements. The following properties can be set to any type of GSN node:</p>
<ol>
<li> Name of the GSN element in the <span class="bold">Name</span>
text box;</li>
<li> Comment regarding the GSN element in the <span class="bold">Comment</span>
text box;</li>
<li> Element identifier of the argumentation element in the <span class="bold">ID</span> text box;</li>
<li> Claim of the GSN element in the <span class="bold">Claim</span>
text box. This text may and should be filled in for all types of GSN
elements, except for solution elements.
Furthermore, you cannot set claims to away entities, as they have the
same claim as the assurance argument element they point to;</li>
<li> Add a reference to a document to the GSN element by pressing the <span class="bold">Add document</span> button. A
file browser will open and you can select any file of type
pdf/Word/Excel;</li>
<li> To delete a reference, press the <span class="bold">Remove
document</span> button;</li>
<li> To give some further explanation of the reference to a certain
document, use the <span class="bold">Reference
Explanation</span> text box;</li>
</ol>
<p><img src="./pictures/argument-element-properties.png"/></p>
<h2> Setting particular properties of <span class="italic">Away Entities</span></h2>
<p> Away entities act as interface of argument modules. An away entity references an argument element
in another module. Right-click on the away entity in the Model Navigator View. A <span class="italic">Context Menu</span> will appear.
Click on the
<span class="bold">Connect to Goal/Solution/Context</span>
menu item and a wizard will appear. Select from the assurance argument elements
that appear in the wizard one to which you want your away entity to point
to. If the selected node was set as private, you will be asked if you want
to change the visibility of the node. If you do not that, the reference will not be
done. Only public elements may be referenced by away entities.
In the <span class="italic">Properties View</span>, in the
<span class="bold">Referenced module ID</span>
the ID of the module containing the node referenced by the away entity
node is automatically filled in. After setting a reference to an entity,
you can go again in the <span class="italic">Model Navigator View</span>
and right-click on the away entity and select "Go To Refenced ..." button from
the <span class="italic">Context Menu</span>.</p>
<p> </p>
<p> <img src="./pictures/away-entity.png"/></p>
<h2>Setting states to GSN elements</h2>
<p>According to the <a target="_blank" rel="noopener noreferrer" href="https://www.goalstructuringnotation.info/">GSN standard</a>,
an argument element may take different states in the
course of the assurance case development. One can right-click on a GSN
element in the <span class="italic">Model Navigator View</span>
and select the following states: <span class="italic">private/public</span>,
<span class="italic">instantiated/uninstantiated</span>,
<span class="italic">developed/undeveloped</span> and <span class="italic">supported by
contract</span>. </p>
<p><img src="./pictures/argument-element-states.png"/></p>
<h2>Visual Aids</h2>
<p> Different coloring of GSN elements raises the assurance case developer's
awareness about the existence of undeveloped or uninstantiated entities
(see Fig. 5). In addition, contract modules have a distinct coloring in
order to distinguish them from regular argumentation modules. We do not
allow users to color elements by themselves, in order to keep a certain
meaning of each coloring so that anyone can easily "read" the coloring.
This is motivated, by the fact that the
<a target="_blank" rel="noopener noreferrer" href="https://www.goalstructuringnotation.info/">GSN standard</a>
says that, <span class="italic">In
cases where the elements defined in these sections are used in the
development of instantiations of the patterns to produce individual
assurance arguments, it is important to ensure that they are all
removed, or instantiated, in the final, delivered, version of the
argument</span>. </p>
<figure> <img src="./pictures/argument-element-coloring.png"/> <figcaption>
Different coloring for different node properties.</figcaption> </figure>
<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
<a target="_blank" rel="noopener noreferrer" href="https://www.goalstructuringnotation.info/">GSN standard</a>
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>
<button onclick="topFunction()" id="upBtn" title="Go to top">Top</button>
</div>
<script src="../layout/jsscript/topBtn.js"></script>
<script src="../layout/jsscript/submenuScript.js"></script>
<div class="footer">
<p>
&copy; 2020 <a href="https://www.fortiss.org/">fortiss GmbH</a> &nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/publications/software/autofocus-3#c2007">Contact</a>&nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/imprint">Imprint</a>
</p>
</div>
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- Documentation on Support for Assurance Case Maintenances. -->
<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
<head>
<link rel="stylesheet" type="text/css" href="../layout/stylesheet.css"/>
<title>Assurance Case Maintenance</title>
</head>
<body>
<div class="header">
<div class="box">
<div class="navbar">
<div class="dropdown">
<a href="../getting_started.html" style="padding:0;">
<button class="btn" id="hamburger" onclick="javascript:window.location.href='../getting_started.html'">
<label for="hamburger" class="hamburger">
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
<span class="hamburgerLine"></span>
</label>
</button>
</a>
<div class="dropdown-content">
<button class="dropdown-btn">Getting Started<i class="caret-down"></i></button>
<div class="dropdown-container">
<button class="dropdown-btn">Resources for Users<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href=".././managing_projects.html">Managing AutoFOCUS3 Projects</a>
<a href=".././examples.MainPage.html">Examples</a>
<a href=".././tipsAndTricks.html">Tips &amp; Tricks</a>
<a href=".././af3_faq.html">FAQs</a>
</div>
<a href=".././rcphelp.gettingstarted.MainPage.html">Resources for Developers</a>
<a href=".././rcphelp.gettingstarted.MainPage.html">Contact</a>
</div>
<button class="dropdown-btn">Requirements Engineering<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../requirements/MIRA.requirements_analysis.html"> Requirements Analysis Node</a>
<a href="../requirements/MIRA.glossary.html">Glossary</a>
<a href="../requirements/MIRA.requirements.html">Requirements</a>
</div>
<button class="dropdown-btn">Modeling and Simulation<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/model_element_attributes.html" >Introduction to Graphical Modeling Interface</a>
<a href="../ModandSim/component_architecture.html">Component Architecture Modeling</a>
<a href="../ModandSim/data_dictionary.html">Data Dictionary: Types and Functions</a>
<a href="../ModandSim/refactoring.html">Refactoring</a>
<a href="../ModandSim/model_markers_view.html">On-the-fly Checks</a>
<button class="dropdown-btn">Behavior Modeling<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/code_specification.html">Code Specification</a>
<a href="../ModandSim/state_automaton.html">State Automata</a>
<a href="../ModandSim/hierarchical_state_automaton.html">Hierarchical State Automata</a>
<a href="../ModandSim/mode_automaton.html"> Mode Automata</a>
</div>
<button class="dropdown-btn">Simulation<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ModandSim/simulation_with_af3.html">Simulation</a>
<a href="../ModandSim/operatorpanels.html">Operator Panels</a>
<a href="../ModandSim/operatorpanels_advanced.html">Advanced Operator Panels</a>
<a href="../ModandSim/cosimulation_with_af3.html"> Co-Simulation and FMI Support</a>
</div>
</div>
<button class="dropdown-btn">Deployment and Code Generation<i class="caret-down"></i></button>
<div class="dropdown-container">
<button class="dropdown-btn">Modeling Technical Architectures<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ta/platform_architecture.html">Platform Architecture</a>
<button class="dropdown-btn">Supported Platform Architectures<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../ta/platform_architecture_generic.html">Generic Platform Architecture</a>
<a href="../ta/platform_architecture_hierarchical.html">Hierarchical Platform Architecture</a>
<a href="../ta/platform_architecture_raspberrypi.html">RaspberryPi Platform Architecture</a>
</div>
<a href="../ta/task_architecture.html">Task Architecture</a>
<a href="../ta/partition_architecture.html"> Partition Architecture</a>
<a href="../ta/allocations.html"> Deployments/Allocations</a>
<a href="../ta/system_schedule.html"> System Schedule</a>
</div>
<a href="../ta/code_generation.html">Code Generation</a>
</div>
<button class="dropdown-btn">Design Space Exploration (DSE)<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="../dse/dse_perspective.html">DSE Perspective Overview</a>
<a href="../dse/dse_dashboard.html">DSE Dashboard</a>
<a href="../dse/constraints.html">Constraint Modeling</a>
<a href="../dse/objectives.html">Objective Modeling</a>
<a href="../dse/synthesis.html">Deployment/Schedule Synthesis (Exploration)</a>
<a href="../dse/visualization.html">Solution Visualization</a>
</div>
<button class="dropdown-btn">Assurance Case Modeling<i class="caret-down"></i></button>
<div class="dropdown-container">
<a href="creation.html">Modeling GSN-based Assurance Cases</a>
<a href="assessment.html">Quantitative Assessment of Assurance Cases</a>
<a style="background-color:#f2f2f2;">Assurance Case Maintenance</a>
</div>
</div>
</div>
<div class="topnav-right">
<a href="mailto:af_user@lists.fortiss.org?subject=Reporting 'maintenance.html' Documentation Problem!&body= Dear AutoFOCUS3 team, I am reporting an issue related to Assurance Case Modeling.
{Please specify the problem precisely here.}.">Report a Problem?</a>
</div>
</div>
</div>
</div>
<div class="box">
<button onclick="topFunction()" id="upBtn" title="Go to top">Top</button>
<h1>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,
<!--##################### 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
......@@ -39,38 +139,38 @@ font-style: italic;
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
engineers with tool-supported Assurance Case Maintenance.</p>
<!--##################### CIA for assurance cases-->
<h2>Assurance Case Maintenance (CIA) for assurance cases</h2>
<p>The Assurance Case Maintenance 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
<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
</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
</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
</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.
......@@ -78,11 +178,11 @@ 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>
<!--##################### CIA in ExplicitCase-->
<h3>Change impact analysis in ExplicitCase</h3>
<p> The assurance case maintenance in ExplicitCase requires the
<!--##################### CIA in ExplicitCase-->
<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
......@@ -93,27 +193,38 @@ 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/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.
<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>.
<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
<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>
<p> <img src="./pictures/maintenance5.PNG"/></p>
</ol>
</div>
<script src="../layout/jsscript/topBtn.js"></script>
<script src="../layout/jsscript/submenuScript.js"></script>
<div class="footer">
<p>
&copy; 2020 <a href="https://www.fortiss.org/">fortiss GmbH</a> &nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/publications/software/autofocus-3#c2007">Contact</a>&nbsp;&nbsp;&bull;&nbsp;&nbsp;
<a href="https://www.fortiss.org/en/imprint">Imprint</a>
</p>
</div>
</body>
</html>
\ No newline at end of file
org.fortiss.af3.rcp.help/html/assuranceCases/pictures/maintenance1.png

41.7 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/maintenance2.png

148 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/maintenance3.png

63.8 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/maintenance4.png

30.6 KiB

org.fortiss.af3.rcp.help/html/assuranceCases/pictures/maintenance5.png

94.5 KiB

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
Documentation of Creating a Code Specification for a Component.
@author becker
@ConQAT.Rating GREEN Hash: EE5DC9DDEA7B859D0B83504DECB1B455
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Creating a Code Specification using AutoFOCUS3 (AF3)</title>
</head>
<body>
<h2><u><font color="#336699">Creating a Code Specification for a Component</font></u></h2>
If you added a Code Specification to a Component, you are able to specify the behavior of that component on code level.
<br><br>
<img src="./pictures/CodeSpecification.png">
<br><br>
<!--
if (mergeA == Present( )) {
mergeReq = Present( );
return;
}
if (mergeB == Present( )) {
mergeReq = Present( );
}
-->
The Code Specification View also provides Syntax-Checking and marks invalid code with a little red error-marker.
Move your mouse over this error-marker and you will get an info-text about at which position in the code the error is found and what kind of error it is.
Only the first error in your code is marked. If you remove this error, the next error will be marked.
<br><br>
<img src="./pictures/CodeSpecification.Errors.png">
<br><br>
Things to note:
<ul><li>Variables can not be defined in a code specification.</li>
<li>Code specifications do not return a value.</li></ul>
<br><br>
</font>
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
Documentation of Creating a Component Architecture.
@author becker
@ConQAT.Rating GREEN Hash: 589F754EB8ACFD8E12013E9DBE185BCA
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Creating a Component Architecture using AutoFOCUS3 (AF3)</title>
</head>
<body>
<h2><u><font color="#336699">Creating a Component Architecture</font></u></h2>
<h4><font color="#336699">Introduction</font></h4>
To create a component architecture inside an empty new project, open the context menu of the project and select <i>Component Architecture</i>.
<br><br>
<img src="./pictures/components_new-architecture.png">
<br><br>
In the same way, you can add more component architectures to your project.
<h4><font color="#336699">Modeling a Component Architecture</font></h4>
Once you have created a component architecture, you can specify the contained components as well as channels between them.
To add a component, drag &amp; drop a component from the <i>Model Elements</i> view on the right side to your diagram. In the same way, you can add Input or Output-Ports to your components.
<br><br>
<img src="./pictures/components_add-component.png">
<br><br>
To move a component, just pick the component somewhere in the middle and move.
To resize a component, pick it in the lower right corner and move the mouse to resize.
<br><br>
Channels can be created by dragging from one port to the other.
When starting the drag, potential target ports are highlighted with green color, while unavailable or incompatible ones are marked red.
Channels will only be created when dropping over compatible ports.
<br><br>
<img src="./pictures/components_channels.png">
<br><br>
To support the drag &amp; drop actions the interactive areas around elements can be displayed via the respective option in the editor's context menu:
<br><br>
<img src="./pictures/components_interactive-area-shading.png">
<br><br>
These are the areas within which an element can be dragged. Where areas are overlapping, the action applies to the topmost element.
<br><br>
Notice that Input-Ports of Sub-Components have a different color than Input-Ports of the Parent-Component.
This is, because from the inner point of view, the Input-Ports of the Parent-Component are sending (delegating) data.
Hence, these Input-Ports are black (like the Output-Ports of Sub-Components).
<br><br>
<img src="./pictures/components_ports.png">
<br><br>
The shape and route of channels can be modified by adding and moving bend points.
Bend points can be added by clicking on a point along the channel while pressing the <b>&lt;ctrl&gt;-key</b>.
The bend points can then be moved by dragging &amp; dropping the red squares around them.
To remove a bend point, right-click on it while pressing the <b>&lt;ctrl&gt;-key</b>.
<br><br>
<img src="./pictures/components_bend-points.png">
<br><br>
In the <i>Properties View</i>, you can edit the names of selected components, channels and ports. You can also specify comments.
<br><br>
<img src="./pictures/components_properties.png">
<br><br>
<h4><font color="#336699">Causality</font></h4>
Each component is declared to be <i>weakly causal</i> or <i>strongly causal</i>.
Weak causality models instantaneous reaction, while strong causality models a delayed reaction.
This means that in a weak causal component a value arrived at an Input-Port is directly accessible in the same time step,
whereas in a strongly causal component such an input value is accessible only at the next time step.
This indicates that for a strongly causal component, there is a delay of at least one time step before input has any effect on output.
<br><br>
If you add a component, it is per default weakly causal. You can change the causality in the Properties-View of a component.
<br><br>
<img src="./pictures/components_causality.png">
<br><br>
The color of a component indicates its causality. There is also a difference in the colors of composite components and atomic components.
However the causality of a composite component depends on its sub-components, therefore composite components all have the same color.
<h4><font color="#336699">Causality and Cycles</font></h4>
Cycles which contain only weakly causal components can entail infinitely many system state modifications at once:
one component of the cycle makes a change, which triggers <i>immediately</i> (due to weak causality)
a change in the next component, which also immediately triggers a change in the next component, etc.
Since we have a cycle, these changes will at one point reach the first component,
thus yielding an infinite loop of changes.
This can be the source of many theoretical and practical problems, therefore,
to avoid this, AF3 only allows cycles which contain <i>at least one strongly causal component:</i>
this way, the infinite loop of changes cannot occur during a single time unit,
but instead spreads on several time instants.
<p>
When a cycle does not have this property, one gets the error "Component ... is part of a weakly causal cycle":
<br><br>
<img src="./pictures/components_decorations_weak-cycle.png">
<br><br>
If it is indeed a property of the model to have such a cycle then one has no other choice than modifying
the design of the model so as to satisfy the strong-causal-cycle requirements.
However, most of the time, the error happens in the process of building a model, when the components are not marked yet
as strongly causal, or when they are composite components whose (not yet provided) implementation is intended to be
made only of strongly causal components.
In such cases one can either accept the error until one provides a strongly-causal implementation, or fix the error
by just marking (at least) one of the components among the path as strongly causal:
<br><br>
<img src="./pictures/components_decorations_strong-cycle.png">
<br><br>
<h4><font color="#336699">Initial Message</font></h4>
The field initial message provides the first message delivered by the port.
If a port is of type array, it can be initialized by the expression "[value_0, value_1, ..., value_N]".
If a port is of type structure, it can be initialized by the expression "{MEMBER_x:value_x, MEMBER_y:value_y, ..., MEMBER_z:value_z}".
<h4><font color="#336699">Propagate Data</font></h4>
AutoFOCUS provides some mechanisms to make development easier and faster.
For instance, if you have already connected two Ports by a Channel and want subsequently change the type of the Ports,
you have to do this only at one of the both connected Ports.
Instead of doing the same at the other Port again, you should use the <i>backward</i> and <i>forward</i> buttons in the Properties-View of a Port.
<br><br>
<i>Forward</i> copies the Port-Settings (Name, Type and initial message) to all Ports connected by an outgoing channel.<br>
<i>Backward</i> copies the Port-Settings to all Ports connected by an incoming channel.<br>
<br><br>
<img src="./pictures/components_propagation.png">
<br><br>
In the shown example the settings of the selected Output-Port are propagated to the connected Input-Port. Also the channel is renamed by this.
<h4><font color="#336699">Behavior</font></h4>
In order to specify the behavior of your components, you might add either <a href="code_specification.html"><i>Code Specifications</i></a> or <a href="state_automaton.html"><i>Automaton Specifications</i></a> to these.
<br><br>
<h4><font color="#336699">Selecting Multiple Elements</font></h4>
Multiple elements of a component architecture can be selected by pressing the <b>&lt;ctrl&gt;-key</b> while selecting components:
<br><br>
<img src="./pictures/components_multi-select.png">
<h4><font color="#336699">Copy &amp; Paste Components</font></h4>
Components can be copied and pasted via the respective entry in the context menu of the model navigator:
<br><br>
<img src="./pictures/components_copy-paste.png">
<h4><font color="#336699">Moving Ports</font></h4>
Ports attached to components can be manually moved by
<ol>
<li>
clicking on the port first to select it and<br>
<img src="./pictures/components_moving-ports_selected.png">
</li>
<li>dragging and dropping it at any point along the component's border.</li>
</ol>
<h4><font color="#336699">Zoom</font></h4>
Rolling the mouse wheel while hovering over the component architecture editor and holding the <b>&lt;ctrl&gt;-key</b> zooms in or out, allowing the inspection parts of the model in detail or providing an overview over large models.
<br><br>
<img src="./pictures/components_zoom.png">
<h4><font color="#336699">Auto-Layout</font></h4>
A component architecture can be automatically organized using the <i>Auto-Layout</i> feature found in the conext menu of the respective architecture in the model viewer:
<br><br>
<img src="./pictures/components_auto-layout_context-menu.png">
<br><br>
The components of the architecture are then automatically reorganized like so:
<br><br>
<img src="./pictures/components_auto-layout_architecture.png">
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
User documentation for Cosimulation feature.
@author vogelsan
@ConQAT.Rating
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Cosimulation</title>
</head>
<body>
<h2><u><font color="#336699">Coupling AF3 with other tools using cosimulation</font></u></h2>
<h3><font color="#336699">Introduction</font></h3>
<font color="#000000" style="font-family:Verdana, Geneva, sans-serif" size="2px">
AF3 alone cannot satisfy all the needs of system development.
Other tools are often needed, e.g., for modeling continuous behavior
(for the environment or for analog parts of a system),
for interoperability with legacy tools, or simply for using non-AF3 features in combination with AF3
(e.g., visualization).
<br>
In such cases, AF3 has <i>cosimulation</i> capabilities which allows to use AF3 <a href="simulation_with_af3.html">simulation</a>
with other tools in a synchronous manner.
AF3 offers cosimulation functionality in the following two ways:
<ul> <li>
The AF3 model can be exported as an <a href="http://www.fmi-standard.org">FMU</a>, which can be used as one of the components for cosimulation in other tools.
<li>AF3 provides the environment for FMUs cosimulation by utilizing Cosimulation Orchestration Engine (<a href="https://into-cps.github.io/simulation/coe.html">COE</a>)
provided by INTO-CPS as a service. Thus, the FMUs from different tools can be imported and cosimulated together along with the AF3 components.
</ul>
</font>
<h3><font color="#336699">Cosimulation using FMI (Functional Mockup Interface)</b></font></h3>
<b>This feature supports for now only FMU export satisfying the following constraints:
<ul> <li>FMI2.0
<li> Windows 32/64bit
<li> GCC compilation - One has to use <a href="http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/tdm64-gcc-5.1.0-2.exe/download"> TDM-GCC MinGW</a>
<li> Input and output values cannot carry NoVal but instead contain default values (0 for integers and reals, false for booleans, first item for enumerations)
Note: This behaviour is different from AF3 <i>simulation</i>
</ul>
Please contact us if you wish to get support for a different environment.</b>
<h3><font color="#336699">Exporting component architecture as an FMU </font></h3>
<p>
FMI export can be done at the level of both component architecture and component.
To export anyone of them to the FMU, right-click on it in the model navigator and select "Export to FMU2.0":
<br><br><img src="./pictures/FMI_menu.png">
<br><br>
AF3 works with logical time, however cosimulation is generally achieved with tools modeling reality and therefore working with real time.
Therefore, the FMI standard requires that AF3 notion of time is translated to real time.
For that, a function with the name 'samplingTime()' can be defined in the data dictionary and used inside the AF3 component's behavior.
If the samplingTime() is not defined, the user will be
asked to provide the required frequency (equivalent to sampling time) for the component:
<br><br><img src="./pictures/FMI_tick_duration.png">
<br><br>
You will then be asked where to store the generated FMU.
Once this is done, a message confirming that generation was successful appears and you can find the generated FMU in the directory that you selected.
You can then make use of the <a href="https://www.fmi-standard.org/tools">numerous cosimulation tools</a> along with AF3 itself, supporting FMI to cosimulate the generated AF3 model's FMU.
<h3><font color="#336699">Importing FMUs and their cosimulation</font></h3>
<p>
The FMU's from other tools can be imported in AF3 for the cosimulation together with the AF3's own behavior components.
<h4><font color="#336699">Creating an FMU Specification</font></h4>
<p>
To use the cosimulation feature, you have to create the <i>FMU Specification</i> inside the component.
Only the entire component architecture can be simulated having FMUs or other AF3 behaviors inside its subcomponents.
To create an <i>FMU specification</i> for a component, open the context menu of the component and select "FMU Specification".
<br><br>
<img src="./pictures/FMUSpecification.png">
<br><br>
The FMU Specification can also be dragged and dropped from the <i>Model Elements</i> window.
<br><br>
<img src="./pictures/FMUModelElements.png">
<br><br>
The <i>FMU Specification</i> consists of only one section available by double clicking the FMU Specification icon or its component.
It has two fields with:
<ul>
<li><i>Browse button:</i> To upload the FMU. The input/output ports will be automatically generated.
<li><i>Update button:</i> If any changes in the FMU has been made, it can be updated (without again providing the path).
</ul>
<img src="./pictures/externalSpecificationEditor.png">
<br><br>
Different AF3 component and the FMUs are connected with each other through the input and output ports. The outputs that has to be displayed as a result of the
cosimulation are assigned to the Component Architecture's root component.
<br><br>
<img src="./pictures/cosimulationComponentsConnection.png">
<h4><font color="#336699">Running a Cosimulation</font></h4>
<p>
To start the cosimulation, right-click on the <i>Component Architecture</i> element in the <i>Model Navigator</i> and select "Run Cosimulator". Remember
that this option will only be available, if there is at least two atomic component and one of them has an FMU Specification behavior.
<br><br>
<img src="./pictures/runCosimulator.png">
<br>
<br>
If there would be no error in the model, then Cosimulation Configuration window will open containing two sections:
<ul>
<li><i>Simulation time:</i> The step size, start and end time values has to be provided for which the simulation needs to be run.
The end time should be greater than the start time and the step size should be greater than zero and within the range of start and end time.
<li><i>Ports to be displayed:</i> The check boxes with port names (that were assigned to the root component ports) to be displayed on the output graph.
</ul>
Then press OK to proceed or cancel to stop the cosimulator.
<br><br>
<img src="./pictures/cosimulationConfigurations.png">
<br><br>
Pressing OK will execute the cosimulation of the components and at last the window with graph having the results will pop up.
<br><br>
<img src="./pictures/cosimulationResults.png">
<br>
</font>
</body>
</html>
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!--
Documentation of Defining a Data Dictionary.
@author becker
@ConQAT.Rating GREEN Hash: C359C5FBF27AA4D36ECA49D9504DA64A
-->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Defining a Data Dictionary using AutoFOCUS3 (AF3)</title>
</head>
<body>
<h2><u><font color="#336699">Data Dictionary: Types and functions</font></u></h2>
AF3 allows you to define your own datatypes and functions by using a socalled "Data Dictionary".
<br>
To create such a Data Dictionary, right-click at the root of your project and select "Data Dictionary", as shown below:
<br><br>
<img src="./pictures/DataDictionary.Add.png">
<br><br>
You can then add the following elements to your Data Dictionary:
<ul>
<li>Enumeration</li>
<li>Structure</li>
<li>Array</li>
<li>Function</li>
</ul>
These can be added by drag-and-drop from the model elements palette or by the context menu (right-click)
<br>of the data dictionary itself in the model navigator.
We describe below every of these elements in more details: what they consist of, how to define them,
<br>as well as the <i>syntax</i> to use to refer to the data items they define. The latter is particularly
<br>useful, e.g., in Guards and Actions of <a href="state_automaton.html"><i>State Automata</i></a> or in <a href="code_specification.html"><i>Code Specifications</i></a>.
<h3>Enumeration</h3>
An enumeration is a data type defined as a finite list of values. Variables of this type can only contain a value which belong to this list.
<br>This is similar to "unions" in C, or to "sum types" in functional languages.
<br>After having created an enumeration, you can add elements to it by drag and dropping "enumeration members" from the
<br>palette or by right-clicking the enumeration in the data dictionary editor.
<p><i>Syntax</i>: an enumeration member can be accessed by writing its name followed by "()" (this allows to distinguish enumeration members from ports).
<br>For instance, referring to the elements of the enumeration defined below is done by writing "Green()", "Red()", "RedYellow()", "Yellow()".
<br>
<img src="./pictures/DataDictionary.Enumeration.png">
<br><br>
<h3>Structure</h3>
A structure is a data type which allows to gather various values in one variable, each value being uniquely identified by a structure member <i>name</i>.
<br>One can for instance state a value shall always have a member called "x" of type integer and a member called "y" of type boolean.
<br>This is similar to "records" in C, or to "product types" in functional languages.
<br>After having created a structure, you can add elements to it by drag and dropping "structure members" from the
<br>palette or by right-clicking the structure in the data dictionary editor.
<p><i>Syntax</i>: a structure member of a variable "v" can be accessed by writing "v.MEMBER_NAME".
<br>For instance, for the example structure mentioned in the previous paragraph, one would access the integer by "v.x" and the boolean by "v.y".
<br>Creating a structure is done with the syntax "{member_name_1: value_1, member_name_2: value_2, ...}". With the same example above: "{ x: 1, y: true }".
</p>
<h3>Array</h3>
Arrays are like usual C arrays, but <i>their size is defined in the datatype itself</i>.
<p><i>Syntax</i>: Given a variable "v" whose type is an array, the i-th element can be accessed by the expression
<br>"v[i]". The index starts from 0. Assigning a value x to the i-th element is done with the syntax "v[i] = x".</p>
<h3>Function</h3>
Functions denote small functions which can be used in various places in an AF3 project.
<br><i>Note:</i>Functions are not a type but are still defined in the data dictionary.
<p>Functions have:
<ul>
<li>parameters
<li>a return type
<li>a definition
<i>Note:</i> the definition cannot contain local variables!
<br>(this means that practically, most function definitions contain only "if" and "return" statements.)
</ul>
(see next figure for an example).
</p>
<img src="./pictures/DataDictionary.Definitions.png">
<br><br>
<h3>Evaluator</h3>
If you want to check your defined functions, AutoFOCUS provides an Evaluator for the Data Dictionary.
<br>Simply click onto the Evaluator-Tab and insert commands into the lower field. The upper field shows the results of your inputs.
<br>As you can see in the following Example, the Function "tRed()" returns 5 as defined.
<br><br>
<img src="./pictures/DataDictionary.Evaluator.png">
<br><br>
</font>
</body>
</html>
\ No newline at end of file