Added online help for APP4MC Release 0.7.2
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/content/documentation.md b/websites/www.eclipse.org-app4mc-hugo/site/content/documentation.md
index bbbb70b..4807a61 100644
--- a/websites/www.eclipse.org-app4mc-hugo/site/content/documentation.md
+++ b/websites/www.eclipse.org-app4mc-hugo/site/content/documentation.md
@@ -3,12 +3,17 @@
title: Documentation
---
-Documentation for APP4MC will be published soon!
Sign up on the [mailing list](https://dev.eclipse.org/mailman/listinfo/app4mc-dev "APP4MC mailing list") for the latest news about APP4MC.
---
+### Online Help
+---
+
+<a href="../help/app4mc-0.7.2/index.html" target="_blank">APP4MC 0.7.2</a> (opens in new tab)
+
+---
### Related Standards
---
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/frames.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/frames.css
new file mode 100644
index 0000000..2988b4d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/frames.css
@@ -0,0 +1,43 @@
+
+body{
+ margin: 0;
+ padding: 0;
+ border: 0;
+ overflow: hidden;
+ height: 100%;
+ max-height: 100%;
+}
+
+#framecontent{
+ position: fixed;
+ top: 0;
+ bottom: 0;
+ left: 0;
+ width: 350px; /*Width of frame div*/
+ height: 100%;
+ overflow: scroll;
+ background: #eee;
+ color: black;
+}
+
+#maincontent{
+ position: fixed;
+ top: 0;
+ left: 350px; /*Set left value to WidthOfFrameDiv*/
+ right: 0;
+ bottom: 0;
+ overflow-y: scroll;
+ overflow-x: hidden;
+ background: #fff;
+}
+
+.innertube{
+ margin: 10px; /*Margins for inner DIV inside each DIV (to provide padding)*/
+}
+
+article {
+ border: 1px solid #000000;
+ margin: -8px -8px 13px -8px;
+ padding: 8px 14px;
+ box-shadow: 0 4px 3px #aaa;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/help.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/help.css
new file mode 100644
index 0000000..026a330
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/help.css
@@ -0,0 +1,134 @@
+
+/* Additional styles */
+
+h1 {
+ line-height: 1.5em;
+ color: black;
+ font-size: 20px;
+ border-bottom: 2px solid #aaa;
+}
+
+h2 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h3 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h4 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h5 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/toc-icons.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/toc-icons.png
new file mode 100644
index 0000000..49ec3ad
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/toc-icons.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/toc-style.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/toc-style.css
new file mode 100644
index 0000000..2aed802
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/css/toc-style.css
@@ -0,0 +1,128 @@
+
+/* Table of contents tree */
+
+
+
+/* --- basic toc-tree settings --- */
+
+.toc-tree
+{
+ user-select: none;
+ font-family: Helvetica, Arial, Sans-serif;
+ font-style: normal;
+ font-size: 14px;
+ line-height: 120%;
+}
+
+.toc-tree ul,
+.toc-tree li
+{
+ padding: 0;
+ margin: 4px 0;
+ list-style: none;
+ white-space: nowrap;
+}
+
+.toc-tree input
+{
+ position: absolute;
+ opacity: 0;
+}
+
+.toc-tree label,
+.toc-tree label::before,
+.toc-tree a
+{
+ display: inline-block;
+ height: 16px;
+ line-height: 16px;,
+ vertical-align: middle;
+}
+
+/* --- link decoration --- */
+
+.toc-tree a,
+.toc-tree a:visited
+{
+ text-decoration: none;
+ color: #0000aa;
+}
+
+.toc-tree a:hover
+{
+ text-decoration: underline;
+}
+
+/* --- indented sub tree --- */
+
+.toc-tree input + label + ul
+{
+ margin: 0 0 0 22px;
+}
+
+/* --- hidden sub tree --- */
+
+.toc-tree input ~ ul
+{
+ display: none;
+}
+
+/* --- visible sub tree --- */
+
+.toc-tree input:checked ~ ul
+{
+ display: block;
+}
+
+/* --- cursor --- */
+
+.toc-tree input,
+.toc-tree label,
+.toc-tree label::before
+{
+ cursor: pointer;
+}
+
+.toc-tree label.leaf,
+.toc-tree label.leaf::before
+{
+ cursor: default;
+}
+
+/* --- icons definition --- */
+
+.toc-tree label,
+.toc-tree label::before
+{
+ background: url("toc-icons.png") no-repeat;
+}
+
+/* --- document icon --- */
+
+.toc-tree label
+{
+ background-position: 18px 0;
+}
+
+/* --- plus / minus icon (for expandable nodes)--- */
+
+.toc-tree label::before
+{
+ content: "";
+ width: 16px;
+ margin: 0 22px 0 0;
+ vertical-align: middle;
+ background-position: 0 -32px;
+}
+
+.toc-tree input:checked + label::before
+{
+ background-position: 0 -16px;
+}
+
+/* --- empty icon (for leaf nodes) --- */
+
+.toc-tree label.leaf::before
+{
+ background-position: 0 -48px;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/01-create-new-example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/01-create-new-example.png
new file mode 100644
index 0000000..4ae0828
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/01-create-new-example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/02-democar-example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/02-democar-example.png
new file mode 100644
index 0000000..3573751
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/02-democar-example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/02-select-democar-example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/02-select-democar-example.png
new file mode 100644
index 0000000..560c299
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/02-select-democar-example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/03_democar-example-finish.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/03_democar-example-finish.png
new file mode 100644
index 0000000..485f9fc
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/03_democar-example-finish.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/04-generate-tasks.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/04-generate-tasks.png
new file mode 100644
index 0000000..17e5102
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/04-generate-tasks.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/05-output-model.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/05-output-model.png
new file mode 100644
index 0000000..bf7ddea
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/05-output-model.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/06-perform-mapping.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/06-perform-mapping.png
new file mode 100644
index 0000000..c09a37c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/06-perform-mapping.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/07-perform-mapping-ui.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/07-perform-mapping-ui.png
new file mode 100644
index 0000000..de0d804
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/07-perform-mapping-ui.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/08-inspect.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/08-inspect.png
new file mode 100644
index 0000000..106dc86
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/08-inspect.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/09-preferences.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/09-preferences.png
new file mode 100644
index 0000000..4075ce3
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/09-preferences.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/10inspect.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/10inspect.png
new file mode 100644
index 0000000..bcd85bd
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/10inspect.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_1_sphinx_validation_trigger_command.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_1_sphinx_validation_trigger_command.png
new file mode 100644
index 0000000..7ed0973
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_1_sphinx_validation_trigger_command.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_2_sphinx_validation_catalog.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_2_sphinx_validation_catalog.png
new file mode 100644
index 0000000..b946db2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_2_sphinx_validation_catalog.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_3_sphinx_validation_results.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_3_sphinx_validation_results.png
new file mode 100644
index 0000000..f9de324
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-18_3_sphinx_validation_results.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-19_sphinx_validation_catalog.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-19_sphinx_validation_catalog.png
new file mode 100644
index 0000000..eb2fa06
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/2015-06-19_sphinx_validation_catalog.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_import_options.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_import_options.png
new file mode 100644
index 0000000..e700b98
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_import_options.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_models.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_models.png
new file mode 100644
index 0000000..e5ab5aa
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_models.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_models_actions.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_models_actions.png
new file mode 100644
index 0000000..d7309b8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_models_actions.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_system_model.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_system_model.png
new file mode 100644
index 0000000..acbc861
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_system_model.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_trace_db_example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_trace_db_example.png
new file mode 100644
index 0000000..91625cf
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/amalthea_trace_db_example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/app4mc-logo-g.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/app4mc-logo-g.png
new file mode 100644
index 0000000..2ab0953
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/app4mc-logo-g.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/app4mc_platform_features.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/app4mc_platform_features.png
new file mode 100644
index 0000000..1843d92
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/app4mc_platform_features.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/applet_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/applet_small.png
new file mode 100644
index 0000000..82d963e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/applet_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/atdb_import_dialogue.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/atdb_import_dialogue.png
new file mode 100644
index 0000000..749df38
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/atdb_import_dialogue.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/atdb_import_result.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/atdb_import_result.png
new file mode 100644
index 0000000..60aa25e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/atdb_import_result.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/cache_builder.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/cache_builder.png
new file mode 100644
index 0000000..8244db5
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/cache_builder.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/click_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/click_small.png
new file mode 100644
index 0000000..3a4fa90
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/click_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/config.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/config.png
new file mode 100644
index 0000000..52d5653
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/config.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/configuring_models_mwe2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/configuring_models_mwe2.png
new file mode 100644
index 0000000..d8417d8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/configuring_models_mwe2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_content.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_content.png
new file mode 100644
index 0000000..8502731
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_content.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_dependencies.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_dependencies.png
new file mode 100644
index 0000000..8bf1443
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_dependencies.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_dependencies_details.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_dependencies_details.png
new file mode 100644
index 0000000..71bc2cb
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_dependencies_details.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_extension_points.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_extension_points.png
new file mode 100644
index 0000000..7cb03f4
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/converters_extension_points.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/copy_models.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/copy_models.png
new file mode 100644
index 0000000..e57530b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/copy_models.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/cycle_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/cycle_small.png
new file mode 100644
index 0000000..f8d4468
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/cycle_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/dependency_new.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/dependency_new.png
new file mode 100644
index 0000000..20a0c1b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/dependency_new.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/different_model_versions.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/different_model_versions.png
new file mode 100644
index 0000000..b3fc26d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/different_model_versions.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/execute_workflow.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/execute_workflow.png
new file mode 100644
index 0000000..9ab8f9b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/execute_workflow.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_model.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_model.png
new file mode 100644
index 0000000..3976546
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_model.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_wizard1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_wizard1.png
new file mode 100644
index 0000000..185b591
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_wizard1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_wizard2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_wizard2.png
new file mode 100644
index 0000000..0f9f61d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/export_wizard2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/franca_interface_handling.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/franca_interface_handling.png
new file mode 100644
index 0000000..1fc7a98
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/franca_interface_handling.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/generated_model_file_names.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/generated_model_file_names.png
new file mode 100644
index 0000000..83028a1
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/generated_model_file_names.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/ggp_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/ggp_small.png
new file mode 100644
index 0000000..f63383e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/ggp_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-2.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-2.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-2.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-3.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-3.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-3.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-4.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-4.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-4.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-5.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-5.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-5.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-6.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-6.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-6.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-7.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-7.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-7.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-8.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-8.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-8.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-9.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-9.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help-9.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help.css
new file mode 100644
index 0000000..a49e267
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/help.css
@@ -0,0 +1,127 @@
+
+/* Additional styles */
+
+h1 {
+ font-size: 36px;
+ line-height: 40px;
+ text-align: center;
+
+ color: #015A20;
+ margin: 40px 0;
+ padding: 10px;
+}
+
+h2 {
+ font-size: 30px;
+ line-height: 40px;
+ border-bottom: solid 1px #666;
+}
+
+h3 {
+ font-size: 24px;
+ line-height: 40px;
+}
+
+h4 {
+ font-size: 18px;
+ line-height: 20px;
+ font-style: italic;
+}
+
+
+body {
+ font-family: Helvetica,Arial,sans-serif;
+ line-height: 1.3;
+}
+
+
+/* styling of code listings and code snippets */
+
+pre, code {
+ background-color: #f7f7f9;
+ border: 1px solid #e1e1e8;
+}
+
+pre {
+ padding: 10px;
+ word-break: break-all;
+ word-wrap: break-word;
+ white-space: pre-wrap;
+ border-radius: 5px;
+}
+
+code {
+ vertical-align: 5%;
+ padding: 1px 3px 0px;
+ color: #d14;
+ border-radius: 2px;
+}
+
+pre code {
+ padding: 0px;
+ color: inherit;
+ background-color: transparent;
+ border: 0;
+}
+
+
+/* styling of tables: minimal, classic */
+
+td, th {
+ padding: 6px 6px 6px 6px;
+}
+
+
+table.minimal td {
+ border-top: solid black 1px;
+}
+
+
+table.classic {
+ border: solid black 1px;
+ border-collapse: collapse;
+}
+
+table.classic th, table.classic td {
+ border: solid black 1px;
+}
+
+
+/* borders and scaling (used for images) */
+
+img.gray {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+}
+
+
+img.scale {
+ max-width: 100%;
+ height: auto;
+}
+
+
+img.gray_scale {
+ background: #dddddd;
+ padding: 5px;
+ margin: 10px;
+
+ max-width: 100%;
+ height:auto;
+}
+
+
+img.shadow {
+ box-shadow: 0px 0px 5px 8px #ccc;
+ margin: 10px;
+}
+
+
+/* not applicable (because border=0 is added by default) */
+
+img.dotted {
+ border-width: 2;
+ border-color: gray;
+ border-style: dotted;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/hwmodel_attributes_features.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/hwmodel_attributes_features.png
new file mode 100644
index 0000000..ee8fd16
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/hwmodel_attributes_features.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import.png
new file mode 100644
index 0000000..70cfe16
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import_existing_projects.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import_existing_projects.png
new file mode 100644
index 0000000..597c82c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import_existing_projects.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import_franca-core.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import_franca-core.png
new file mode 100644
index 0000000..77c13c0
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/import_franca-core.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/labelswitch_migration.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/labelswitch_migration.png
new file mode 100644
index 0000000..50c30d9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/labelswitch_migration.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/labelvalueentry_stimuli_migration.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/labelvalueentry_stimuli_migration.png
new file mode 100644
index 0000000..1a952b7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/labelvalueentry_stimuli_migration.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/lgp_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/lgp_small.png
new file mode 100644
index 0000000..f61fd6b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/lgp_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/mappingmodel_processallocations.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/mappingmodel_processallocations.png
new file mode 100644
index 0000000..1df4b6e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/mappingmodel_processallocations.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/metric-viewer_open.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/metric-viewer_open.png
new file mode 100644
index 0000000..615e736
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/metric-viewer_open.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/metric-viewer_table.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/metric-viewer_table.png
new file mode 100644
index 0000000..1ca1da7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/metric-viewer_table.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/migration_dialog.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/migration_dialog.png
new file mode 100644
index 0000000..9069ba2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/migration_dialog.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/migration_flow.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/migration_flow.png
new file mode 100644
index 0000000..44b027e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/migration_flow.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model__activations.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model__activations.png
new file mode 100644
index 0000000..2adc611
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model__activations.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model__stimuli.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model__stimuli.png
new file mode 100644
index 0000000..949d021
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model__stimuli.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_custom_property.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_custom_property.png
new file mode 100644
index 0000000..91051f5
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_custom_property.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_custom_property_value.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_custom_property_value.png
new file mode 100644
index 0000000..b5c51bc
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_custom_property_value.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_data_rate.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_data_rate.png
new file mode 100644
index 0000000..c0c2148
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_data_rate.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_data_size.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_data_size.png
new file mode 100644
index 0000000..fb4da99
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_data_size.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation.png
new file mode 100644
index 0000000..7febd6c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_beta.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_beta.png
new file mode 100644
index 0000000..7f2af29
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_beta.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_boundaries_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_boundaries_1.png
new file mode 100644
index 0000000..ef5a38b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_boundaries_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_boundaries_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_boundaries_2.png
new file mode 100644
index 0000000..0a92465
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_boundaries_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_normal.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_normal.png
new file mode 100644
index 0000000..9e5b268
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_normal.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_uniform.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_uniform.png
new file mode 100644
index 0000000..117fc86
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_uniform.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_weibull.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_weibull.png
new file mode 100644
index 0000000..f5eb15d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_deviation_weibull.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_elements.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_elements.png
new file mode 100644
index 0000000..78dd931
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_elements.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_frequency.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_frequency.png
new file mode 100644
index 0000000..85478e2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_frequency.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_instructions.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_instructions.png
new file mode 100644
index 0000000..9e5b2c9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_instructions.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_interfaces_base_objects.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_interfaces_base_objects.png
new file mode 100644
index 0000000..9bb145d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_interfaces_base_objects.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_statistic.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_statistic.png
new file mode 100644
index 0000000..988aff2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_statistic.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_tag.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_tag.png
new file mode 100644
index 0000000..e123e21
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_tag.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_time.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_time.png
new file mode 100644
index 0000000..a22ef08
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_common_time.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components.png
new file mode 100644
index 0000000..8f9da3a
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_common.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_common.png
new file mode 100644
index 0000000..29f7107
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_common.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_component_references.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_component_references.png
new file mode 100644
index 0000000..34f204e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_component_references.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_example.png
new file mode 100644
index 0000000..d30776b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_example_treeview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_example_treeview.png
new file mode 100644
index 0000000..e3c12c8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_example_treeview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_franca_idl.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_franca_idl.png
new file mode 100644
index 0000000..dbabbd3
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_franca_idl.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_isystem.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_isystem.png
new file mode 100644
index 0000000..d9c93c2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_components_isystem.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_config_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_config_overview.png
new file mode 100644
index 0000000..46b6f74
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_config_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_config_sample.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_config_sample.png
new file mode 100644
index 0000000..1ce4b7c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_config_sample.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints.png
new file mode 100644
index 0000000..4e4c0bc
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity.png
new file mode 100644
index 0000000..d9002cd
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_data.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_data.png
new file mode 100644
index 0000000..ca9a2af
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_data.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_process.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_process.png
new file mode 100644
index 0000000..8c2e80d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_process.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_runnable.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_runnable.png
new file mode 100644
index 0000000..8aacebc
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_affinity_runnable.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_age.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_age.png
new file mode 100644
index 0000000..4f5159b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_age.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_coherency.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_coherency.png
new file mode 100644
index 0000000..3a352e6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_coherency.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_stability.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_stability.png
new file mode 100644
index 0000000..23847b1
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_data_stability.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain.png
new file mode 100644
index 0000000..00b1db5
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain_eventgroups.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain_eventgroups.png
new file mode 100644
index 0000000..ba8580e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain_eventgroups.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain_segments.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain_segments.png
new file mode 100644
index 0000000..527e560
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_eventchain_segments.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_requirements.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_requirements.png
new file mode 100644
index 0000000..25beb8e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_requirements.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing.png
new file mode 100644
index 0000000..d2748e7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing_basic.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing_basic.png
new file mode 100644
index 0000000..b89929e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing_basic.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing_scope.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing_scope.png
new file mode 100644
index 0000000..34b45e5
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_runnable_sequencing_scope.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_delay.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_delay.png
new file mode 100644
index 0000000..4eeb773
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_delay.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_latency.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_latency.png
new file mode 100644
index 0000000..706b7df
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_latency.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_repetition.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_repetition.png
new file mode 100644
index 0000000..1530e11
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_repetition.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_sync.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_sync.png
new file mode 100644
index 0000000..fe30a21
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_constraints_timing_sync.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_custom_entity.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_custom_entity.png
new file mode 100644
index 0000000..5b25d8f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_custom_entity.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_dependencies.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_dependencies.png
new file mode 100644
index 0000000..1acb0e2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_dependencies.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_events.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_events.png
new file mode 100644
index 0000000..73cad92
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_events.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_events_process.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_events_process.png
new file mode 100644
index 0000000..68c5c17
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_events_process.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_franca_editor_screenshot.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_franca_editor_screenshot.png
new file mode 100644
index 0000000..c3f5142
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_franca_editor_screenshot.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path.png
new file mode 100644
index 0000000..a9c6e68
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_hw_element_sample.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_hw_element_sample.png
new file mode 100644
index 0000000..28cb3f1
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_hw_element_sample.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_hw_element_sample_editor.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_hw_element_sample_editor.png
new file mode 100644
index 0000000..c27b12e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_hw_element_sample_editor.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_latency_sample.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_latency_sample.png
new file mode 100644
index 0000000..63f25e3
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_latency_sample.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_latency_sample_editor.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_latency_sample_editor.png
new file mode 100644
index 0000000..af8f50d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_access_path_latency_sample_editor.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_network.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_network.png
new file mode 100644
index 0000000..9686f52
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_network.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_overview.png
new file mode 100644
index 0000000..f738c5f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_hw_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_mapping_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_mapping_overview.png
new file mode 100644
index 0000000..93fca18
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_mapping_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_migration_sequence_diagram.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_migration_sequence_diagram.png
new file mode 100644
index 0000000..8e70c5b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_migration_sequence_diagram.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_data_consistency.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_data_consistency.png
new file mode 100644
index 0000000..2f595be
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_data_consistency.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_hwunit.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_hwunit.png
new file mode 100644
index 0000000..d461429
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_hwunit.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_operatingsystem.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_operatingsystem.png
new file mode 100644
index 0000000..f1da0c0
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_operatingsystem.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_osoverhead.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_osoverhead.png
new file mode 100644
index 0000000..41e39f7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_osoverhead.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_overview.png
new file mode 100644
index 0000000..7d08bd5
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_scheduler.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_scheduler.png
new file mode 100644
index 0000000..2fddc59
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_scheduler.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_semaphore.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_semaphore.png
new file mode 100644
index 0000000..821489b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_semaphore.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_swunit.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_swunit.png
new file mode 100644
index 0000000..3515985
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_os_swunit.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_propertyconstraints_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_propertyconstraints_overview.png
new file mode 100644
index 0000000..bdfbc2e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_propertyconstraints_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_section.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_section.png
new file mode 100644
index 0000000..089d0f4
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_section.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_section_memory.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_section_memory.png
new file mode 100644
index 0000000..67c5e63
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_section_memory.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli.png
new file mode 100644
index 0000000..b1b61ce
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_1.png
new file mode 100644
index 0000000..c061935
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_2.png
new file mode 100644
index 0000000..9314165
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_3.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_3.png
new file mode 100644
index 0000000..a7b88f6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_3.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_4.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_4.png
new file mode 100644
index 0000000..c5ec18b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_4.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_5.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_5.png
new file mode 100644
index 0000000..1d620e1
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_arrival_curve_5.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_clocks.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_clocks.png
new file mode 100644
index 0000000..91264d2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_clocks.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_modevaluelist.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_modevaluelist.png
new file mode 100644
index 0000000..841a0a9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_modevaluelist.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_periodic.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_periodic.png
new file mode 100644
index 0000000..146524b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_periodic.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_stimuli.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_stimuli.png
new file mode 100644
index 0000000..e8a5ffd
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_stimuli_stimuli.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_activation.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_activation.png
new file mode 100644
index 0000000..dfcd5b2
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_activation.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_call_graph.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_call_graph.png
new file mode 100644
index 0000000..b614da6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_call_graph.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_channel.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_channel.png
new file mode 100644
index 0000000..2538a60
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_channel.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_label.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_label.png
new file mode 100644
index 0000000..ff12561
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_label.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_memory_inf.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_memory_inf.png
new file mode 100644
index 0000000..0c8da07
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_memory_inf.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_modes.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_modes.png
new file mode 100644
index 0000000..ca1d62c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_modes.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_modeswitch.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_modeswitch.png
new file mode 100644
index 0000000..4d16d23
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_modeswitch.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_osevents.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_osevents.png
new file mode 100644
index 0000000..a58700c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_osevents.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_probabilityswitch.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_probabilityswitch.png
new file mode 100644
index 0000000..37128a3
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_probabilityswitch.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_process_prototype.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_process_prototype.png
new file mode 100644
index 0000000..3c90057
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_process_prototype.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_1_group.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_1_group.png
new file mode 100644
index 0000000..553b06c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_1_group.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_3_semaphores.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_3_semaphores.png
new file mode 100644
index 0000000..8002848
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_3_semaphores.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_4_modes.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_4_modes.png
new file mode 100644
index 0000000..5e93826
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items_4_modes.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__calls.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__calls.png
new file mode 100644
index 0000000..745bc39
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__calls.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__channel_access.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__channel_access.png
new file mode 100644
index 0000000..4077969
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__channel_access.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__label_access.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__label_access.png
new file mode 100644
index 0000000..6791bf8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_items__label_access.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_overview.png
new file mode 100644
index 0000000..a11e485
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnable_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnableinstructions.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnableinstructions.png
new file mode 100644
index 0000000..c866af8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnableinstructions.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnablemodeswitch.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnablemodeswitch.png
new file mode 100644
index 0000000..2af9910
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnablemodeswitch.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnableprobabilityswitch.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnableprobabilityswitch.png
new file mode 100644
index 0000000..b972153
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_runnableprobabilityswitch.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_statistic.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_statistic.png
new file mode 100644
index 0000000..8a71965
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_statistic.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_callgraph.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_callgraph.png
new file mode 100644
index 0000000..d6a84ba
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_callgraph.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_callgraph_structure.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_callgraph_structure.png
new file mode 100644
index 0000000..40d2880
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_callgraph_structure.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_isr.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_isr.png
new file mode 100644
index 0000000..237ae6f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_task_isr.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_type_sample.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_type_sample.png
new file mode 100644
index 0000000..e74c9f0
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_type_sample.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_type_system.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_type_system.png
new file mode 100644
index 0000000..20f6268
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_sw_type_system.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_transient_backpointer.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_transient_backpointer.png
new file mode 100644
index 0000000..e5ca921
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_transient_backpointer.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_transient_backpointer_ui.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_transient_backpointer_ui.png
new file mode 100644
index 0000000..acff3c3
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/model_transient_backpointer_ui.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_gantt.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_gantt.png
new file mode 100644
index 0000000..2c12c92
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_gantt.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_hw.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_hw.png
new file mode 100644
index 0000000..6933cd6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_hw.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_mapping.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_mapping.png
new file mode 100644
index 0000000..a092810
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_mapping.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_runnables.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_runnables.png
new file mode 100644
index 0000000..24ee93d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_runnables.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_schedulers.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_schedulers.png
new file mode 100644
index 0000000..83191e3
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_schedulers.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_stimuli.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_stimuli.png
new file mode 100644
index 0000000..0d2885d
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_stimuli.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_tasks.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_tasks.png
new file mode 100644
index 0000000..7635b82
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_1_tasks.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_gantt.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_gantt.png
new file mode 100644
index 0000000..6fc1a21
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_gantt.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_hw.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_hw.png
new file mode 100644
index 0000000..cf63082
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_hw.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_mapping.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_mapping.png
new file mode 100644
index 0000000..55f6804
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_mapping.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_runnables.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_runnables.png
new file mode 100644
index 0000000..c0c41bd
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_runnables.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_scheduler.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_scheduler.png
new file mode 100644
index 0000000..14746a0
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_scheduler.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_stimuli.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_stimuli.png
new file mode 100644
index 0000000..5832a8c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_stimuli.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_tasks.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_tasks.png
new file mode 100644
index 0000000..7490168
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_2_tasks.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server.png
new file mode 100644
index 0000000..503458e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_1.png
new file mode 100644
index 0000000..9e4ce6f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_2.png
new file mode 100644
index 0000000..a3d7905
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_3.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_3.png
new file mode 100644
index 0000000..8c38508
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_3.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_4.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_4.png
new file mode 100644
index 0000000..4fb2280
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_4.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_5.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_5.png
new file mode 100644
index 0000000..a7f6428
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_5.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_6.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_6.png
new file mode 100644
index 0000000..bd19e6e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_6.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_7.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_7.png
new file mode 100644
index 0000000..627105b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_7.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_8.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_8.png
new file mode 100644
index 0000000..a2df57a
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_8.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_9.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_9.png
new file mode 100644
index 0000000..31f9ae6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_client_server_9.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop.png
new file mode 100644
index 0000000..4721e08
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_1.png
new file mode 100644
index 0000000..4139049
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_2.png
new file mode 100644
index 0000000..666c02a
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_3.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_3.png
new file mode 100644
index 0000000..9326936
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_3.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_4.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_4.png
new file mode 100644
index 0000000..f7ea88b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_4.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_5.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_5.png
new file mode 100644
index 0000000..22643d4
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_5.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_6.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_6.png
new file mode 100644
index 0000000..e683a89
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_6.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_7.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_7.png
new file mode 100644
index 0000000..aa82a81
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_7.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_8.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_8.png
new file mode 100644
index 0000000..0712971
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_8.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_9.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_9.png
new file mode 100644
index 0000000..91521f7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_feedback_loop_9.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_1.png
new file mode 100644
index 0000000..72608ea
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_2.png
new file mode 100644
index 0000000..74c1e23
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_3.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_3.png
new file mode 100644
index 0000000..a24aad7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_3.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_4.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_4.png
new file mode 100644
index 0000000..ffc570e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_4.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_5.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_5.png
new file mode 100644
index 0000000..b2e1ebe
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_5.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_6.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_6.png
new file mode 100644
index 0000000..1a5f4e5
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_6.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_7.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_7.png
new file mode 100644
index 0000000..25698ab
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_7.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_8.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_8.png
new file mode 100644
index 0000000..d966f2f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_8.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_9.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_9.png
new file mode 100644
index 0000000..82ce9c8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_periodic_9.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine.png
new file mode 100644
index 0000000..74904a9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_1.png
new file mode 100644
index 0000000..ed4b5dd
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_2.png
new file mode 100644
index 0000000..0906bab
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_3.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_3.png
new file mode 100644
index 0000000..8ce5db8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_3.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_4.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_4.png
new file mode 100644
index 0000000..29b2f76
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_4.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_5.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_5.png
new file mode 100644
index 0000000..8e5ad38
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_5.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_6.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_6.png
new file mode 100644
index 0000000..5d29572
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_6.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_7.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_7.png
new file mode 100644
index 0000000..bd6e870
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_7.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_8.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_8.png
new file mode 100644
index 0000000..4391a9e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_8.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_9.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_9.png
new file mode 100644
index 0000000..5e1ed59
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_9.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop.png
new file mode 100644
index 0000000..a5ada85
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_1.png
new file mode 100644
index 0000000..1769334
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_2.png
new file mode 100644
index 0000000..f606216
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_3.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_3.png
new file mode 100644
index 0000000..56c546e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_3.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_4.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_4.png
new file mode 100644
index 0000000..ea6b139
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_4.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_5.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_5.png
new file mode 100644
index 0000000..2b981ac
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_5.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_6.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_6.png
new file mode 100644
index 0000000..12b72ea
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_6.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_7.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_7.png
new file mode 100644
index 0000000..cdc239a
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_7.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_8.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_8.png
new file mode 100644
index 0000000..be72a68
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_8.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_9.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_9.png
new file mode 100644
index 0000000..83c7506
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/modeling_example_state_machine_feedback_loop_9.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/models_selection.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/models_selection.png
new file mode 100644
index 0000000..65b04e6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/models_selection.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/osbuffering_migration_071_072.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/osbuffering_migration_071_072.png
new file mode 100644
index 0000000..30748da
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/osbuffering_migration_071_072.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/partexample.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/partexample.png
new file mode 100644
index 0000000..5c5a2ec
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/partexample.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/post_processor.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/post_processor.png
new file mode 100644
index 0000000..640027c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/post_processor.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/pre_processor.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/pre_processor.png
new file mode 100644
index 0000000..8aece53
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/pre_processor.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/print.css b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/print.css
new file mode 100644
index 0000000..3577aca
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/print.css
@@ -0,0 +1,22 @@
+/*******************************************************************************
+ * Copyright (c) 2007 IBM Corporation and others.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * IBM Corporation - initial API and implementation
+ *******************************************************************************/
+
+#toc {
+ margin-bottom: 2em;
+}
+
+#toc_content {
+ margin-top: 1em;
+}
+
+.toc_subentry {
+ margin-left: 1.5em;
+}
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/process_prototypes.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/process_prototypes.png
new file mode 100644
index 0000000..0c4cc50
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/process_prototypes.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/psteps_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/psteps_small.png
new file mode 100644
index 0000000..ff2eeb8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/psteps_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/sample_workflow.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/sample_workflow.png
new file mode 100644
index 0000000..ab4532f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/sample_workflow.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/select_project_to_import.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/select_project_to_import.png
new file mode 100644
index 0000000..d1f32f8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/select_project_to_import.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/show_plugins_view.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/show_plugins_view.png
new file mode 100644
index 0000000..3338d52
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/show_plugins_view.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/ta_small.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/ta_small.png
new file mode 100644
index 0000000..a4b345b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/ta_small.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_add_schedule_points.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_add_schedule_points.png
new file mode 100644
index 0000000..4f4d318
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_add_schedule_points.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_add_schedule_points_mwe2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_add_schedule_points_mwe2.png
new file mode 100644
index 0000000..c228fee
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_add_schedule_points_mwe2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_context.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_context.png
new file mode 100644
index 0000000..dba18d7
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_context.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_create_tasks.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_create_tasks.png
new file mode 100644
index 0000000..a2301f4
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_create_tasks.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_default_context.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_default_context.png
new file mode 100644
index 0000000..3a1e596
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_default_context.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_reader.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_reader.png
new file mode 100644
index 0000000..d7cd911
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_reader.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_reader_mwe2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_reader_mwe2.png
new file mode 100644
index 0000000..62e34cc
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_reader_mwe2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_writer.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_writer.png
new file mode 100644
index 0000000..064f4d4
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_writer.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_writer_mwe2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_writer_mwe2.png
new file mode 100644
index 0000000..7c29021
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_model_writer_mwe2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_component.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_component.png
new file mode 100644
index 0000000..67c2a7e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_component.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_component_mwe2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_component_mwe2.png
new file mode 100644
index 0000000..ca9d2a9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_component_mwe2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_overview.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_overview.png
new file mode 100644
index 0000000..6cbc390
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_overview.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_overview_sequence.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_overview_sequence.png
new file mode 100644
index 0000000..f66c647
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/uml_workflow_overview_sequence.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel.png
new file mode 100644
index 0000000..19abba1
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_access.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_access.png
new file mode 100644
index 0000000..7f9584e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_access.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_example.png
new file mode 100644
index 0000000..f60f93b
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_operations.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_operations.png
new file mode 100644
index 0000000..4477d26
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_operations.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_transmission_example.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_transmission_example.png
new file mode 100644
index 0000000..b36f337
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_channel_transmission_example.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_editor_with_central_model.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_editor_with_central_model.png
new file mode 100644
index 0000000..61c14b0
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_editor_with_central_model.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_commands.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_commands.png
new file mode 100644
index 0000000..c009872
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_commands.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_input.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_input.png
new file mode 100644
index 0000000..cbf3d81
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_input.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_result1.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_result1.png
new file mode 100644
index 0000000..8b6dbb9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_result1.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_result2.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_result2.png
new file mode 100644
index 0000000..9c01c84
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_search_result2.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_showtypes.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_showtypes.png
new file mode 100644
index 0000000..b3b89c1
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_showtypes.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_structure.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_structure.png
new file mode 100644
index 0000000..c258355
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_editor_structure.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step1_create-project.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step1_create-project.png
new file mode 100644
index 0000000..a6e6f90
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step1_create-project.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step2_create-folder.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step2_create-folder.png
new file mode 100644
index 0000000..b0a5f5e
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step2_create-folder.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step3_create-model.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step3_create-model.png
new file mode 100644
index 0000000..fd51f44
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_guide_step3_create-model.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_amalthea.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_amalthea.png
new file mode 100644
index 0000000..b1b0928
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_amalthea.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_label_ref_to_memsection.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_label_ref_to_memsection.png
new file mode 100644
index 0000000..7523be4
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_label_ref_to_memsection.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_linker_memsection.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_linker_memsection.png
new file mode 100644
index 0000000..4412e7f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_linker_memsection.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_virtual_to_physical.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_virtual_to_physical.png
new file mode 100644
index 0000000..e7f99f6
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_section_virtual_to_physical.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_new_runnable_iitem.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_new_runnable_iitem.png
new file mode 100644
index 0000000..f03c98f
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_new_runnable_iitem.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt.png
new file mode 100644
index 0000000..debbc85
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_runnable.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_runnable.png
new file mode 100644
index 0000000..0f6894a
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_runnable.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_semaphore.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_semaphore.png
new file mode 100644
index 0000000..fc34090
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_semaphore.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_signal.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_signal.png
new file mode 100644
index 0000000..a804489
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_signal.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_task.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_task.png
new file mode 100644
index 0000000..846b51c
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/user_sw_runtime_gantt_task.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/vm_arguments_configuration.png b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/vm_arguments_configuration.png
new file mode 100644
index 0000000..d31eab8
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/images/vm_arguments_configuration.png
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/index.html b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/index.html
new file mode 100644
index 0000000..985b3b9
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/index.html
@@ -0,0 +1,10302 @@
+<!DOCTYPE html>
+
+<!--
+ ! Copyright (c) 2017 Robert Bosch GmbH and others.
+ ! All rights reserved. This program and the accompanying materials
+ ! are made available under the terms of the Eclipse Public License v1.0
+ ! which accompanies this distribution, and is available at
+ ! http://www.eclipse.org/legal/epl-v10.html
+ -->
+
+<html lang="en">
+
+<head>
+ <meta charset="UTF-8">
+ <title>APP4MC Documentation</title>
+ <link rel="stylesheet" href="css/help.css" type="text/css">
+ <link rel="stylesheet" href="css/frames.css" type="text/css">
+ <link rel="stylesheet" href="css/toc-style.css" type="text/css">
+</head>
+
+<body>
+
+ <div id="framecontent">
+ <div class="innertube">
+
+<!-- - - - - - - - - Table of contents - - - - - - - - -->
+<div class="toc-tree">
+<ul>
+<li><label class="leaf"><a href="#section1">Introduction to APP4MC</a></label></li>
+<li><input type="checkbox" id="toc2" /><label for="toc2"><a href="#section2">User Guide</a></label>
+<ul>
+<li><input type="checkbox" id="toc2.1" /><label for="toc2.1"><a href="#section2.1">Introduction</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.1.1">Steps to create a new AMALTHEA model</a></label></li>
+<li><input type="checkbox" id="toc2.1.2" /><label for="toc2.1.2"><a href="#section2.1.2">AMALTHEA Editor</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.1.2.1">Show types of model elements</a></label></li>
+<li><label class="leaf"><a href="#section2.1.2.2">Search for model elements</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.1.3">AMALTHEA Examples</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.2" /><label for="toc2.2"><a href="#section2.2">Concepts</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.1">Hardware</a></label></li>
+<li><input type="checkbox" id="toc2.2.2" /><label for="toc2.2.2"><a href="#section2.2.2">Software (development)</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.2.1">Runnables</a></label></li>
+<li><label class="leaf"><a href="#section2.2.2.2">Process Prototypes</a></label></li>
+<li><label class="leaf"><a href="#section2.2.2.3">Constraints</a></label></li>
+<li><label class="leaf"><a href="#section2.2.2.4">Activations</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.2.3" /><label for="toc2.2.3"><a href="#section2.2.3">Software (runtime)</a></label>
+<ul>
+<li><input type="checkbox" id="toc2.2.3.1" /><label for="toc2.2.3.1"><a href="#section2.2.3.1">Processes (Tasks or ISRs)</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.3.1.1">Runnables</a></label></li>
+<li><label class="leaf"><a href="#section2.2.3.1.2">Labels</a></label></li>
+<li><label class="leaf"><a href="#section2.2.3.1.3">Semaphore</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.2.3.2">Stimulation</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.2.4" /><label for="toc2.2.4"><a href="#section2.2.4">General Concepts</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.4.1">Grouping of elements (Tags, Tag groups)</a></label></li>
+<li><label class="leaf"><a href="#section2.2.4.2">Custom Properties</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.2.5" /><label for="toc2.2.5"><a href="#section2.2.5">Communication via channels</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.5.1">Channel</a></label></li>
+<li><input type="checkbox" id="toc2.2.5.2" /><label for="toc2.2.5.2"><a href="#section2.2.5.2">Channel Access</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.5.2.1">Sending</a></label></li>
+<li><label class="leaf"><a href="#section2.2.5.2.2">Receiving</a></label></li>
+<li><label class="leaf"><a href="#section2.2.5.2.3">Common Read Policies: Last, New, and AllNew</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.2.5.3">Transmission Policy</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.2.6" /><label for="toc2.2.6"><a href="#section2.2.6">Memory Sections</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.2.6.1">Virtual Memory Section</a></label></li>
+<li><label class="leaf"><a href="#section2.2.6.2">Physical Memory Section</a></label></li>
+<li><label class="leaf"><a href="#section2.2.6.3">Modeling Memory Section information in AMALTHEA</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.3" /><label for="toc2.3"><a href="#section2.3">Examples</a></label>
+<ul>
+<li><input type="checkbox" id="toc2.3.1" /><label for="toc2.3.1"><a href="#section2.3.1">Modeling Example 1</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.1.1">General information</a></label></li>
+<li><label class="leaf"><a href="#section2.3.1.2">Hardware Model</a></label></li>
+<li><label class="leaf"><a href="#section2.3.1.3">Operating System Model</a></label></li>
+<li><input type="checkbox" id="toc2.3.1.4" /><label for="toc2.3.1.4"><a href="#section2.3.1.4">Mapping Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.1.4.1">Executable Allocation</a></label></li>
+<li><label class="leaf"><a href="#section2.3.1.4.2">Core Allocation</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.3.1.5" /><label for="toc2.3.1.5"><a href="#section2.3.1.5">Software Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.1.5.1">Tasks</a></label></li>
+<li><label class="leaf"><a href="#section2.3.1.5.2">Runnables</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.3.1.6">Stimuli Model</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.3.2" /><label for="toc2.3.2"><a href="#section2.3.2">Modeling Example 2</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.2.1">General information</a></label></li>
+<li><label class="leaf"><a href="#section2.3.2.2">Hardware Model</a></label></li>
+<li><label class="leaf"><a href="#section2.3.2.3">Operating System Model</a></label></li>
+<li><input type="checkbox" id="toc2.3.2.4" /><label for="toc2.3.2.4"><a href="#section2.3.2.4">Mapping Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.2.4.1">Executable Allocation</a></label></li>
+<li><label class="leaf"><a href="#section2.3.2.4.2">Core Allocation</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.3.2.5" /><label for="toc2.3.2.5"><a href="#section2.3.2.5">Software Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.2.5.1">Tasks</a></label></li>
+<li><label class="leaf"><a href="#section2.3.2.5.2">Runnables</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.3.2.6">Stimulation Model</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.3.3">Modeling Example "Purely Periodic without Communication"</a></label></li>
+<li><label class="leaf"><a href="#section2.3.4">Modeling Example "Client-Server without Reply"</a></label></li>
+<li><label class="leaf"><a href="#section2.3.5">Modeling Example "State Machine"</a></label></li>
+<li><label class="leaf"><a href="#section2.3.6">Modeling Example "Feedback Loop"</a></label></li>
+<li><label class="leaf"><a href="#section2.3.7">Modeling Example "State Machine Feedback Loop"</a></label></li>
+<li><input type="checkbox" id="toc2.3.8" /><label for="toc2.3.8"><a href="#section2.3.8">Democar Example</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.3.8.1">Origin</a></label></li>
+<li><label class="leaf"><a href="#section2.3.8.2">Files</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.3.9">Hwmodel Example</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.4" /><label for="toc2.4"><a href="#section2.4">Tutorials</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.4.1">Task creation example</a></label></li>
+<li><label class="leaf"><a href="#section2.4.2">Mapping example 1</a></label></li>
+<li><label class="leaf"><a href="#section2.4.3">Mapping example 2</a></label></li>
+<li><label class="leaf"><a href="#section2.4.4">AMALTHEA Trace Database (ATDB) Import Example</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.5" /><label for="toc2.5"><a href="#section2.5">Editors / Viewers</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.5.1">AMALTHEA Trace Database Metrics Viewer</a></label></li>
+<li><label class="leaf"><a href="#section2.5.2">Other editors</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.6" /><label for="toc2.6"><a href="#section2.6">Model Validation</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.6.1">Usage of Check-based Validation</a></label></li>
+<li><input type="checkbox" id="toc2.6.2" /><label for="toc2.6.2"><a href="#section2.6.2">Available Validations</a></label>
+<ul>
+<li><input type="checkbox" id="toc2.6.2.1" /><label for="toc2.6.2.1"><a href="#section2.6.2.1">A. Basic Check Validator</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.6.2.1.1">CustomPropertyDuplicateKeyConstraint</a></label></li>
+<li><label class="leaf"><a href="#section2.6.2.1.2">WeibullParametersConstraint</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.6.2.2" /><label for="toc2.6.2.2"><a href="#section2.6.2.2">B. ConstraintsModel Check Validator</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.6.2.2.1">EventChainsConstraint</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.6.2.3" /><label for="toc2.6.2.3"><a href="#section2.6.2.3">C. EventModel Check Validator</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.6.2.3.1">LabelEventMappingConstraint</a></label></li>
+<li><label class="leaf"><a href="#section2.6.2.3.2">ProcessEventMappingConstraint</a></label></li>
+<li><label class="leaf"><a href="#section2.6.2.3.3">RunnableEventMappingConstraint</a></label></li>
+<li><label class="leaf"><a href="#section2.6.2.3.4">SemaphoreEventMappingConstraint</a></label></li>
+<li><label class="leaf"><a href="#section2.6.2.3.5">StimulusEventMappingConstraint</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.6.2.4" /><label for="toc2.6.2.4"><a href="#section2.6.2.4">D. HardwareModel Check Validator</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.6.2.4.1">HwModelAbstractTypeDuplicateNameConstriant</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.6.2.5" /><label for="toc2.6.2.5"><a href="#section2.6.2.5">E. MappingModel Check Validator</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.6.2.5.1">Process2Scheduler2CoreMappingConstraint</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc2.7" /><label for="toc2.7"><a href="#section2.7">Model Migration</a></label>
+<ul>
+<li><input type="checkbox" id="toc2.7.1" /><label for="toc2.7.1"><a href="#section2.7.1">AMALTHEA Model Migration</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.7.1.1">Why model migration is required ?</a></label></li>
+<li><label class="leaf"><a href="#section2.7.1.2">AMALTHEA model migration</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.7.2">Supported versions for model Migration</a></label></li>
+<li><input type="checkbox" id="toc2.7.3" /><label for="toc2.7.3"><a href="#section2.7.3">Pre-requisites for AMALTHEA model migration</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.7.3.1">VM arguments</a></label></li>
+<li><input type="checkbox" id="toc2.7.3.2" /><label for="toc2.7.3.2"><a href="#section2.7.3.2">Usage of UUID's instead of URI fragments inside AMALTHEA models</a></label>
+<ul>
+<li><label class="leaf"><a href="#section2.7.3.2.1">How to identify if Xpath like URI fragments are used in AMALTHEA model files</a></label></li>
+<li><label class="leaf"><a href="#section2.7.3.2.2">How to identify if UUID's are used in AMALTHEA model files</a></label></li>
+<li><label class="leaf"><a href="#section2.7.3.2.3">Update AMALTHEA models to use UUID's instead of Xpath like URI fragments</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section2.7.4">How to invoke AMALTHEA model migration</a></label></li>
+<li><label class="leaf"><a href="#section2.7.5">Additional details</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3" /><label for="toc3"><a href="#section3">Data Models</a></label>
+<ul>
+<li><input type="checkbox" id="toc3.1" /><label for="toc3.1"><a href="#section3.1">Data Model Overview</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.1.1">AMALTHEA System Model</a></label></li>
+<li><label class="leaf"><a href="#section3.1.2">AMALTHEA Trace Model</a></label></li>
+<li><label class="leaf"><a href="#section3.1.3">Structure of the model</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.2" /><label for="toc3.2"><a href="#section3.2">Common Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.2.1">Common Elements</a></label></li>
+<li><label class="leaf"><a href="#section3.2.2">Tags</a></label></li>
+<li><label class="leaf"><a href="#section3.2.3">Custom Properties</a></label></li>
+<li><label class="leaf"><a href="#section3.2.4">Time (and Time Unit)</a></label></li>
+<li><label class="leaf"><a href="#section3.2.5">Frequency (and Frequency Unit)</a></label></li>
+<li><label class="leaf"><a href="#section3.2.6">Data Size (and Data Size Unit)</a></label></li>
+<li><label class="leaf"><a href="#section3.2.7">Data Rate (and Data Rate Unit)</a></label></li>
+<li><input type="checkbox" id="toc3.2.8" /><label for="toc3.2.8"><a href="#section3.2.8">Deviation</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.2.8.1">Boundaries</a></label></li>
+<li><label class="leaf"><a href="#section3.2.8.2">Uniform Distribution</a></label></li>
+<li><label class="leaf"><a href="#section3.2.8.3">Gaussian/Normal Distribution</a></label></li>
+<li><label class="leaf"><a href="#section3.2.8.4">Beta Distribution</a></label></li>
+<li><label class="leaf"><a href="#section3.2.8.5">Weibull Distribution</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.2.9">Statistic Elements</a></label></li>
+<li><label class="leaf"><a href="#section3.2.10">Instructions</a></label></li>
+<li><label class="leaf"><a href="#section3.2.11">Counters</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.3" /><label for="toc3.3"><a href="#section3.3">Components Model</a></label>
+<ul>
+<li><input type="checkbox" id="toc3.3.1" /><label for="toc3.3.1"><a href="#section3.3.1">Components Model Elements</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.3.1.1">Component</a></label></li>
+<li><label class="leaf"><a href="#section3.3.1.2">System and Composite</a></label></li>
+<li><label class="leaf"><a href="#section3.3.1.3">ComponentInstance and Connector</a></label></li>
+<li><label class="leaf"><a href="#section3.3.1.4">QualifiedPort</a></label></li>
+<li><label class="leaf"><a href="#section3.3.1.5">FInterfacePort</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.3.2" /><label for="toc3.3.2"><a href="#section3.3.2">Example</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.3.2.1">Diagram</a></label></li>
+<li><label class="leaf"><a href="#section3.3.2.2">Model Editor</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.3.3">Franca IDL</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.4" /><label for="toc3.4"><a href="#section3.4">Configuration Model</a></label>
+<ul>
+<li><input type="checkbox" id="toc3.4.1" /><label for="toc3.4.1"><a href="#section3.4.1">Event Configuration</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.4.1.1">Sample</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.5" /><label for="toc3.5"><a href="#section3.5">Constraints Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.5.1">Requirements</a></label></li>
+<li><label class="leaf"><a href="#section3.5.2">Runnable Sequencing Constraints</a></label></li>
+<li><label class="leaf"><a href="#section3.5.3">Data Age Constraints</a></label></li>
+<li><label class="leaf"><a href="#section3.5.4">Data Coherency Groups</a></label></li>
+<li><label class="leaf"><a href="#section3.5.5">Data Stability Groups</a></label></li>
+<li><label class="leaf"><a href="#section3.5.6">Event Chains</a></label></li>
+<li><input type="checkbox" id="toc3.5.7" /><label for="toc3.5.7"><a href="#section3.5.7">Timing Constraints</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.5.7.1">Synchronization Constraints</a></label></li>
+<li><label class="leaf"><a href="#section3.5.7.2">Repetition Constraint</a></label></li>
+<li><label class="leaf"><a href="#section3.5.7.3">Delay Constraint</a></label></li>
+<li><label class="leaf"><a href="#section3.5.7.4">Event Chain Latency Constraint</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.5.8" /><label for="toc3.5.8"><a href="#section3.5.8">Affinity Constraints</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.5.8.1">Data Affinity Constraints</a></label></li>
+<li><label class="leaf"><a href="#section3.5.8.2">Process Affinity Constraints</a></label></li>
+<li><label class="leaf"><a href="#section3.5.8.3">Runnable Affinity Constraints</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.5.9">Physical Section Constraints</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.6">Event Model</a></label></li>
+<li><input type="checkbox" id="toc3.7" /><label for="toc3.7"><a href="#section3.7">Hardware model</a></label>
+<ul>
+<li><input type="checkbox" id="toc3.7.1" /><label for="toc3.7.1"><a href="#section3.7.1">Structure</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.7.1.1">ComplexNode</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.2">HwSystem</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.3">ECU</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.4">Microcontroller</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.5">Core</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.6">Memory</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.7">Network</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.8">Quartz</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.9">Component</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.10">HardwareTypeDescription</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.11">AbstractionTypeDescription</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.12">SystemType</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.13">ECUType</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.14">MicrocontrollerType</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.15">CoreType</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.16">MemoryType</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.17">NetworkType</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.18">CrossbarSwitch</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.19">Bus</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.20">Bridge</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.21">Pin</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.22">ComplexPin</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.23">Port</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.24">ComplexPort</a></label></li>
+<li><label class="leaf"><a href="#section3.7.1.25">AbstractType</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.7.2" /><label for="toc3.7.2"><a href="#section3.7.2">AccessPaths</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.7.2.1">Latency Overview</a></label></li>
+<li><label class="leaf"><a href="#section3.7.2.2">Hardware Access Path</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.8" /><label for="toc3.8"><a href="#section3.8">Mapping Model</a></label>
+<ul>
+<li><input type="checkbox" id="toc3.8.1" /><label for="toc3.8.1"><a href="#section3.8.1">Overview</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.8.1.1">MappingModel</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.8.2" /><label for="toc3.8.2"><a href="#section3.8.2">Mapping</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.8.2.1">AbstractElementMapping</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.8.3">PhysicalSectionMapping</a></label></li>
+<li><input type="checkbox" id="toc3.8.4" /><label for="toc3.8.4"><a href="#section3.8.4">Allocation</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.8.4.1">CoreAllocation</a></label></li>
+<li><label class="leaf"><a href="#section3.8.4.2">RunnableAllocation</a></label></li>
+<li><label class="leaf"><a href="#section3.8.4.3">ISRAllocation</a></label></li>
+<li><label class="leaf"><a href="#section3.8.4.4">TaskAllocation</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.9" /><label for="toc3.9"><a href="#section3.9">OS Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.9.1">Operating System</a></label></li>
+<li><input type="checkbox" id="toc3.9.2" /><label for="toc3.9.2"><a href="#section3.9.2">Scheduler</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.9.2.1">Scheduling HW Unit</a></label></li>
+<li><label class="leaf"><a href="#section3.9.2.2">Scheduling SW Unit</a></label></li>
+<li><label class="leaf"><a href="#section3.9.2.3">Scheduling Algorithm</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.9.3" /><label for="toc3.9.3"><a href="#section3.9.3">Os Overhead</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.9.3.1">ISR Overhead</a></label></li>
+<li><label class="leaf"><a href="#section3.9.3.2">API Overhead</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.9.4">OS Data Consistency</a></label></li>
+<li><label class="leaf"><a href="#section3.9.5">Semaphore</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.10" /><label for="toc3.10"><a href="#section3.10">PropertyConstraints Model</a></label>
+<ul>
+<li><input type="checkbox" id="toc3.10.1" /><label for="toc3.10.1"><a href="#section3.10.1">Structure</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.10.1.1">PropertyConstraintsModel</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.2">AllocationConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.3">ProcessAllocationConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.4">RunnableAllocationConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.5">HwCoreConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.6">HwCoreConjunction</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.7">HwCoreProperty</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.8">MappingConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.9">AbstractElementMappingConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.10">HwMemoryConstraint</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.11">HwMemoryConjunction</a></label></li>
+<li><label class="leaf"><a href="#section3.10.1.12">HwMemoryProperty</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.11" /><label for="toc3.11"><a href="#section3.11">Stimuli Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.11.1">Stimuli</a></label></li>
+<li><label class="leaf"><a href="#section3.11.2">Clocks</a></label></li>
+<li><label class="leaf"><a href="#section3.11.3">Arrival Curves</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.12" /><label for="toc3.12"><a href="#section3.12">Software Model</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.12.1">Memory Information</a></label></li>
+<li><label class="leaf"><a href="#section3.12.2">Labels</a></label></li>
+<li><label class="leaf"><a href="#section3.12.3">Channels</a></label></li>
+<li><input type="checkbox" id="toc3.12.4" /><label for="toc3.12.4"><a href="#section3.12.4">Data Types</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.12.4.1">General Information</a></label></li>
+<li><label class="leaf"><a href="#section3.12.4.2">Sample</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.12.5">Activations</a></label></li>
+<li><label class="leaf"><a href="#section3.12.6">Runnables and Services</a></label></li>
+<li><label class="leaf"><a href="#section3.12.7">Runnables</a></label></li>
+<li><input type="checkbox" id="toc3.12.8" /><label for="toc3.12.8"><a href="#section3.12.8">Runnable Items</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.12.8.1">Groups</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.2">Calls and AUTOSAR communication</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.3">Label Access</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.4">Channel Access</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.5">Semaphore Access</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.6">Mode Label Access</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.7">Runnable Mode Switch</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.8">Runnable Probability Switch</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.9">Runnable Instructions</a></label></li>
+<li><label class="leaf"><a href="#section3.12.8.10">Statistical Values</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.12.9">Tasks / ISR</a></label></li>
+<li><input type="checkbox" id="toc3.12.10" /><label for="toc3.12.10"><a href="#section3.12.10">The Call Graph</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.12.10.1">Mode Switch</a></label></li>
+<li><label class="leaf"><a href="#section3.12.10.2">Probability Switch</a></label></li>
+<li><label class="leaf"><a href="#section3.12.10.3">Call Sequence</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.12.11" /><label for="toc3.12.11"><a href="#section3.12.11">Call Sequence Content</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.12.11.1">Task Runnable Call</a></label></li>
+<li><label class="leaf"><a href="#section3.12.11.2">Enforced Migration</a></label></li>
+<li><label class="leaf"><a href="#section3.12.11.3">Inter Process Activation</a></label></li>
+<li><label class="leaf"><a href="#section3.12.11.4">Schedule Point</a></label></li>
+<li><label class="leaf"><a href="#section3.12.11.5">Terminate Process</a></label></li>
+<li><label class="leaf"><a href="#section3.12.11.6">Wait/Clear/Set Event</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc3.12.12" /><label for="toc3.12.12"><a href="#section3.12.12">Modes</a></label>
+<ul>
+<li><label class="leaf"><a href="#section3.12.12.1">Modes and Mode Labels</a></label></li>
+<li><label class="leaf"><a href="#section3.12.12.2">Mode Changes</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section3.12.13">Process Prototypes</a></label></li>
+<li><label class="leaf"><a href="#section3.12.14">Process Chains</a></label></li>
+<li><label class="leaf"><a href="#section3.12.15">Custom Entities</a></label></li>
+<li><label class="leaf"><a href="#section3.12.16">Section</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4" /><label for="toc4"><a href="#section4">Developer Guide</a></label>
+<ul>
+<li><input type="checkbox" id="toc4.1" /><label for="toc4.1"><a href="#section4.1">Overview of Features and Plug-ins</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.1.1">Features</a></label></li>
+<li><label class="leaf"><a href="#section4.1.2">Plug-ins</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.2" /><label for="toc4.2"><a href="#section4.2">Model Validation</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.2.1">Understanding Check Catalogs</a></label></li>
+<li><label class="leaf"><a href="#section4.2.2">Adding own Validations</a></label></li>
+<li><input type="checkbox" id="toc4.2.3" /><label for="toc4.2.3"><a href="#section4.2.3">Plugin dependencies</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.2.3.1">Implementation</a></label></li>
+<li><label class="leaf"><a href="#section4.2.3.2">Plugin configuration</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.3" /><label for="toc4.3"><a href="#section4.3">Model Workflow</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.3.1">Introduction</a></label></li>
+<li><label class="leaf"><a href="#section4.3.2">General Structure</a></label></li>
+<li><input type="checkbox" id="toc4.3.3" /><label for="toc4.3.3"><a href="#section4.3.3">Available Basic Components</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.3.3.1">Model Reader</a></label></li>
+<li><label class="leaf"><a href="#section4.3.3.2">Model Writer</a></label></li>
+<li><label class="leaf"><a href="#section4.3.3.3">Add Schedule Points</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.3.4" /><label for="toc4.3.4"><a href="#section4.3.4">Other Components</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.3.4.1">Create Tasks</a></label></li>
+<li><label class="leaf"><a href="#section4.3.4.2">Generate Mapping</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.3.5" /><label for="toc4.3.5"><a href="#section4.3.5">EASE modules</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.3.5.1">Workflow Module</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.3.6" /><label for="toc4.3.6"><a href="#section4.3.6">MWE2 Workflow</a></label>
+<ul>
+<li><input type="checkbox" id="toc4.3.6.1" /><label for="toc4.3.6.1"><a href="#section4.3.6.1">MWE2 Components</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.3.6.1.1">Reader</a></label></li>
+<li><label class="leaf"><a href="#section4.3.6.1.2">Writer</a></label></li>
+<li><label class="leaf"><a href="#section4.3.6.1.3">Add Schedule Points</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section4.3.7">Current Limitations / Open Points</a></label></li>
+<li><label class="leaf"><a href="#section4.3.8">Overall Sample</a></label></li>
+<li><label class="leaf"><a href="#section4.3.9">Adding a new workflow component</a></label></li>
+<li><input type="checkbox" id="toc4.3.10" /><label for="toc4.3.10"><a href="#section4.3.10">Create project</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.3.10.1">Execute the new component in the available sample</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.4" /><label for="toc4.4"><a href="#section4.4">Model Migration</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.4.1">Technologies used</a></label></li>
+<li><label class="leaf"><a href="#section4.4.2">Framework for model migration</a></label></li>
+<li><input type="checkbox" id="toc4.4.3" /><label for="toc4.4.3"><a href="#section4.4.3">Components of Model Migration Framework</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.4.3.1">Model migration sequence</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section4.4.4">How to add custom Model Migration components</a></label></li>
+<li><input type="checkbox" id="toc4.4.5" /><label for="toc4.4.5"><a href="#section4.4.5">AMALTHEA meta model changes</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.4.5.1">Version ITEA 1.0.3 to ITEA 1.1.0</a></label></li>
+<li><label class="leaf"><a href="#section4.4.5.2">Version ITEA 1.1.0 to ITEA 1.1.1</a></label></li>
+<li><label class="leaf"><a href="#section4.4.5.3">Version ITEA 1.1.1 to App4MC 0.7.0</a></label></li>
+<li><label class="leaf"><a href="#section4.4.5.4">Version APP4MC 0.7.0 to App4MC 0.7.1</a></label></li>
+<li><label class="leaf"><a href="#section4.4.5.5">Version APP4MC 0.7.1 to APP4MC 0.7.2</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.5" /><label for="toc4.5"><a href="#section4.5">Partitioning</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.5.1">Usage of Partitioning</a></label></li>
+<li><input type="checkbox" id="toc4.5.2" /><label for="toc4.5.2"><a href="#section4.5.2">Prepartitioning</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.5.2.1">Activation Analysis</a></label></li>
+<li><label class="leaf"><a href="#section4.5.2.2">Label Analysis</a></label></li>
+<li><label class="leaf"><a href="#section4.5.2.3">Cycle Elimination</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.5.3" /><label for="toc4.5.3"><a href="#section4.5.3">Partitioning Algorithms</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.5.3.1">Independent Graph Partitioning (GGP)</a></label></li>
+<li><label class="leaf"><a href="#section4.5.3.2">Critical Path Partitioning (CPP)</a></label></li>
+<li><label class="leaf"><a href="#section4.5.3.3">Earliest Start Schedule Partitioning (ESSP)</a></label></li>
+<li><label class="leaf"><a href="#section4.5.3.4">Partitioning Exmaple</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.5.4" /><label for="toc4.5.4"><a href="#section4.5.4">Further Features</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.5.4.1">Applet Generation</a></label></li>
+<li><label class="leaf"><a href="#section4.5.4.2">Dependency Alternative</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section4.5.5">Workflow example</a></label></li>
+<li><label class="leaf"><a href="#section4.5.6">Plugin dependencies</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc4.6" /><label for="toc4.6"><a href="#section4.6">Model Details</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.6.1">Unique ID generation</a></label></li>
+<li><label class="leaf"><a href="#section4.6.2">Interfaces and base objects</a></label></li>
+<li><input type="checkbox" id="toc4.6.3" /><label for="toc4.6.3"><a href="#section4.6.3">Transient back pointers</a></label>
+<ul>
+<li><label class="leaf"><a href="#section4.6.3.1">Current back pointers</a></label></li>
+<li><label class="leaf"><a href="#section4.6.3.2">Implementation</a></label></li>
+<li><label class="leaf"><a href="#section4.6.3.3">User Interface</a></label></li>
+</ul>
+</li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section4.7">AMALTHEA Model XSD Schema</a></label></li>
+</ul>
+</li>
+<li><input type="checkbox" id="toc5" /><label for="toc5"><a href="#section5">Release Notes</a></label>
+<ul>
+<li><label class="leaf"><a href="#section5.1">Eclipse APP4MC 0.7.2 (Jan 2017)</a></label></li>
+<li><label class="leaf"><a href="#section5.2">Eclipse APP4MC 0.7.1 (Oct 2016)</a></label></li>
+<li><label class="leaf"><a href="#section5.3">Eclipse APP4MC 0.7.0 (Jul 2016)</a></label></li>
+<li><label class="leaf"><a href="#section5.4">AMALTHEA 1.1.1 (Oct 2015)</a></label></li>
+<li><label class="leaf"><a href="#section5.5">AMALTHEA 1.1.0 (Aug 2015)</a></label></li>
+</ul>
+</li>
+<li><label class="leaf"><a href="#section6">Roadmap</a></label></li>
+</ul>
+</div>
+<!-- - - - - - - - - Table of contents - - - - - - - - -->
+
+ </div>
+ </div>
+
+ <div id="maincontent">
+ <div class="innertube">
+
+<!-- - - - - - - - - - - Articles - - - - - - - - - - -->
+<article>
+<h1><a id="section1">1 </a>Introduction to APP4MC</h1>
+ <p>
+ <img src="images/app4mc-logo-g.png"/>
+ </p>
+ <p>The goal of the project is the development of a consistent, open, expandable tool platform for embedded software engineering. It is based on the model driven approach as basic engineering methodology. The main focus is the optimization of embedded multi-core systems.</p>
+ <p>Most functions in a modern car are controlled by embedded systems. Also more and more driver assistance functions are introduced. This implies a continuous increase of computing power accompanied by the request for reduction of energy and costs. To handle these requirements the multi-core technology permeates the control units in cars. This is today one of the biggest challenges for automotive systems. Existing applications can not realize immediate benefit from these multi-core ECUs because they are not designed to run on such architectures. In addition applications and systems have to be migrated into AUTOSAR compatible architectures. Both trends imply the necessity for new development environments which cater for these requirements.</p>
+ <p>The tool platform shall be capable to support all aspects of the development cycle. This addresses predominantly the automotive domain but is also applicable to telecommunication by extensions which deal with such systems in their native environment and integrated in a car.</p>
+ <p>Future extensions will add support for visualization tools, graphical editors. But not only design aspects will be supported but also verification and validation of the systems will be taken into account and support tools for optimal multi-core real-time scheduling and validation of timing requirements will be provided. In the course of this project not all of the above aspects will be addressed in the same depth. Some will be defined and some will be implemented on a prototype basis. But the basis platform and the overall architecture will be finalized as much as possible.</p>
+ <p>The result of the project is an open tool platform in different aspects. On the one hand it is published under the Eclipse Public License (EPL) and on the other hand it is open to be integrated with existing or new tools either on a company individual basis or with commercially available tools.</p>
+</article>
+
+
+<article>
+<h1><a id="section2">2 </a>User Guide</h1>
+
+
+<h2><a id="section2.1">2.1 </a>Introduction</h2>
+ <p>APP4MC comes with a predefined perspective available in the Eclipse menu under Window -> Open Perspective -> Other -> APP4MC. This perspective consists of the following elements:</p>
+ <ul>
+ <li>AMALTHEA Model Explorer</li>
+ <li>Editor
+ <ul>
+ <li>Tree Editor showing the structure of the model content</li>
+ <li>Standard Properties Tab is used to work on elements attributes</li>
+ </ul>
+ </li>
+ </ul>
+ <p>The following screenshot is showing this perspective and its contained elements.</p>
+ <p>
+ <img src="images/user_guide_editor_structure.png"/>
+ </p>
+
+
+<h3><a id="section2.1.1">2.1.1 </a>Steps to create a new AMALTHEA model</h3>
+ <p>APP4MC provides a standard wizard to create a new AMALTHEA model from scratch.</p>
+ <p>
+ <strong>Step 1: Create a new general project</strong>
+ </p>
+ <blockquote>
+ <p>The scope of an AMALTHEA model is defined by its enclosing container (project or folder).
+ <br> Therefore a project is required.
+ </p>
+ <p>
+ <img src="images/user_guide_step1_create-project.png"/>
+ </p>
+ </blockquote>
+ <p>
+ <strong>Step 2: Create a new folder inside of the created project</strong>
+ </p>
+ <blockquote>
+ <p>It is recommended to create a folder (
+ <i>although a project is also a possible container</i> ).
+ </p>
+ <p>
+ <img src="images/user_guide_step2_create-folder.png"/>
+ </p>
+ </blockquote>
+ <p>
+ <strong>Step 3: Create a new AMALTHEA model</strong>
+ </p>
+ <blockquote>
+ <p>In the context menu (right mouse button) an entry for a new AMALTHEA model can be found.</p>
+ <p>
+ <img src="images/user_guide_step3_create-model.png"/>
+ </p>
+ <p> Another starting point is
+ <i>File</i> ->
+ <i>New</i> ->
+ <i>Other</i>
+ </p>
+ <p> In the dialog you can select the parent folder and the file name.</p>
+ </blockquote>
+
+
+<h3><a id="section2.1.2">2.1.2 </a>AMALTHEA Editor</h3>
+ <p>The AMALTHEA Editor shows either the entire model that contains sub models or one of the sub models.
+ <br>The next screenshot shows the "New Child" menu with all its possibilities.
+ </p>
+ <p>
+ <img class="gray" src="images/user_editor_with_central_model.png"/>
+ </p>
+ <p>In addition the AMALTHEA Editor has two commands available at the top right of the Editor.</p>
+ <p>
+ <img class="gray" src="images/user_guide_editor_commands.png"/>
+ </p>
+
+
+<h4><a id="section2.1.2.1"></a>Show types of model elements</h4>
+ <p>The Show types of elements button triggers the editor to show the direct type of the element in the tree editor using [element_type]. The following screenshot shows the toggle and the types marked with an underline.</p>
+ <p>
+ <img class="gray" src="images/user_guide_editor_showtypes.png"/>
+ </p>
+
+
+<h4><a id="section2.1.2.2"></a>Search for model elements</h4>
+ <p>The editor provides the possibility to filter model elements by using the available name attribute. This can be used for example to filter all elements in the model which has abs in their name. The search and result view is using the Eclipse search as result view.</p>
+ <p>
+ <img class="gray" src="images/user_guide_editor_search_input.png"/>
+ </p>
+ <p>The search result is using the Eclipse Search View.</p>
+ <p>
+ <img class="gray" src="images/user_guide_editor_search_result1.png"/>
+ </p>
+ <p>An additional option is to toggle the search results to group them by type as shown in the next screenshot.</p>
+ <p>
+ <img class="gray" src="images/user_guide_editor_search_result2.png"/>
+ </p>
+
+
+<h3><a id="section2.1.3">2.1.3 </a>AMALTHEA Examples</h3>
+ <p>The AMALTHEA tool platform comes with several examples. This section will describe how a new project based on these examples can be created. </p>
+ <p>
+ <strong>Step 1</strong>
+ </p>
+ <blockquote>
+ <p>Click the "new" icon in the top left corner and select "Example...".</p>
+ <p>
+ <img src="images/01-create-new-example.png"/>
+ </p>
+ </blockquote>
+ <p>
+ <strong>Step 2</strong>
+ </p>
+ <blockquote>
+ <p>The "New Example" wizard will pop up and shows several examples.
+ <br> Select one examples and hit continue.
+ </p>
+ <p>
+ <img src="images/02-select-democar-example.png"/>
+ </p>
+ </blockquote>
+ <p>
+ <strong>Step 3</strong>
+ </p>
+ <blockquote>
+ <p>You will see a summary of the example projects that will be created.
+ <br> Click "Finish" to exit this dialog.
+ </p>
+ <p>
+ <img src="images/03_democar-example-finish.png"/>
+ </p>
+ <p> You can now open the editor to inspect the models.</p>
+ </blockquote>
+
+
+<h2><a id="section2.2">2.2 </a>Concepts</h2>
+
+
+<h3><a id="section2.2.1">2.2.1 </a>Hardware</h3>
+ <p>The AMALTHEA hardware model is used to describe hardware systems. The overall structure of this model is as followed:</p>
+ <ul>
+ <li>A
+ <strong>System</strong> contains one or more
+ <strong>ECUs</strong>
+ </li>
+ <li>An
+ <strong>ECU</strong> contains one or more
+ <strong>Microcontrollers</strong>
+ </li>
+ <li>A
+ <strong>Microcontroller</strong> contains one or more
+ <strong>Cores</strong>
+ </li>
+ <li>(Optional) Each of these abstractions can contain one or more memories, networks or peripheral elements. </li>
+ </ul>
+ <p>Usually, this is also considered the least amount of information which
+ <strong>must</strong> be present in the model.
+ </p>
+ <p>Since the hardware model is meant to be utilized for a wide range of use cases, additional information might be required w.r.t. the specific use case. Examples for its usage, as well as the resp. minimal amount of required information, are provided within the example section (
+ <strong>User Guide</strong> ->
+ <strong>Examples</strong> ->
+ <strong>Hwmodel Example</strong>).
+ </p>
+ <p>The information, which is required in determining a software-to-hardware-mapping with the AMALTHEA Mapping Plugin, is listed in Deliverable D3.4. Examples of hardware models for this use case will be generated during the mapping tutorials (See sections
+ <strong>User Guide</strong> ->
+ <strong>Tutorials</strong> ->
+ <strong>Mapping Example 1/2</strong>).
+ </p>
+
+
+<h3><a id="section2.2.2">2.2.2 </a>Software (development)</h3>
+ <p>The AMALTHEA System Model can also be used in early phases of the development process when only limited information about the resulting software is available.</p>
+
+
+<h4><a id="section2.2.2.1"></a>Runnables</h4>
+ <p>The
+ <i>Runnable</i> element is the basic software unit that defines the behavior of the software in terms of runtime and communication. It can be described on different levels of abstraction:
+ </p>
+ <ol>
+ <li>timing only (activation and runtime)</li>
+ <li>including communication (in general)</li>
+ <li>adding detailed call sequences</li>
+ </ol>
+ <p>To allow a more detailed simulation a description can also include statistical values like deviations or probabilities. This requires additional information that is typically derived from an already implemented function. The modeling of observed behavior is described in more detail in chapter
+ <a href="#user-sw-runtime" shape="rect">Software (runtime)</a>.
+ </p>
+
+
+<h4><a id="section2.2.2.2"></a>Process Prototypes</h4>
+ <p>Process Prototypes are used to define the basic data of a task. This is another possibility to describe that a set of Runnables has a similar characteristic (e.g. they have the same periodic activation).
+ <br>A prototype can then be processed and checked by different algorithms. Finally a partitioning algorithm generates (one or more) tasks that are the runtime equivalents of the prototype.
+ </p>
+ <p>
+ <img src="images/process_prototypes.png"/>
+ </p>
+ <p>This processing can be guided by specifications that are provided by the function developers:</p>
+ <ul>
+ <li>The
+ <strong>Order Specification</strong> is a predefined execution order that has to be guaranteed.
+ </li>
+ <li>An
+ <strong>Access Specification</strong> defines exceptions from the standard write-before-read semantics.
+ </li>
+ </ul>
+
+
+<h4><a id="section2.2.2.3"></a>Constraints</h4>
+ <p>In addition the partitioning and mapping can be restricted by
+ <i>Affinity Constraints</i> that enforce the pairing or separation of software elements and by
+ <i>Property Constraints</i> that connect hardware capabilities and the corresponding software requirements.
+ <br>The
+ <i>Timing Constraints</i> will typically be used to check if the resulting system fulfills all the requirements.
+ </p>
+
+
+<h4><a id="section2.2.2.4"></a>Activations</h4>
+ <p>Activations are used to specify the intended activation behavior of
+ <i>Runnables</i> and
+ <i>ProcessPrototypes</i>. Typically they are defined before the creation of tasks (and the runnable to task mappings). So this is a way to cluster runnables and to document when the runnables should be executed.
+ </p>
+ <p>
+ <img src="images/model__activations.png"/>
+ </p>
+ <p>The following three activation patterns can be distinguished:</p>
+ <ul>
+ <li>Single: single activation</li>
+ <li>Periodic: periodic activation with a specific frequency</li>
+ <li>Sporadic: recurring activation without following a specific pattern </li>
+ </ul>
+ <p>To describe a specific (observed) behavior at runtime there are
+ <i>Stimuli</i> in the AMALTHEA model. They can be created based on the information of the specified activations.
+ </p>
+
+
+<h3 id="user-sw-runtime"><a id="section2.2.3">2.2.3 </a>Software (runtime)</h3>
+ <p>During runtime, the dynamic behavior of the software can be observed. The following Gantt chart shows an excerpt of such a dynamic behavior.</p>
+ <p>
+ <img src="images/user_sw_runtime_gantt.png" style="width: 1000px"/>
+ </p>
+ <p>To model the observed behavior in the AMALTHEA model there are schedulable units (Processes) that contain the basic software units (Runnables) and stimuli that describe when the processes are executed. Statistical elements like distributions (Gauss, Weibull, ...) are also available in the model. They allow describing the variation of values if there are multiple occurrences. </p>
+ <p>In the following sections, a high level description of the individual elements of a software description that define the dynamic behavior are presented.</p>
+
+
+<h4><a id="section2.2.3.1"></a>Processes (Tasks or ISRs)</h4>
+ <p>
+ <img src="images/user_sw_runtime_gantt_task.png" style="width: 1000px"/>
+ </p>
+ <p>Processes represent executable units that are managed by an operating system scheduler. A process is thus the smallest schedulable unit managed by the operating system. Each process also has its own name space and resources (including memory) protected against use from other processes. In general, two different kinds of processes can be distinguished: task and Interrupt Service Routine (ISR). Latter is a software routine called in case of an interrupt. ISRs have normally higher priority than tasks and can only be suspended by another ISR which presents a higher priority than the one running. In the Gantt chart above, a task called 'TASK_InputProcessing' can be seen. All elements that run within the context of a process are described in the following sections.</p>
+
+
+<h5><a id="section2.2.3.1.1"></a>Runnables</h5>
+ <p>
+ <img src="images/user_sw_runtime_gantt_runnable.png" style="width: 1000px"/>
+ </p>
+ <p>Runnables are basic software units. In general it can be said, that a Runnable is comparable to a function. It runs within the context of a process and is described by a sequence of instructions. Those instructions can again represent different actions that define the dynamic behavior of the software. Following, such possible actions are listed:</p>
+ <ul>
+ <li>Semaphore Access: request/release of a semaphore</li>
+ <li>Label Access: reading/writing a data signal</li>
+ <li>Instructions: number of unspecified instructions to be executed</li>
+ <li>...</li>
+ </ul>
+ <p>
+ <img src="images/user_sw_new_runnable_iitem.png"/>
+ </p>
+ <p>In the following sections elements, that can be of concern within a runnable, are described in more detail.</p>
+
+
+<h5><a id="section2.2.3.1.2"></a>Labels</h5>
+ <p>
+ <img src="images/user_sw_runtime_gantt_signal.png" style="width: 1000px"/>
+ </p>
+ <p>Labels represent the system's view of data exchange. As a consequence, labels are used to represent communication in a flattened structure, with (at least) one label defined for each data element sent or received by a Runnable instance.</p>
+
+
+<h5><a id="section2.2.3.1.3"></a>Semaphore</h5>
+ <p>
+ <img src="images/user_sw_runtime_gantt_semaphore.png" style="width: 1000px"/>
+ </p>
+ <p>The main functionality of a semaphore is to control simultaneous use of a single resource by several entities, e.g. scheduling of requests, multiple access protection.</p>
+
+
+<h4><a id="section2.2.3.2"></a>Stimulation</h4>
+ <p>Before, we described the dynamic behavior of a specific process instance. In general however, a process is not only activated once but many times. The action of activating a process is called stimulation. The following three stimulation patterns can thereby be distinguished:</p>
+ <ul>
+ <li>Single: single activation of a process</li>
+ <li>Periodic: periodic activation of a process with a specific frequency</li>
+ <li>Sporadic: recurring activation of a process without following a specific pattern </li>
+ </ul>
+ <p>
+ <img src="images/model__stimuli.png"/>
+ </p>
+
+
+<h3><a id="section2.2.4">2.2.4 </a>General Concepts</h3>
+
+
+<h4><a id="section2.2.4.1"></a>Grouping of elements (Tags, Tag groups)</h4>
+ <p>It is possible to use
+ <a href="#common-tags" shape="rect">Tags</a> for grouping elements of the model. Currently the following AMALTHEA sub models are supporting Tags:
+ </p>
+ <ol>
+ <li>Components</li>
+ <li>Software (SW)</li>
+ <li>Hardware (HW)</li>
+ </ol>
+ <p>The corresponding model classes are storing the relevant Tags in a local list, available in: </p>
+ <ul>
+ <li>
+ <code>org.eclipse.app4mc.amalthea.model.ComponentsModel</code>
+ </li>
+ <li>
+ <code>org.eclipse.app4mc.amalthea.model.SWModel</code>
+ </li>
+ <li>
+ <code>org.eclipse.app4mc.amalthea.model.HWModel</code>
+ </li>
+ </ul>
+ <p>The reason for doing this is that Tags used in the sub models mostly have a different technical background. It should be avoided that e.g. elements in the software model are referring to Tags from a components model.</p>
+
+
+<h4><a id="section2.2.4.2"></a>Custom Properties</h4>
+ <p>The AMALTHEA model provides
+ <a href="#common-custom-props" shape="rect">Custom Properties</a> to enhance the model in a generic way. These can be used for different kind of purpose:
+ </p>
+ <ul>
+ <li>Store attributes, which are relevant for your model, but not yet available at the elements</li>
+ <li>Processing information of algorithms can be stored in that way, e.g. to mark an element as already processed</li>
+ </ul>
+
+
+<h3><a id="section2.2.5">2.2.5 </a>Communication via channels</h3>
+
+
+<h4><a id="section2.2.5.1"></a>Channel</h4>
+ <p>Sender and receiver communicating via a channel by issuing send and receive operations on ports; read policy and transmission policy define communciation details.</p>
+ <p>
+ <img src="images/user_channel.png"/>
+ </p>
+ <p>As basic thinking model, reading and writing to channels happens during runnable execution in distinct phases:</p>
+ <ul>
+ <li>Receiving phase: The specified receive operations are performed for every read port.</li>
+ <li>Computing phase: A specified time passes, modeling processing of input data.</li>
+ <li>Sending phase: The specified send operations are performed for every write port. </li>
+ </ul>
+ <p>A channel is specified by two attributes:</p>
+ <ul>
+ <li>
+ <strong>elementType</strong>: the type that is sent or received via connected ports.
+ </li>
+ <li>
+ <strong>defaultElements</strong>: number of elements initially in the channel (at start-up).
+ </li>
+ <li>
+ <strong>maxElements</strong> (integer) denoting a buffer limit, that is, the channel depth.
+ </li>
+ </ul>
+ <p>In other words, no more than maxElements elements of the given type may be stored in the channel.</p>
+
+
+<h4><a id="section2.2.5.2"></a>Channel Access</h4>
+ <p>In the basic thinking model, all elements are stored as a sequential collection without buffer size limit (unlimited storage).</p>
+ <p>
+ <img src="images/user_channel_access.png"/>
+ </p>
+
+
+<h5><a id="section2.2.5.2.1"></a>Sending</h5>
+ <p>A runnable may send elements to a channel by issuing a send operations.
+ <br>The send operation has a single parameter:
+ </p>
+ <ul>
+ <li>elements (integer): Number of elements that are written.</li>
+ </ul>
+
+
+<h5><a id="section2.2.5.2.2"></a>Receiving</h5>
+ <p>A runnable may receive elements from a channel by issuing receive operations.
+ <br>The operation has multiple aspects:
+ </p>
+ <ul>
+ <li>
+ <strong>Port Type</strong>
+ <ul>
+ <li>A
+ <strong>LIFO</strong> (last-in, first-out) port is chosen if processing the last written elements is the primary focus and thereby missing elements is tolerable.
+ </li>
+ <li>A
+ <strong>FIFO</strong> (first-in, first-out) port is chosen if every written element needs to be handled, that is, loss of elements is not tolerable.
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <blockquote>
+ <p>The port type defines the direction the receive operations take effect: accesses from LIFO ports are from top of the sequential collection, while accesses from FIFO ports are from bottom of the sequential collection.</p>
+ </blockquote>
+ <ul>
+ <li>
+ <strong>Receive Operation</strong>
+ <ul>
+ <li>
+ <strong>Read</strong> will received elements without modifying the channel
+ </li>
+ <li>
+ <strong>Take</strong> will remove the received elements from the channel
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>Each operation has two parameters and several attributes specifying the exact behavior:</p>
+ <ul>
+ <li>
+ <strong>elements</strong> (integer): Maximum number n of elements that are received.
+ </li>
+ <li>
+ <strong>elementIndex</strong> (integer): Position (index i) in channel at which the operation is effective. Zero is the default and denotes the oldest (FIFO port) or newest element (LIFO port) in the channel.
+ </li>
+ </ul>
+ <p>Receive operations then are written in function notation, that is Read(n, i) and Take(n, i). For convenience, the index may be left out for default value '0' (Take(n,0) == Take(n)). See next figure for examples which elements are denoted by receive operations for FIFO and LIFO ports.</p>
+ <p>
+ <img src="images/user_channel_operations.png"/>
+ </p>
+ <p>Additional attributes further define the receive operation:</p>
+ <ul>
+ <li>
+ <strong>lowerBound</strong> (integer): Specify the minimum number of elements returned by the operation. The value must be in the range [0,n], with n is the maximum number of elements that are received as specified as attribute of the receive operation. Default value is n.
+ </li>
+ <li>
+ <strong>dataMustBeNew</strong> (Boolean): Specify if the operation must only return elements that are not previously read by this port. Default value is false.
+ </li>
+ </ul>
+
+
+<h5><a id="section2.2.5.2.3"></a>Common Read Policies: Last, New, and AllNew</h5>
+ <p>As three specific read policies are frequently used, these are introduced in the following.</p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Policy</th>
+ <th colspan="1" rowspan="1">Port Type</th>
+ <th colspan="1" rowspan="1">Operation</th>
+ <th colspan="1" rowspan="1">lower bound</th>
+ <th colspan="1" rowspan="1">must be new</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Last(x)</strong>
+ </td>
+ <td colspan="1" rowspan="1">LIFO</td>
+ <td colspan="1" rowspan="1"> Read(x,0)</td>
+ <td colspan="1" rowspan="1">x</td>
+ <td colspan="1" rowspan="1">false</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>New(x)</strong>
+ </td>
+ <td colspan="1" rowspan="1">LIFO</td>
+ <td colspan="1" rowspan="1">Read(x,0)</td>
+ <td colspan="1" rowspan="1">0</td>
+ <td colspan="1" rowspan="1">true</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>AllNew</strong>
+ </td>
+ <td colspan="1" rowspan="1">FIFO</td>
+ <td colspan="1" rowspan="1">Take(sizeOfChannel,0)</td>
+ <td colspan="1" rowspan="1">0</td>
+ <td colspan="1" rowspan="1">true</td>
+ </tr>
+ </table>
+ <p>An example of the different behavior of the New and Last policy is shown in the next figure. For demonstration purpose, in the example periodic triggering of the receiving runnables R1 and R2 and sporadic data writing by runnable S is assumed. Note that while New may be used on an empty channel, Last would lead to an error (dashed boxes).
+ <br>Left: Static connection between three runnables (S, R1, and R2). Right: Dynamic view of writing elements to channel over time (green arrows), runnable execution indicated as blue boxes, and the resulting received elements shown in square brackets.
+ </p>
+ <p>
+ <img src="images/user_channel_example.png"/>
+ </p>
+
+
+<h4><a id="section2.2.5.3"></a>Transmission Policy</h4>
+ <p>To further specify how elements are accessed by a runnable in terms of computing time, an optional transmission policy may specify details for each receive and send operation. The intention of the transmission policy is to reflect computing demand (time) depending on data.</p>
+ <p>the transmission policy consists of two attributes:</p>
+ <ul>
+ <li>
+ <strong>chunkSize</strong>: Size of a part of an element, maximum is the element size.
+ </li>
+ <li>
+ <strong>chunkProcessingInstructions</strong> (integer): Number of instructions that will be executed to send / receive one chunk.
+ </li>
+ <li>
+ <strong>transmitRatio</strong> (float): Specify the ratio of each element that is actually transmitted by the runnable in percent. Value must be between [0, 1], default value is 1.0.
+ </li>
+ </ul>
+ <p>Example for using transmission policy to detail the receiving phase of a runnable execution. Two elements are received, leading to transmission time as given in the formula. After the receiving phase, the runnable starts with the computing phase.</p>
+ <p>
+ <img src="images/user_channel_transmission_example.png"/>
+ </p>
+
+
+<h3><a id="section2.2.6">2.2.6 </a>Memory Sections</h3>
+ <p>
+ <b>Purpose</b>
+ </p>
+ <p>Memory Sections are used for the division of the memory (RAM/ROM) into different blocks and allocate the "software" memory elements (
+ <em>e.g. Labels</em>), code accordingly inside them.
+ <br>Each Memory Section has certain specific properties (
+ <em>e.g. faster access of the elements, storing constant values</em>). By default compiler vendors provide certain Memory Sections (
+ <em>e.g. .data, .text</em>) and additional Memory Sections can be created based on the project need by enhancing the linker configuration.
+ </p>
+ <p>
+ <b>Definition</b>
+ </p>
+ <p>A "Memory Section" is a region in memory (RAM/ROM) and is addressed with a specific name. There can exist multiple "Memory Sections" inside the same Memory (RAM/ROM) but with different names. Memory Section names should be unique across the Memory (RAM/ROM).</p>
+ <p>Memory Sections can be of two types: </p>
+ <ul>
+ <li>Virtual Memory Section</li>
+ <li>Physical Memory Section</li>
+ </ul>
+
+
+<h4><a id="section2.2.6.1"></a>Virtual Memory Section</h4>
+ <p>"Virtual Memory Sections" are defined as a part of data specification and are associated to the corresponding Memory Elements (e.g. Label's) during the development phase of the software. Intention behind associating "Virtual Memory Sections" to Memory elements like Label's is to control their allocation in specific Memory (e.g. Ram1 or Ram2) by linker. </p>
+ <p>As a part of linker configuration – It is possible to specify if a "Virtual Memory Section"
+ <i>(e.g. mem.Sec1)</i> can be part of certain Memory
+ <em>(e.g. Ram1/Ram2/SYSRAM but not Ram3)</em>.
+ </p>
+ <p>
+ <ins>
+ <em>Example:</em>
+ </ins>
+ </p>
+ <p>Software should be built for ManyCore ECU – containing 3 Cores
+ <em>(Core1, Core2, Core3)</em>. Following RAMs are associated to the Cores: Ram1 – Core1, Ram2 – Core2, Ram3 – Core3, and also there is SYSRAM.
+ </p>
+ <p>Virtual Memory Section : mem.sec1
+ <em>(is defined as part of data specification)</em> is associated to Label1 and Label2.
+ </p>
+ <p>
+ <img class="scale" src="images/user_section_label_ref_to_memsection.png"/>
+ </p>
+ <p>In Linker configuration it is specified that mem.sec1 can be allocated only in Ram1 or Ram2.</p>
+ <p>Below diagram represents the
+ <em>
+ <ins>
+ <strong>linker configuration content</strong>
+ </ins>
+ </em> - w.r.t. possibility for physical allocation of mem.sec1 in various memories.
+ </p>
+ <p>
+ <img class="scale" src="images/user_section_linker_memsection.png"/>
+ </p>
+ <p>Based on the above configuration – Linker will allocate Label1, Label2 either in Ram1/Ram2/SYSRAM but not in Ram3/Ram4.</p>
+
+
+<h4><a id="section2.2.6.2"></a>Physical Memory Section</h4>
+ <p>"Physical Memory Sections" are generated by linker. The linker allocates various memory elements (e.g. Label's) inside "Physical Memory Sections".</p>
+ <p>Each "Physical Memory Section" has following properties:</p>
+ <ul>
+ <li>Name – It will be unique across each Memory </li>
+ <li>Start and End address – This represents the size of "Physical Memory Section"</li>
+ <li>Associated Physical Memory
+ <em>(e.g. Ram1 or Ram2)</em>
+ </li>
+ </ul>
+ <p>
+ <ins>
+ <em>Example:</em>
+ </ins> There can exist mem.sec1.py inside Ram1 and also in Ram2. But these are physically two different elements as they are associated to different memories (Ram1 and Ram2) and also they have different "start and end address".
+ </p>
+ <p>Below diagram represents the information w.r.t. virtual memory sections
+ <em class="defined in data specification and associated to memory elements">_ and physical memory sections _(generated after linker run)</em>.
+ </p>
+ <p>
+ <img class="scale" src="images/user_section_virtual_to_physical.png"/>
+ </p>
+
+
+<h4><a id="section2.2.6.3"></a>Modeling Memory Section information in AMALTHEA</h4>
+ <ul>
+ <li>As described in the above concept section:
+ <ul>
+ <li>Virtual memory sections are used:
+ <ul>
+ <li>To specify constraints for creation of Physical memory sections by linker</li>
+ <li>To control allocation of data elements (e.g. Labels) in a specific memory
+ <em>(e.g. Ram1/Ram2/SYSRAM)</em>
+ </li>
+ </ul>
+ </li>
+ <li>Physical memory sections are containing the data elements after linker run
+ <em>(representing the software to be flashed into ECU)</em>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <p>Below figure represents the modeling of "Memory Section" (both virtual and physical) information in AMALTHEA model:
+ <br>
+ <img class="scale" src="images/user_section_amalthea.png"/>
+ </p>
+ <p>Below are equivalent elements of AMALTHEA model used for modeling the Memory Section information:</p>
+ <ul>
+ <li>
+ <strong>Section</strong>
+ <ul>
+ <li>This element is equivalent to Virtual Memory Section defined during the SW development phase.</li>
+ <li>As a part of data specification defined in the sw-development phase, a Section object
+ <em>(with specific name)</em> is associated to Label and Runnable elements.
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <ul>
+ <li>
+ <strong>PhysicalSectionConstraint</strong>
+ <ul>
+ <li>This element is equivalent to the constraint specified in the linker configuration file, which is used to instruct linker for the allocation of Physical Memory Sections in specified Memories.</li>
+ <li>PhysicalSectionContraint is used to specify the combination of Virtual Memory Section and Memories
+ <em>(which can be considered by linker for generation of Physical Memory Sections)</em>.
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <blockquote>
+ <p>
+ <em>
+ <ins>Example:</ins>
+ </em> PhysicalSectionConstraint-1 is specifying following relation "Section-1" <--> "Memory-1", "Memory-2". This means that the corresponding Physical Memory Section for "Section-1" can be generated by linker in "Memory-1" or in "Memory-2" or in both.
+ </p>
+ </blockquote>
+ <ul>
+ <li>
+ <strong>PhysicalSectionMapping</strong>
+ <ul>
+ <li>This element is equivalent to Physical Memory Section generated during the linker run.
+ <ul>
+ <li>Each PhysicalSectionMapping element:
+ <ul>
+ <li>Contains the Virtual Memory Section
+ <em>(e.g. Section-1)</em> which is the source.
+ </li>
+ <li>is associated to a specific Memory and it contains the start and end memory address
+ <em>(difference of start and end address represents the size of Physical Memory Section)</em>.
+ </li>
+ <li>contains the data elements
+ <em>(i.e. Labels, Runnables part of the final software)</em>.
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ <blockquote>
+ <p>
+ <strong>Note:</strong> There is also a possibility to associate multiple Virtual Memory Section's as linker has a concept of grouping Virtual Memory Sections while generation of Physical Memory Section.
+ </p>
+ </blockquote>
+ <blockquote>
+ <p>
+ <em>
+ <ins>Example:</ins>
+ </em> For the same Virtual Memory Section
+ <i>(e.g. Section-1)</i>, linker can generate multiple Physical Memory Sections in different Memories
+ <em>(e.g. PhysicalSectionMapping-1, PhysicalSectionMapping-2)</em>. Each PhysicalSectionMapping element is an individual entity as it has a separate start and end memory address.
+ </p>
+ </blockquote>
+
+
+<h2><a id="section2.3">2.3 </a>Examples</h2>
+
+
+<h3><a id="section2.3.1">2.3.1 </a>Modeling Example 1</h3>
+
+
+<h4><a id="section2.3.1.1"></a>General information</h4>
+ <p>Modeling Example 1 describes a simple system consisting of 4 Tasks, which is running on a dual core processor.
+ <br>The following figure shows the execution footprint in a Gantt chart:
+ <br>
+ <img src="images/modeling_1_gantt.png"/>
+ <br>In the following sections, the individual parts of the AMALTHEA model for Modeling Example 1 are presented followed by a short description of its elements.
+ </p>
+
+
+<h4><a id="section2.3.1.2"></a>Hardware Model</h4>
+ <p>
+ <img src="images/modeling_1_hw.png"/>
+ </p>
+ <p>The hardware model of Modeling Example 1 consists as already mentioned of a dual core processor.
+ <br>The following gives a structural overview on the modeled elements.
+ <br>There, the two cores, 'Core_1' and 'Core_2', have a static processing frequency of 100 MHz each, which is specified by the corresponding quartz oscillator 'Quartz'.
+ </p>
+
+
+<h4><a id="section2.3.1.3"></a>Operating System Model</h4>
+ <p>
+ <img src="images/modeling_1_schedulers.png"/>
+ </p>
+ <p>The operating system (OS) model defines in case of Modeling Example 1 only the needed Scheduler.
+ <br>Since a dual core processor has to be managed, two schedulers are modeled correspondingly.
+ <br>In addition to the scheduling algorithm used by the scheduler, in this case OSEK, a delay of 100 ns is set, which is the presumed time the scheduler needs for context switches.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Scheduler</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Algorithm</th>
+ <th colspan="1" rowspan="1">Delay</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Scheduler_1</strong>
+ </td>
+ <td colspan="1" rowspan="1">SchedulingHWUnit</td>
+ <td colspan="1" rowspan="1">OSEK</td>
+ <td colspan="1" rowspan="1">100 ns</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Scheduler_2</strong>
+ </td>
+ <td colspan="1" rowspan="1">SchedulingHWUnit</td>
+ <td colspan="1" rowspan="1">OSEK</td>
+ <td colspan="1" rowspan="1">100 ns</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section2.3.1.4"></a>Mapping Model</h4>
+ <p>
+ <img src="images/modeling_1_mapping.png"/>
+ </p>
+ <p>The mapping model defines allocations between different model parts.
+ <br>On the one hand, this is the allocation of processes to a scheduler.
+ <br>In case of Example 1, 'Task_1' and 'Task_2' are managed by 'Scheduler_1', while the other tasks are managed by 'Scheduler_2'.
+ <br>On the other hand the allocation of cores to a scheduler is set.
+ <br>For Modeling Example 1 two local schedulers were modeled.
+ <br>As a consequence, each scheduler manages one of the processing cores.
+ <br>A comprehension of the modeled properties can be found in the following tables:
+ </p>
+
+
+<h5><a id="section2.3.1.4.1"></a>Executable Allocation</h5>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Scheduler</th>
+ <th colspan="1" rowspan="1">Process</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Task_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Task_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_2</td>
+ <td colspan="1" rowspan="1">Task_3</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_2</td>
+ <td colspan="1" rowspan="1">Task_4</td>
+ </tr>
+ </table>
+
+
+<h5><a id="section2.3.1.4.2"></a>Core Allocation</h5>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Scheduler</th>
+ <th colspan="1" rowspan="1">Core</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Core_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_2</td>
+ <td colspan="1" rowspan="1">Core_2</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section2.3.1.5"></a>Software Model</h4>
+
+
+<h5><a id="section2.3.1.5.1"></a>Tasks</h5>
+ <p>
+ <img src="images/modeling_1_tasks.png"/>
+ </p>
+ <p>As already mentioned above, the software model of Modeling Example 1 consists exactly of four tasks, named 'Task_1' to 'Task_4'.
+ <br>Each task is preemptive and has a priority assigned according its deadline, meaning the one with the shortest deadline, 'Task_1', has the highest priority, and so on.
+ <br>Each task also calls a definitive number of Runnables in a sequential order.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">MTA*</th>
+ <th colspan="1" rowspan="1">Deadline</th>
+ <th colspan="1" rowspan="1">Calls</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Task_1</strong>
+ </td>
+ <td colspan="1" rowspan="1">4</td>
+ <td colspan="1" rowspan="1">Preemptive</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">75 ms</td>
+ <td colspan="1" rowspan="1">1) Runnable_1_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="2">
+ <strong>Task_2</strong>
+ </td>
+ <td colspan="1" rowspan="2">3</td>
+ <td colspan="1" rowspan="2">Preemptive</td>
+ <td colspan="1" rowspan="2">1</td>
+ <td colspan="1" rowspan="2">115 ms</td>
+ <td colspan="1" rowspan="1">1) Runnable_2_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">2) Runnable_2_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">
+ <strong>Task_3</strong>
+ </td>
+ <td colspan="1" rowspan="3">2</td>
+ <td colspan="1" rowspan="3">Preemptive</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="3">300 ms</td>
+ <td colspan="1" rowspan="1">1) Runnable_3_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">2) Runnable_3_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">3) Runnable_3_3</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="4">
+ <strong>Task_4</strong>
+ </td>
+ <td colspan="1" rowspan="4">1</td>
+ <td colspan="1" rowspan="4">Preemptive</td>
+ <td colspan="1" rowspan="4">1</td>
+ <td colspan="1" rowspan="4">960 ms</td>
+ <td colspan="1" rowspan="1">1) Runnable_4_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">2) Runnable_4_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">3) Runnable_4_3</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">4) Runnable_4_4</td>
+ </tr>
+ </table>
+ <p>*MTA = Multiple Task Activation Limit</p>
+
+
+<h5><a id="section2.3.1.5.2"></a>Runnables</h5>
+ <p>
+ <img src="images/modeling_1_runnables.png"/>
+ </p>
+ <p>In addition to the task, the software model also contains a definition of Runnables.
+ <br>For Modeling Example 1, ten individual Runnables are defined.
+ <br>The only function of those in this example is to consume processing resources.
+ <br>Therefore, for each Runnable a constant number of instruction cycles is stated.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Runnable</th>
+ <th colspan="1" rowspan="1">InstructionCycles</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_1_1</td>
+ <td colspan="1" rowspan="1">1500000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_2_1</td>
+ <td colspan="1" rowspan="1">1500000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_2_2</td>
+ <td colspan="1" rowspan="1">1500000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_3_1</td>
+ <td colspan="1" rowspan="1">1000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_3_2</td>
+ <td colspan="1" rowspan="1">2000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_3_3</td>
+ <td colspan="1" rowspan="1">1000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_4_1</td>
+ <td colspan="1" rowspan="1">1000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_4_2</td>
+ <td colspan="1" rowspan="1">2000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_4_3</td>
+ <td colspan="1" rowspan="1">3000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable_4_4</td>
+ <td colspan="1" rowspan="1">2000000</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section2.3.1.6"></a>Stimuli Model</h4>
+ <p>
+ <img src="images/modeling_1_stimuli.png"/>
+ </p>
+ <p>The stimulation model defines the activations of tasks.
+ <br>Since the four tasks of Modeling Example 1 are activated periodically, four stimuli according their recurrence are modeled.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Stimulus</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Offset</th>
+ <th colspan="1" rowspan="1">Recurrence</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Stimulus_Task_1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1">0 ms</td>
+ <td colspan="1" rowspan="1">180 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Stimulus_Task_2</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1">0 ms</td>
+ <td colspan="1" rowspan="1">200 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Stimulus_Task_3</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1">0 ms</td>
+ <td colspan="1" rowspan="1">300 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Stimulus_Task_4</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1">0 ms</td>
+ <td colspan="1" rowspan="1">1 s</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section2.3.2">2.3.2 </a>Modeling Example 2</h3>
+
+
+<h4><a id="section2.3.2.1"></a>General information</h4>
+ <p>Modeling Example 2 describes a simple system consisting of 4 Tasks, which is running on a single core processor.
+ <br>The following figure shows the execution footprint in a Gantt chart:
+ <br>
+ <img src="images/modeling_2_gantt.png"/>
+ <br>In the following sections, the individual parts of the AMALTHEA model for Modeling Example 2 are presented followed by a short description of its elements.
+ </p>
+
+
+<h4><a id="section2.3.2.2"></a>Hardware Model</h4>
+ <p>
+ <img src="images/modeling_2_hw.png"/>
+ </p>
+ <p>The hardware model of Modeling Example 2 consists as already mentioned of a single core processor.
+ <br>The following gives a structural overview on the modeled elements.
+ <br>There, the core, 'Core_1' , has a static processing frequency of 600 MHz each, which is specified by the corresponding quartz oscillator 'Quartz_1'.
+ </p>
+
+
+<h4><a id="section2.3.2.3"></a>Operating System Model</h4>
+ <p>
+ <img src="images/modeling_2_scheduler.png"/>
+ </p>
+ <p>The operating system (OS) model defines in case of Modeling Example 2 only the needed Scheduler.
+ <br>Since only a single core has to be managed, a single scheduler is modeled correspondingly.
+ <br>In addition to the scheduling algorithm used by the scheduler, in this case OSEK, a delay of 100 ns is set, which is the presumed time the scheduler needs for context switches.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Scheduler</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Algorithm</th>
+ <th colspan="1" rowspan="1">Delay</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Scheduler_1</strong>
+ </td>
+ <td colspan="1" rowspan="1">SchedulingHwUnit</td>
+ <td colspan="1" rowspan="1">OSEK</td>
+ <td colspan="1" rowspan="1">100 ns</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section2.3.2.4"></a>Mapping Model</h4>
+ <p>
+ <img src="images/modeling_2_mapping.png"/>
+ </p>
+ <p>The mapping model defines allocations between different model parts.
+ <br>On the one hand, this is the allocation of processes to a scheduler.
+ <br>Since there is only one scheduler available in the system, all four tasks are mapped to 'Scheduler_1'.
+ <br>On the other hand the allocation of cores to a scheduler is set.
+ <br>As a consequence, the scheduler manages the only available processing core.
+ <br>A comprehension of the modeled properties can be found in the following tables:
+ </p>
+
+
+<h5><a id="section2.3.2.4.1"></a>Executable Allocation</h5>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Scheduler</th>
+ <th colspan="1" rowspan="1">Process</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Task_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Task_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Task_3</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Task_4</td>
+ </tr>
+ </table>
+
+
+<h5><a id="section2.3.2.4.2"></a>Core Allocation</h5>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Scheduler</th>
+ <th colspan="1" rowspan="1">Core</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Scheduler_1</td>
+ <td colspan="1" rowspan="1">Core_1</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section2.3.2.5"></a>Software Model</h4>
+
+
+<h5><a id="section2.3.2.5.1"></a>Tasks</h5>
+ <p>
+ <img src="images/modeling_2_tasks.png"/>
+ </p>
+ <p>As already mentioned above, the software model of Modeling Example 2 consists exactly of four tasks, named 'Task_1' to 'Task_4'.
+ <br>All tasks have assigned the same priority (10) to get a cooperative scheduling.
+ <br>'Task_2' to'Task_4' call a definitive number of Runnables in a sequential order.
+ <br>'Task_1' instead contains a call graph that models two different possible execution sequences.
+ <br>In 70% of the cases the sequence 'Runnable_1_1', 'Runnable_1_2', 'Task_2', 'Runnable_1_4' is called, while in the remaining 30% the sequence 'Runnable_1_1', 'Runnable_1_3', 'Task_3', 'Runnable_1_4' is called.
+ <br>As it can be seen, the call graph of 'Task_1' contains also interprocess activations, which activate other tasks.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">MTA*</th>
+ <th colspan="1" rowspan="1">Deadline</th>
+ <th colspan="1" rowspan="1">Calls</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="8">
+ <strong>Task_1</strong>
+ </td>
+ <td colspan="1" rowspan="8">10</td>
+ <td colspan="1" rowspan="8">Preemptive</td>
+ <td colspan="1" rowspan="8">3</td>
+ <td colspan="1" rowspan="8">25 ms</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">1.1) Runnable_1_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">1.2) Runnable_1_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">1.3) Task_2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">1.4) Runnable_1_4</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">2.1) Runnable_1_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">2.2) Runnable_1_3</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">2.3) Task_3</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">2.4) Runnable_1_4</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Task_2</strong>
+ </td>
+ <td colspan="1" rowspan="1">10</td>
+ <td colspan="1" rowspan="1">Preemptive</td>
+ <td colspan="1" rowspan="1">3</td>
+ <td colspan="1" rowspan="1">25 ms</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">1) Runnable_2_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Task_3</strong>
+ </td>
+ <td colspan="1" rowspan="1">10</td>
+ <td colspan="1" rowspan="1">Preemptive</td>
+ <td colspan="1" rowspan="1">3</td>
+ <td colspan="1" rowspan="1">25 ms</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">1) Runnable_3_1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Task_4</strong>
+ </td>
+ <td colspan="1" rowspan="1">10</td>
+ <td colspan="1" rowspan="1">Preemptive</td>
+ <td colspan="1" rowspan="1">3</td>
+ <td colspan="1" rowspan="1">25 ms</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">1) Runnable_4_1</td>
+ </tr>
+ </table>
+ <p>*MTA = Multiple Task Activation Limit</p>
+
+
+<h5><a id="section2.3.2.5.2"></a>Runnables</h5>
+ <p>
+ <img src="images/modeling_2_runnables.png"/>
+ </p>
+ <p>In addition to the task, the software model also contains a definition of Runnables.
+ <br>For Modeling Example 2, seven individual Runnables are defined.
+ <br>The only function of those in this example is to consume processing resources.
+ <br>Therefore, for each Runnable a number of instruction cycles is stated.
+ <br>The number of instruction cycles is thereby either constant or defined by a statistical distribution.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Runnable</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Instructions</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Runnable_1_1</strong>
+ </td>
+ <td colspan="1" rowspan="1">Constant</td>
+ <td colspan="1" rowspan="1">1000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Runnable_1_2</strong>
+ </td>
+ <td colspan="1" rowspan="1">Constant</td>
+ <td colspan="1" rowspan="1">2000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Runnable_1_3</strong>
+ </td>
+ <td colspan="1" rowspan="1">Constant</td>
+ <td colspan="1" rowspan="1">3000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Runnable_1_4</strong>
+ </td>
+ <td colspan="1" rowspan="1">Constant</td>
+ <td colspan="1" rowspan="1">4000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="2">
+ <strong>Runnable_2_1</strong>
+ </td>
+ <td colspan="1" rowspan="2">Uniform Distribution</td>
+ <td colspan="1" rowspan="1">1000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">5000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">
+ <strong>Runnable_3_1</strong>
+ </td>
+ <td colspan="1" rowspan="3">Gauss Distribution</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">mean: 1000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">sd: 50000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">upper: 5000000</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Runnable_4_1</strong>
+ </td>
+ <td colspan="1" rowspan="1">Constant</td>
+ <td colspan="1" rowspan="1">4000000</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section2.3.2.6"></a>Stimulation Model</h4>
+ <p>
+ <img src="images/modeling_2_stimuli.png"/>
+ </p>
+ <p>The stimulation model defines the activations of tasks.
+ <br>'Task_1' is activated periodically by 'Stimulus_Task_1'
+ <br>'Stimulus_Task_2' and 'Stimulus_Task_3' represent the inter-process activations for the corresponding tasks.
+ <br>'Task_4' finally is activated sporadically following a Gauss distribution.
+ <br>A comprehension of the modeled properties can be found in the following table:
+ </p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Stimulus</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Parameters</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="2">
+ <strong>Stimulus_Task_1</strong>
+ </td>
+ <td colspan="1" rowspan="2">Periodic</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">offset: 0 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">recurrence: 25 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Stimulus_Task_2</strong>
+ </td>
+ <td colspan="1" rowspan="1">Inter-Process</td>
+ <td colspan="1" rowspan="1"/>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Stimulus_Task_3</strong>
+ </td>
+ <td colspan="1" rowspan="1">Inter-Process</td>
+ <td colspan="1" rowspan="1"/>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">
+ <strong>Stimulus_Task_4</strong>
+ </td>
+ <td colspan="1" rowspan="3">Sporadic (Gauss)</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">mean: 30 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">sd: 5 ms</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">upper: 100 ms</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section2.3.3">2.3.3 </a>Modeling Example "Purely Periodic without Communication"</h3>
+ <p>This system architecture pattern consists of a task set, where each task is activated periodically and no data accesses are performed. The execution time for each task is determined by the called runnable entities as specified in the table below. All tasks contain just one runnable except of T<sub>7</sub>, which calls at first R<sub>7,1</sub> and after that R<sub>7,2</sub>.
+ </p>
+ <p>The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.</p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">Multiple Task Activation Limit</th>
+ <th colspan="1" rowspan="1">Activation</th>
+ <th colspan="2" rowspan="1">Execution Time</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="3">7</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 9.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 80</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 10</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="3">6</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 29.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 120</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 30</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>3</sub>
+ </td>
+ <td colspan="1" rowspan="3">5</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>3</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 19.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 160</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 20</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>4</sub>
+ </td>
+ <td colspan="1" rowspan="3">4</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>4</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 14.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 180</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 15</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>5</sub>
+ </td>
+ <td colspan="1" rowspan="3">3</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>5</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 29.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 200</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 30</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>6</sub>
+ </td>
+ <td colspan="1" rowspan="3">2</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>6</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 39.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 300</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 40</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="6">T<sub>7</sub>
+ </td>
+ <td colspan="1" rowspan="6">1</td>
+ <td colspan="1" rowspan="6">FULL</td>
+ <td colspan="1" rowspan="6">1</td>
+ <td colspan="1" rowspan="2"/>
+ <td colspan="1" rowspan="3">R<sub>7,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 59.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 60</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="3">R<sub>7,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 1000</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 19.95</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 20</td>
+ </tr>
+ </table>
+ <p>In order to show the impact of changes to the model, the following consecutive variations are made to the model: </p>
+ <dl>
+ <dt>
+ <b>1) Initial Task Set</b>
+ </dt>
+ <dd>For this variation, the Tasks T<sub>4</sub>, T<sub>5</sub>, T<sub>6</sub>, and T<sub>7</sub> of the table above are active.
+ <br>
+ <img src="images/modeling_example_periodic_1.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>2) Increase of Task Set Size I</b>
+ </dt>
+ <dd>For this variation, the Tasks T<sub>3</sub>, T<sub>4</sub>, T<sub>5</sub>, T<sub>6</sub>, and T<sub>7</sub> are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_periodic_2.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>3) Increase of Task Set Size II</b>
+ </dt>
+ <dd>For this variation, the Tasks T<sub>1</sub>, T<sub>3</sub>, T<sub>4</sub>, T<sub>5</sub>, T<sub>6</sub>, and T<sub>7</sub> are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_periodic_3.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>4) Increase of Task Set Size III</b>
+ </dt>
+ <dd>As from this variation on, all tasks (T<sub>1</sub> - T<sub>7</sub>) are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_periodic_4.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>5) Accuracy in Logging</b>
+ </dt>
+ <dd>For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_periodic_5.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>6) Schedule</b>
+ </dt>
+ <dd>As from this variation on, T<sub>7</sub> is set to non-preemptive. That way, the timing behavior is changed, which results in extinct activations (see red mark in the figure below).
+ <br>
+ <img src="images/modeling_example_periodic_6.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>7) Activation</b>
+ </dt>
+ <dd>As from this variation on, the maximum number of queued activation requests for all tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.
+ <br>
+ <img src="images/modeling_example_periodic_7.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>8) Schedule Point</b>
+ </dt>
+ <dd>For this variation, a schedule point is added to T<sub>7</sub> between the calls of R<sub>7,1</sub> and R<sub>7,2</sub>. That way, the timing behavior is changed in particular.
+ <br>
+ <img src="images/modeling_example_periodic_8.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>9) Scheduling Algorithm</b>
+ </dt>
+ <dd>For this variation, the scheduling algorithm is set to Earliest Deadline First. That way, the timing behavior is changed completely.
+ <br>
+ <img src="images/modeling_example_periodic_9.png"/>
+ </dd>
+ </dl>
+
+
+<h3><a id="section2.3.4">2.3.4 </a>Modeling Example "Client-Server without Reply"</h3>
+ <p>This system architecture pattern extends the modeling example "Purely Periodic without Communication" by adding an one-way communication between tasks. It consists of two tasks T<sub>1</sub>, and T<sub>2</sub>. Task T<sub>1</sub> sends a message to Task T<sub>2</sub> before runnable R~1~ is called. In 20% of the cases Message 1, in 30% of the cases Message 2, in 20% of the cases Message 3, in 15% of the cases Message 4, and in 15% of the cases any other message than the previously mentioned ones is sent. Task T<sub>2</sub> reacts on the contents of the message by calling different runnables. In case of Message 1 runnable R<sub>2,1</sub>, in case of Message 2 runnable R<sub>2,2</sub>, in case of Message 3 runnable R<sub>2,3</sub>, in case of Message 4 runnable R<sub>2,4</sub>, and in case of any other message than the previous mentioned ones runnable R<sub>2,x</sub> is called as default.
+ </p>
+ <p>
+ <img src="images/modeling_example_client_server.png"/>
+ </p>
+ <p>The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.</p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">Multiple Task Activation Limit</th>
+ <th colspan="1" rowspan="1">Activation</th>
+ <th colspan="2" rowspan="1">Execution Time</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="3">2</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 9.9 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 100 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 10 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="15">T<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="15">1</td>
+ <td colspan="1" rowspan="15">FULL</td>
+ <td colspan="1" rowspan="15">1</td>
+ <td colspan="1" rowspan="6"/>
+ <td colspan="1" rowspan="3">R<sub>2,x</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">R<sub>2,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 990</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 1 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>2,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 15 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 60 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="6"/>
+ <td colspan="1" rowspan="3">R<sub>2,3</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 990 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 1 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">R<sub>2,4</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 39.6 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 40 * 10<sup>6</sup>
+ </td>
+ </tr>
+ </table>
+ <p>In order to show the impact of changes to the model, the following consecutive variations are made to the model:</p>
+ <dl>
+ <dt>
+ <b>1) Initial Task Set</b>
+ </dt>
+ <dd>As defined by the table above.
+ <br>
+ <img src="images/modeling_example_client_server_1.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>2) Exclusive Area</b>
+ </dt>
+ <dd>For this variation, all data accesses are protected by an exclusive area. Therefore, the data accesses in T<sub>1</sub> as well as all runnables in T<sub>2</sub> (R<sub>2,x</sub>, R<sub>2,1</sub>, R<sub>2,2</sub>, R<sub>2,3</sub>, and R<sub>2,4</sub>) are protected during their complete time of execution via a mutex and priority ceiling protocol. That way, blocking situations appear.
+ <br>
+ <img src="images/modeling_example_client_server_2.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>3) Inter-process Activation</b>
+ </dt>
+ <dd>As from this variation on, task T<sub>2</sub> gets activated by an inter-process activation from task T<sub>1</sub> instead of being activated periodically. The interprocess activation is performed right after the message
+ <em>message</em> is written in T<sub>2</sub> and consequently before the runnable R<sub>1</sub> is called. That way, a direct connection between T<sub>1</sub> and T<sub>2</sub> is established.
+ <br>
+ <img src="images/modeling_example_client_server_3.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>4) Priority Ordering</b>
+ </dt>
+ <dd>As from this variation on, the priority relation between task T<sub>1</sub> and T<sub>2</sub> is reversed. As a consequence, the priority of task T<sub>1</sub> is set to 1 and the priority of task T<sub>2</sub> is set to 2. That way, a switch from asynchronous to synchronous communication is considered.
+ <br>
+ <img src="images/modeling_example_client_server_4.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>5) Event Frequency Increase</b>
+ </dt>
+ <dd>As from this variation on, the periodicity of T<sub>1</sub> is shortened. For this, the value for the period of task T<sub>1</sub> is cut in half to 50 * 10<sup>6</sup> time units. That way, the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_client_server_5.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>6) Execution Time Fluctuation</b>
+ </dt>
+ <dd>As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of every uniform distribution is increased by 1 percent so that they vary now by 2 percent. That way, the utilisation of the system is increased, which results in extinct activations.
+ <br>
+ <img src="images/modeling_example_client_server_6.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>7) Activation</b>
+ </dt>
+ <dd>As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.
+ <br>
+ <img src="images/modeling_example_client_server_7.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>8) Accuracy in Logging of Data State I</b>
+ </dt>
+ <dd>For this variation, the data accesses in task T<sub>1</sub> and task T<sub>2</sub> are omitted. Instead, the runnable entities R<sub>2,x</sub>, R<sub>2,1</sub>, R<sub>2,2</sub>, R<sub>2,3</sub>, and R<sub>2,4</sub>, each representing the receipt of a specific message, are executed equally random, meaning each with a probability of 20%. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_client_server_8.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>9) Accuracy in Logging of Data State II</b>
+ </dt>
+ <dd>For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_client_server_9.png"/>
+ </dd>
+ </dl>
+
+
+<h3><a id="section2.3.5">2.3.5 </a>Modeling Example "State Machine"</h3>
+ <p>In this system architecture pattern the modeling example "Client Server without Reply" is extended in such a way that now the task that receives messages (T<sub>2</sub>) not only varies its dynamic behavior and consequently also its execution time according the transmitted content but also depending on its internal state, meaning the prior transmitted contents. To achieve, this task T<sub>1</sub> sends a message to task T<sub>2</sub> with either 0 or 1 before runnable R<sub>1</sub> is called. The value 0 is used in 75 % of the cases and 1 in the other cases as content of the message. Starting in state 0, T<sub>2</sub> decreases or increases the state its currently in depending on the content of the message, 0 or 1 respectively. The runnable R<sub>2,1</sub>, R<sub>2,2</sub>, and R<sub>2,3</sub> represent then the three different states that the system can be in.
+ </p>
+ <p>
+ <img src="images/modeling_example_state_machine.png"/>
+ </p>
+ <p>The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.</p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">Multiple Task Activation Limit</th>
+ <th colspan="1" rowspan="1">Activation</th>
+ <th colspan="2" rowspan="1">Execution Time</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="3">2</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 9.9 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 100 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 10 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="9">T<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="9">1</td>
+ <td colspan="1" rowspan="9">FULL</td>
+ <td colspan="1" rowspan="9">1</td>
+ <td colspan="1" rowspan="3"/>
+ <td colspan="1" rowspan="3">R<sub>2,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>2,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 15 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 60 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3"/>
+ <td colspan="1" rowspan="3">R<sub>2,3</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>6</sup>
+ </td>
+ </tr>
+ </table>
+ <p>In order to show the impact of changes to the model, the following consecutive variations are made to the model:</p>
+ <dl>
+ <dt>
+ <b>1) Initial Task Set</b>
+ </dt>
+ <dd>As defined by the table above.
+ <br>
+ <img src="images/modeling_example_state_machine_1.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>2) Exclusive Area</b>
+ </dt>
+ <dd>For this variation, all data accesses are protected by an exclusive area. Therefore, the data accesses in T<sub>1</sub> as well as all runnables in T<sub>2</sub> (R<sub>2,1</sub>, R<sub>2,2</sub>, and R<sub>2,3</sub>) are protected during their complete time of execution via a mutex and priority ceiling protocol. That way, blocking situations appear.
+ <br>
+ <img src="images/modeling_example_state_machine_2.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>3) Priority Ordering</b>
+ </dt>
+ <dd>As from this variation on, the priority relation between task T<sub>1</sub> and T<sub>2</sub> is reversed. As a consequence, the priority of task T<sub>1</sub> is set to 1 and the priority of task T<sub>2</sub> is set to 2. That way, the timing behavior is changed fully.
+ <br>
+ <img src="images/modeling_example_state_machine_3.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>4) Inter-process Activation</b>
+ </dt>
+ <dd>As from this variation on, task T<sub>2</sub> gets activated by an inter-process activation from task T<sub>1</sub> instead of being activated periodically. The interprocess activation is performed right after the message
+ <em>message</em> is written in T<sub>1</sub> and consequently before the runnable R<sub>1</sub> is called. That way, a direct connection between T<sub>1</sub> and T<sub>2</sub> is established.
+ <br>
+ <img src="images/modeling_example_state_machine_4.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>5) Event Frequency Increase</b>
+ </dt>
+ <dd>As from this variation on, the periodicity of T<sub>1</sub> is shortened. For this, the value for the period of task T<sub>1</sub> is halved to 50 * 10<sup>6</sup>. That way, the utilisation of the system is increased, which results in extinct activations.
+ <br>
+ <img src="images/modeling_example_state_machine_5.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>6) Activation</b>
+ </dt>
+ <dd>As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.
+ <br>
+ <img src="images/modeling_example_state_machine_6.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>7) Execution Time Fluctuation</b>
+ </dt>
+ <dd>As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilisation of the system is further increased.
+ <br>
+ <img src="images/modeling_example_state_machine_7.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>8) Accuracy in Logging of Data State I</b>
+ </dt>
+ <dd>For this variation, the data write accesses in task T<sub>1</sub> and task T<sub>2</sub> are omitted. Instead, the runnables R<sub>2,1</sub>, R<sub>2,2</sub>, and R<sub>2,3</sub>, each representing the execution of a specific state, are executed with a probability of 60 %, 30 %, and 10 % respectively. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_state_machine_8.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>9) Accuracy in Logging of Data State II</b>
+ </dt>
+ <dd>For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_state_machine_9.png"/>
+ </dd>
+ </dl>
+
+
+<h3><a id="section2.3.6">2.3.6 </a>Modeling Example "Feedback Loop"</h3>
+ <p>The task set of the modeling example "State Machine" is expanded further in this architecture pattern with the result that messages are exchanged in a loop, instead of just in one way. To achieve this, task T<sub>1</sub> sends a message
+ <em>u</em> to task T<sub>2</sub> before runnable R<sub>1</sub> is called. The content of this message is 0, if the content of a previously received message
+ <em>e</em> is 0, or 1 if it was 1. Task T<sub>2</sub> represents then a state machine with three states that increases its state, if message
+ <em>u</em> is 1 and decreases, if it is 0. In each state the messages
+ <em>y</em> and
+ <em>w</em> are set with state specific values and sent to task T<sub>3</sub> and task T<sub>4</sub> respectively. In case of
+ <em>State 0</em>, the messages
+ <em>y</em> and
+ <em>w</em> contain the value 0, in case of
+ <em>State 1</em> both contain 50 and in case of
+ <em>State 2</em> the value 100 is sent. These messages are written before runnable R<sub>2</sub> is called. However, in 30 % of the cases task T<sub>4</sub> is activated via an inter-process activation before this runnable call happens. Task T<sub>3</sub> varies its dynamic behavior and consequently also its execution time according the transmitted content of message
+ <em>y</em>. Task T<sub>4</sub> finally prepares again the input for task T~1~. If the content received in message
+ <em>w</em> is 0, then in 30% of the cases the content of message
+ <em>e</em> is 0, otherwise 1. In the case that message
+ <em>w</em> is 50, message
+ <em>e</em> is set to 0 with a probability of 50% and to 1 accordingly. Finally, message
+ <em>e</em> is set to 0 in 70% of the cases and to 1 in 30% of the cases, if message
+ <em>w</em> is 100. In addition to this feedback loop, other system architecture patterns are added to be executed concurrently in order to increase the complexity. The tasks T<sub>5</sub> and T<sub>6</sub> represent a client-server without reply and are equal to the tasks T<sub>1</sub> and T<sub>2</sub> respectively as described in the modeling example "Client-Server without Reply". T<sub>7</sub> is a periodically activated task without any communication and identical to task T<sub>7</sub> of modeling example "Purely Periodic without Communication".
+ </p>
+ <p>
+ <img src="images/modeling_example_feedback_loop.png"/>
+ </p>
+ <p>The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.</p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">Multiple Task Activation Limit</th>
+ <th colspan="1" rowspan="1">Activation</th>
+ <th colspan="2" rowspan="1">Execution Time</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="3">3</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 9.9 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 600 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 10 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="3">2</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 20 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>4</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 300 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>4</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="9">T<sub>3</sub>
+ </td>
+ <td colspan="1" rowspan="9">3</td>
+ <td colspan="1" rowspan="9">FULL</td>
+ <td colspan="1" rowspan="9">1</td>
+ <td colspan="1" rowspan="3"/>
+ <td colspan="1" rowspan="3">R<sub>3,0</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>4</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>4</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>3,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 50 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 500 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3"/>
+ <td colspan="1" rowspan="3">R<sub>3,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>4</sub>
+ </td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="3">R<sub>4</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Inter-process Activation</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>5</sub>
+ </td>
+ <td colspan="1" rowspan="3">5</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>5</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 100 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="15">T<sub>6</sub>
+ </td>
+ <td colspan="1" rowspan="15">4</td>
+ <td colspan="1" rowspan="15">FULL</td>
+ <td colspan="1" rowspan="15">1</td>
+ <td colspan="1" rowspan="6"/>
+ <td colspan="1" rowspan="3">R<sub>6,x</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">R<sub>6,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 990</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 1 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>6,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 15 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 60 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="6"/>
+ <td colspan="1" rowspan="3">R<sub>6,3</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 990 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 1 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">R<sub>6,4</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="6">T<sub>7</sub>
+ </td>
+ <td colspan="1" rowspan="6">0</td>
+ <td colspan="1" rowspan="6">FULL</td>
+ <td colspan="1" rowspan="6">1</td>
+ <td colspan="1" rowspan="2"/>
+ <td colspan="1" rowspan="3">R<sub>7,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 59.4 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 60 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="3">R<sub>7,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 1000</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 19.8 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 20 * 10<sup>6</sup>
+ </td>
+ </tr>
+ </table>
+ <p>In order to show the impact of changes to the model, the following consecutive variations are made to the model:</p>
+ <dl>
+ <dt>
+ <b>1) Initial Task Set</b>
+ </dt>
+ <dd>For this variation, the tasks T<sub>1</sub>, T<sub>2</sub>, T<sub>3</sub>, and T<sub>4</sub> of the table above are active.
+ <br>
+ <img src="images/modeling_example_feedback_loop_1.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>2) Increase of Task Set Size I</b>
+ </dt>
+ <dd>For this variation, the Tasks T<sub>1</sub>, T<sub>2</sub>, T<sub>3</sub>, T<sub>4</sub>, T<sub>5</sub>, and T<sub>6</sub> are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_feedback_loop_2.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>3) Increase of Task Set Size II</b>
+ </dt>
+ <dd>As from this variation on, all tasks are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_feedback_loop_3.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>4) Inter-process Activation</b>
+ </dt>
+ <dd>As from this variation on, task T<sub>2</sub> gets activated by an inter-process activation from task T<sub>1</sub>, task T<sub>3</sub> by an inter-process activation from task T<sub>2</sub>, and task T<sub>6</sub> by an inter-process activation from task T<sub>5</sub> instead of being activated periodically. The inter-process activation in task T<sub>1</sub> is performed right after the message
+ <em>u</em> is written in T<sub>2</sub> and consequently before the runnable R<sub>1</sub> is called, in task T<sub>2</sub> respectively right before task T<sub>4</sub> is activated, and in task T<sub>5</sub> task T<sub>6</sub> is called right before runnable R<sub>5</sub>. That way, a direct connection between these tasks is established.
+ <br>
+ <img src="images/modeling_example_feedback_loop_4.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>5) Event Frequency Increase</b>
+ </dt>
+ <dd>As from this variation on, the periodicity of the tasks T<sub>1</sub>, T<sub>5</sub>, and T<sub>7</sub> are shortened. For task T<sub>1</sub>, the value for the period is set to 450 * 10<sup>6</sup>, the task T<sub>5</sub> to 60 * 10<sup>6</sup>, and for task T<sub>7</sub> to 575 * 10<sup>6</sup>. That way, the information density is increased.
+ <br>
+ <img src="images/modeling_example_feedback_loop_5.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>6) Execution Time Fluctuation</b>
+ </dt>
+ <dd>As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilisation of the system is increased, which results in extinct activations.
+ <br>
+ <img src="images/modeling_example_feedback_loop_6.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>7) Activation</b>
+ </dt>
+ <dd>As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.
+ <br>
+ <img src="images/modeling_example_feedback_loop_7.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>8) Accuracy in Logging of Data State I</b>
+ </dt>
+ <dd>For this variation, the data accesses in all tasks are omitted. Instead, the runnable entities R<sub>3,0</sub>, R<sub>3,1</sub>, and R<sub>3,2</sub>, are executed with a probability of 50 %, 30 %, and 20 % respectively, and the runnable entities R<sub>6,x</sub>, R<sub>6,1</sub>, R<sub>6,2</sub>, R<sub>6,3</sub>, and R<sub>6,4</sub> are executed with a probability of 15 %, 20 %, 30 %, 20 %, and 15 % respectively. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_feedback_loop_8.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>9) Accuracy in Logging of Data State II</b>
+ </dt>
+ <dd>For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_feedback_loop_9.png"/>
+ </dd>
+ </dl>
+
+
+<h3><a id="section2.3.7">2.3.7 </a>Modeling Example "State Machine Feedback Loop"</h3>
+ <p>The task set of the modeling example "State Machine" is expanded further in this architecture pattern by combining the ideas behind the modeling example "State Machine" and "Feedback Loop". This means that messages are exchanged in a loop and each sender/receiver is also a state machine. To achieve this, task T<sub>1</sub> has two different internal states 0 and 1, and task T<sub>2</sub> manages three consecutive states 0, 1, and 2. The state task T<sub>1</sub> is currently in is sent via a message to task T<sub>2</sub> before runnable R<sub>1</sub> is called. If the content of the message sent from task T<sub>1</sub> is 1, task T<sub>2</sub> increases its internal state, e.g. from state 0 to 1, and if it is 0, task T<sub>2</sub> decreases its internal state accordingly. Then, depending on the state task T<sub>2</sub> is currently in, the according runnable (R<sub>2,0</sub> for state 0, etc.) is executed. If the maximum or minimum state of task T<sub>2</sub> is reached but the received message from task T<sub>1</sub> tells task T<sub>2</sub> to further increase or respectively decrease its internal state, task T<sub>2</sub> sends a message to task T<sub>1</sub>. This message then causes task T<sub>1</sub> to toggle its internal state which consequently results in a switch from increasing to decreasing or vice versa. In addition to this state machine feedback loop, other system architecture patterns are added to be executed concurrently in order to increase the complexity. The tasks T<sub>3</sub> and T<sub>4</sub> represent a client-server without reply and are equal to the tasks T<sub>1</sub> and T<sub>2</sub> respectively as described above in the modeling example "Client-Server without Reply". T<sub>5</sub> is a periodically activated task without any communication and identical to task T<sub>7</sub> in the modeling example "Purely Periodic without Communication".
+ </p>
+ <p>
+ <img src="images/modeling_example_state_machine_feedback_loop.png"/>
+ </p>
+ <p>The table below gives a detailed specification of the tasks and their parameters. The tasks are scheduled according fixed-priority, preemptive scheduling and if not indicated otherwise, all events are active in order to get a detailed insight into the system's behavior.</p>
+ <table class="classic" style="text-align:center; background:#f8f8f8">
+ <tr style="background:#eee">
+ <th colspan="1" rowspan="1">Task</th>
+ <th colspan="1" rowspan="1">Priority</th>
+ <th colspan="1" rowspan="1">Preemption</th>
+ <th colspan="1" rowspan="1">Multiple Task Activation Limit</th>
+ <th colspan="1" rowspan="1">Activation</th>
+ <th colspan="2" rowspan="1">Execution Time</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="3">2</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 9.9 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 300 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 10 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="9">T<sub>2</sub>
+ </td>
+ <td colspan="1" rowspan="9">1</td>
+ <td colspan="1" rowspan="9">FULL</td>
+ <td colspan="1" rowspan="9">1</td>
+ <td colspan="1" rowspan="3"/>
+ <td colspan="1" rowspan="3">R<sub>2,0</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>2,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 15 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 250 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3"/>
+ <td colspan="1" rowspan="3">R<sub>2,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">T<sub>3</sub>
+ </td>
+ <td colspan="1" rowspan="3">4</td>
+ <td colspan="1" rowspan="3">FULL</td>
+ <td colspan="1" rowspan="3">1</td>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>3</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 100 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100 * 10<sup>5</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="15">T<sub>4</sub>
+ </td>
+ <td colspan="1" rowspan="15">3</td>
+ <td colspan="1" rowspan="15">FULL</td>
+ <td colspan="1" rowspan="15">1</td>
+ <td colspan="1" rowspan="6"/>
+ <td colspan="1" rowspan="3">R<sub>4,x</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 99</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 100</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">R<sub>4,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 990</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 1 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="3">R<sub>4,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 15 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 60 * 10<sup>6</sup>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="6"/>
+ <td colspan="1" rowspan="3">R<sub>4,3</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 990 * 10<sup>3</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 1 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="3">R<sub>4,4</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 49.5 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 50 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="6">T<sub>5</sub>
+ </td>
+ <td colspan="1" rowspan="6">0</td>
+ <td colspan="1" rowspan="6">FULL</td>
+ <td colspan="1" rowspan="6">1</td>
+ <td colspan="1" rowspan="2"/>
+ <td colspan="1" rowspan="3">R<sub>5,1</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 59.4 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 60 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Offset = 0</td>
+ <td colspan="1" rowspan="3">R<sub>5,2</sub>
+ </td>
+ <td colspan="1" rowspan="1">Uniform</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="text-align: left;">Recurrence = 1000</td>
+ <td colspan="1" rowspan="1" style="text-align: left;">Min = 19.8 * 10<sup>6</sup>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1" style="text-align: left;">Max = 20 * 10<sup>6</sup>
+ </td>
+ </tr>
+ </table>
+ <p>In order to show the impact of changes to the model, the following consecutive variations are made to the model:</p>
+ <dl>
+ <dt>
+ <b>1) Initial Task Set</b>
+ </dt>
+ <dd>For this variation, the tasks T<sub>1</sub>, and T<sub>2</sub> of the table above are active.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_1.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>2) Increase of Task Set Size I</b>
+ </dt>
+ <dd>For this variation, the tasks T<sub>1</sub>, T<sub>2</sub>, T<sub>3</sub>, and T<sub>4</sub> are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_2.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>3) Increase of Task Set Size II</b>
+ </dt>
+ <dd>As from this variation on, all tasks are active. That way the utilisation of the system is increased.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_3.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>4) Inter-process Activation</b>
+ </dt>
+ <dd>As from this variation on, task T<sub>2</sub> gets activated by an inter-process activation from task T<sub>1</sub>, and task T<sub>4</sub> by an inter-process activation from task T<sub>3</sub> instead of being activated periodically. The inter-process activation in task T<sub>1</sub> is performed right after the message to task T<sub>2</sub> is written and consequently before the runnable R<sub>1</sub> is called, and in task T<sub>3</sub> task T<sub>4</sub> is called right before runnable R<sub>3</sub>. That way, a direct connection between these tasks is established.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_4.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>5) Event Frequency Increase</b>
+ </dt>
+ <dd>As from this variation on, the periodicity of the tasks T<sub>1</sub>, T<sub>3</sub>, and T<sub>5</sub> are shortened. For task T<sub>1</sub>, the value for the period is set to 220 * 10<sup>6</sup>, the task T<sub>3</sub> to 50 * 10<sup>6</sup>, and for task T<sub>5</sub> to 500 * 10<sup>6</sup>. That way, the information density is increased.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_5.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>6) Execution Time Fluctuation</b>
+ </dt>
+ <dd>As from this variation on, the execution time distribution is widened for both tasks. Therefore, the maximum of the uniform distribution is increased by 1 percent so that the uniform distribution varies now by 2 percent. That way, the utilisation of the system is increased, which results in extinct activations.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_6.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>7) Activation</b>
+ </dt>
+ <dd>As from this variation on, the maximum number of queued activation requests for both tasks is set to 2. That way, the problem with extinct activations resulting from the previous variation is solved.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_7.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>8) Accuracy in Logging of Data State I</b>
+ </dt>
+ <dd>For this variation, the data accesses in all tasks are omitted. Instead, all runnablea representing a state are executed equally random, meaning the runnables R<sub>2,0</sub>, R<sub>2,1</sub>, and R<sub>2,2</sub> are each executed with a probability of 33 %, and the runnables R<sub>4,x</sub>, R<sub>4,1</sub>, R<sub>4,2</sub>, R<sub>4,3</sub>, and R<sub>4,4</sub> each with a probability of 20 %. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_8.png"/>
+ </dd>
+ </dl>
+ <dl>
+ <dt>
+ <b>9) Accuracy in Logging of Data State II</b>
+ </dt>
+ <dd>For this variation, just task events are active. That way, only a limited insight into the system's runtime behavior is available.
+ <br>
+ <img src="images/modeling_example_state_machine_feedback_loop_9.png"/>
+ </dd>
+ </dl>
+
+
+<h3><a id="section2.3.8">2.3.8 </a>Democar Example</h3>
+ <p>The so called Democar model presented in the AMALTHEA example files describe a simple engine management system.</p>
+
+
+<h4><a id="section2.3.8.1"></a>Origin</h4>
+ <p>The Democar example is loosely based on the publicly available information taken from</p>
+ <blockquote>
+ <p>
+ <br>
+ <strong>A Timing Model for Real-Time Control-Systems and its Application</strong>
+ <br>
+ <strong>on Simulation and Monitoring of AUTOSAR Systems</strong>
+ <br>
+ <em>Author: Patrick Frey</em>
+ </p>
+ </blockquote>
+ <p>A version of the dissertation can be downloaded from University of Ulm:
+ <a href="http://vts.uni-ulm.de/docs/2011/7505/vts_7505_10701.pdf" shape="rect">pdf</a>.
+ </p>
+
+
+<h4><a id="section2.3.8.2"></a>Files</h4>
+ <p>
+ <strong>AMALTHEA_Democar.amxmi</strong>
+ <br>contains the complete model, consisting of a hardware model, a model of the operating system, a stimulation model and a model that describes the software system.
+ </p>
+ <p>
+ <strong>Amalthea_ArExampleEngine.atdb</strong>
+ <br>is an AMALTHEA Trace Database and it contains a trace that is the result of a simulation of this example.
+ </p>
+
+
+<h3><a id="section2.3.9">2.3.9 </a>Hwmodel Example</h3>
+ <p>This example contains several hardware model examples. These are:</p>
+ <p>
+ <strong>gateway.amxmi</strong>
+ <br>which describes how to model master/slave Networks. It shows a Local Interconnect Network® (LIN) with one Master, represented by a the microcontroller "Gateway" and two sensors which respond to multiple unique commands. The lin specification is publicly available under
+ <a href="http://www.lin-subbus.org/" shape="rect">http://www.lin-subbus.org/</a>.
+ </p>
+ <p>
+ <strong>memory.amxmi</strong>
+ <br>which describes how to model memory segments with the AMALTHEA hardware model.
+ </p>
+ <p>
+ <strong>MPC5668G.amxmi</strong>
+ <br>which describes a sample system consisting of a Freescale MPC5668G Demo Board and its SoC.
+ <br>It is loosely based on the publicly available information taken from the Freescale website:
+ <a href="http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5668G" shape="rect">Product summary MPC5668G</a>.
+ </p>
+
+
+<h2><a id="section2.4">2.4 </a>Tutorials</h2>
+
+
+<h3 id="example-task-creation"><a id="section2.4.1">2.4.1 </a>Task creation example</h3>
+ <p>The following section will describe how to generate tasks out of software models with
+ <i>sequencing constraints</i>.
+ </p>
+ <p>
+ <strong>Step 1</strong>
+ </p>
+ <p>
+ <img src="images/02-democar-example.png"/>
+ </p>
+ <p>Create a new example project based on the "Democar Example" (
+ <strong>File -> New -> Example</strong>).
+ </p>
+ <p>
+ <strong>Step 2</strong>
+ </p>
+ <p>
+ <img class="gray" src="images/04-generate-tasks.png"/>
+ </p>
+ <p>Click on the left arrow of the "org.eclipse.app4mc.amalthea.example.democar.mapping" project to expand it. You will see several files with models of the democar project, each of them containing one specific model, e.g. "AMALTHEA_Democar_MappingExample.amxmi" with the software model and constraints model. Usually, a software model needs to be partitioned before it can be mapped. You can either use the partitioning plugin for this, or the included (already partitioned) software model.
+ <br>Right-click on the file "AMALTHEA_Democar_MappingExample.amxmi" and click "Generate Tasks" to start the task generation process. This will also convert the
+ <i>Activation</i> elements from the partitioned software model to
+ <i>Stimuli</i> and store these in a stimulation model.
+ </p>
+ <p>
+ <strong>Step 3</strong>
+ </p>
+ <p>
+ <img src="images/05-output-model.png"/>
+ </p>
+ <p>Once the tasks have been generated, a new file with tasks will be created in the "output" folder. The file "AMALTHEA_Democar_MappingExample_withTasks.amxmi" contains the final software model, the stimulation model and the constraints model and is ready to be mapped.</p>
+
+
+<h3 id="example-mapping-1"><a id="section2.4.2">2.4.2 </a>Mapping example 1</h3>
+ <p>The following section will describe how to calculate a mapping with the AMALTHEA tool platform using the DFG and ILP based load balancing algorithms.</p>
+ <p>
+ <strong>Step 1</strong>
+ </p>
+ <p>
+ <img src="images/06-perform-mapping.png"/>
+ </p>
+ <p>The mapping example required a software model with tasks. You can either use the resulting model from the previous task creation example ("AMALTHEA_Democar_MappingExample_withTasks.amxmi") or the already existing software model example. Right-click the file with the software model you would like to map and select "Perform Mapping" to open the GUI for the mapping.</p>
+ <p>
+ <strong>Step 2</strong>
+ </p>
+ <p>
+ <img src="images/07-perform-mapping-ui.png"/>
+ </p>
+ <p>The name of the project as well as the path to the software project have already been entered for you. To perform the mapping, you need to specify the path to a hardware model. This can be done by clicking on the second "Search" button from the top and locating the file "AMALTHEA_Democar_MappingExample-hw.amxmi". Now you only need to click "Create Mapping" to perform the calculations and create a mapping from tasks to cores.</p>
+ <p>
+ <strong>Step 3</strong>
+ </p>
+ <p>
+ <img class="gray" src="images/08-inspect.png"/>
+ </p>
+ <p>Once the mapping is performed, a new file will be generated in the "output" folder. Mapping and OS can be found in the file "AMALTHEA_Democar_MappingExample_withTasks_out.amxmi". To inspect this file, just double-click on it to open a content tree explorer.
+ <br>Additional information about the mapping is provided in the console.
+ </p>
+
+
+<h3 id="example-mapping-2"><a id="section2.4.3">2.4.3 </a>Mapping example 2</h3>
+ <p>The following section will describe how to calculate a mapping with the AMALTHEA Tool Platform using the experimental energy minimization algorithm.</p>
+ <p>
+ <strong>Step 1</strong>
+ </p>
+ <p>
+ <img src="images/09-preferences.png"/>
+ </p>
+ <p>The first step is to change the mapping algorithm into the "Energy efficient mapping" algorithm. Do this by clicking on "Window" and then "Preferences" in the menu bar. The preferences window will open and you are able to configure the mapping plugin on its preferences page under the point "AMALTHEA Mapping".
+ <br>Select "Energy efficient mapping (Experimental)" and close the page using the OK button on the bottom.
+ </p>
+ <p>
+ <strong>Step 2</strong>
+ </p>
+ <p>The algorithm for energy efficient mapping (minimization of the energy consumption) comes with specifically altered model files based on the Democar and HVAC use case which are stored in the folder "modelEnergyEfficient". Open this folder, right click on one of the two "AMALTHEA????_EnergyEfficientMappingExample.amxmi" files and select perform mapping. As this algorithm comes with its own task creation algorithm, we can skip the task creation process.</p>
+ <p>
+ <strong>Step 3</strong>
+ </p>
+ <p>Similar to the previous example, the name of the project as well as the path have already been entered for you. To perform the mapping, specify the path to the hardware model. This is done by clicking the second search button from the top and locating the file "IMX6.amxmi-hw" within the "modelEnergyEfficient" folder. Start the mapping calculation by hitting the "Create Mapping" button.</p>
+ <p>
+ <strong>Step 4</strong>
+ </p>
+ <p>
+ <img src="images/10inspect.png"/>
+ </p>
+ <p>Once the mapping is performed, two additional files will be generated in the "output" folder. The mapping can be found in the file "AMALTHEA_????_MappingExample_withTasks_mapping.amxmi-mapping". To inspect this file, just double-click on it to open a content tree explorer.
+ <br>Additional information about the mapping is provided in the console.
+ </p>
+
+
+<h3><a id="section2.4.4">2.4.4 </a>AMALTHEA Trace Database (ATDB) Import Example</h3>
+ <p>The following section describes how to use the information contained within an AMALTHEA Trace Database (ATDB) to create a model.</p>
+ <p>
+ <strong>Step 1</strong>
+ </p>
+ <p>
+ <img src="images/amalthea_trace_db_example.png"/>
+ </p>
+ <p>The figure above shows content of "Amalthea_ArExampleEngine.atdb", an AMALTHEA Trace database provided with the "Democar Example".
+ <br>To get this file create a new example project (see "Creating an example"), based on the "Democar Example".
+ </p>
+ <p>
+ <strong>Step 2</strong>
+ </p>
+ <p>
+ <img src="images/amalthea_import_options.png"/>
+ </p>
+ <p>Right-click on the project folder "org.eclipse.app4mc.amalthea.example.democar" or any other. You will see several possible options. In that option menu press "Import..." then.
+ <br>This will open a dialogue where the different import options available are listed. Open the folder called "AMALTHEA" by clicking on cross next to the title. This is shown in the figure above.
+ </p>
+ <p>
+ <strong>Step 3</strong>
+ </p>
+ <p>
+ <img src="images/atdb_import_dialogue.png"/>
+ </p>
+ <p>Next, choose mark the option "From AMALTHEA Trace DB" by clicking on it and proceed to the next page by either double-clicking the option name or by pressing the "Next" button. There you are prompted to enter the location of the ATDB file you want to import. Click the upper "Browse..." button to navigate your file system and select the wanted file. If you want to change the target project the model will be created in press the lower "Browse..." button and make your choice. The figure above shows an example input.</p>
+ <p>
+ <strong>Step 4</strong>
+ </p>
+ <p>
+ <img src="images/atdb_import_result.png"/>
+ </p>
+ <p>After you have made all required inputs, click on "Finish". This will start the analysis of the database. Once the model creation is done the dialogue will close and the newly created amxmi file opened on the AMALTHEA Model editor as shown in the figure above.</p>
+
+
+<h2><a id="section2.5">2.5 </a>Editors / Viewers</h2>
+ <p>In addition to the standard model editor there are editors and viewers for specific purposes:</p>
+ <ul>
+ <li>AMALTHEA Trace Database Metrics Viewer</li>
+ </ul>
+
+
+<h3><a id="section2.5.1">2.5.1 </a>AMALTHEA Trace Database Metrics Viewer</h3>
+ <p>This is a simple viewer that shows how to access the AMALTHEA trace database.</p>
+ <p>
+ <img src="images/metric-viewer_open.png"/>
+ </p>
+ <p>
+ <img src="images/metric-viewer_table.png"/>
+ </p>
+
+
+<h3><a id="section2.5.2">2.5.2 </a>Other editors</h3>
+ <p>
+ <i>Further (graphical) editors / viewers are under development</i>
+ </p>
+
+
+<h2><a id="section2.6">2.6 </a>Model Validation</h2>
+
+
+<h3><a id="section2.6.1">2.6.1 </a>Usage of Check-based Validation</h3>
+ <p>The AMALTHEA validation can be triggered by right clicking a model element in the left Model Explorer View and choose in the context menu Validate – Check-based Validation.</p>
+ <p>
+ <img class="gray" src="images/2015-06-18_1_sphinx_validation_trigger_command.png"/>
+ </p>
+ <p>All AMALTHEA sub elements of the chosen element are then included for the validation. In the next window the catalog appears allowing the selection of specific validation checks based on your selected model. Button "Select All" will select all listed validation checks for execution. Each entry of the catalog is called
+ <i>Category</i> which may contain several validation checks (i.e. constraints). The simplest way is to define a 1:1 relationship between category and constraint.
+ </p>
+ <p>
+ <img class="gray" src="images/2015-06-18_2_sphinx_validation_catalog.png"/>
+ </p>
+ <p>If an error is found, it is shown in the Problems view of Eclipse. A simple double click on the error will lead you to the affected elements in the AMALTHEA model. Sphinx validation distinguishes between three error types:
+ <i>errors</i>,
+ <i>warnings</i> and
+ <i>info</i>.
+ </p>
+ <p>
+ <img class="gray" src="images/2015-06-18_3_sphinx_validation_results.png"/>
+ </p>
+
+
+<h3><a id="section2.6.2">2.6.2 </a>Available Validations</h3>
+ <p>The plugin
+ <i>org.eclipse.app4mc.amalthea.model.all.sphinx.validation</i> contains several validators and constraints (i.e. checks) for various model types of AMALTHEA.
+ </p>
+
+
+<h4><a id="section2.6.2.1"></a>A. Basic Check Validator</h4>
+ <p>Basic checks which cannot be assigned to a specific AMALTHEA model are summarized. Responsible implementation for this validation is the class
+ <code>org.eclipse.app4mc.amalthea.model.all.sphinx.validation.checks.BasicCheckValidator</code>.
+ </p>
+
+
+<h5><a id="section2.6.2.1.1"></a>CustomPropertyDuplicateKeyConstraint</h5>
+ <p>A custom validation to check all set custom attributes of one element. If it contains duplicate key entries, it is treated as an error of this element.</p>
+
+
+<h5><a id="section2.6.2.1.2"></a>WeibullParametersConstraint</h5>
+ <p>Checks the parameters in the
+ <i>Distribution</i> of type
+ <i>WeibullEstimators</i>. The parameters must not be equal to each other, if this is the case, it will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h4><a id="section2.6.2.2"></a>B. ConstraintsModel Check Validator</h4>
+ <p>Responsible implementation for this validation is the class
+ <code>org.eclipse.app4mc.amalthea.model.all.sphinx.validation.checks.ConstraintsModelCheckValidator</code>.
+ </p>
+
+
+<h5><a id="section2.6.2.2.1"></a>EventChainsConstraint</h5>
+ <p>Checks for the AMALTHEA constraints model if the
+ <i>EventChains</i> are consistent regarding completeness (fully build chain) and correctness. Therefore each EventChain's stimulus/response pair is checked if events are existent and linked properly to a complete chain. An event chain of type
+ <i>SubEventChain</i> is checked for its "border" events fit to the stimulus and response event of the parent event chain. Cascades of sub events are processed recursively. A missing or wrong information in the event chain will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h4><a id="section2.6.2.3"></a>C. EventModel Check Validator</h4>
+ <p>Responsible implementation for this validation is the class
+ <code>org.eclipse.app4mc.amalthea.model.all.sphinx.validation.checks.EventModelCheckValidator</code>.
+ </p>
+
+
+<h5><a id="section2.6.2.3.1"></a>LabelEventMappingConstraint</h5>
+ <p>Checks for the AMALTHEA event model in AMALTHEA if the mapping information for all
+ <i>LabelEvent</i> are complete and correct. If there is a missing mapping information (i.e. no
+ <i>Entity</i>,
+ <i>Process</i> or
+ <i>Runnable</i>) it will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h5><a id="section2.6.2.3.2"></a>ProcessEventMappingConstraint</h5>
+ <p>Checks for the AMALTHEA event model in AMALTHEA if the mapping information for all
+ <i>ProcessEvent</i> are complete and correct. If there is a missing mapping information (i.e. no
+ <i>Entity</i> or
+ <i>Core</i>) it will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h5><a id="section2.6.2.3.3"></a>RunnableEventMappingConstraint</h5>
+ <p>Checks for the AMALTHEA event model in AMALTHEA if the mapping information for all
+ <i>RunnableEvent</i> are complete and correct. If there is a missing mapping information (i.e. no
+ <i>Entity</i>,
+ <i>Core</i> or
+ <i>Process</i>) it will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h5><a id="section2.6.2.3.4"></a>SemaphoreEventMappingConstraint</h5>
+ <p>Checks for the AMALTHEA event model in AMALTHEA if the mapping information for all
+ <i>SemaphoreEvent</i> are complete and correct. If there is a missing mapping information (i.e. no
+ <i>Entity</i>,
+ <i>Core</i>,
+ <i>Process</i> or
+ <i>Runnable</i>) it will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h5><a id="section2.6.2.3.5"></a>StimulusEventMappingConstraint</h5>
+ <p>Checks for the AMALTHEA event model in AMALTHEA if the mapping information for all
+ <i>StimulusEvent</i> are complete and correct. If there is a missing mapping information (i.e. no
+ <i>Entity</i>) it will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h4><a id="section2.6.2.4"></a>D. HardwareModel Check Validator</h4>
+ <p>Responsible implementation for this validation is the class
+ <code>org.eclipse.app4mc.amalthea.model.all.sphinx.validation.checks.HardwareModelCheckValidator</code>.
+ </p>
+
+
+<h5><a id="section2.6.2.4.1"></a>HwModelAbstractTypeDuplicateNameConstriant</h5>
+ <p>Checks for the entire AMALTHEA hardware model instance if elements of Type
+ <i>org.eclipse.app4mc.amalthea.model.hw.AbstractionTypeDescription</i> (e.g. ECUType, CoreType or System) contain AMALTHEA elements of
+ <i>org.eclipse.app4mc.amalthea.model.hw.AbstractType</i> (e.g. StrValue, BoolValue) with the identical name. A found duplicate will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h4><a id="section2.6.2.5"></a>E. MappingModel Check Validator</h4>
+ <p>Responsible implementation for this validation is the class
+ <code>org.eclipse.app4mc.amalthea.model.all.sphinx.validation.checks.MappingModelCheckValidator</code>.
+ </p>
+
+
+<h5><a id="section2.6.2.5.1"></a>Process2Scheduler2CoreMappingConstraint</h5>
+ <p>Checks for the entire AMALTHEA model instance if the mapping information are complete and correct between
+ <i>Software</i>(SW) <->
+ <i>Operating System</i>(OS) <->
+ <i>Software</i>(SW) model. I.e. mapping relationship {Process(SW) to Scheduler(OS) to Core(HW)}. A missing mapping information (i.e. no Entity) or unmapped Processes will be handled as an
+ <b>
+ <i>error</i>
+ </b>.
+ </p>
+
+
+<h2><a id="section2.7">2.7 </a>Model Migration</h2>
+
+
+<h3><a id="section2.7.1">2.7.1 </a>AMALTHEA Model Migration</h3>
+
+
+<h4><a id="section2.7.1.1"></a>Why model migration is required ?</h4>
+ <p>EMF based models are the instances of ECORE meta model (which is updated for each release). </p>
+ <p>As there is a tight dependency between model instance and the corresponding meta model, old EMF models can not be loaded with the newer release of meta model.</p>
+ <blockquote>
+ <p>Example : Due to the change in the namespace of the metamodel, loading of model files from prior versions would fail with the latest version</p>
+ </blockquote>
+ <p>This problem can be solved by explicitly migrating the model files from the prior versions to be compatible to the latest meta model version</p>
+
+
+<h4><a id="section2.7.1.2"></a>AMALTHEA model migration</h4>
+ <p>As described above, same scenario is also applicable for AMALTHEA models as they are instances of EMF based AMALTHEA ECORE meta model.</p>
+ <p>For each release of AMALTHEA there will be changes in the meta model contents, due to this it is not possible to load models built from previous releases of AMALTHEA into latest tool distribution.</p>
+ <p>
+ <strong>Model Migration functionality</strong> is part of this distribution, using this feature it is possible to convert models from previous releases (e.g: itea.1.0.3, itea.1.1.0, itea.1.1.1, 0.7.0 ,0.7.1) to the ones which are compatible to the next versions of AMALTHEA meta model.
+ </p>
+ <p>
+ <em>Only forward migration of models is supported by Model Migration functionality of AMALTHEA</em>
+ </p>
+
+
+<h3><a id="section2.7.2">2.7.2 </a>Supported versions for model Migration</h3>
+ <p>Model migration functionality provides a possibility to migrate the models (
+ <em>created from previous releases of AMALTHEA</em> ) to the latest versions
+ </p>
+ <p>
+ <em>Only forward migration is supported</em>
+ </p>
+ <p>
+ <b>AMALTHEA metamodel versions information</b>
+ </p>
+ <p>Below were the releases of AMALTHEA metamodel during its phase of being as a ITEA2 funded project ( For details refer :
+ <a href="http://www.amalthea-project.org/index.php/roadmap" shape="rect">www.amalthea-project.org</a> )
+ </p>
+ <ul>
+ <li>1.0.3</li>
+ <li>1.1.0</li>
+ <li>1.1.1</li>
+ </ul>
+ <p>From below version, AMALTHEA metamodel is a part of the official project Eclipse APP4MC ( See:
+ <a href="https://www.eclipse.org/app4mc" shape="rect">www.eclipse.org/app4mc</a> )
+ </p>
+ <ul>
+ <li>0.7.0</li>
+ <li>0.7.1</li>
+ </ul>
+ <p>
+ <b>Model migration</b>
+ </p>
+ <p>As described above, only forward migration is supported by the AMALTHEA model migration utility.</p>
+ <p>Model migration utility migrates the specified model sequentially to the next versions (step by step) till expected version is reached.</p>
+ <p>Below figure represents the steps involved in the migration of model from ITEA2 1.0.3 version to APP4MC 0.7.0 version:</p>
+ <p>
+ <img class="scale" src="images/migration_flow.png"/>
+ </p>
+
+
+<h3><a id="section2.7.3">2.7.3 </a>Pre-requisites for AMALTHEA model migration</h3>
+
+
+<h4 id="migration-vm-args"><a id="section2.7.3.1"></a>VM arguments</h4>
+ <p>Default max heap memory (Xmx) used by the APP4MC distribution is 2 GB. In case of migrating huge models, it is recommended to increase this memory to 4 GB before invocation of "AMALTHEA Model Migration" feature</p>
+ <p>Follow the below steps to increase the heap memory setting of APP4MC :</p>
+ <ul>
+ <li>Open
+ <strong>app4mc.ini</strong> file (
+ <em>present in the location where APP4MC is installed</em>) and change the parameter -Xmx from 2g to 4g. (
+ <em>
+ <strong>Note</strong>: In case if APP4MC plugins are integrated inside custom eclipse application, then corresponding <application_name>.ini file -Xmx parameter should be updated as specified below
+ </em>)
+ </li>
+ </ul>
+ <img class="gray_scale" src="images/vm_arguments_configuration.png"/>
+
+
+<h4 id="migration-uuid"><a id="section2.7.3.2"></a>Usage of UUID's instead of URI fragments inside AMALTHEA models</h4>
+ <p>It is recommended that AMALTHEA models (1.0.3 and 1.1.0 versions) have UUID's instead of Xpath like URI fragments for identifying the elements.</p>
+ <p>
+ <strong>
+ <em>Note:</em>
+ </strong> Default referencing mechanism within an EMF model or across models is to have Xpath like URI fragments (example : "//@stimuliModel/@stimuli.9") but this is not recommended when the model elements are modified through external mechanism (
+ <em>instead of standard EMF editors</em>) as it is quite challenging to update index order and references accordingly.
+ </p>
+ <p>
+ <strong>Model files generated by AMALTHEA (1.0.3) /Amalthea4Public (1.1.0) IDE contains UUID instead of Xpath like URI fragments. From Amalthea4Public (1.1.1), custom URI fragments are introduced which are based on the element names rather than index</strong>
+ </p>
+
+
+<h5><a id="section2.7.3.2.1"></a>How to identify if Xpath like URI fragments are used in AMALTHEA model files</h5>
+ <p>Open AMALTHEA model files in text editor </p>
+ <ul>
+ <li>search if xmi:id attribute is present for the tags</li>
+ <li>search for String : "//@" , if the search result consists of this kind of Strings
+ <code>"//@stimuliModel/@stimuli.9"</code>
+ </li>
+ </ul>
+ <p>If the results of "xmi:id" are false and "//@" are true, this means - > URI fragments are used in the AMALTHEA model files</p>
+
+
+<h5><a id="section2.7.3.2.2"></a>How to identify if UUID's are used in AMALTHEA model files</h5>
+ <p>Open AMALTHEA model files in text editor </p>
+ <ul>
+ <li>search if xmi:id attribute is present for the tags</li>
+ </ul>
+ <p>If model elements consists of xmi:id attributes for their identification and for referencing, model content looks like below: </p>
+ <p>
+ <code><calls xsi:type="sw:TaskRunnableCall" xmi:id="_FddJyEJsEeW3445fEkSwWQ" runnable="_FeWjyUJsEeW3445fEkSwWQ"/></code>
+ </p>
+
+
+<h5><a id="section2.7.3.2.3"></a>Update AMALTHEA models to use UUID's instead of Xpath like URI fragments</h5>
+ <p>Once it is identified that models contain Xpath like URI fragments, it is recommended to update them to have UUID's before invoking model migration.</p>
+ <p>For update of models to have UUID's, use one of the below plugin (depending on the model version) and execute it in the corresponding AMALTHEA distribution to which model is belonging to</p>
+ <table class="classic">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>AMALTHEA Model Version</strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>Utility plugin to convert URI Fragments to UUID's</strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">1.0.3</td>
+ <td colspan="1" rowspan="1"><div><a href="zip/1.0.3_org.itea2.amalthea.urifragments.converter.zip" shape="rect">download : 1.0.3 AMALTHEA models converter</a> </div></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">1.1.0</td>
+ <td colspan="1" rowspan="1"><div><a href="zip/1.1.0_org.itea2.amalthea.urifragments.converter.zip" shape="rect">download : 1.1.0 AMALTHEA models converter</a> </div></td>
+ </tr>
+ </table>
+ <p>Follow the below steps to convert URI Fragments to UUID's:</p>
+ <ol>
+ <li>Import the dowloaded utility plugin into corresponding AMALTHEA distribution <br><br>
+ <img class="gray_scale" src="images/import.png"/> <br><br>
+ <ul>
+ <li>Select the option "Existing Projects into Workspace" <br><br>
+ <img class="gray_scale" src="images/import_existing_projects.png"/> <br><br>
+ </li>
+ <li>Select the location of zip file (downloaded utility plugin) <br><br>
+ <img class="gray_scale" src="images/select_project_to_import.png"/> <br><br>
+ </li>
+ </ul>
+ </li>
+ <li>Open the models folder in the project - > remove the existing models and copy the models which should be updated for UUID's (
+ <em>It is important to have all the models and the dependent models copied with the same folder structure</em>) <br><br>
+ <img class="gray_scale" src="images/copy_models.png"/> <br><br>
+ </li>
+ <li>Configuring the copied models to be considered for UUID's updation : <br><br>
+ <img class="gray_scale" src="images/configuring_models_mwe2.png"/> <br><br>
+ </li>
+ <li>Executing workflow to update the Amalthea models : <br><br>
+ <img class="gray_scale" src="images/execute_workflow.png"/> <br><br>
+ </li>
+ <li>Updated model files (with UUID's) will overwrite the input models.
+ <strong>These model files should be used for model migration</strong>
+ </li>
+ </ol>
+ <p>
+ <strong>Special behavior</strong>
+ </p>
+ <p>During the UUID update process following behavior is performed:</p>
+ <ul>
+ <li>If AMALTHEA model elements are referring to Franca Interfaces, references are removed but the content of the reference is copied as CustomProperty for FInterfacePort element <br><br>
+ <img class="gray_scale" src="images/franca_interface_handling.png"/> <br><br>
+ </li>
+ </ul>
+
+
+<h3><a id="section2.7.4">2.7.4 </a>How to invoke AMALTHEA model migration</h3>
+ <p>AMALTHEA model migration utility is developed as a eclipse plugin and it is part of APP4MC distribution (
+ <em>from release 0.7.0</em>)
+ </p>
+ <p>Model migration utility can be invoked by selecting the required models to be migrated in the UI and specifying the target AMALTHEA version to which models should be migrated</p>
+ <ul>
+ <li>
+ <b>Step 1:</b> Selection of AMALTHEA models
+ </li>
+ </ul>
+ <p>
+ <img class="gray_scale" src="images/models_selection.png"/>
+ </p>
+ <ul>
+ <li>
+ <strong>Step 2:</strong> Opening AMALTHEA Model Migration dialog and configuring migration inputs
+ </li>
+ </ul>
+ <p>On click of AMALTHEA Model Migration action, selected files are parsed and the following information is retrieved:</p>
+ <ol>
+ <li>AMALTHEA model version to which model is belonging to</li>
+ <li>Referred AMALTHEA models inside the selected model (
+ <em>i.e. case of cross document references</em>)
+ <ul>
+ <li>AMALTHEA model version to which these models are belonging to</li>
+ </ul>
+ </li>
+ </ol>
+ <p>Once the above information is sucessfully retreived, following Model Migration dialog is opened:</p>
+ <p>
+ <img class="gray_scale" src="images/migration_dialog.png"/>
+ </p>
+ <p>Model Migration dialog consists of following information:</p>
+ <ol>
+ <li>Selected AMALTHEA model files : These are the models which are explicitly selected by the user</li>
+ <li>Model scope files : These are the model files which are referred in the models explicitly selected by the user <div>
+ <em>Example:</em> In the dialog shown above, mapping.amxmi is the file selected by the user, and it contains references to the model elements of : sw.amxmi, sw.amxmi-sw, default.amxmi-os. Due to this reason, all these referred models are selected implicitly for model migration <br>
+ <strong>
+ <em>Note:</em>
+ </strong> In case if the selected/referred models are having the different AMALTHEA model versions, migration can not be proceeded and the following error dialog is displayed <br>
+ <img class="gray_scale" src="images/different_model_versions.png"/> </div>
+ </li>
+ <li>Input model version : This is the AMALTHEA model version to which both selected & referred models are belonging to <br><div>
+ <strong>
+ <em>Note:</em>
+ </strong> AMALTHEA model versions are represented with the following naming convention in this dialog<br><table id="classic"><tr><td colspan="1" rowspan="1">AMALTHEA 1.0.3</td><td colspan="1" rowspan="1">itea.103</td></tr><tr><td colspan="1" rowspan="1">AMALTHEA4public 1.1.0</td><td colspan="1" rowspan="1">itea.110</td></tr><tr><td colspan="1" rowspan="1">AMALTHEA4public 1.1.1</td><td colspan="1" rowspan="1">itea.111</td></tr><tr><td colspan="1" rowspan="1">APP4MC 0.7.0</td><td colspan="1" rowspan="1">0.7.0</td></tr><tr><td colspan="1" rowspan="1">APP4MC 0.7.1</td><td colspan="1" rowspan="1">0.7.1</td></tr></table><br></div>
+ </li>
+ <li>Output model version : This is the AMALTHEA model version to which both selected & referred models should be migrated to</li>
+ <li>Output directory : This is the location where migrated AMALTHEA models should be generated. <div>
+ <strong>
+ <em>Note:</em>
+ </strong> <u>This option is available only if the specified output model version is 1.1.1 or higher.</u><br> In case of AMALTHEA model versions 1.0.3 and 1.1.0 - > Model scope is set as project, where as from version 1.1.1 and higher - > model scope is limited to a folder. Due to this reason below is the behavior of model migration utility : <ul><li>If the output model version is selected as 1.1.1 or higher - > <u>migrated models are generated in a single folder (due to scope restriction) specified by the user</u></li><li>If the output model version is selected as 1.1.0 - > <u>input model files will be overwritten by the migrated model files</u></li></ul></div>
+ </li>
+ </ol>
+ <ul>
+ <li>
+ <strong>Step 3:</strong> Model migration
+ </li>
+ </ul>
+ <p>Once the required parameters are configured in the model migration dialog, click on "Migrate Models" button in the dialog to invoke migration.</p>
+ <p>
+ <strong>Special cases:</strong>
+ </p>
+ <ul>
+ <li>
+ <strong>Handling of input model files with name in the following format :</strong> <model name>.amxmi-<sub model name> (
+ <em>Example: test.amxmi-sw</em>)
+ <ul>
+ <li>From 1.1.1 version, files of these extension are not recognized by the AMALTHEA loader as AMALTHEA models, due to this reason if such files are supplied as input to model migration utility - > generated files will be of following convention <model name>.amxmi-<sub model name>.amxmi (
+ <em>Example: test.amxmi-sw.amxmi</em>). <div>For details refer to the below image containing both input models and migrated models :<br>
+ <img class="gray_scale" src="images/generated_model_file_names.png"/></div>
+ </li>
+ </ul>
+ </li>
+ </ul>
+
+
+<h3><a id="section2.7.5">2.7.5 </a>Additional details</h3>
+ <p>For details regarding the below topics, refer to the corresponding links:</p>
+ <ol>
+ <li>
+ <a href="#metamodel-changes" shape="rect">How model elements are migrated across various versions ?</a>
+ </li>
+ <li>
+ <a href="#migration-uuid" shape="rect">How to update models to contain UUID ?</a>
+ </li>
+ <li>
+ <a href="#migration-vm-args" shape="rect">How to update max heap memory used by the application ?</a>
+ </li>
+ </ol>
+</article>
+
+
+<article>
+<h1><a id="section3">3 </a>Data Models</h1>
+
+
+<h2><a id="section3.1">3.1 </a>Data Model Overview</h2>
+ <p>The AMALTHEA data models are related to the activities in a typical design flow. The focus is on design, implementation and optimization of software for multicore systems. The data exchange between the activities is supported by the two main models of AMALTHEA, the System-Model and the Trace-Model.</p>
+ <p>
+ <img src="images/amalthea_models_actions.png"/>
+ </p>
+ <p>
+ <strong>Modeling</strong>
+ <br>The behavior of a component or system is often defined in the form of block diagrams or state charts. Dynamical behavior can also be formalized by differential equations that describe how the state of a system changes over time. Modeling tools like Matlab/Simulink, ASCET or Yakindu allow to simulate the model and to generate software descriptions and implementation.
+ </p>
+ <p>
+ <strong>Partitioning</strong>
+ <br>Based on the description of the software behavior (e.g. label accesses, synchronization, ...) this step identifies software units that can be executed in parallel.
+ </p>
+ <p>
+ <strong>System Modeling</strong>
+ <br>The structure of the hardware (e.g. cores, memory sizes, ...) and system constraints are added to the model.
+ <br>The constraints are limiting the possible results of the next step.
+ </p>
+ <p>
+ <strong>Optimization</strong>
+ <br>The activity of assigning executable software units to the cores and mapping data and instructions to memory sections. This step can be done manually or supported by a tool that optimizes the partitioning based on information about the software behavior (e.g. data dependencies, required synchronization, etc.).
+ </p>
+ <p>
+ <strong>Simulation / Software Execution</strong>
+ <br>In this step model-based simulation tools evaluate the timing behavior of the software.
+ <br>Typically these types of high level simulations are based on the hardware and software description of the system.
+ <br>Low level simulators (e.g. instruction set simulators) or real hardware can be used to execute existing software.
+ <br>The resulting traces provide additional data that is the basis for a more detailed analysis.
+ </p>
+ <p>A simplified picture shows the main purpose of the models.</p>
+ <p>
+ <img src="images/amalthea_models.png" style="width: 500px"/>
+ </p>
+ <p>The open AMALTHEA models allow custom tooling, interoperability of tools and the combination of different simulation or execution environments.</p>
+
+
+<h3><a id="section3.1.1">3.1.1 </a>AMALTHEA System Model</h3>
+ <p>
+ <img src="images/amalthea_system_model.png" style="width: 400px"/>
+ </p>
+ <p>The System Model contains:</p>
+ <p>
+ <strong>Hardware / ECU Description</strong>
+ <br>Hardware abstraction that includes general information about the hardware. Examples are: Number of cores, features of the cores, available memory, access times (from core x to memory y), etc.
+ </p>
+ <p>
+ <strong>SW Description</strong>
+ <br>The description contains information about the static or dynamic behavior the software. This includes: tasks, software components, interfaces, variables, types, etc. It is also possible to describe the characteristics of software functions like the access to variables (read, write, frequency) or the calls to service routines (call tree).
+ </p>
+ <p>
+ <strong>Timing Constraints</strong>
+ <br>Timing Constraints like End-to-End Delay, Latency and Synchronization can be formally written in the "TIMMO Timing Augmented Description Language" (TADL). They are derived from timing requirements or control theory.
+ </p>
+ <p>
+ <strong>Mapping Constraints</strong>
+ <br>The different cores of a typical embedded multicore ECU have different features. For optimal performance it is necessary to restrict the assignment of some software functions to e.g. cores with fastest I/O connections or the maximum clock rate. For safety reasons it is required that some functions are located on specific cores that e.g. can run in lock step mode. Constraints like this are represented in this sub model.
+ </p>
+ <p>
+ <strong>SW Mapping</strong>
+ <br>All information about the assignment of software units (e.g. tasks or runnables) to the cores and about the mapping of data and instructions to memory sections.
+ </p>
+
+
+<h3><a id="section3.1.2">3.1.2 </a>AMALTHEA Trace Model</h3>
+ <p>There is no specific EMF data model to describe event traces. The relevant events and their states are represented in the Event Model. In addition special trace formats for multicore have been specified in the AMALTHEA project and a Trace Database has been implemented. This database stores traces in a way that allows fast retrieval of the information (see the Developer Guide for a detailed description of the database structure).</p>
+
+
+<h3><a id="section3.1.3">3.1.3 </a>Structure of the model</h3>
+ <p>The definition of the AMALTHEA data model follows some basic principles:</p>
+ <ul>
+ <li>The model is defined in one package to simplify the handling (e.g. allow opposite references).</li>
+ <li>Different aspects are addressed in different logical sub models.</li>
+ <li>Existing EMF models from other Eclipse projects are reused and referenced instead of creating own definitions.</li>
+ <li>References are based on unique names within the same type of element.</li>
+ </ul>
+ <p>We also try to use cycles wherever possible and needed instead of direct time information. This has advantages in a multi-core environment, as the cores could have different clock frequencies.</p>
+ <p>The following figure shows the different logical parts of the AMALTHEA data model and how they are referencing each other. The central AMALTHEA model and common model that contains reusable elements are drawn without connections in this diagram.</p>
+ <p>
+ <img src="images/model_dependencies.png"/>
+ </p>
+
+
+<h2><a id="section3.2">3.2 </a>Common Model</h2>
+ <p>The AMALTHEA common model is not a model by itself, but provides standard elements used by other models as containments.</p>
+
+
+<h3><a id="section3.2.1">3.2.1 </a>Common Elements</h3>
+ <p>
+ <img src="images/model_common_elements.png"/>
+ </p>
+
+
+<h3 id="common-tags"><a id="section3.2.2">3.2.2 </a>Tags</h3>
+ <p>
+ <img src="images/model_common_tag.png"/>
+ </p>
+
+
+<h3 id="common-custom-props"><a id="section3.2.3">3.2.3 </a>Custom Properties</h3>
+ <p>The
+ <i>CustomProperty</i> element is used to define own, in AMALTHEA not available properties. If there is the need to extend an element or to store tool information related to processing steps,
+ <i>CustomProperties</i> can be used to store this type of information.
+ </p>
+ <p>
+ <img src="images/model_common_custom_property.png"/>
+ </p>
+ <p>The elements are stored in a
+ <i>HashMap</i>. The values can be of different types as shown in the structure picture, like String, Integer, Boolean...
+ <br>In addition a
+ <i>ReferenceObject</i> is available to store own references to other
+ <i>EObject</i> elements.
+ <br>The
+ <i>ListObject</i> can be used to store multi-valued custom properties.
+ </p>
+ <p>
+ <img class="scale" src="images/model_common_custom_property_value.png"/>
+ </p>
+
+
+<h3><a id="section3.2.4">3.2.4 </a>Time (and Time Unit)</h3>
+ <p>The AMALTHEA data model includes two common elements to describe time ranges in an easy way, the
+ <i>Time</i> and
+ <i>SignedTime</i> element. The
+ <i>SignedTime</i> is like the general
+ <i>Time</i> class but explicit allows defining negative time values.
+ <br>These elements can be referenced by any other element for specifying attributes to store time information.
+ <br>Time units are needed to describe different timing behavior and requirements, like deadlines or offsets of components.
+ <br>To support different time ranges, especially different time units, AMALTHEA predefines these types like seconds, milli-seconds, micro-seconds, nano-seconds or pico-seconds.
+ </p>
+ <p>
+ <img class="scale" src="images/model_common_time.png"/>
+ </p>
+
+
+<h3><a id="section3.2.5">3.2.5 </a>Frequency (and Frequency Unit)</h3>
+ <p>
+ <img class="scale" src="images/model_common_frequency.png"/>
+ </p>
+
+
+<h3><a id="section3.2.6">3.2.6 </a>Data Size (and Data Size Unit)</h3>
+ <p>The
+ <i>DataSize</i> (and
+ <i>DataRate</i>) definition contains units and prefixes
+ </p>
+ <ul>
+ <li>according to the SI Standard</li>
+ <li>for binary multiples</li>
+ </ul><table>
+ <tr>
+ <th colspan="1" rowspan="1" style="padding:15px">International System of Units (SI)</th>
+ <th colspan="1" rowspan="1" style="padding:15px">Prefixes for binary multiples</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1" style="vertical-align:top; padding:15px">
+ <table class="classic">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <em>
+ <strong>Name</strong>
+ </em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>
+ <strong>Prefix</strong>
+ </em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>
+ <strong>Factor</strong>
+ </em>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">kilo</td>
+ <td colspan="1" rowspan="1">k</td>
+ <td colspan="1" rowspan="1">10<sup>3</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">mega</td>
+ <td colspan="1" rowspan="1">M</td>
+ <td colspan="1" rowspan="1">10<sup>6</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">giga</td>
+ <td colspan="1" rowspan="1">G</td>
+ <td colspan="1" rowspan="1">10<sup>9</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">tera</td>
+ <td colspan="1" rowspan="1">T</td>
+ <td colspan="1" rowspan="1">10<sup>12</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <em>peta</em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>P</em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>10<sup>15</sup></em>
+ </td>
+ </tr>
+ </table></td>
+ <td colspan="1" rowspan="1" style="vertical-align:top; padding:15px">
+ <table class="classic">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <em>
+ <strong>Name</strong>
+ </em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>
+ <strong>Prefix</strong>
+ </em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>
+ <strong>Factor</strong>
+ </em>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">kibi</td>
+ <td colspan="1" rowspan="1">Ki</td>
+ <td colspan="1" rowspan="1">2<sup>10</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">mebi</td>
+ <td colspan="1" rowspan="1">Mi</td>
+ <td colspan="1" rowspan="1">2<sup>20</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">gibi</td>
+ <td colspan="1" rowspan="1">Gi</td>
+ <td colspan="1" rowspan="1">2<sup>30</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">tebi</td>
+ <td colspan="1" rowspan="1">Ti</td>
+ <td colspan="1" rowspan="1">2<sup>40</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">pebi</td>
+ <td colspan="1" rowspan="1">Pi</td>
+ <td colspan="1" rowspan="1">2<sup>50</sup></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <em>exbi</em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>Ei</em>
+ </td>
+ <td colspan="1" rowspan="1">
+ <em>2<sup>60</sup></em>
+ </td>
+ </tr>
+ </table></td>
+ </tr>
+ </table>
+ <p>The
+ <i>DataSize</i> provides convenience methods to get the size also in bit and byte.
+ <br>It is internally converted and can be retrieved in both ways.
+ </p>
+ <p>
+ <img class="scale" src="images/model_common_data_size.png"/>
+ </p>
+
+
+<h3><a id="section3.2.7">3.2.7 </a>Data Rate (and Data Rate Unit)</h3>
+ <p>
+ <img class="scale" src="images/model_common_data_rate.png"/>
+ </p>
+
+
+<h3><a id="section3.2.8">3.2.8 </a>Deviation</h3>
+ <p>The
+ <i>Deviation</i> class is used to model statistical distributions within AMALTHEA. There is a wide variety of possible use cases, where such a distribution is needed. With such a deviation for example, the variation in run times of functions or respectively their instructions can be imitated. Therefore, AMALTHEA currently supports the following three statistical distributions:
+ </p>
+ <p>
+ <img class="scale" src="images/model_common_deviation.png"/>
+ </p>
+
+
+<h4><a id="section3.2.8.1"></a>Boundaries</h4>
+ <p>With the
+ <i>Boundaries</i> class it is possible to define the deviation of instructions in such a way that a specific scenario is covered. The scenario is on the one hand specified by the minimum and maximum value between which the instructions vary. On the other hand, the
+ <i>Sampling Type</i> specifies the specific scenario that is covered. The following sampling types are available which are visualised in the figures below:
+ </p>
+ <dl>
+ <dt>BestCase</dt>
+ <dd>Defines the scenario in which most instances should have runtimes close to the set minimum runtime, but still should consider some more time-consuming outliers up to the set maximum.</dd>
+ <dt>WorstCase</dt>
+ <dd>Defines the scenario in which most instances should have runtimes close to the set maximum runtime, but still should consider some less time-consuming outliers down to the set minimum.</dd>
+ <dt>AverageCase</dt>
+ <dd>Defines the scenario in which most instances should have runtimes close to the middle between the set minimum and maximum, but still should consider some less and more time-consuming outliers down to the set minimum or up to the set maximum respectively.</dd>
+ <dt>CorenerCase</dt>
+ <dd>Defines the scenario in which most instances should have runtimes close to the set minimum and maximum runtime, but still should consider some other time-consuming outliers between those two.</dd>
+ <dt>Uniform</dt>
+ <dd>Defines the scenario in which all instances should have runtimes that are uniformly distributed between the set minimum and maximum.</dd>
+ </dl>
+ <p>
+ <img src="images/model_common_deviation_boundaries_1.png"/>
+ </p>
+ <p>
+ <img src="images/model_common_deviation_boundaries_2.png"/>
+ </p>
+
+
+<h4><a id="section3.2.8.2"></a>Uniform Distribution</h4>
+ <p>The uniform distribution is a statistical distribution where the values between the stated lower and upper bound are equally likely to be observed.</p>
+ <p>
+ <img src="images/model_common_deviation_uniform.png"/>
+ </p>
+
+
+<h4><a id="section3.2.8.3"></a>Gaussian/Normal Distribution</h4>
+ <p>The Gaussian/normal distribution is a statistical distribution where the values decrease symmetrically. The maximum value and thus its location is thereby stated by the mean and the rate of decrease is defined by its standard deviation. Since the curves approach zero on either side, an additional upper and lower bound can be added to constraint the values.</p>
+ <p>
+ <img src="images/model_common_deviation_normal.png"/>
+ </p>
+
+
+<h4><a id="section3.2.8.4"></a>Beta Distribution</h4>
+ <p>The Beta distribution is a statistical distribution whose shape is defined by alpha > 0 and beta > 0. That way, the Beta distribution can also be used to model other distributions like for example uniform, normal, or Bernoulli distribution. Since the curves can approach zero or infinity on either side, an additional upper and lower bound can be added to constraint the values.</p>
+ <p>
+ <img src="images/model_common_deviation_beta.png"/>
+ </p>
+
+
+<h4><a id="section3.2.8.5"></a>Weibull Distribution</h4>
+ <p>The Weibull distribution is a statistical distribution whose shape is defined by kappa > 0 and the scale of the distribution by lambda > 0. That way, the Weibull distribution can also be used to model other distributions like for example the exponential or normal distribution. Since the curves can approach zero or infinity on either side, an additional upper and lower bound can be added to constraint the values. Alternatively, the Weibull distribution can also be parameterized using the mean value and a parameter that constraints the distribution regarding the per mill of remaining values.</p>
+ <p>
+ <img src="images/model_common_deviation_weibull.png"/>
+ </p>
+
+
+<h3><a id="section3.2.9">3.2.9 </a>Statistic Elements</h3>
+ <p>The contained elements are representing statistical values.
+ <br>The values can be set either with a min, avg and max representation using the
+ <i>MinAvgMaxStatistic</i> element.
+ <br>The other possibility is to set a single value using the
+ <i>SingleValueStatistic</i> element.
+ <br>The values itself are set as a normal
+ <i>int</i> value or in case of the single value as
+ <i>float</i>.
+ </p>
+ <p>
+ <img src="images/model_common_statistic.png"/>
+ </p>
+
+
+<h3><a id="section3.2.10">3.2.10 </a>Instructions</h3>
+ <p>Instructions are used to express execution times in a more abstract way. The number of instructions characterizes the amount of computation that is necessary to execute e.g. a
+ <i>Runnable</i>. Depending on the capabilities of a
+ <i>Core</i> (the frequency and the instructions per cycle) the time to execute such an element will differ.
+ </p>
+ <p>In the next picture a more detailed overview is given about the
+ <i>Instructions</i>.
+ </p>
+ <p>
+ <img src="images/model_common_instructions.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>Instructions</i>
+ </td>
+ <td colspan="1" rowspan="1">As a runnable contains several instructions to perform, this is represented using different algorithms or a constant value to consume the same amount of time/ticks per cycle.</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.2.11">3.2.11 </a>Counters</h3>
+ <p>The
+ <i>Counter</i> element describes an activation of a target element that happens only every n<sup>th</sup> time.
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>prescaler</i>
+ </td>
+ <td colspan="1" rowspan="1">Gives the number n for the activation,<br>e.g. if set to 2, the target element is executed every second time.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>offset</i>
+ </td>
+ <td colspan="1" rowspan="1">Initial shift for the first execution of the target.</td>
+ </tr>
+ </table>
+ <p>If for example
+ <i>prescaler</i> is 5 and
+ <i>offset</i> is 2 it is executed on the 2<sup>nd</sup>, 7<sup>th</sup>, 12<sup>th</sup>, … time.
+ </p>
+ <p>Counters are available at the following elements:</p>
+ <ul>
+ <li>Call sequence items:
+ <ul>
+ <li>
+ <i>ClearEvent</i>
+ </li>
+ <li>
+ <i>EnforcedMigration</i>
+ </li>
+ <li>
+ <i>InterProcessActivation</i>
+ </li>
+ <li>
+ <i>SchedulePoint</i>
+ </li>
+ <li>
+ <i>SetEvent</i>
+ </li>
+ <li>
+ <i>TaskRunnableCall</i>
+ </li>
+ <li>
+ <i>TerminateProcess</i>
+ </li>
+ <li>
+ <i>WaitEvent</i>
+ </li>
+ </ul>
+ </li>
+ <li>Stimuli:
+ <ul>
+ <li>
+ <i>InterProcess</i>
+ </li>
+ <li>
+ <i>EventStimulus</i>
+ </li>
+ </ul>
+ </li>
+ </ul>
+
+
+<h2><a id="section3.3">3.3 </a>Components Model</h2>
+ <p>The AMALTHEA component model is central accessible through the
+ <i>ComponentsModel</i> element.
+ </p>
+ <p>It holds the following types:</p>
+ <ul>
+ <li>
+ <strong>Component</strong> /
+ <strong>Composite</strong> ('components' containment reference)
+ </li>
+ <li>
+ <strong>System</strong> ('systems' containment reference)
+ </li>
+ <li>
+ <strong>Tag</strong> ('tags' containment reference)
+ </li>
+ </ul>
+ <p>
+ <img class="scale" src="images/model_components.png"/>
+ </p>
+
+
+<h3><a id="section3.3.1">3.3.1 </a>Components Model Elements</h3>
+ <p>The elements of the Components Model inherit several capabilities from common elements.</p>
+ <p>
+ <img class="scale" src="images/model_components_common.png"/>
+ </p>
+ <p>Ports, Components, Composites and ComponentInstances are referable by unique names.
+ <br>A Connector also has a name but the name is optional and does not have to be unique.
+ </p>
+
+
+<h4><a id="section3.3.1.1"></a>Component</h4>
+ <p>The 'Component' class represents a component. Components could be created directly within the 'ComponentModel' and are used as a type for a component instance.</p>
+ <p>
+ <img class="scale" src="images/model_components_component_references.png"/>
+ </p>
+ <p>It contains several ports of type 'Port'. A component refers the classes 'OsEvent', 'Label', 'Runnable' and 'AbstractProcess' from the software model and the class 'Semaphore' from the OS model.</p>
+
+
+<h4><a id="section3.3.1.2"></a>System and Composite</h4>
+ <p>Systems are defined as top level elements within a component model. A system contains several Component- and
+ <br>Connection-instances and is used to define the architecture of a technical system.
+ </p>
+ <p>A 'Composite' is a special component type to aggregate Component- and Connection-instances compositely.
+ <br>So it could be used to create hierarchical component structures.
+ </p>
+ <p>System and Composite implement the interface 'ISystem'.
+ <br>The following diagram shows the main elements to represent the hierarchical structure.
+ </p>
+ <p>
+ <img src="images/model_components_isystem.png"/>
+ </p>
+ <p>In general each inner port should be connected. If a port is intentionally left unconnected it has to be added to the list of 'groundedPorts'.</p>
+
+
+<h4><a id="section3.3.1.3"></a>ComponentInstance and Connector</h4>
+ <p>The 'ComponentInstance' and the 'Connector' can be created within a 'System' or a 'Composite'. 'ComponentInstances' are used to represent instances of component- or composite-types. The 'Connector' class is used to connect the component instances to each other via their Ports. The connector contains a source and target 'QualifiedPort'.</p>
+
+
+<h4><a id="section3.3.1.4"></a>QualifiedPort</h4>
+ <p>A 'qualified' port refers a 'ComponentInstance' and a 'Port'.
+ <br>If the 'instance' link is null then the QualifiedPort refers to a port of the enclosing composite.
+ </p>
+
+
+<h4><a id="section3.3.1.5"></a>FInterfacePort</h4>
+ <p>The 'FInterfacePort' class contains the attribute 'kind' to set the port direction ('provides' or 'requires').
+ <br>The attribute 'interface name' can be used to refer to an external definition, e.g. described in detail with the Franca IDL.
+ </p>
+
+
+<h3><a id="section3.3.2">3.3.2 </a>Example</h3>
+
+
+<h4><a id="section3.3.2.1"></a>Diagram</h4>
+ <p>The diagram of the example shows a composite 'A' that contains two component instances 'X' and 'Y' of type 'B'. The connections between the ports are named 'c1' to 'c4'. The grounded port 'in_3' of instance 'X' (intentionally left unconnected) is marked green. The second unconnected port 'in_2' of instance 'Y' is unspecified. It is marked red and has to be changed, either declared as grounded or connected to another port. </p>
+ <p>
+ <img src="images/model_components_example.png"/>
+ </p>
+
+
+<h4><a id="section3.3.2.2"></a>Model Editor</h4>
+ <p>The same example is shown in the standard AMALTHEA editor.</p>
+ <p>
+ <img src="images/model_components_example_treeview.png"/>
+ </p>
+
+
+<h3><a id="section3.3.3">3.3.3 </a>Franca IDL</h3>
+ <p>Franca is a common interface definition language (IDL). The initial version has been developed by the GENIVI consortium as part of the standardization of an In-Vehicle Infotainment (IVI) platform. The first public version of Franca was released in 2012 under the Eclipse Public License. The future development of Franca will take place in an official Eclipse project under the Eclipse Modeling Top-level Project.</p>
+ <p>The Franca IDL files can be edited in a textual editor that is provided by Franca. </p>
+ <p>
+ <img src="images/model_franca_editor_screenshot.png"/>
+ </p>
+ <p>AMALTHEA ports can specify the 'interface name' to refer to interfaces in Franca.</p>
+ <p>
+ <img src="images/model_components_franca_idl.png"/>
+ </p>
+
+
+<h2><a id="section3.4">3.4 </a>Configuration Model</h2>
+ <p>The purpose of the configuration model is to provide a common mechanism for configuration purpose.
+ <br>The included configurations can contain elements for further processing or build steps.
+ </p>
+ <p>The central element is the
+ <i>ConfigModel</i> class.
+ </p>
+ <p>Currently the only configuration object is
+ <i>EventConfig</i>.
+ </p>
+ <p>
+ <img src="images/model_config_overview.png"/>
+ </p>
+
+
+<h3><a id="section3.4.1">3.4.1 </a>Event Configuration</h3>
+ <p>The event configuration represents target events to trace, either in a simulation or on a target hardware platform. The
+ <i>EventConfig</i> elements are contained in the ConfigModel class as list with the name
+ <i>eventsToTrace</i>. Attributes of
+ <i>EventConfig</i> are:
+ </p>
+ <ol>
+ <li>
+ <i>name</i>: (optional) name of the element
+ </li>
+ <li>
+ <i>event</i>: reference to an existing events in the
+ <i>Events</i> model
+ </li>
+ </ol>
+
+
+<h4><a id="section3.4.1.1"></a>Sample</h4>
+ <p>An example use case can be to trace all
+ <i>Process</i> activate events. To express this in the configuration, one contained element must be of type
+ <i>EventConfig</i> with the corresponding
+ <i>Event</i> pointing to an already existent element. The
+ <i>Event</i> is of type
+ <i>ProcessEvent</i> and the
+ <i>ProcessEventType</i> is set to
+ <i>activate</i>. The other attributes are left blank to not limit the configuration to one
+ <i>Process</i> with a given name for example.
+ </p>
+ <p>The consumer of the configuration must then match and filter the relevant elements for further processing.</p>
+ <p>The following screenshot is showing this minimal configuration.</p>
+ <p>
+ <img src="images/model_config_sample.png"/>
+ </p>
+
+
+<h2><a id="section3.5">3.5 </a>Constraints Model</h2>
+ <p>The constraints model contains different kind of constraints. There are the runnable-sequencing-constraints that can be used to define a required order for the runnables of the Software Model, the affinity constraints for defining the constraints for the mapping of runnables, processes and schedulers, and the timing constraints for restricting the time span between events or the duration of event chains. Regarding to that, it is also possible to define event chains in this model. </p>
+ <p>
+ <img src="images/model_constraints.png"/>
+ </p>
+
+
+<h3><a id="section3.5.1">3.5.1 </a>Requirements</h3>
+ <p>The Requirements are used to specify quality requirements for the dynamic architecture.
+ <br>Requirements are divided into the following types depending on the entity type for which the requirement is specified:
+ </p>
+ <ul>
+ <li>Architecture Requirements for components</li>
+ <li>Process Chain Requirements for process chains</li>
+ <li>Process Requirements for tasks and isrs</li>
+ <li>Runnable Requirements for runnables</li>
+ </ul>
+ <p>The Severity attribute is used to describe the quality impact if the requirement is not fulfilled.
+ <br>The Limit defines the metric, the value and if the value for the metric is an upper limit or a lower limit.
+ <br>Depending on the metric unit, the following Limits can be specified
+ </p>
+ <ul>
+ <li>Count Requirement Limit for metrics like
+ <i>Preemptions</i>
+ </li>
+ <li>CPU Percentage Requirement Limit for metrics like
+ <i>CPULoad</i>
+ </li>
+ <li>Frequency Requirement Limit for metrics like
+ <i>CacheMissFrequency</i>
+ </li>
+ <li>Percentage Requirement Limit for metrics like
+ <i>OsOverheadRelative</i>
+ </li>
+ <li>Time Requirement Limit for metrics like
+ <i>ResponseTime</i>
+ </li>
+ </ul>
+ <p>
+ <img class="scale" src="images/model_constraints_requirements.png"/>
+ </p>
+ <p>An example for a requirement is the Deadline for a task. The Deadline is specified by an upper limit for the response time of the respective task.</p>
+
+
+<h3><a id="section3.5.2">3.5.2 </a>Runnable Sequencing Constraints</h3>
+ <p>These constraints can be used to define execution orders of runnables, or in other words, the dependencies between runnables. These dependencies can result from data exchange or any functional dependency, which is not necessarily visible by other model parameter.</p>
+ <p>The following requirements can be specified with this constraint:</p>
+ <ul>
+ <li>Execution sequence of runnables A->B, meaning A has to be finished before B starts</li>
+ <li>Scope on certain process(es), when a runnable is executed multiple times in different process contexts</li>
+ <li>Binding of runnables within a process (loosely, strict)</li>
+ <li>Position, where sequence should start (start sequence), end (end sequence) or at any position</li>
+ <li>Occurrence attribute for multiple preceding/succeeding runnables (all or at least one)</li>
+ </ul>
+ <p>A
+ <i>RunnableSequencingConstraint</i> contains a list of
+ <i>ProcessRunnableGroup</i> elements and an enumeration describing the basic rule for the sequencing. Each runnable group collects references to the runnables that should be sequenced. The sequence is defined by the order of the runnable groups within the sequencing constraint. The order of the runnables references within a group is unimportant. To sequence two runnables it is necessary to create the
+ <i>RunnableSequencingConstraint</i> and two
+ <i>ProcessRunnableGroups</i>, each referencing a runnable.
+ </p>
+ <p>It is possible to describe that a set of runnables have to be executed before or after another runnable or set of runnables. For that it is possible to put more than one runnable reference in a group. As already mentioned, the order of the referenced runnables within a
+ <i>ProcessRunnableGroup</i> is unimportant.
+ </p>
+ <p>The
+ <i>RunnableOrderType</i> provides different sequencing modes. The mode "loose binding" allows the execution of runnables (that are not part of the constraint) between the runnables of the sequencing-constraint. In addition to that, the option "lose binding & unspecified start runnable" allows to start with any runnable from the sequence, but the sequence itself must not be violated.
+ </p>
+ <p>The "strict binding" option is the opposite of "loose binding". It says that the runnables must execute in direct order, without any interrupt by another runnable. With "start-", "any-" and "end sequence" it can be defined if the runnables of the constraint should be executed at the start, at the end or at any position in the process. </p>
+ <p>A runnable-sequencing-constraint is independent of the processes that are executing the runnables. With a scope it is possible to define that a sequencing-constraint checks only the runnables of a set of processes or just one process. The scope can be defined individually for each runnable.</p>
+ <p>
+ <img src="images/model_constraints_runnable_sequencing.png"/>
+ </p>
+ <p>The following picture shows a
+ <i>RunnableSequencingConstraint</i>. The constraint has two runnable groups, visualized by the circles. In this case there is just one runnable in each group.
+ <br>The runnables in the group must be executed in the order of the group. Basically there is no restriction on which core or process the runnables are executed. It is important that the order is correct, and that the runnable of one group terminates before the runnable of the next group starts.
+ </p>
+ <p>
+ <img src="images/model_constraints_runnable_sequencing_basic.png"/>
+ </p>
+ <p>The
+ <i>RunnableSequencingConstraint</i> in this figure has two processes as a scope in its second group. That means that the runnable "R3" is allowed to be executed on the processes "P1" and "P3". But it is only expected one time!
+ </p>
+ <p>
+ <img src="images/model_constraints_runnable_sequencing_scope.png"/>
+ </p>
+ <p>Each runnable-sequencing-constraint has a runnable-order-type.
+ <br>This type can be:
+ </p>
+ <ul>
+ <li>loose binding</li>
+ <li>loose binding & unspecified start runnable</li>
+ <li>strict binding & any sequence</li>
+ <li>strict binding & start sequence</li>
+ <li>strict binding & end sequence</li>
+ </ul>
+ <p>The meaning of "loose binding" is that the runnables of a constraint do not have to follow each other directly, they can be also separated by other runnables that are not part of the sequencing-constraint.
+ <br>"Unspecified start runnable" means that the order of runnables must be fulfilled (this is always the case) but it does not matter which of the runnables is the runnable to start with.
+ <br>So with an "unspecified start runnable" the sequence can be:
+ </p>
+ <ul>
+ <li>"R1" -> "R3" -> "R4" </li>
+ <li>"R3" -> "R4" -> "R1"</li>
+ <li>"R4" -> "R1" -> "R3"</li>
+ </ul>
+ <p>The opposite of loose binding is strict binding. It means that, if the runnables are executed within the same process, they have to be executed directly after each other. It is not allowed that other runnables than the sequencing runnables execute within this sequence.
+ <br>The mode "start sequence" means that the first runnable has to be at the beginning of its process. Assuming that all runnables are executed on the same processes, the combination "strict binding & start sequence" means that all runnables of the constraint have to be executed in the correct order at the beginning of the process.
+ <br>The mode "end sequence" is like "start sequence" but here the last runnable must be executed at the end of the last process of the runnable sequence.
+ </p>
+
+
+<h3><a id="section3.5.3">3.5.3 </a>Data Age Constraints</h3>
+ <p>Data Age constraints are used to define when the information in a label becomes valid or invalid after its last update. Therefore a runnable and a label has to be set. The information update occurs when the runnable performs a write access on the label. It is possible to define the minimum time after the information of a label update becomes valid. This means that the information shall not be used for further calculations before this time is over. The maximum time on the other hand defines the time after the label update when the information becomes invalid. Beside of time it is possible to define a minimum and maximum cycle. The cycle is related to the activation of the process that executes the runnable. </p>
+ <p>
+ <img src="images/model_constraints_data_age.png"/>
+ </p>
+
+
+<h3><a id="section3.5.4">3.5.4 </a>Data Coherency Groups</h3>
+ <p>A
+ <i>DataCoherencyGroup</i> is used to define data coherency requirements for a group of labels.
+ <br>The Direction hereby is used to specify if the labels have to be read or written coherently. Moreover, the scope attribute defines the context of the coherent read or write requirement. Possible scopes are components, processes, and runnables.
+ </p>
+ <p>
+ <img src="images/model_constraints_data_coherency.png"/>
+ </p>
+
+
+<h3><a id="section3.5.5">3.5.5 </a>Data Stability Groups</h3>
+ <p>A
+ <i>DataStabilityGroup</i> is used to define that the values of labels have to be kept stable within a given execution context.
+ <br>Currently, the following execution contexts are covered by the scope:
+ </p>
+ <ul>
+ <li>Component</li>
+ <li>Process</li>
+ <li>Runnable</li>
+ </ul>
+ <p>This means, that it has to be guaranteed that the values of labels are identical either within the runnable, the process, or the component in which the denoted labels are accessed.</p>
+ <p>
+ <img src="images/model_constraints_data_stability.png"/>
+ </p>
+
+
+<h3><a id="section3.5.6">3.5.6 </a>Event Chains</h3>
+ <p>The concept for event chains is based on the Timing Augmented Description Language.
+ <br>The Timing Augmented Description Language (TADL) is coming from the
+ <a href="https://itea3.org/project/timmo-2-use.html" shape="rect">TIMMO-2-USE </a> project.
+ </p>
+ <p>
+ <img src="images/model_constraints_eventchain.png"/>
+ </p>
+ <p>The
+ <i>EventChain</i> consists of
+ <i>EventChainItems</i>. These items are classified in two types:
+ </p>
+ <ol>
+ <li>SubEventChains: Inner anonymous EventChains, which are only defined once and has no global meaning, but only in the context of the current defined EventChain.</li>
+ <li>EventChainReference: Used to reference already global defined EvenChains in the root list of the model.</li>
+ </ol>
+ <p>An Event Chain object references always two events, a stimulus event and a response event. To define a simple event chain that just contains two events, one event chain object is enough. In this case it would just be a chain that with its stimulus as first event and the response as second event.
+ <br>If more events are required it is necessary to add sub event chains. The stimulus is always the first event of an event chain, the response is always the last event. The events that are defined in the sub event chains are the events in between.
+ </p>
+ <p>The picture below shows a simple example for an event chain of four events in a row.
+ <br>The top level chain defines the first event (E1) and the last event (E4).
+ <br>It contains a number of event chains. They describe the way from E1 to E4.
+ <br>These sub event chains are added as
+ <i>strands</i> to the parent.
+ <br>For this some rules has to be considered:
+ <br>The stimulus of the first child event chain has to be the same as the stimulus of the parent (red in picture).
+ <br>The stimulus of other child event chains have to be equal to the response of the previous chain (blue in picture).
+ <br>The response of the last child event chain has to be the same as the response of the parent (green in picture).
+ </p>
+ <p>
+ <img src="images/model_constraints_eventchain_segments.png" style="width: 500px"/>
+ </p>
+ <p>As a stimulus or response event it is either possible to use an Entity Event or an Event Set.
+ <br>An Entity Event is a single event regarding to an entity like a task or a runnable. So it can be e.g. the start of a runnable.
+ <br>If a set of events is used, then all events of this group must occur fulfill the event chain. The order in which the events occur is not important.
+ </p>
+ <p>
+ <img src="images/model_constraints_eventchain_eventgroups.png"/>
+ </p>
+
+
+<h3><a id="section3.5.7">3.5.7 </a>Timing Constraints</h3>
+
+
+<h4><a id="section3.5.7.1"></a>Synchronization Constraints</h4>
+ <p>An
+ <i>EventSynchronizationConstraint</i> describes how tightly the occurrences of a group of events follow each other.
+ <br>There must exist a sequence of time windows of width tolerance, such that every occurrence of every event in events belongs to at least one window, and every window is populated by at least one occurrence of every event.
+ <br>The parameter
+ <i>multipleOccurrencesAllowed</i> defines, whether for the constraint all occurrences have to be considered or just the subsequent ones.
+ </p>
+ <p>An
+ <i>EventChainSynchronizationConstraint</i> describes how tightly the occurrences of an event chain follow the occurrences of a different event chain.
+ <br>The
+ <i>SynchronizationType</i> defines which parts of the event chains have to be in sync, stimulus or response, and the width of a time window sets the allowed tolerance.
+ <br>The parameter
+ <i>multipleOccurrencesAllowed</i> defines, whether for the constraint all occurrences have to be considered or just the subsequent ones.
+ </p>
+ <p>
+ <img src="images/model_constraints_timing_sync.png"/>
+ </p>
+
+
+<h4><a id="section3.5.7.2"></a>Repetition Constraint</h4>
+ <p>A
+ <i>RepetitionConstraint</i> describes the distribution of the occurrences of a single event, including jitter.
+ <br>Every sequence of span occurrences of event must have a length of at least lower and at most upper time units.
+ </p>
+ <p>
+ <img src="images/model_constraints_timing_repetition.png"/>
+ </p>
+
+
+<h4><a id="section3.5.7.3"></a>Delay Constraint</h4>
+ <p>A Delay Constraint imposes limits between the occurrences of an event called source and an event called target.
+ <br>Every instance of source must be matched by an instance of target, within a time window starting at lower and ending at upper time units relative to the source occurrence.
+ <br>In addition, a
+ <i>MappingType</i> defines whether there is a strong (
+ <i>OneToOne</i> ), neutral (
+ <i>Reaction</i> ), or weak (
+ <i>UniqueReaction</i> ) delay relation between the events.
+ </p>
+ <p>
+ <img src="images/model_constraints_timing_delay.png"/>
+ </p>
+
+
+<h4><a id="section3.5.7.4"></a>Event Chain Latency Constraint</h4>
+ <p>An
+ <i>EventChainLatencyConstraint</i> defines how long before before each response a corresponding stimulus must have occurred (
+ <i>Age</i> ), or how long after a stimulus a corresponding response must occur (
+ <i>Reaction</i> ).
+ <br>It always refers to an EventChain.
+ </p>
+ <p>
+ <img src="images/model_constraints_timing_latency.png"/>
+ </p>
+
+
+<h3><a id="section3.5.8">3.5.8 </a>Affinity Constraints</h3>
+ <p>Affinity constraints are used to define the mapping of executable objects to each other.
+ <br>The objects that can be mapped are:
+ </p>
+ <ul>
+ <li>Runnables</li>
+ <li>Processes (Task or ISR)</li>
+ <li>Labels</li>
+ </ul>
+ <p>
+ <img src="images/model_constraints_affinity.png"/>
+ </p>
+ <p>An affinity constraint can either be a pairing or a separation constraint. A pairing constraint contains one amount of objects and a target. The pairing constraints say "All these objects must run together on this target". A separation constraint contains two groups of objects and a target. It says "This group of objects is not allowed to be mapped with the other group of objects on the specific target". So the separation constraint can be used to forbid a combination of objects on a target. It can also be used to say "These objects are not allowed to be mapped on this target". In this case only one group of the separation constraint is used.</p>
+ <p>Each affinity constraint has one or more targets. The type of the target depends on the type that should be mapped.</p>
+
+
+<h4><a id="section3.5.8.1"></a>Data Affinity Constraints</h4>
+ <p>A
+ <i>DataConstraint</i> is used to define the mapping of label objects to memory units.
+ </p>
+ <p>
+ <img src="images/model_constraints_affinity_data.png"/>
+ </p>
+
+
+<h4><a id="section3.5.8.2"></a>Process Affinity Constraints</h4>
+ <p>A
+ <i>ProcessConstraint</i> is used to define the mapping of process (Task or ISR) objects to processing cores or scheduling units.
+ </p>
+ <p>
+ <img src="images/model_constraints_affinity_process.png"/>
+ </p>
+
+
+<h4><a id="section3.5.8.3"></a>Runnable Affinity Constraints</h4>
+ <p>A
+ <i>RunnableConstraint</i> is used to define the mapping of runnable objects to processing cores or scheduling units.
+ </p>
+ <p>
+ <img src="images/model_constraints_affinity_runnable.png"/>
+ </p>
+
+
+<h3><a id="section3.5.9">3.5.9 </a>Physical Section Constraints</h3>
+ <p>A
+ <i>PhysicalSectionConstraint</i> is used to to define the mapping of Section objects to Memories. This mapping of Section object to Memory objects specifies that corresponding
+ <strong>PhysicalSectionMapping</strong> associated to this
+ <strong>Section</strong> element can be allocated only in the mapped Memories.
+ </p>
+ <pre xml:space="preserve"><code>Example: PhysicalSectionConstraint with the below properties has the following semantic:
+ name: Ram1_Ram2_PhysicalSectionConstraint
+ Memories : RAM1, RAM2
+ Section : .abc.reini
+Semantic: PhysicalSectionMapping for .abc.reini section can only be allocated either in RAM1 or RAM2 or in both. But not in other Memories.
+</code></pre>
+
+
+<h2><a id="section3.6">3.6 </a>Event Model</h2>
+ <p>The event model provides the classes to describe the BTF-Events that can be used for the tracing configuration, for the modeling of event chains and for some timing constraints. </p>
+ <p>
+ <img class="scale" src="images/model_events.png"/>
+ </p>
+ <p>There are different event classes for the different entity types that can be traced: </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Entity</th>
+ <th colspan="1" rowspan="1">Event Class</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Process (Task, ISR)</td>
+ <td colspan="1" rowspan="1">ProcessEvent</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Stimulus</td>
+ <td colspan="1" rowspan="1">StimulusEvent</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Runnable</td>
+ <td colspan="1" rowspan="1">RunnableEvent</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Label</td>
+ <td colspan="1" rowspan="1">LabelEvent</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Semaphore</td>
+ <td colspan="1" rowspan="1">SemaphoreEvent</td>
+ </tr>
+ </table>
+ <p>In a running system, each entity can have different states. An event trace consists of the events that are visualizing the state-transitions of the traced entities. To define such an event in the model, each kind of event class contains an event-type-enumeration that provides the event-types for the state-transitions of its entity. The following picture shows the possible states of a process: </p>
+ <p>
+ <img src="images/model_events_process.png"/>
+ </p>
+ <p>So for example the event-type-enumeration for a process event contains the events
+ <i>activate</i>,
+ <i>start</i>,
+ <i>resume</i>, ...
+ </p>
+ <p>If it is required to define an event like "start-event of
+ <strong>some</strong> process" then it is enough to create a object of type
+ <i>ProcessEvent</i> and set the event-type
+ <i>start</i>.
+ </p>
+ <p>It is also possible to restrict the definition of an event to a special entity. So it can be defined like "start-event of task T_1". Therefore it is possible to reference a process from
+ <i>ProcessEvent</i>. In general, each event class can reference an entity of the corresponding type. In addition to that, each event class provides individual restrictions. So it is possible for
+ <i>ProcessEvent</i> that the event is not only restricted to a special process, it can be also restricted to a core. So that would be like "start-event of task T_1 on core C_2". Another example is the class
+ <i>RunnableEvent</i>, it allows to restrict the event to a runnable, the process that executes the runnable and the core that executes the process.
+ </p>
+
+
+<h2><a id="section3.7">3.7 </a>Hardware model</h2>
+ <p>The AMALTHEA hardware model is used to described hardware systems which usually consists of ECUs, microcontrollers, cores, memories, additional peripherals etc. It is central accessible through the
+ <i>HWModel</i> element and contains following elements:
+ </p>
+ <ul>
+ <li>SystemType</li>
+ <li>ECUType</li>
+ <li>MicrocontrollerType</li>
+ <li>CoreType</li>
+ <li>MemoryType</li>
+ <li>NetworkType</li>
+ <li>HwSystem</li>
+ <li>AccessPath</li>
+ </ul>
+
+
+<h3><a id="section3.7.1">3.7.1 </a>Structure</h3>
+ <p>A reduced overview of the Meta Model specifying the Hardware Model is shown below. The overall hierarchy within this model is represented by blue classes (HwSystem, ECU, Microcontroller and Core). Red classes indicate type descriptions which contain the parameters of their referencing elements, e.g. it is possible to specify a type of a core with all relevant attributes which will be referenced by core instances. This supports quick modeling of homogeneous architectures and increases the reutilization of already described hardware. Green classes represent additional hardware peripherials which can be described on each of the hardware hierarchies (HwSystem, ECU, Microcontroller and Core). </p>
+ <p>
+ <img class="scale" src="images/model_hw_overview.png"/>
+ </p>
+ <p>The structure of descriptions regarding the network is shown in the following figure. The
+ <i>ComplexNode</i> and each of its specializations (e.g. HwSystems, ECUs, Networks, ...) may contain a list of HwPort elements. The
+ <i>ComplexPort</i> element is a specialization which is attached to exactly one network. More detailed descriptions about the respective elements are given in the following section.
+ </p>
+ <p>
+ <img src="images/model_hw_network.png"/>
+ </p>
+
+
+<h4><a id="section3.7.1.1"></a>ComplexNode</h4>
+ <p>The
+ <i>ComplexNode</i> is the generalization of all hardware components. It holds the described components name and contains its nested hardware elements, e.g. memories, networks, ports etc.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">quartzes</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">*</td>
+ <td colspan="1" rowspan="1">
+ <i>Quartz</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>Quartz</i> objects (i.e. frequency generators) located on the specialization of this element.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">prescaler</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">*</td>
+ <td colspan="1" rowspan="1">
+ <i>Prescaler</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>Prescaler</i> (i.e. frequency prescaler) objects located on the specialization of this element.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">memories</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">*</td>
+ <td colspan="1" rowspan="1">
+ <i>Memory</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>Memory</i> (i.e. memories, such as RAM or ROM) objects located on the specialization of this element.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">networks</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">*</td>
+ <td colspan="1" rowspan="1">
+ <i>Network</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>Network</i> (i.e. networks, such as LIN, CAN or ETHERNET) objects located on the specialization of this element.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">components</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">*</td>
+ <td colspan="1" rowspan="1">
+ <i>HwComponent</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>HwComponent</i> (i.e. all other entities of hardware) objects located on the specialization of this element.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ports</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">*</td>
+ <td colspan="1" rowspan="1">
+ <i>HwPort</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>HwPort</i> (i.e. interfaces with multiple pins) objects located on the specialization of this element.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.2"></a>HwSystem</h4>
+ <p>The
+ <i>HwSystem</i> is a specialization of the
+ <i>ComplexNode</i> and represents a cluster of one or more
+ <i>ECU</i> elements which in sum implement a specific system.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">systemType</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>SystemType</i>
+ </td>
+ <td colspan="1" rowspan="1">Refers to a
+ <i>SystemType</i> containing the configuration for this system.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ecus</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">+</td>
+ <td colspan="1" rowspan="1">
+ <i>ECU</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for Electronic Control Units (
+ <i>ECU</i>) that are part of this system.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.3"></a>ECU</h4>
+ <p>The
+ <i>ECU</i> (Electronic Control Unit) is a specialization of the
+ <i>ComplexNode</i> and represents any physical electronic hardware on an embedded system level abstraction level.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ecuType</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>ECUType</i>
+ </td>
+ <td colspan="1" rowspan="1">Refers to a
+ <i>ECUType</i> containing the configuration for this ECU.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">microcontrollers</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">+</td>
+ <td colspan="1" rowspan="1">
+ <i>Microcontroller</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>Microcontrollers</i> that are part of this ECU.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.4"></a>Microcontroller</h4>
+ <p>The
+ <i>Microcontroller</i> is a specialization of the
+ <i>ComplexNode</i> and represents any physical hardware on System on Chip abstraction level, e.g. processors with one or more special or generic purpose cores.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">microcontrollerType</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>MicrocontrollerType</i>
+ </td>
+ <td colspan="1" rowspan="1">Refers to a
+ <i>MicrocontrollerType</i> containing the configuration for this microcontroller.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">cores</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">+</td>
+ <td colspan="1" rowspan="1">
+ <i>Core</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for processing cores (
+ <i>Core</i>) that are part of this microcontroller.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.5"></a>Core</h4>
+ <p>The
+ <i>Core</i> is a specialization of the
+ <i>ComplexNode</i> and represents the respective processing units on any type of single- or multi core processor.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">coreType</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>CoreType</i>
+ </td>
+ <td colspan="1" rowspan="1">Refers to a
+ <i>CoreType</i> containing the configuration for this core.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">lockstepGroup</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">?</td>
+ <td colspan="1" rowspan="1">0 – 255</td>
+ <td colspan="1" rowspan="1">If set, this value defines the lockstep group of the core. All cores with the same lockstep group are operating in lockstep mode together.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.6"></a>Memory</h4>
+ <p>The
+ <i>Memory</i> is a specialization of the
+ <i>ComplexNode</i> and represents memories. It is used to describe any type of memory module, e.g. Flash, RAM, etc.
+ <br>Please note that to specify a memory with the type
+ <i>CACHE</i> (e.g. lv1 cache as part of a core) it is sufficient to specify it within a core. It is not necessary to specify additional networks or ports.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">type</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>MemoryType</i>
+ </td>
+ <td colspan="1" rowspan="1">Refers to a
+ <i>MemoryType</i> containing the configuration for this memory.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.7"></a>Network</h4>
+ <p>The
+ <i>Network</i> is a specialization of the
+ <i>ComplexNode</i> and represents networks of interconnected
+ <i>ComplexPort</i> elements.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">type</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>NetworkType</i>
+ </td>
+ <td colspan="1" rowspan="1">Refers to a
+ <i>NetworkType</i> containing the configuration for this network.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.8"></a>Quartz</h4>
+ <p>The
+ <i>Quartz</i> is a specialization of the
+ <i>ComplexNode</i> and represents a frequency generator which may be located on any
+ <i>ComplexNode</i> or its specializations. It may be referenced by any number of
+ <i>Prescalers</i>.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">type</td>
+ <td colspan="1" rowspan="1">
+ <i>QType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">STATIC / DYNAMIC</td>
+ <td colspan="1" rowspan="1">Specifies if the
+ <i>Quartz</i> operates at either a static or dynamic frequency.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">frequency</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">?</td>
+ <td colspan="1" rowspan="1">0 – 255</td>
+ <td colspan="1" rowspan="1">Frequency on which this
+ <i>Quartz</i> is operating.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.9"></a>Component</h4>
+ <p>The
+ <i>Component</i> (or
+ <i>HwComponent</i>) is a specialization of the
+ <i>ComplexNode</i> and represent hardware elements which are not further specified. They may contain any number of nested
+ <i>Components</i>.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">nestedComponents</td>
+ <td colspan="1" rowspan="1">Containment</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>HwComponent</i>
+ </td>
+ <td colspan="1" rowspan="1">Containment for
+ <i>HwComponent</i> (i.e. all other entities of hardware) objects located below this component.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.10"></a>HardwareTypeDescription</h4>
+ <p>The abstract class
+ <i>HardwareTypeDescription</i> is the generalization of all type description for memories, cores, ECUs, networks etc. It allows its specializations to stor information about their features.
+ </p>
+
+
+<h4><a id="section3.7.1.11"></a>AbstractionTypeDescription</h4>
+ <p>The abstract class
+ <i>AbstractionTypeDescription</i> is a specialization of the
+ <i>HardwareTypeDescription</i> and generalization for hardware types which describe hardware abstraction, i.e. the
+ <i>HwSystem</i>,
+ <i>ECU</i>,
+ <i>Microcontroller</i> and
+ <i>Core</i>.
+ </p>
+
+
+<h4><a id="section3.7.1.12"></a>SystemType</h4>
+ <p>The
+ <i>SystemType</i> is a specialization of the
+ <i>AbstractionTypeDescription</i> and used to define a specific type of a system. If multiple systems with the same characteristics exist, it is sufficient to define only one type and reference it by all systems sharing the same type.
+ </p>
+
+
+<h4><a id="section3.7.1.13"></a>ECUType</h4>
+ <p>The
+ <i>ECUType</i> is a specialization of the
+ <i>AbstractionTypeDescription</i> and used to define a type of an ECU.
+ </p>
+
+
+<h4><a id="section3.7.1.14"></a>MicrocontrollerType</h4>
+ <p>The
+ <i>MicrocontrollerType</i> is a specialization of the
+ <i>AbstractionTypeDescription</i> and used to define a type of a Microcontroller.
+ </p>
+
+
+<h4><a id="section3.7.1.15"></a>CoreType</h4>
+ <p>The
+ <i>CoreType</i> is a specialization of the
+ <i>AbstractionTypeDescription</i> and used to define a type of a Core, i.e. its bit width and ticks per cycle.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">bitWidth</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">0-255</td>
+ <td colspan="1" rowspan="1">The cores architectures bit width (e.g. 32 or 64 bit)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">instructionsPerCycle</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">0-255</td>
+ <td colspan="1" rowspan="1">Number of processed (computed) instructions per cycle.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.16"></a>MemoryType</h4>
+ <p>The
+ <i>MemoryType</i> is a specialization of the
+ <i>HardwareTypeDescription</i> and used to define a type of a memory, i.e. its size, access pattern and type.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">xAccessPattern</td>
+ <td colspan="1" rowspan="1">String</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">String</td>
+ <td colspan="1" rowspan="1">Timing Architects specific value. Will be used in the future to determine the access pattern of a memory element.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">type</td>
+ <td colspan="1" rowspan="1">
+ <i>MemoryType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">RAM/CACHE/FLASH_INT/FLASH_EXT</td>
+ <td colspan="1" rowspan="1">Specifies the type of this Memory.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">size</td>
+ <td colspan="1" rowspan="1">Long</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Size of this memory.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.17"></a>NetworkType</h4>
+ <p>The
+ <i>NetworkType</i> is a specialization of the
+ <i>HardwareTypeDescription</i> and used to define a type of a Network, i.e. max supported bit width and scheduling policy.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">schedPolicy</td>
+ <td colspan="1" rowspan="1">
+ <i>SchedType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">RROBIN/PRIORITY</td>
+ <td colspan="1" rowspan="1">Specifies the scheduling policy which is used on this Network.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">bitWidth</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">0 – 255</td>
+ <td colspan="1" rowspan="1">Specifies the max bit width that may be transferred on this network per cycle.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.18"></a>CrossbarSwitch</h4>
+ <p>The
+ <i>CrossbarSwitch</i> is a specialization of a
+ <i>NetworkType</i> and represents switches, which allow simultaneous/concurrent connections between all types of components
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">conConnections</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">0 – 255</td>
+ <td colspan="1" rowspan="1">Maximum number of concurrent 1:n connections</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.19"></a>Bus</h4>
+ <p>The
+ <i>Bus</i> is a specialization of the
+ <i>NetworkType</i> and represents any kind of bus network, e.g. CAN, LIN etc.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">type</td>
+ <td colspan="1" rowspan="1">
+ <i>BusType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">CAN/TTCAN/LIN/FLEXRAY/ETHERNET/SPI/NA</td>
+ <td colspan="1" rowspan="1">Specifies the type of the bus network.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.20"></a>Bridge</h4>
+ <p>The
+ <i>Bridge</i> is a specialization of a
+ <i>NetworkType</i> and represents bridges or gateways. It is used to transfer data from one network to another and performs a one-way translation, e.g. a
+ <i>ComplexNode</i> containing a
+ <i>Bridge</i> is accessed by its
+ <i>ComplexPort</i> and routes the data to its containing
+ <i>Bridge</i>. If a
+ <i>ComplexNode</i> contains more than one
+ <i>Bridge</i>, the respective target network is determined by the address range of its connected
+ <i>ComplexPort</i> elements.
+ </p>
+
+
+<h4><a id="section3.7.1.21"></a>Pin</h4>
+ <p>The
+ <i>Pin</i> represents a single pin and serves as abstract representation for pure informative use, e.g. by a developer describing a port.
+ </p>
+
+
+<h4><a id="section3.7.1.22"></a>ComplexPin</h4>
+ <p>The
+ <i>ComplexPin</i> is a specialization of the
+ <i>Pin</i> and contains detailed information, i.e. the type of the pin, its address and its direction (read/write).
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">type</td>
+ <td colspan="1" rowspan="1">
+ <i>PinType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">ANALOG/DIGITAL</td>
+ <td colspan="1" rowspan="1">Specifies if this pin is either operating in analog or digital mode</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">baseAddress</td>
+ <td colspan="1" rowspan="1">Long</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>= 0</td>
+ <td colspan="1" rowspan="1">Specifies the address of this pin, i.e. the address this pin is accessed by.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">direction</td>
+ <td colspan="1" rowspan="1">
+ <i>RWType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">R/W/RW</td>
+ <td colspan="1" rowspan="1">Specifies the direction the data may travel through this pin, e.g. ®ead only, (W)rite only or both (RW).</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.23"></a>Port</h4>
+ <p>The
+ <i>Port</i> represents groups of pins and may be used to describe simple interfaces, e.g. 8-bit ports etc. Its main purpose is to describe ports which only serve informative use.
+ </p>
+
+
+<h4><a id="section3.7.1.24"></a>ComplexPort</h4>
+ <p>The
+ <i>ComplexPort</i> is a specialization of the
+ <i>Port</i> and represents interfaces on any type of
+ <i>ComplexNode</i> which are connected to a
+ <i>Network</i>.
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Type</th>
+ <th colspan="1" rowspan="1">Mul.</th>
+ <th colspan="1" rowspan="1">Valid Values</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">network</td>
+ <td colspan="1" rowspan="1">Reference</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">
+ <i>Network</i>
+ </td>
+ <td colspan="1" rowspan="1">References the network which this ComplexPort is a part of. Only ComplexPorts attached to the same network are capable of communicated directly with each other. If data is transfered over multiple networks, either a valid route (e.g. Port A -> Network A -> Port B and Port C -> Network B -> Port D, with Ports B and C beeing on the same device), or an access path have to be present.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isMaster</td>
+ <td colspan="1" rowspan="1">Boolean</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">TRUE/FALSE</td>
+ <td colspan="1" rowspan="1">Specifies if this ComplexPort may send requests to a Network (e.g. a processor) or just answer them (e.g. a memory).</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">bitWidth</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Specifies the max bit width that may be transferred via this ComplexPort.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">baseAddress</td>
+ <td colspan="1" rowspan="1">Long</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Specifies the base address of this ComplexPort, making it addressable through other ComplexPorts in the Network.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">addressRange</td>
+ <td colspan="1" rowspan="1">Long</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Specifies the size of the addressable area this ComplexPort is addressed by. The address space is determined by the baseAddress offset and this value.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">direction</td>
+ <td colspan="1" rowspan="1">
+ <i>RWType</i>
+ </td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">R/W/RW</td>
+ <td colspan="1" rowspan="1">Specifies the direction the data may travel through this port, e.g. ®ead only, (W)rite only or both (RW). Note that the direction is always related to the isMaster attribute, e.g. Master ports read and write TO the network, while non-master ports are read and written BY the network.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">readCycles</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Specifies the number of cycles until a read is performed.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">writeCycles</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Specifies the number of cycles until a write is performed.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">schedValue</td>
+ <td colspan="1" rowspan="1">Integer</td>
+ <td colspan="1" rowspan="1">1</td>
+ <td colspan="1" rowspan="1">>0</td>
+ <td colspan="1" rowspan="1">Optional parameter for the usage in network scheduling policies. The meaning of this attribute depends on the used schedulingPolicy of the referenced Network, e.g. it may be the priority in a priority scheduled network or the order in a round robin scheduled network.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.7.1.25"></a>AbstractType</h4>
+ <p>The
+ <i>AbstractType</i> is an abstract class, allowing attributes to describe data without specifying their data type. It contains the field name to specify the name of the value while the specializations
+ <i>BoolValue</i>,
+ <i>CharValue</i>,
+ <i>IntValue</i>,
+ <i>LongValue</i>,
+ <i>DoubleValue</i> and
+ <i>StringValue</i> contain the resp. value types.
+ </p>
+
+
+<h3><a id="section3.7.2">3.7.2 </a>AccessPaths</h3>
+ <p>The
+ <i>AccessPath</i> element describes in general the needed time in cycles for a hardware element (
+ <i>ComplexNode</i>) A to access a hardware element B.
+ <br>It can be configured in two different ways:
+ </p>
+ <ol>
+ <li>
+ <strong>Latency</strong>: Describes the needed cycles for a given
+ <i>RWType</i> using a
+ <i>Deviation</i> (from common model) or a constant value.
+ </li>
+ <li>
+ <strong>Sequence of ports</strong>: Describes the access path in detail by referencing the
+ <i>ComplexPorts</i> from given Hardware elements. These ports includes the specification for the different access types in cycles, which can then be summed up to get the total value.
+ </li>
+ </ol>
+ <p>Both approaches includes the possibility to reference another given path of the same type, so it is possible for example to describe sub paths, which are then included in a main path.</p>
+ <p>The following picture shows the structure of these two approaches:</p>
+ <p>
+ <img class="scale" src="images/model_hw_access_path.png"/>
+ </p>
+
+
+<h4><a id="section3.7.2.1"></a>Latency Overview</h4>
+ <p>To describe a latency for a given core a memory, only these elements are needed inside of the Hardware model.
+ <br>The next picture shows a simple overview of a core, which is able to access two memories with different latencies.
+ </p>
+ <p>
+ <img src="images/model_hw_access_path_latency_sample.png"/>
+ </p>
+ <p>Using the provided AMALTHEA model editor this small sample would look like the following picture:</p>
+ <p>
+ <img src="images/model_hw_access_path_latency_sample_editor.png"/>
+ </p>
+
+
+<h4><a id="section3.7.2.2"></a>Hardware Access Path</h4>
+ <p>Using the
+ <i>HwAccessPath</i> element to describe an access path, the included elements must be available with the proper
+ <i>ComplexPorts</i>. The access path consists with a list of elements, which are referencing existing ports.
+ </p>
+ <p>The next overview shows a very simple sample, with a core and two memories connected using a network and the proper ports.</p>
+ <p>
+ <img src="images/model_hw_access_path_hw_element_sample.png"/>
+ </p>
+ <p>Configuring the two access paths from Core1 to Memory1 and to Memory2 results in two
+ <i>HwAccessPaths</i> containing the proper ports, showed in the next overview.
+ </p>
+ <p>
+ <img src="images/model_hw_access_path_hw_element_sample_editor.png"/>
+ </p>
+
+
+<h2><a id="section3.8">3.8 </a>Mapping Model</h2>
+ <p>The mapping model is intended to provide tools that use hardware and software models (e.g. code generators) information about the corresponding mappings and allocations. This information contains associations between</p>
+ <ul>
+ <li>schedulers and executable software: A scheduler manages and distributes executable software like runnables or tasks on its managed cores,</li>
+ <li>schedulers and cores: A scheduler can manage one or more cores and deploy computations on these</li>
+ <li>data and memories: Data (such as functions, variables, heap etc) is mapped on static and volatile memories.</li>
+ </ul>
+
+
+<h3><a id="section3.8.1">3.8.1 </a>Overview</h3>
+ <p>The Meta Model specifying the Mapping Model is shown below. </p>
+ <p>
+ <img class="scale" src="images/model_mapping_overview.png"/>
+ </p>
+
+
+<h4><a id="section3.8.1.1"></a>MappingModel</h4>
+ <p>The
+ <i>MappingModel</i> serves as a container for each of the mapping rules, i.e.
+ <i>Allocations</i> (executable software and cores which are allocated to schedulers) and
+ <i>Mappings</i> (labels and software which is mapped to memories).
+ </p>
+
+
+<h3><a id="section3.8.2">3.8.2 </a>Mapping</h3>
+ <p>The
+ <i>Mapping</i> is an abstract class, describing the mapping of parts of the software model to
+ <i>Memory</i>. The target memory is specified by a reference to an explicit
+ <i>Memory</i> within an existing hardware model. The position in memory can also be defined as address here. If the address is a absolute memory address, a offset address from the memories first address, or if the address information is not expected at all is defined by the
+ <i>Memory Address Mapping Type</i> enumeration in the root element of the
+ <i>Mapping Model</i>. The Additional attributes, e.g. to supply further information for a code generator, may be described by the containment attributeList.
+ </p>
+
+
+<h4><a id="section3.8.2.1"></a>AbstractElementMapping</h4>
+ <p>The
+ <i>AbstractElementMapping</i> is a specialization of the
+ <i>Mapping</i>. It is used to associate specializations of the
+ <i>AbstractElementMemoryInformation</i> (i.e.
+ <i>Label</i>,
+ <i>Runnable</i>,
+ <i>TaskPrototype</i> and
+ <i>Process</i>), specified within the software model, with a
+ <i>Memory</i>.
+ </p>
+
+
+<h3><a id="section3.8.3">3.8.3 </a>PhysicalSectionMapping</h3>
+ <p>The
+ <em>PhysicalSectionMapping</em> class (can also be called as
+ <strong>Physical Memory Section</strong> ) describes the following:
+ </p>
+ <ul>
+ <li>mapping of various
+ <strong>Section</strong> elements to a specific
+ <strong>Memory</strong>
+ </li>
+ <li>mapping various
+ <strong>Label and Runnable</strong> elements to a Physical Memory Section
+ </li>
+ <li>description of memory address location where the Physical Memory Section is allocated </li>
+ </ul>
+
+
+<h3><a id="section3.8.4">3.8.4 </a>Allocation</h3>
+
+
+<h4><a id="section3.8.4.1"></a>CoreAllocation</h4>
+ <p>The
+ <i>CoreAllocation</i> describes the allocation of cores to a
+ <i>Scheduler</i>. This class consists of references to the respective
+ <i>Scheduler</i>, which specified within an existing OS model, and a core, which is specified in a hardware model. Further attributes, which may be used to supply additional information, e.g. for a code generator, may be described by the containment attributeList.
+ </p>
+
+
+<h4><a id="section3.8.4.2"></a>RunnableAllocation</h4>
+ <p>The
+ <i>RunnableAllocation</i> is a specialization of the
+ <i>ExecutableAllocation</i>. It is used to associate a
+ <i>Runnable</i>, specified within an existing software model, with a
+ <i>Scheduler</i>.
+ </p>
+
+
+<h4><a id="section3.8.4.3"></a>ISRAllocation</h4>
+ <p>The
+ <i>ISRAllocation</i> is used to associate an
+ <i>ISR</i> with an
+ <i>InterruptConroller</i>. The attribute 'priority' can be used to assign a value for this specific context. If the value is set, it will be used instead of the default.
+ </p>
+
+
+<h4><a id="section3.8.4.4"></a>TaskAllocation</h4>
+ <p>The
+ <i>TaskAllocation</i> is used to associate a
+ <i>Task</i> with a
+ <i>TaskScheduler</i>. The attribute 'priority' can be used to assign a value for this specific context. If the value is set, it will be used instead of the default.
+ </p>
+
+
+<h2><a id="section3.9">3.9 </a>OS Model</h2>
+ <p>This part of the AMALTHEA model describes the provided functionality of an operating system. It mainly provides a way to specify how access is given to certain system resources. Therefore the concepts of scheduling, buffering, and semaphores are supported, which are described in detail in the following chapter.</p>
+ <p>
+ <img src="images/model_os_overview.png"/>
+ </p>
+
+
+<h3><a id="section3.9.1">3.9.1 </a>Operating System</h3>
+ <p>The basic element in the OS Model is the operating system. There can multiple operating systems in one model. The operating system type can be used to describe a generic operating system. It is also possible to use the vendor operating system type to define a vendor specific OS. An operating system contains a number of task schedulers and interrupt controllers. A task scheduler controls the execution of a task on one or multiple processor cores. An interrupt controller is the controller for the execution of ISRs and can be also mapped to multiple cores. The mapping of tasks and ISRs to their controller and the mapping of the controller to the cores can be done in the Mapping Model. An operating system can also contain a description of the overhead it produces. For this there is a more detailed explanation below. </p>
+ <p>
+ <img src="images/model_os_operatingsystem.png"/>
+ </p>
+
+
+<h3><a id="section3.9.2">3.9.2 </a>Scheduler</h3>
+ <p>Interrupt controller and task scheduler have a scheduling algorithm. The picture below shows that both types are inherited of the scheduler type. Each scheduler has a scheduling unit. The scheduling unit can be either a hardware scheduling unit or a software scheduling unit. </p>
+ <p>
+ <img src="images/model_os_scheduler.png"/>
+ </p>
+
+
+<h4><a id="section3.9.2.1"></a>Scheduling HW Unit</h4>
+ <p>This class is used when scheduling is done by a hardware unit. The only attribute of this class
+ <br>is the delay attribute. It represents the amount of time that is required to execute scheduling.
+ </p>
+ <p>
+ <img src="images/model_os_hwunit.png"/>
+ </p>
+
+
+<h4><a id="section3.9.2.2"></a>Scheduling SW Unit</h4>
+ <p>This class is used when scheduling is done by software unit.</p>
+ <p>
+ <img src="images/model_os_swunit.png"/>
+ </p>
+
+
+<h4><a id="section3.9.2.3"></a>Scheduling Algorithm</h4>
+ <p>This is an abstract class for the different scheduling algorithms.</p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Scheduling Algorithm</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OSEK</td>
+ <td colspan="1" rowspan="1">OSEK compliant Scheduling Algorithm</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">PfairPD2</td>
+ <td colspan="1" rowspan="1">Proportionate Fair PD<sup>2</sup> Scheduling Algorithm
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">PartlyPFairPD2</td>
+ <td colspan="1" rowspan="1">PPfair-PD<sup>2</sup> (Partly Proportionate Fair PD<sup>2</sup> Scheduling Algorithm)
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">PartlyEarlyReleaseFairPD2</td>
+ <td colspan="1" rowspan="1">P-ERfair-PD<sup>2</sup> (Partly Early Release Fair PD<sup>2</sup> Scheduling Algorithm)
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">EarlyReleaseFairPD2</td>
+ <td colspan="1" rowspan="1">ERfair-PD<sup>2</sup> (Early Release Fair PD<sup>2</sup> Scheduling Algorithm)
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">LeastLocalRemainingExecutionTimeFirst</td>
+ <td colspan="1" rowspan="1">Task with the smallest local remaining execution time gets the highest priority</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">EarliestDeadlineFirst</td>
+ <td colspan="1" rowspan="1">EDF (Earliest Deadline First Scheduling Algorithm): Task with the earliest deadline gets the highest priority</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">DeadlineMonotonic</td>
+ <td colspan="1" rowspan="1">DMS (Deadline Monotonic Scheduling Algorithm): Task with the shortest period gets the lowest priority</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">RateMonotonic</td>
+ <td colspan="1" rowspan="1">RMS (Rate Monotonic Scheduling Algorithm): Task with the shortest period gets the highest priority</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">PriorityBasedRoundRobin</td>
+ <td colspan="1" rowspan="1">Round Robin Scheduling Algorithm with prioritized processes</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">UserSpecificSchedulingAlgorithm</td>
+ <td colspan="1" rowspan="1">This class contains a list of algorithm parameter. Each parameter has a key and a value (both Strings). A user can store all information for its own specific scheduling algorithm here</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.9.3">3.9.3 </a>Os Overhead</h3>
+ <p>It is possible to define the the overhead that is produced by an operating system. The defined overhead can be assigned to an operating system definition. Each overhead information is defined as a set of instructions that has to be executed when the corresponding OS function is used. The instructions can be either a constant set or a deviation of instructions. It is possible to define the overhead for the ISR category one and two and for a number of operating system API functions.</p>
+ <p>
+ <img src="images/model_os_osoverhead.png"/>
+ </p>
+
+
+<h4><a id="section3.9.3.1"></a>ISR Overhead</h4>
+ <ul>
+ <li>ISR category 1 & 2: Describes the overhead for ISRs of category one and two by adding a set of instructions that is executed at start and terminate of the ISR </li>
+ </ul>
+
+
+<h4><a id="section3.9.3.2"></a>API Overhead</h4>
+ <p>There exists also an overhead for API calls. The following API calls are considered:</p>
+ <ul>
+ <li>API Activate Task: Runtime overhead for the activation of a task or ISR by another task or ISR (inside the activating process)</li>
+ <li>API Terminate Task: Runtime for explicit task termination call (inside a task)</li>
+ <li>API Schedule: Runtime for task scheduling (on scheduling request)</li>
+ <li>API Request Resource: Runtime overhead for requesting a semaphore (inside a runnable)</li>
+ <li>API Release Resource: Runtime overhead for releasing a semaphore (inside a runnable)</li>
+ <li>API Set Event: Runtime overhead for requesting an OS event (inside a task or ISR)</li>
+ <li>API Wait Event: Runtime overhead for waiting for an OS event (inside a task or ISR)</li>
+ <li>API Clear Event: Runtime overhead for clearing an OS event (inside a task or ISR)</li>
+ <li>API Send Message: Runtime overhead for activating another process on another core or setting a event for a process on another core (inside a task or ISR) </li>
+ <li>API Enforced Migration: Runtime overhead for migrating from one scheduler to another scheduler (inside a task or ISR)</li>
+ </ul>
+
+
+<h3 id="os-data-consistency"><a id="section3.9.4">3.9.4 </a>OS Data Consistency</h3>
+ <p>The
+ <i>OsDataConsistency</i> class provides a way to globally configure an automatic data consistency mechanism. It is used to cover the following two use cases:
+ </p>
+ <ul>
+ <li>Provide a configuration for external tools that perform a data consistency calculation based on the stated information.</li>
+ <li>Provide the results of a performed data consistency calculation which then have to be considered by external tools (e.g. by timing simulation).</li>
+ </ul>
+ <p>
+ <img src="images/model_os_data_consistency.png"/>
+ </p>
+ <p>To distinguish the different use cases and to consequently also indicate the workflow progress for achieving data consistency,
+ <i>OsDataConsistencyMode</i> allows to define the general configuration of the data consistency. The following modes are available:
+ </p>
+ <ol>
+ <li>noProtection: data stability and coherency is NOT automatically ensured.</li>
+ <li>automaticProtection: data stability and coherency HAS TO BE ensured according configuration either via custom protection or via model elements.
+ <ol>
+ <li>customProtection: data stability and coherency IS ensured according configuration but not via model elements.</li>
+ <li>handeldByModelElements: data stability and coherency IS ensured via model elements.</li>
+ </ol>
+ </li>
+ </ol>
+ <p>The
+ <i>DataStability</i> class defines for which sequence of runnables data has to be kept stable. This can either be stability within a process meaning over all its runnables, within each runnable or within each schedule section. Furthermore, it can be stated whether all data is considered for stability or just those accessed multiple times.
+ </p>
+ <p>The
+ <i>NonAtomicDataCoherency</i> class defines for which sequence of runnables data has to be kept coherent. Like for data stability it can be stated whether all data is considered for coherency or just those accessed multiple times.
+ </p>
+
+
+<h3><a id="section3.9.5">3.9.5 </a>Semaphore</h3>
+ <p>With this object, a semaphore can be described which limits the access of several processes to one resource at the same time.</p>
+ <p>
+ <img src="images/model_os_semaphore.png"/>
+ </p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Attribute</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">Name of semaphore (inherited from ReferableBaseObject)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>maxValue</i>
+ </td>
+ <td colspan="1" rowspan="1">Maximum number of processes that can concurrently access the semaphore</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>initialValue</i>
+ </td>
+ <td colspan="1" rowspan="1">Initial number of processes that access the semaphore</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>priorityCeilingPrototcol</i>
+ </td>
+ <td colspan="1" rowspan="1">Defines if the priority ceiling protocol is activated. If it is activated, a process that accesses the semaphore gets a higher priority as the processes that can also access the same semaphore</td>
+ </tr>
+ </table>
+
+
+<h2><a id="section3.10">3.10 </a>PropertyConstraints Model</h2>
+ <p>The scope of the Property Constraints model is to limit the design space by providing information about the specific hardware properties that parts of the software rely on, i.e. what properties or features have to be supplied by the respective hardware in order to be a valid mapping or allocation target.</p>
+ <p>This information comprises</p>
+ <ul>
+ <li>Allocation constraints, which describe the constraints on cores.</li>
+ <li>Mapping constraints, which describe the constraints on memories.</li>
+ </ul>
+
+
+<h3><a id="section3.10.1">3.10.1 </a>Structure</h3>
+ <p>The figure below shows the Property Constraints model. In order to provide a better understanding of the model, interconnections between software model elements are not shown in this figure.</p>
+ <p>
+ <img src="images/model_propertyconstraints_overview.png"/>
+ </p>
+
+
+<h4><a id="section3.10.1.1"></a>PropertyConstraintsModel</h4>
+ <p>The
+ <i>PropertyConstraintsModel</i> serves as container for constraints, i.e.
+ <i>AllocationConstraints</i> and
+ <i>MappingConstraints</i>.
+ </p>
+
+
+<h4><a id="section3.10.1.2"></a>AllocationConstraint</h4>
+ <p>The
+ <i>AllocationConstraint</i> is an abstract class for describing constraints which affect the selection of a suitable
+ <i>Core</i>. The actual constraint on the core is described by the
+ <i>HwCoreConstraint</i>.
+ </p>
+
+
+<h4><a id="section3.10.1.3"></a>ProcessAllocationConstraint</h4>
+ <p>The
+ <i>ProcessAllocationConstraint</i> is a specialization of the
+ <i>AllocationConstraint</i>. It is used to specify constraints on
+ <i>Core</i> elements which are used in the allocation of Process's specializations (i.e.
+ <i>Task</i> and
+ <i>ISR</i>), to
+ <i>Cores</i>.
+ </p>
+
+
+<h4><a id="section3.10.1.4"></a>RunnableAllocationConstraint</h4>
+ <p>The
+ <i>RunnableAllocationConstraint</i> is a specialization of the
+ <i>AllocationConstraint</i>. It is used to specify constraints on
+ <i>Core</i> elements which are used in
+ <i>Runnable</i> to
+ <i>Core</i> allocations.
+ </p>
+
+
+<h4><a id="section3.10.1.5"></a>HwCoreConstraint</h4>
+ <p>The
+ <i>HwCoreConstraint</i> is an abstract class and used to describe constraints on Core elements, i.e. the criteria they have to provide in order to be a valid allocation target.
+ </p>
+
+
+<h4><a id="section3.10.1.6"></a>HwCoreConjunction</h4>
+ <p>The
+ <i>HwCoreConjunction</i> is a specialization of the
+ <i>HwCoreConstraint</i> and used to link two
+ <i>HwCoreConstraints</i> with each other. The conjunction between the constraints may either be AND (both constraints must be true) or OR (at least one of both constraints must be true).
+ </p>
+
+
+<h4><a id="section3.10.1.7"></a>HwCoreProperty</h4>
+ <p>The
+ <i>HwCoreProperty</i> is a specialization of the
+ <i>HwCoreConstraint</i> and used to describe the features and attributes a
+ <i>Core</i> needs to provide in order to be a valid target. This is done by the Core revealing a "prototype" of the Core the software expects. Core elements of hardware models are compared with this prototype w.r.t. the comparator, e.g. "greater" means, the
+ <i>Core</i> from the hardware model needs to have higher attributes compared to the contained prototype-__Core__.
+ </p>
+
+
+<h4><a id="section3.10.1.8"></a>MappingConstraint</h4>
+ <p>The
+ <i>MappingConstraint</i> is an abstract class for describing constraints which affect the selection of a suitable
+ <i>Memory</i>. The actual constraint on the core is described by the
+ <i>HwMemoryConstraint</i>.
+ </p>
+
+
+<h4><a id="section3.10.1.9"></a>AbstractElementMappingConstraint</h4>
+ <p>The
+ <i>AbstractElementMappingConstaint</i> is a specialization of the
+ <i>MappingConstraint</i>. It is used to specify constraints on
+ <i>Memory</i> elements which are used in the mapping of
+ <i>AbstractElementMemoryInformations</i> specializations (i.e.
+ <i>Label</i>,
+ <i>Runnable</i>,
+ <i>TaskPrototype</i> or
+ <i>Process</i>) to
+ <i>Memories</i>.
+ </p>
+
+
+<h4><a id="section3.10.1.10"></a>HwMemoryConstraint</h4>
+ <p>The
+ <i>HwMemoryConstraint</i> is an abstract class and used to describe constraints on
+ <i>Memory</i> elements, i.e. the criteria they have to provide in order to be a valid mapping target.
+ </p>
+
+
+<h4><a id="section3.10.1.11"></a>HwMemoryConjunction</h4>
+ <p>The
+ <i>HwMemoryConjunction</i> is a specialization of the
+ <i>HwMemoryConstraint</i> and used to link two
+ <i>HwMemoryConstraints</i> with each other. The conjunction between the constraints may either be AND (both constraints must be true) or OR (at least one of both constraints must be true).
+ </p>
+
+
+<h4><a id="section3.10.1.12"></a>HwMemoryProperty</h4>
+ <p>The
+ <i>HwMemoryProperty</i> is a specialization of the
+ <i>HwMemoryConstraint</i> and used to describe the features and attributes a
+ <i>Memory</i> needs to provide in order to be a valid target. This is done by the
+ <i>Memory</i> revealing a 'prototype' of the
+ <i>Memory</i> the software expects.
+ <i>Memory</i> elements of hardware models are compared with this prototype w.r.t. the comparator, e.g. 'greater' means, the Memory of the hardware model needs to have higher attributes compared to the prototype core.
+ </p>
+
+
+<h2><a id="section3.11">3.11 </a>Stimuli Model</h2>
+ <p>The Stimuli Model contains stimulus and clock objects.</p>
+ <p>
+ <img class="scale" src="images/model_stimuli.png"/>
+ </p>
+
+
+<h3><a id="section3.11.1">3.11.1 </a>Stimuli</h3>
+ <p>
+ <img class="scale" src="images/model_stimuli_stimuli.png"/>
+ </p>
+ <p>A stimulus is responsible to activate processes. The following different types are available:</p>
+ <ul>
+ <li>
+ <strong>ArrivalCurve</strong>: A list of time-borders in which a specified number of events are expected
+ </li>
+ <li>
+ <strong>CustomStimulus</strong>: To describe own custom types of activations, including properties
+ </li>
+ <li>
+ <strong>InterProcess</strong>: Activations based on an explicit inter-process activation. Contains a Counter element if activation is either shifted and / or happening every n<sup>th</sup> time.
+ </li>
+ <li>
+ <strong>Periodic</strong>: Periodic activations based on an offset and a recurrence.
+ </li>
+ <li>
+ <strong>Single</strong>: Activates the process only once
+ </li>
+ <li>
+ <strong>Sporadic</strong>: Sporadic activations of processes
+ </li>
+ <li>
+ <strong>Synthetic</strong>: Activations periodically triggered depending on a defined list of trigger times.
+ </li>
+ <li>
+ <strong>PeriodicEvent</strong>: Periodic activations based on other events, like rotation speed dependency
+ </li>
+ <li>
+ <strong>EventStimulus</strong>: Activation triggered by an event, defined in the event model. Contains a Counter element if activation is either shifted and / or happening every n<sup>th</sup> time.
+ </li>
+ </ul>
+ <p>It is possible to define a deviation of time for every type of stimulus. For this, a stimulus can have an object of type Deviation, which refers to the deviation in the common model. This reference uses the class SignedTime as parameter for the generic values of the deviation. So the deviation is about time. The values (negative or positive) represents a shift of the activation to left or right on the time line. In this way it is possible to increase or decrease the activation time.</p>
+ <p>The following figure shows a stimulus example. First there is a periodic stimulus with a fix offset and recurrence time. The first activation occurs after offset, every following activation occurs after recurrence. In the second diagram is the same stimulus with a Gaussian stimulation deviation. The activation time however varies now according the values of the distribution.</p>
+ <p>
+ <img src="images/model_stimuli_periodic.png"/>
+ </p>
+ <p>Beside of the deviation, a periodic stimulus can have a clock.</p>
+
+
+<h3><a id="section3.11.2">3.11.2 </a>Clocks</h3>
+ <p>A clock is a time base which describes the progress of time for one or more periodic stimuli in relation to global time. If two equal stimuli have a different time base, the time of task activation can be different. There are different kind of clock functions, the clock sinus function, the clock triangle function and the clock multiplier list. The clock multiplier list is a list of timestamp-multiplier value pairs. Is a specified timestamp arrived, the clock changes to the corresponding multiplier value.</p>
+ <p>
+ <img class="scale" src="images/model_stimuli_clocks.png"/>
+ </p>
+ <p>It is possible to define lists of mode label values for a stimulus. An entry in this list is always a pair of a mode label and a mode literal. One of this lists is the set-mode-labels-list. Each time the stimulus is triggered all mode labels in this list are set to the corresponding value.
+ <br>The enabling-mode-label-list and the disabling-mode-label-list can be used to enable or disable a stimulus by setting the mode label to a specific value (e.g. by a write access with a runnable).
+ </p>
+ <ul>
+ <li>If there are entries in the disabling-mode-label-list, the stimulus is disabled if one of these mode labels has the defined value.</li>
+ <li>If there are entries in the enabling-mode-label-list, the stimuli is disabled if no one of these mode labels has the defined value. </li>
+ <li>If there are entries in both lists, the stimulus is disabled when at least one label of the disabling-mode-label-list has the defined value or if all labels in the enabling-mode-label-list are different to their defined value. If no one of the disabling-mode-label-list fits its value but at least one of the enabling-mode-label-list, then the stimulus is enabled. </li>
+ </ul>
+ <p>
+ <img class="scale" src="images/model_stimuli_modevaluelist.png"/>
+ </p>
+
+
+<h3><a id="section3.11.3">3.11.3 </a>Arrival Curves</h3>
+ <p>An arrival curve is described as a list of time-borders in which a specified number of events are expected. The picture below shows an example for this. In the first picture there is a number of events on a timeline.</p>
+ <p>
+ <img src="images/model_stimuli_arrival_curve_1.png" style="width:400px"/>
+ </p>
+ <p>In the picture below every distance between two events is measured. The minimum and the maximum distance is added to the table as time-border for the occurrence of two events. This means that after one event there has to be at least a gap of one time-unit before the next event can occur. It also means that there will be always a second event within eight time units after the event before. Basically this would be enough to describe an Arrival Curve Stimulus. But it is possible to create a more precise stimulus by describing additional time borders for greater number of events. This is shown in the steps below. </p>
+ <p>
+ <img src="images/model_stimuli_arrival_curve_2.png" style="width:400px"/>
+ </p>
+ <p>The same as for two events in the picture above is done here for three events. Like already mentioned above, this is an additional restriction for occurrence of an event. </p>
+ <p>
+ <img src="images/model_stimuli_arrival_curve_3.png" style="width:400px"/>
+ </p>
+ <p>And for four events:</p>
+ <p>
+ <img src="images/model_stimuli_arrival_curve_4.png" style="width:400px"/>
+ </p>
+ <p>The picture below shows the table as arrival curve graph. The red line is the upper-time-border that shows the latest time where the event will occur. The green line shows the earliest possible time where the event can occur. </p>
+ <p>
+ <img src="images/model_stimuli_arrival_curve_5.png" style="width:600px"/>
+ </p>
+
+
+<h2><a id="section3.12">3.12 </a>Software Model</h2>
+ <p>The AMALTHEA software model is central accessible through the
+ <i>SWModel</i> element.
+ </p>
+
+
+<h3><a id="section3.12.1">3.12.1 </a>Memory Information</h3>
+ <p>Analyzing and mapping the software structure to available memories needs additional information of the included elements. This type of information targets the consumed size of memory of an element, represented by the
+ <i>size</i> attribute of type
+ <i>DataUnit</i>. The element
+ <i>AbstractElementMemoryInformation</i> is a generalized element that provides this data. The following image shows the structure and also the elements of the software model that are extending
+ <i>AbstractElementMemoryInformation</i> (the overview picture is only showing the hierarchy and not possible relationships between the elements):
+ </p>
+ <p>
+ <img class="scale" src="images/model_sw_memory_inf.png"/>
+ </p>
+
+
+<h3><a id="section3.12.2">3.12.2 </a>Labels</h3>
+ <p>The label element represents a data element. It is directly located in a defined area of a given memory.
+ <br>It can be used as a parameter, a temporarily existing variable or representing a constant value.
+ </p>
+ <p>
+ <img src="images/model_sw_label.png"/>
+ </p>
+ <p>The following attributes are describing a label:</p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">The name represented as String value (derived from
+ <i>AbstractElementMemoryInformation</i>)
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>displayName</i>
+ </td>
+ <td colspan="1" rowspan="1">In addition to the name attribute, which must be unique, a label can also be described by an additional and optional display name. The displayName attribute must not be unique. It can be used for example to represent specification data, which can be different from the unique name (like a symbol) of an available software build.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>dataType</i>
+ </td>
+ <td colspan="1" rowspan="1">Reference to the data type definition</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>constant</i>
+ </td>
+ <td colspan="1" rowspan="1">Boolean value to represent, if label is representing a constant value</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>bVolatile</i>
+ </td>
+ <td colspan="1" rowspan="1">Boolean value to mark a label as volatile</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>dataStability</i>
+ </td>
+ <td colspan="1" rowspan="1">Enumeration value to represent the data stability needs of the label. If set, it overwrites the global settings stated by the
+ <i>OsDataDependency</i>, otherwise it inherits them (see <a href="#os-data-consistency" shape="rect">OS Data Consistency</a>).
+ </td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.12.3">3.12.3 </a>Channels</h3>
+ <p>The channel element has two different characteristics: it represents a data element in memory and also a way how runnables transmit larger amounts of data. A typical applications is the streaming of video data where a continuous sequence of images is sent in smaller chunks.</p>
+ <p>
+ <img src="images/model_sw_channel.png"/>
+ </p>
+ <p>The following attributes are describing a label:</p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">The name represented as String value (derived from
+ <i>AbstractElementMemoryInformation</i>)
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>displayName</i>
+ </td>
+ <td colspan="1" rowspan="1">In addition to the name attribute, which must be unique, a label can also be described by an additional and optional display name. The displayName attribute must not be unique. It can be used for example to represent specification data, which can be different from the unique name (like a symbol) of an available software build.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>elementType</i>
+ </td>
+ <td colspan="1" rowspan="1">Reference to the data type definition of a single element</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>defaultElements</i>
+ </td>
+ <td colspan="1" rowspan="1">Number of elements initially in the channel (at start-up)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>maxElements</i>
+ </td>
+ <td colspan="1" rowspan="1">Depth of channel (maximum number of elements that may be stored)</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.12.4">3.12.4 </a>Data Types</h3>
+
+
+<h4><a id="section3.12.4.1"></a>General Information</h4>
+ <p>The AMALTHEA data model supports meta information for base data types. Therefore the element
+ <i>BaseTypeDefinition</i> exists in the software part of the model. It consists of the name and number of bits to define a data type. Additional information to store is the mapping information of these data types for a target platform, represented by the
+ <i>DataPlatformMapping</i> element, like AUTOSAR or any other one.
+ </p>
+ <p>The compound data types are data structures, based on given or defined base types.
+ <br>In the literature they are also often named composite or derived types
+ <a href="http://en.wikipedia.org/wiki/Data_type" shape="rect">see Wiki</a>.
+ <br>The result of this type of definition is an own data type, which can be used as base data types.
+ <br>They can consist of static structures or dynamic ones, like arrays or stacks.
+ </p>
+ <p>
+ <img src="images/model_sw_type_system.png"/>
+ </p>
+ <p>The following compound data type definitions are currently supported:</p>
+ <ul>
+ <li>Pointer: Holds a reference to another type using its memory address</li>
+ <li>Array: Contains a number of elements of the same data type. The size of an array can be fixed or expandable.</li>
+ <li>Struct: Contains other data types in a structured way, often called fields or members. The fields can be accessed by their name.</li>
+ </ul>
+
+
+<h4><a id="section3.12.4.2"></a>Sample</h4>
+ <p>In the picture below a small sample is modeled containing the following information:</p>
+ <ul>
+ <li>Boolean type with size of 8 bits and platform mapping for AR (Boolean) and C (bool)</li>
+ <li>Char16 type with size of 16 bits and platform mapping for AR (Char16) and C (short)</li>
+ <li>charArray consists of 4 elements of type Char16</li>
+ <li>"hello world struct" with the attribute name (Char16) and valid (Boolean)</li>
+ </ul>
+ <p>Note: The picture shows the activated element types for better understanding!</p>
+ <p>
+ <img class="gray" src="images/model_sw_type_sample.png"/>
+ </p>
+
+
+<h3><a id="section3.12.5">3.12.5 </a>Activations</h3>
+ <p>Activations are used to specify the intended activation behavior of
+ <i>Runnables</i> and
+ <i>ProcessPrototypes</i>. Typically they are defined before the creation of tasks (and the runnable to task mappings). So if there are no tasks defined, or if the mapping of runnables to tasks is not done, this is a way to document when the runnables should be executed.
+ <br>Activations are independent of other top level elements in the AMALTHEA model. Single, periodic, sporadic or custom (free textual description) activation pattern can be defined. This information can be used in the following development steps to create tasks, stimuli and the mappings to dedicated hardware.
+ </p>
+ <p>
+ <img src="images/model_sw_activation.png"/>
+ </p>
+
+
+<h3><a id="section3.12.6">3.12.6 </a>Runnables and Services</h3>
+ <p>Both elements, runnables and services, are an abstraction of an executable entity. They are both represented by the
+ <i>Runnable</i> element and are distinguished by using the service attribute of type boolean.
+ <br>Instead of tasks, which are providing a context for the operating system, runnables and services are including the instructions to perform. They include an abstraction of these instructions using different algorithms, based on performance data.
+ <br>The difference between runnables and functions is based on their activation and type of calling. While the initial activation of a runnable can only be performed by a task or another runnable, services can only be activated by runnables or other services.
+ <br>Runnables and Services in the AMALTHEA model currently have no call parameters.
+ <i>Remark: Under discussion for one of the next releases.</i>
+ </p>
+ <p>Based on these types of information, an additional analysis can be performed.
+ <br>The next picture is showing the call graph of task, runnable and services.
+ </p>
+ <p>
+ <img src="images/model_sw_call_graph.png"/>
+ </p>
+
+
+<h3><a id="section3.12.7">3.12.7 </a>Runnables</h3>
+ <p>The next picture shows the general structure of the
+ <i>Runnable</i> element.
+ </p>
+ <p>
+ <img src="images/model_sw_runnable_overview.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>callback</i>
+ </td>
+ <td colspan="1" rowspan="1">
+ <i>True</i> if a runnable is used as a callback
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>service</i>
+ </td>
+ <td colspan="1" rowspan="1">
+ <i>True</i> if
+ <i>Runnable</i> element can be seen in a service or global function manner. In more detail, the
+ <i>Runnable</i> is only called from other
+ <i>Runnables</i> and not directly from a
+ <i>Task</i> context.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>deadline</i>
+ </td>
+ <td colspan="1" rowspan="1">Information in
+ <i>Time</i> at which the element must be finished / terminated.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>runnableItems</i>
+ </td>
+ <td colspan="1" rowspan="1">List containing
+ <i>RunnableItem</i> objects, representing instructions, label accesses, other
+ <i>Runnable</i> accesses. The possibilities are described below.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>tags</i>
+ </td>
+ <td colspan="1" rowspan="1">Can be used to annotate or group special kind of
+ <i>Runnables</i>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>activation</i>
+ </td>
+ <td colspan="1" rowspan="1">Although runnables in the simulation can be only activated by tasks, it is possible to specify an activation pattern for a runnable.</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.12.8">3.12.8 </a>Runnable Items</h3>
+ <p>The
+ <i>RunnableItems</i> are describing the detailed behavior of a
+ <i>Runnable</i> element. This can be either an abstraction of instructions by representing the used running time or representing access to other elements like
+ <i>Runnables</i>,
+ <i>Labels</i> and
+ <i>Semaphore</i>. An overview of the different possibilities is given in the next pictures.
+ </p>
+
+
+<h4><a id="section3.12.8.1"></a>Groups</h4>
+ <p>
+ <img src="images/model_sw_runnable_items_1_group.png"/>
+ </p>
+ <p>A
+ <i>Group</i> is used to structure the
+ <i>RunnableItems</i>. The
+ <i>boolean</i> attribute
+ <i>isOrdered</i> indicates if the execution order of the contained elements is fixed or random.
+ </p>
+
+
+<h4><a id="section3.12.8.2"></a>Calls and AUTOSAR communication</h4>
+ <p>
+ <img class="scale" src="images/model_sw_runnable_items__calls.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>RunnableCall</i>
+ </td>
+ <td colspan="1" rowspan="1">The activation of another
+ <i>Runnable</i>.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>ServerCall</i>
+ </td>
+ <td colspan="1" rowspan="1">An abstract description for client/server communication. It refers to a required runnable that describes the called server operation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>SenderReceiverCommunication</i>
+ </td>
+ <td colspan="1" rowspan="1">An abstract description for sender-receiver-communication (it can be read or write). If the access has to be buffered is represented using the values of
+ <i>LabelAccessBuffering</i>.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.12.8.3"></a>Label Access</h4>
+ <p>
+ <img class="scale" src="images/model_sw_runnable_items__label_access.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>access</i>
+ </td>
+ <td colspan="1" rowspan="1">The type of access is represented using the values of
+ <i>LabelAccessEnum</i>.
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>data</i>
+ </td>
+ <td colspan="1" rowspan="1">Describes the access to an existent
+ <i>Label</i> (set as reference).
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>dataStability</i>
+ </td>
+ <td colspan="1" rowspan="1">Describes the data stability needs. If set, it overwrites the label settings, otherwise it inherits them (see <a href="#os-data-consistency" shape="rect">OS Data Consistency</a>).</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>statistic</i>
+ </td>
+ <td colspan="1" rowspan="1">Defines the frequency of the label access.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>transmissionPolicy</i>
+ </td>
+ <td colspan="1" rowspan="1">The following attributes reflect the computing demand (time) depending on data: <ul><li>
+ <strong>chunkSize</strong>: Size of a part of an element, maximum is the element size. </li><li>
+ <strong>chunkProcessingInstructions</strong>: Number of instructions that will be executed to transmit one chunk. </li></ul> The next attribute specifies the amount of data actually accessed by a runnable (required to analyze memory bandwidth demands): <ul><li>
+ <strong>transmitRatio</strong>: Specify the ratio of each element that is actually transmitted by the runnable in percent. Value must be between [0, 1], default value is 1.0. </li></ul>
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.12.8.4"></a>Channel Access</h4>
+ <p>
+ <img src="images/model_sw_runnable_items__channel_access.png"/>
+ </p>
+ <p>Common attributes:</p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>data</i>
+ </td>
+ <td colspan="1" rowspan="1">Describes the access (
+ <i>ChannelSend</i> or
+ <i>ChannelReceive</i>) to an existent
+ <i>Channel</i> (set as reference).
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>elements</i>
+ </td>
+ <td colspan="1" rowspan="1">Maximum number of elements that are transmitted.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>transmissionPolicy</i>
+ </td>
+ <td colspan="1" rowspan="1">The following attributes reflect computing demand (time) depending on data: <ul><li>
+ <strong>chunkSize</strong>: Size of a part of an element, maximum is the element size. </li><li>
+ <strong>chunkProcessingInstructions</strong>: Number of instructions that will be executed to send / receive one chunk. </li></ul> The next attribute specifies the amount of data actually accessed by a runnable (required to analyze memory bandwidth demands): <ul><li>
+ <strong>transmitRatio</strong>: Specify the ratio of each element that is actually transmitted by the runnable in percent. Value must be between [0, 1], default value is 1.0. </li></ul>
+ </td>
+ </tr>
+ </table>
+ <p>Receive attributes:</p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>receiveOperation</i>
+ </td>
+ <td colspan="1" rowspan="1">The type of an operation is defined by LIFO or FIFO, Read or Take: <ul><li>
+ <strong>LIFO</strong>: last-in, first-out </li><li>
+ <strong>FIFO</strong>: first-in, first-out </li><li>
+ <strong>Read</strong>: reads elements (without modifying the channel content) </li><li>
+ <strong>Take</strong>: removes the received elements </li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>elementIndex</i>
+ </td>
+ <td colspan="1" rowspan="1">Position (index) in channel at which the operation is effective. Zero is the default and denotes the oldest (FIFO) or newest element (LIFO) in the channel.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>lowerBound</i>
+ </td>
+ <td colspan="1" rowspan="1">Minimum number of elements returned by the operation. The value must be in the range [0,n], with n is the maximum number of elements that are received. Default value is n.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>dataMustBeNew</i>
+ </td>
+ <td colspan="1" rowspan="1">Specify if the operation must only return elements that are not previously read by the runnable. Default value is false.</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.12.8.5"></a>Semaphore Access</h4>
+ <p>
+ <img src="images/model_sw_runnable_items_3_semaphores.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>SemaphoreAccess</i>
+ </td>
+ <td colspan="1" rowspan="1">Represents an access of a Semaphore. The type of access is defined using the
+ <i>SemaphoreAccessEnum</i> values. The
+ <i>Semaphore</i> itself is set as a reference to an existent one.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.12.8.6"></a>Mode Label Access</h4>
+ <p>
+ <img src="images/model_sw_runnable_items_4_modes.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>ModeLabelAccess</i>
+ </td>
+ <td colspan="1" rowspan="1">Describes the access to an existing
+ <i>ModeLabel</i> (set as reference). The type of access is represented using the values of
+ <i>LabelAccessEnum</i>:
+ <code>write</code> represents the change of a mode label. The defined
+ <i>ModeLiteral</i> is set.
+ <code>read</code> indicates that the behavior of the runnable is influenced by the current value of the
+ <i>ModeLabel</i>.
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.12.8.7"></a>Runnable Mode Switch</h4>
+ <p>With the
+ <i>RunnableModeSwitch</i> it is possible to define different execution paths. They can be used like
+ <i>if-else</i> or
+ <i>switch-case</i> statements in a programming language. A
+ <i>RunnableModeSwitch</i> uses the value of a
+ <i>ModeLabel</i> (with the help of
+ <i>ModeValueProvider</i>) to decide which path has to be executed.
+ <br>A
+ <i>ModeSwitchEntry</i> object is referenced to represent the different paths and each entry defines the value the mode must have to execute the path with the help of the
+ <i>ModeLiteral</i> values.
+ <br>At the
+ <i>RunnableModeSwitch</i> it is also possible to define a default path, which is executed if none of the
+ <i>ModeSwitchEntries</i> fits to the current set value of the mode.
+ </p>
+ <p>
+ <img src="images/model_sw_runnablemodeswitch.png"/>
+ </p>
+
+
+<h4><a id="section3.12.8.8"></a>Runnable Probability Switch</h4>
+ <p>Each entry (path) of a
+ <i>Runnable Probability Switch</i> has a probability-value. As the name indicates, this is the value that defines the probability that the path is executed. It is computed as a fraction of its value divided by the sum of all
+ <i>Probability Switch Entries</i> in the surrounding switch.
+ </p>
+ <p>
+ <img src="images/model_sw_runnableprobabilityswitch.png"/>
+ </p>
+
+
+<h4><a id="section3.12.8.9"></a>Runnable Instructions</h4>
+ <p>
+ <i>Runnable Instructions</i> allow to specify the default instructions and (optional) the instructions for specific core types (e.g. FPGA). These extended instructions are implemented as a map with the core type as the key.
+ </p>
+ <p>
+ <img src="images/model_sw_runnableinstructions.png"/>
+ </p>
+
+
+<h4><a id="section3.12.8.10"></a>Statistical Values</h4>
+ <p>
+ <img src="images/model_sw_statistic.png"/>
+ </p>
+ <p>It is possible to add to different elements (as shown in the picture above) different types of statistical values. These values can be used to describe in more detail the following behaviors:</p>
+ <ul>
+ <li>
+ <i>RunEntityCallStatistic</i>: Can be used to describe in more detail the dynamic call behavior of a [
+ <i>Task</i> -
+ <i>Runnable</i>] or [
+ <i>Runnable</i> -
+ <i>Runnable</i>] call. The value is representing how often the call is performed.
+ </li>
+ <li>
+ <i>LabelAccessStatistic</i>: Describes in more detail the dynamic behavior accessing a
+ <i>Label</i> by having cache misses or how often a read/write is performed.
+ </li>
+ <li>
+ <i>InstructionFetch</i>: Describes the behavior to fetch instructions from the memory.
+ </li>
+ </ul>
+
+
+<h3><a id="section3.12.9">3.12.9 </a>Tasks / ISR</h3>
+ <p>The following figure shows the structure which describes
+ <i>Tasks</i> and Interrupt Service Routines (
+ <i>ISR</i>) in the AMALTHEA software model. The abstract class
+ <i>Process</i> generalizes ISRs and Tasks and provides the common attributes, like priority for priority based scheduling algorithms or the activation represented by the
+ <i>Stimulus</i>. A
+ <i>Task</i> or
+ <i>ISR</i> contains
+ <i>calls</i> either to other Tasks or Runnables. These types of
+ <i>calls</i> are included in the
+ <i>callGraph</i> attribute.
+ </p>
+ <p>
+ <img class="scale" src="images/model_sw_task_isr.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">Name of the process</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>priority</i>
+ </td>
+ <td colspan="1" rowspan="1">Priority of the process for priority based scheduling.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>osekTaskGroup</i>
+ </td>
+ <td colspan="1" rowspan="1">Priority for defining groups of tasks according OSEK</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>callGraph</i>
+ </td>
+ <td colspan="1" rowspan="1">List of task calls. This specifies the behavior of the process. The objects will be executed in the same order they are stored in the list.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>preemption</i>
+ </td>
+ <td colspan="1" rowspan="1">Defines the preemption of a task by higher priority tasks.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>multipleTaskActivationLimit</i>
+ </td>
+ <td colspan="1" rowspan="1">Defines the maximal number of existing instances from the same task, which is checked for load limitation reasons when a task is activated. For the case of an exceeded multipleTaskActivationLimit, the activation is ignored.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>stimuli</i>
+ </td>
+ <td colspan="1" rowspan="1">Reference to one or more
+ <i>Stimuli</i> representing the different types of possible activations of this
+ <i>Task</i>
+ </td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.12.10">3.12.10 </a>The Call Graph</h3>
+ <p>The
+ <i>Call Graph</i> is used to define how a
+ <i>Task</i> or
+ <i>ISR</i> behaves during its execution. For that it contains two different kinds of elements,
+ <i>Call Sequences</i> and
+ <i>Switches</i>. The following picture shows the data structure of a
+ <i>Call Graph</i>:
+ </p>
+ <p>
+ <img class="scale" src="images/model_sw_task_callgraph.png"/>
+ </p>
+ <p>The
+ <i>Call Graph</i> contains a list of elements of type
+ <i>GraphEntryBase</i>. This is the basic, abstract type for the
+ <i>Switch</i> types and for the
+ <i>Call Sequence</i>. With the
+ <i>Switches</i> it is possible to define different execution paths. They can be used like
+ <i>if-else</i> or
+ <i>switch-case</i> statements in a programming language. There are two different kind of
+ <i>Switches</i>, a
+ <i>Mode Switch</i> and a
+ <i>Probability Switch</i>. Each
+ <i>Switch</i> contains a number
+ <i>Switch Entry</i> objects. These are the different possible program paths that can be executed. Also like the
+ <i>Call Graph</i>, the
+ <i>Switch Entry</i> can contain a list of objects that can be
+ <i>Switches</i> or
+ <i>Call Sequences</i>.
+ </p>
+
+
+<h4><a id="section3.12.10.1"></a>Mode Switch</h4>
+ <p>A
+ <i>Mode Switch</i> uses the value of a
+ <i>Mode Label</i> to decide which entry has to be executed. Therefore a
+ <i>Mode Label</i> object is referenced (via ModeValueProvider) and each entry defines the values the mode label must have to execute the path.
+ </p>
+ <p>
+ <img class="scale" src="images/model_sw_modeswitch.png"/>
+ </p>
+
+
+<h4><a id="section3.12.10.2"></a>Probability Switch</h4>
+ <p>Each entry (path) of a
+ <i>Probability Switch</i> has a probability-value. As the name indicates, this is the value that defines the probability that the path is executed. It is computed as a fraction of its value divided by the sum of all
+ <i>Probability Switch Entries</i> in the surrounding switch.
+ </p>
+ <p>
+ <img class="scale" src="images/model_sw_probabilityswitch.png"/>
+ </p>
+
+
+<h4><a id="section3.12.10.3"></a>Call Sequence</h4>
+ <p>A
+ <i>Call Sequence</i> contains a list of elements that are executed by the
+ <i>Process</i>. The following list gives a short overview over these elements:
+ </p>
+ <ul>
+ <li>
+ <i>Wait Event</i>: Wait for an
+ <i>OS-Event</i>
+ </li>
+ <li>
+ <i>Clear Event</i>: Clear an
+ <i>OS-Event</i>
+ </li>
+ <li>
+ <i>Set Event</i>: Set/Fire an
+ <i>OS-Event</i>
+ </li>
+ <li>
+ <i>Enforced Migration</i>: Migrate to another
+ <i>Scheduler</i>
+ </li>
+ <li>
+ <i>Inter Process Activation</i>: Activate a
+ <i>Process</i>
+ </li>
+ <li>
+ <i>Schedule Point</i>: Trigger the Scheduler
+ </li>
+ <li>
+ <i>Task Runnable Call</i>: Invoke a
+ <i>Runnable</i>
+ </li>
+ </ul>
+ <p>The following picture shows the structure of a
+ <i>Call Graph</i>. The graph is like a tree of
+ <i>Call Sequences</i> and
+ <i>Switches</i>. The
+ <i>Call Sequences</i> are used to define what the task is actually executing. With the
+ <i>Switches</i> it is possible to define alternative execution paths. The elements of the graph are executed in the order they are stored in the data model. The same goes for the elements within a
+ <i>Call Sequence</i>.
+ </p>
+ <p>
+ <img src="images/model_sw_task_callgraph_structure.png"/>
+ </p>
+
+
+<h3><a id="section3.12.11">3.12.11 </a>Call Sequence Content</h3>
+ <p>As already explained, the content of a
+ <i>Call Sequence</i> specifies what a process is actually doing when it is executed.
+ <br>This section describes the different entry-types of a
+ <i>Call Sequence</i>.
+ </p>
+
+
+<h4><a id="section3.12.11.1"></a>Task Runnable Call</h4>
+ <p>With the
+ <i>Task Runnable Call</i> the process executes a specific runnable.
+ </p>
+
+
+<h4><a id="section3.12.11.2"></a>Enforced Migration</h4>
+ <p>Each process is controlled by at least one scheduler. A scheduler is the resource owner of one or multiple processor cores (The scheduler decides on which of its cores the process is executed). The
+ <i>Enforced Migration</i> forces the process to switch to another scheduler. Therefore the
+ <i>Enforced Migration</i> entry contains a reference to the new scheduler.
+ </p>
+
+
+<h4><a id="section3.12.11.3"></a>Inter Process Activation</h4>
+ <p>The
+ <i>Inter Process Activation</i> references a stimulus of type
+ <i>Inter Process</i>. The execution of an
+ <i>Inter Process Activation</i> entry triggers the processes that are mapped to this stimulus.
+ </p>
+
+
+<h4><a id="section3.12.11.4"></a>Schedule Point</h4>
+ <p>At a
+ <i>Schedule Point</i>, the process calls the scheduler that currently administrates it. This is used for cooperative task scheduling (see OSEK Specification 2.2.3, 2005).
+ </p>
+
+
+<h4><a id="section3.12.11.5"></a>Terminate Process</h4>
+ <p>If a
+ <i>Terminate Process</i> is reached during the execution of a
+ <i>Call Graph</i>, the
+ <i>Task</i> or
+ <i>ISR</i> terminates immediately. It is not required to insert this element at the end of a
+ <i>Call Graph</i>. It can be used to define an execution path (by using
+ <i>Switches</i>) that terminates a process.
+ </p>
+
+
+<h4><a id="section3.12.11.6"></a>Wait/Clear/Set Event</h4>
+ <p>The AMALTHEA Software Model contains a list of
+ <i>OS-Event</i> objects. These can be used for task synchronization. To deal with
+ <i>OS-Events</i> a
+ <i>Call Sequence</i> can execute the elements
+ <i>Wait Event</i>,
+ <i>Clear Event</i> and
+ <i>Set Event</i>.
+ </p>
+ <p>
+ <img src="images/model_sw_osevents.png"/>
+ </p>
+ <p>With
+ <i>Wait Event</i> the process waits for a number of events (defined in the
+ <i>Event Mask</i>) to be set. Here it can be defined if the process waits just for one of the
+ <i>OS-Events</i> (maskType = OR) or for all of them (maskType = AND). The
+ <i>waiting behavior</i> defines if the process is blocking the core when it waits (active) or not (passive).
+ </p>
+ <p>
+ <i>Set Event</i> sets/fires a list of
+ <i>OS-Events</i>. Here it is possible to define a context for the
+ <i>OS-Event</i>. If a process is referenced, then the
+ <i>OS-Events</i> are set just for this process.
+ </p>
+ <p>The execution of a
+ <i>Clear Event</i> entry unsets all referenced
+ <i>OS-Events</i>.
+ </p>
+ <p>For more information about OS-Events, see the OSEK Specification 2.2.3, 2005. </p>
+
+
+<h3><a id="section3.12.12">3.12.12 </a>Modes</h3>
+
+
+<h4><a id="section3.12.12.1"></a>Modes and Mode Labels</h4>
+ <p>The
+ <i>Mode</i> element denotes a specific system state. It is described using the following attributes:
+ </p>
+ <p>
+ <img class="scale" src="images/model_sw_modes.png"/>
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">Name of the mode</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>literals</i>
+ </td>
+ <td colspan="1" rowspan="1">Enumeration values of the mode</td>
+ </tr>
+ </table>
+ <p>Modes are used in
+ <i>Mode Switches</i> inside the
+ <i>Call Graph</i> of
+ <i>Tasks</i> and
+ <i>ISRs</i> using
+ <i>Mode Labels</i>. Moreover, mode labels are used to enable and disable
+ <i>Stimuli</i>.
+ </p>
+ <p>The
+ <i>Mode Label</i> element represents a value of a specific
+ <i>Mode</i>. Is is described using the following attributes:
+ </p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">Name of the mode label</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>displayName</i>
+ </td>
+ <td colspan="1" rowspan="1">In addition to the name attribute, which must be unique, a mode label can also be described by an additional and optional display name. The displayName attribute must not be unique. It can be used for example to represent specification data, which can be different from the unique name (like a symbol) of an available software build.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>mode</i>
+ </td>
+ <td colspan="1" rowspan="1">Reference of the
+ <i>Mode</i>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>initialValue</i>
+ </td>
+ <td colspan="1" rowspan="1">Initial value of the referenced mode</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section3.12.12.2"></a>Mode Changes</h4>
+ <p>The value of the mode label can be changed from it's initial value using the set-mode-labels-list of a
+ <i>Stimulus</i>.
+ </p>
+ <p>Another possibility is a write access within a Runnable via
+ <i>Mode Label Access</i>.
+ </p>
+
+
+<h3><a id="section3.12.13">3.12.13 </a>Process Prototypes</h3>
+ <p>
+ <img class="scale" src="images/model_sw_process_prototype.png"/>
+ </p>
+ <p>In addition to the Task elements, the AMALTHEA model contains an element process prototype.
+ <br>This prototype can be used to define raw data of a task. It can be used to specify access to
+ <br>labels (read, write) or other runnables/functions as possible with the normal task, but not the
+ <br>order of the access. These prototypes are then processed by different algorithms. The algorithms are creating the tasks, are filling, verifying or modifying the data based on their different checks. The final result of this processing are tasks, which are corresponding to the data of the prototypes.
+ </p>
+ <p>
+ <img src="images/process_prototypes.png"/>
+ </p>
+ <p>These tasks are representing the current state and can be further processed, for example to generate code or further simulation. With the process prototypes available in the model, it is possible to define the structure of the software in an early development phase. The implementation at that moment is open and not yet completed, but the general idea can be verified.
+ <br>Another issue can be the distribution to a multi-core system, coming from a single-core system. Therefore the call graph can be analyzed and computed to get the right order and parallelization of the elements and dependencies.
+ </p>
+
+
+<h3><a id="section3.12.14">3.12.14 </a>Process Chains</h3>
+ <p>The following figure shows the structure which describes
+ <i>Process Chains</i> in the AMALTHEA software model. A process chain is used to group task and isrs together which are executing after each other and represent an end-to-end data processing path. The processes inside a process chain are connected via
+ <i>Inter Process Activations</i>.
+ </p>
+ <p>The following attributes are describing a process chain:</p>
+ <table class="minimal" style="padding:10px; border:1px solid black; background:#f8f8f8">
+ <tr>
+ <th colspan="1" rowspan="1">Name</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>name</i>
+ </td>
+ <td colspan="1" rowspan="1">Name of the process chain</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <i>processes</i>
+ </td>
+ <td colspan="1" rowspan="1">List of tasks and isrs which are included in the process chain</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section3.12.15">3.12.15 </a>Custom Entities</h3>
+ <p>
+ <img src="images/model_custom_entity.png"/>
+ </p>
+ <p>The
+ <i>CustomEntity</i> element defines a way to add not yet available elements of the software model in a generic way. The only contained attribute defines the type of the entity by setting it as a
+ <i>String</i>. Additional properties can be set using the
+ <i>CustomAttributes</i>.
+ </p>
+
+
+<h3><a id="section3.12.16">3.12.16 </a>Section</h3>
+ <p>Section (Vitual Memory Section) is used to group the memory elements (Labels, Runnables). This is acheived by associating the
+ <strong>Section</strong> element to
+ <strong>Label</strong> &
+ <strong>Runnable</strong> elements
+ </p>
+ <p>Below are properties of Section element:</p>
+ <ul>
+ <li>name</li>
+ <li>asilLevel</li>
+ </ul>
+ <p>
+ <img src="images/model_section.png"/>
+ </p>
+ <p>With this type of information available, the complexity of mapping software components to memories can be reduced. The next picture gives an overview about the general idea of the mapping with Sections.</p>
+ <p>
+ <img src="images/model_section_memory.png"/>
+ </p>
+</article>
+
+
+<article>
+<h1><a id="section4">4 </a>Developer Guide</h1>
+
+
+<h2><a id="section4.1">4.1 </a>Overview of Features and Plug-ins</h2>
+
+
+<h3><a id="section4.1.1">4.1.1 </a>Features</h3>
+ <p>There are two top-level features of the AMALTHEA Tool Platform, the AMALTHEA Tool Platform and the AMALTHEA Tool Platform SDK features. The non-SDK feature contains everything you need to run the AMALTHEA tools and models. If you like to develop new tools on top of the models or extend the models you may need the SDK. It contains beside the runtime all sources.</p>
+ <p>The top-level feature itself contains basic platform plug-ins and tools as well as several sub-features. These are</p>
+ <ul>
+ <li>APP4MC Platform – Platform (includes all features and 3rd party libraries).</li>
+ <li>APP4MC Docu – Basic Help (is extended by loading other features).</li>
+ <li>APP4MC Examples – Examples that can be added by the example wizard.</li>
+ </ul>
+ <ul>
+ <li>APP4MC Multicore – Algorithms for multicore develepment like partitioning and mapping.</li>
+ <li>APP4MC Tracing – Record, analyze and transform runtime traces of the embedded system.</li>
+ <li>APP4MC Validation – Model validations (an be selected and executed on demand).</li>
+ </ul>
+ <ul>
+ <li>AMALTHEA Models – AMALTHEA models (EMF).</li>
+ <li>AMALTHEA Edit – AMALTHEA model edit support.</li>
+ <li>AMALTHEA Editors – Editors for the models.</li>
+ </ul>
+ <ul>
+ <li>AMALTHEA Converters – Independent feature for AMALTHEA model migration.</li>
+ </ul>
+ <ul>
+ <li>AMALTHEA Workflow Common – Basic elements to define workflows on the model.</li>
+ <li>AMALTHEA Workflow – Defining workflows (based on MWE2 workflow engine).</li>
+ <li>AMALTHEA Workflow Scripting – Defining workflows (based on EASE scripting).</li>
+ </ul>
+ <ul>
+ <li>AMALTHEA Import – Import of the models.</li>
+ <li>AMALTHEA Export – Exports of the models.</li>
+ </ul>
+ <p>
+ <img src="images/app4mc_platform_features.png"/>
+ </p>
+ <p>For all features there also exists an SDK containing the sources. If you install the AMALTHEA Tool Platform SDK, it contains all features as SDKs.</p>
+
+
+<h3><a id="section4.1.2">4.1.2 </a>Plug-ins</h3>
+ <p>The plug-ins are organized in various namespaces. The id's of most plug-ins containing models are within the namespace
+ <code>org.eclipse.app4mc.amalthea.model</code>, whereas examples can be found in plug-ins named
+ <code>org.eclipse.app4mc.amalthea.example</code>.
+ </p>
+
+
+<h2><a id="section4.2">4.2 </a>Model Validation</h2>
+ <p>AMALTHEA uses for custom model validations the
+ <a href="https://projects.eclipse.org/projects/modeling.mdt.sphinx" shape="rect">Sphinx validation project</a> which is based on
+ <a href="http://www.eclipse.org/modeling/emf/?project=validation" shape="rect">EMF validation </a>.
+ </p>
+
+
+<h3><a id="section4.2.1">4.2.1 </a>Understanding Check Catalogs</h3>
+ <p>A Sphinx validator optionally makes use of a Catalog. When a catalog is used, each @Check annotations should have a
+ <i>constraint name</i> (which can be seen as unique id) to match a constraint in the catalog. So there is a logical mapping from methods to constraints. For a constraint to be applicable within the scope of a validator, the set of categories specified in its @Check annotation should be a subset of the set of categories referenced by the constraint in the check catalog. In other words, categories are used to restrict applicability to check methods.
+ </p>
+ <p>Following catalog is going to demonstrate the relationship between categories and constraint. </p>
+ <p>
+ <img class="gray" src="images/2015-06-19_sphinx_validation_catalog.png"/>
+ </p>
+ <p>Except for constraint
+ <i>check 5</i> each other constraint is assigned to at least one category. Constraints
+ <i>check 4</i> and
+ <i>check 5</i> are linked to multiple categories.
+ </p>
+ <p>Hint: The assignment from constraint to one or more categories could also be done in the @Check annotation itself.</p>
+
+
+<h3><a id="section4.2.2">4.2.2 </a>Adding own Validations</h3>
+ <p>Adding an own validation to the AMALTHEA framework can be done by the following steps:</p>
+
+
+<h3><a id="section4.2.3">4.2.3 </a>Plugin dependencies</h3>
+ <p>org.eclipse.core.runtime,
+ <br>org.eclipse.sphinx.emf,
+ <br>org.eclipse.sphinx.emf.check,
+ <br>org.eclipse.app4mc.amalthea.model.common,
+ <br>org.eclipse.app4mc.amalthea.model.central,
+ <br>org.eclipse.app4mc.amalthea.model.central.sphinx.ui,
+ <br>org.eclipse.app4mc.amalthea.model.config,
+ <br>org.eclipse.app4mc.amalthea.model.constraints,
+ <br>org.eclipse.app4mc.amalthea.model.events,
+ <br>org.eclipse.app4mc.amalthea.model.hw,
+ <br>org.eclipse.app4mc.amalthea.model.mapping,
+ <br>org.eclipse.app4mc.amalthea.model.os,
+ <br>org.eclipse.app4mc.amalthea.model.propertyconstraints,
+ <br>org.eclipse.app4mc.amalthea.model.stimuli,
+ <br>org.eclipse.app4mc.amalthea.model.sw
+ </p>
+
+
+<h4><a id="section4.2.3.1"></a>Implementation</h4>
+ <p>Create a class which is extending
+ <code>org.eclipse.sphinx.emf.check.AbstractCheckValidator</code> and implement a method of arbitrary name and tag it with the
+ <code>check</code> annotation. At this point, it is important to know, that at least one parameter is needed for the check method. For instance, if you want to perform a check related to the whole AMALTHEA model you should consider
+ <code>org.eclipse.app4mc.amalthea.model.central.AMALTHEA</code> as parameter type. An empty parameter list will never activate the check for your AMALTHEA model. This raises the capability of an so called out-of-the-box scoping which means that the validation checks only appears on the relevant model elements
+ <br>(e.g. validations related to the AMALTHEA software model may only appear when right-clicking on an appropriate model element of type Software)
+ </p>
+ <pre xml:space="preserve"><code>import org.eclipse.sphinx.emf.check.AbstractCheckValidator;
+import org.eclipse.sphinx.emf.check.Check;
+import org.eclipse.app4mc.amalthea.model.central.AMALTHEA;
+
+
+public class BasicExampleConstraint extends AbstractCheckValidator {
+
+ /**
+ *
+ * constraint:
+ * Must match at least to one existing constraint from the check catalog
+ *
+ * categories:
+ * Is of type array, thus constraint can be assigned to multiple categories
+ *
+ */
+ @Check(constraint = "BasicExampleConstraint", categories = { "BasicCategory", ...and many more ... })
+ void checkVeryImportantConstraint(final AMALTHEA ama)
+ {
+
+ /**
+ * Perform your check
+ */
+
+ error("Error occurs", ama, ama.eContainingFeature());
+ warning("Warning occurs", ama, ama.eContainingFeature());
+ info("Info occurs", ama, ama.eContainingFeature());
+ // Error type information is taken directly from catalog
+ issue(ama, ama.eContainingFeature());
+ }
+}
+</code></pre>
+ <p><!-- --></p>
+ <p>Create your own class and insert at least one method extended by the
+ <code>check</code> Sphinx annotation. The method should contain exactly one parameter of at least the type of the most generic model element of the AMALTHEA model (i.e.
+ <code>org.eclipse.app4mc.amalthea.model.central.AMALTHEA</code>).
+ <br>Implement the validate method by adding your own custom validation.
+ </p>
+
+
+<h4><a id="section4.2.3.2"></a>Plugin configuration</h4>
+ <p>Add an
+ <i>extension point</i> called
+ <code>org.eclipse.sphinx.emf.check.checkvalidators</code> and for each implemented constraint a child entry for your class to the plugin.xml to register it in the Sphinx Validation framework. For each child entry you must specify your constraint class (including @Check annotated methods) and optionally a catalog which contains more detailed information about the composition and relationship between constraints.
+ </p>
+ <p>The current configuration of the AMALTHEA model validations can be found in the plugin
+ <i>org.eclipse.app4mc.amalthea.model.common.validation.sphinx</i> in the
+ <i>plugin.xml</i>.
+ </p>
+ <p>There the constraints section includes the list of available validations and their corresponding implementation class.</p>
+
+
+<h2><a id="section4.3">4.3 </a>Model Workflow</h2>
+
+
+<h3><a id="section4.3.1">4.3.1 </a>Introduction</h3>
+ <p>The APP4MC AMALTHEA platform provides the option to define a workflow on a model with different steps. AMALTHEA provides a simple API for implementing such a workflow. The definition of the workflow can be done either in plain Java or any other language, which is able to access Java classes.
+ <br>The
+ <a href="https://www.eclipse.org/ease/" shape="rect">EASE</a> framework provides a scripting environment inside of Eclipse with different script engines like Rhino (JavaScript), Jython or Groovy. AMALTHEA provides a sample and some convenient helpers based on EASE to define and execute such a workflow.
+ <br>As an alternative APP4MC provides also an implementation for the
+ <a href="http://www.eclipse.org/Xtext/documentation/302_configuration.html" shape="rect">Modeling Workflow Engine 2 (MWE2)</a>, coming from the Xtext framework. The definition of the workflow can be done in a textual syntax from MWE2, containing different components which are working on the given model.
+ <br>AMALTHEA provides several plugins for this purpose:
+ </p>
+ <dl>
+ <dt>org.eclipse.app4mc.amalthea.workflow.core</dt>
+ <dd>Includes basic API and some predefined workflow components, which can be used independent from any framework.</dd>
+ </dl>
+ <dl>
+ <dt>org.eclipse.app4mc.amalthea.workflow.ease</dt>
+ <dd>Provides some helper modules for EASE</dd>
+ </dl>
+ <dl>
+ <dt>org.eclipse.app4mc.amalthea.workflow.base</dt>
+ <dd>Provides basic classes for usage with MWE2</dd>
+ </dl>
+
+
+<h3><a id="section4.3.2">4.3.2 </a>General Structure</h3>
+ <p>The plugin
+ <i>org.eclipse.app4mc.amalthea.workflow.core</i> provides a general abstract class
+ <code>org.eclipse.app4mc.amalthea.workflow.core.WorkflowComponent</code> which can be used to extend in the case to provide or implement an own workflow step.
+ </p>
+ <p>
+ <img src="images/uml_workflow_component.png"/>
+ </p>
+ <p>It provides the following features:</p>
+ <ul>
+ <li>Defines the constant
+ <code>AMALTHEA_SLOT</code>, which can be used to store and retrieve the AMALTHEA model from the
+ <code>org.eclipse.app4mc.amalthea.workflow.core.Context</code>.
+ </li>
+ <li>Provides some convenient methods to retrieve the model from the context, get a copy of the model or store the model in the context.</li>
+ </ul>
+ <p>The interface
+ <code>org.eclipse.app4mc.amalthea.workflow.core.Context</code> provides convenient methods to store and retrieve data in a
+ <code>org.eclipse.app4mc.amalthea.workflow.core.WorkflowComponent</code>.
+ </p>
+ <p>
+ <img src="images/uml_context.png"/>
+ </p>
+ <p>The class
+ <code>org.eclipse.app4mc.amalthea.workflow.core.DefaultContext</code> is a default implementation using an internal
+ <code>java.util.HashMap</code> to store the data.
+ </p>
+ <p>
+ <img src="images/uml_default_context.png"/>
+ </p>
+ <p>A sample workflow implementation with two components
+ <code>WorkfklowComponent1</code> and
+ <code>WorkflowComponent2</code> can look like the following structure.
+ </p>
+ <p>Both classes are extending
+ <code>org.eclipse.app4mc.amalthea.workflow.core.WorkflowComponent</code>.
+ </p>
+ <p>
+ <img src="images/uml_workflow_overview.png"/>
+ </p>
+ <p>The next step is to create a
+ <i>WorkflowDefinition</i>, which needs to do the following steps:
+ </p>
+ <ol>
+ <li>Create an instance of a
+ <code>org.eclipse.app4mc.amalthea.workflow.core.Context</code> using the
+ <code>org.eclipse.app4mc.amalthea.workflow.core.DefaultContext</code>
+ </li>
+ <li>Create an instance of
+ <code>WorkfklowComponent1</code> and configure it if needed with the proper setter methods
+ </li>
+ <li>Call the
+ <i>run</i> method of
+ <code>WorkfklowComponent1</code> and pass the context
+ </li>
+ <li>Create an instance of
+ <code>WorkfklowComponent2</code> and configure it if needed with the proper setter methods
+ </li>
+ <li>Call the
+ <i>run</i> method of
+ <code>WorkfklowComponent2</code> and pass the context
+ </li>
+ </ol>
+ <p>Therefore using the context, data can be shared between the different workflow component implementations.
+ <br>The following diagram is showing this flow in more detail:
+ </p>
+ <p>
+ <img src="images/uml_workflow_overview_sequence.png"/>
+ </p>
+
+
+<h3 id="workflow-basic-components"><a id="section4.3.3">4.3.3 </a>Available Basic Components</h3>
+ <p>The APP4MC AMALTHEA platform ships with some available workflow steps, which can be used out of the box.</p>
+
+
+<h4><a id="section4.3.3.1"></a>Model Reader</h4>
+ <p>The component
+ <code>org.eclipse.app4mc.amalthea.workflow.component.ModelReader</code> reads a given list of files containing AMALTHEA models. The result model is stored in the
+ <code>AMALTHEA_SLOT</code> as default. Please refer the JavaDoc for more details.
+ </p>
+ <p>
+ <img src="images/uml_model_reader.png"/>
+ </p>
+ <p>Simple configuration inside of a workflow can look like the following:</p>
+ <pre xml:space="preserve"><code>ModelReader reader = new ModelReader();
+reader.addFileName("path to file");
+reader.run(ctx);
+</code></pre>
+ <p><!-- --></p>
+
+
+<h4><a id="section4.3.3.2"></a>Model Writer</h4>
+ <p>The component
+ <code>org.eclipse.app4mc.amalthea.workflow.component.ModelWriter</code> writes a given AMALTHEA model to either one file or several files. As default the current available model in the
+ <code>AMALTHEA_SLOT</code> is taken.
+ <br>The following parameters are available to set:
+ </p>
+ <ul>
+ <li>
+ <code>boolean singleFile</code> default
+ <code>true</code>
+ </li>
+ <li>
+ <code>String</code>
+ <code>outputDir</code>
+ </li>
+ <li>
+ <code>String</code>
+ <code>fileName</code>, if output is set to split files the different models are separated by an additional suffix in the name indicating the contained model.
+ </li>
+ </ul>
+ <p>
+ <img src="images/uml_model_writer.png"/>
+ </p>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>ModelWriter writer = new ModelWriter();
+writer.setOutputDir("path to dir");
+writer.setFileName("output.amxmi");
+writer.run(ctx);
+</code></pre>
+ <p><!-- --></p>
+
+
+<h4><a id="section4.3.3.3"></a>Add Schedule Points</h4>
+ <p>The component
+ <code>org.eclipse.app4mc.amalthea.workflow.component.AddSchedulePoints</code> modifies a given model (default in the
+ <code>AMALTHEA_SLOT</code>) in that way, that in the
+ <code>org.eclipse.app4mc.amalthea.model.sw.SWModel</code> the contained
+ <code>org.eclipse.app4mc.amalthea.model.sw.Task</code> elements are checked if the preemption is set to cooperative. If this is the case, it will add between the elements of the
+ <code>org.eclipse.app4mc.amalthea.model.sw.CallGraph</code> new elements of type
+ <code>org.eclipse.app4mc.amalthea.model.sw.SchedulePoint</code>.
+ </p>
+ <p>
+ <img src="images/uml_add_schedule_points.png"/>
+ </p>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>AddSchedulePoints addSchedulePoints = new AddSchedulePoints();
+addSchedulePoints.run(ctx);
+</code></pre>
+ <p><!-- --></p>
+
+
+<h3><a id="section4.3.4">4.3.4 </a>Other Components</h3>
+
+
+<h4><a id="section4.3.4.1"></a>Create Tasks</h4>
+ <p>The component
+ <code>org.eclipse.app4mc.multicore.openmapping.workflow.CreateTasks</code> from the plugin
+ <i>org.eclipse.app4mc.multicore.openmapping</i> is the corresponding workflow element for the
+ <a href="#example-task-creation" shape="rect">Task creation example</a>. It takes a copy of a given model (defaults to
+ <code>AMALTHEA_SLOT</code>) and performs the action
+ <code>org.eclipse.app4mc.multicore.openmapping.algorithms.taskgen.pragmatic.PragmaticTaskCreator</code>. The result of this action is stored as default in the model slot
+ <i>createtasks</i>.
+ </p>
+ <p>
+ <img src="images/uml_create_tasks.png"/>
+ </p>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>CreateTasks ct = new CreateTasks();
+ct.run(ctx);
+</code></pre>
+ <p><!-- --></p>
+
+
+<h4><a id="section4.3.4.2"></a>Generate Mapping</h4>
+ <p>The component
+ <code>org.eclipse.app4mc.multicore.openmapping.workflow.GenerateMapping</code> from the plugin
+ <i>org.eclipse.app4mc.multicore.openmapping</i> is the corresponding workflow element for the
+ <a href="#example-mapping-1" shape="rect">Mapping example</a>. It takes a copy of a given model (defaults to
+ <code>AMALTHEA_SLOT</code>) and performs one of the actions
+ <code>org.eclipse.app4mc.multicore.openmapping.algorithms.heuristic.lb.LoadBalancingDFG</code> or
+ <code>org.eclipse.app4mc.multicore.openmapping.algorithms.ilp.lb.ILPBasedLoadBalancing</code> or
+ <code>org.eclipse.app4mc.multicore.openmapping.algorithms.ilp.energyminimization.EnergyMinimization</code> or
+ <code>org.eclipse.app4mc.multicore.openmapping.algorithms.ga.lb.GABasedLoadBalancing</code> depending on the parameter
+ <code>mappingAlg</code>. The result of this action is stored as default in the model slot
+ <i>mapping</i>.
+ <br>Parameter:
+ </p>
+ <ul>
+ <li>
+ <code>String</code>
+ <code>mappingAlg</code> with the value of either
+ <i>dfg</i> or
+ <i>ilp_lb</i> or
+ <i>ilp_energy</i> or
+ <i>ga_lb</i>
+ </li>
+ </ul>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>GenerateMapping mappingDfg = new GenerateMapping();
+mappingDfg.setModelSlot("createtasks");
+mappingDfg.setMappingAlg("dfg");
+mappingDfg.setEnableLog(true);
+mappingDfg.run(ctx);
+</code></pre>
+ <p><!-- --></p>
+
+
+<h3><a id="section4.3.5">4.3.5 </a>EASE modules</h3>
+ <p>The purpose of using EASE is to provide one way to define and run a workflow for a model.
+ <br>Therefore APP4MC provides some helper methods to be used in the
+ <a href="https://www.eclipse.org/ease/" shape="rect">EASE</a> scripting environment.
+ <br>The modules are provided by the plugin
+ <i>org.eclipse.app4mc.amalthea.workflow.ease</i>.
+ </p>
+
+
+<h4><a id="section4.3.5.1"></a>Workflow Module</h4>
+ <p>The workflow module provides some helpers regarding running a APP4MC workflow definition based on EASE.
+ <br>The general module can be loaded with the following line:
+ </p>
+ <pre xml:space="preserve"><code>loadModule('/APP4MC/Workflow')
+</code></pre>
+ <p>EASE opens an own Eclipse console by default to show the output of the executed script when using right click and
+ <i>Run as -> EASE Script</i>. Therefore if you are using Log4J for your logging, you can use the following provided methods to configure dedicated Log4J Loggers to use also the EASE console for output.
+ </p>
+ <p>The following overview gives an overview about the available helper methods:</p>
+ <table class="minimal">
+ <tr>
+ <th colspan="1" rowspan="1">Method</th>
+ <th colspan="1" rowspan="1">Params</th>
+ <th colspan="1" rowspan="1">Description</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">addLoggerToConsole</td>
+ <td colspan="1" rowspan="1">String loggerName</td>
+ <td colspan="1" rowspan="1">Adds a Log4J logger to the output of the current used output of the EASE script engine.</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">addLoggerToConsole</td>
+ <td colspan="1" rowspan="1">String loggerName, String pattern</td>
+ <td colspan="1" rowspan="1">Adds a Log4J logger to the output of the current used output of the EASE script engine with a given pattern, see
+ <code>org.apache.log4j.PatternLayout</code> for more details
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">endWorkflow</td>
+ <td colspan="1" rowspan="1">-</td>
+ <td colspan="1" rowspan="1">Basic finish actions to be performed, should be called at the end</td>
+ </tr>
+ </table>
+
+
+<h3><a id="section4.3.6">4.3.6 </a>MWE2 Workflow</h3>
+ <p>The plugin
+ <i>org.eclipse.app4mc.amalthea.workflow.base</i> provides a general class
+ <code>org.eclipse.app4mc.amalthea.workflow.base.AmaltheaWorkflow</code> which can be used to extend in the case to provide or implement an own workflow step based on
+ <a href="http://www.eclipse.org/Xtext/documentation/302_configuration.html" shape="rect">Modeling Workflow Engine 2 (MWE2)</a>.
+ <br>It provides the following features:
+ </p>
+ <ul>
+ <li>Extends
+ <code>org.eclipse.emf.mwe.core.lib.WorkflowComponentWithModelSlot</code>
+ </li>
+ <li>Defines the constant AMALTHEA_SLOT, which can be used to store and retrieve the AMALTHEA model from the
+ <code>org.eclipse.emf.mwe.core.WorkflowContext</code>.
+ </li>
+ <li>Provides some convenient methods to retrieve the model from the context, get a copy of the model or store the model in the context.</li>
+ </ul>
+ <p>
+ <img src="images/uml_workflow_component_mwe2.png"/>
+ </p>
+ <p>To use the AMALTHEA model workflow component, currently the following dependencies are needed in addition to the AMALTHEA model plugins:</p>
+ <ul>
+ <li>org.eclipse.app4mc.amalthea.workflow.base</li>
+ <li>org.eclipse.emf.mwe2.lib</li>
+ <li>org.eclipse.emf.mwe2.launch</li>
+ <li>org.apache.log4j</li>
+ </ul>
+
+
+<h4><a id="section4.3.6.1"></a>MWE2 Components</h4>
+ <p>The APP4MC AMALTHEA platform ships with some available workflow steps for usage together with MWE2.
+ <br>Note: To use the components below as shown in the corresponding configurations, the classes must be imported!
+ </p>
+
+
+<h5><a id="section4.3.6.1.1"></a>Reader</h5>
+ <p>The component
+ <code>org.eclipse.app4mc.amalthea.workflow.util.AmaltheaReader</code> reads a given list of files containing AMALTHEA models. The result model is stored in the
+ <i>AMALTHEA_SLOT</i> as default.
+ </p>
+ <p>
+ <img src="images/uml_model_reader_mwe2.png"/>
+ </p>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>component = AmaltheaReader {
+ fileName = "${base}/model/AMALTHEA_Democar_MappingExample.amxmi"
+ fileName = "${base}/model/AMALTHEA_Democar_MappingExample-hw.amxmi"
+}
+</code></pre>
+
+
+<h5><a id="section4.3.6.1.2"></a>Writer</h5>
+ <p>The component
+ <code>org.eclipse.app4mc.amalthea.workflow.util.AmaltheaWriter</code> writes a given AMALTHEA model to either one file or several files. As default the current available model in the
+ <i>AMALTHEA_SLOT</i> is taken.
+ <br>The following parameters are available to set:
+ </p>
+ <ul>
+ <li>boolean singleFile default true</li>
+ <li>String outputDir</li>
+ <li>String fileName, if output is set to split files the different models are separated by an additional suffix in the name indicating the contained model.</li>
+ </ul>
+ <p>
+ <img src="images/uml_model_writer_mwe2.png"/>
+ </p>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>component = AmaltheaWriter {
+ fileName = "createtasks"
+ singleFile = true
+ outputDir = "${base}/workflow-output"
+}
+</code></pre>
+
+
+<h5><a id="section4.3.6.1.3"></a>Add Schedule Points</h5>
+ <p>The component
+ <code>org.eclipse.app4mc.amalthea.workflow.util.AddSchedulePoints</code> modifies a given model (default in the AMALTHEA_SLOT) in that way, that in the
+ <code>org.eclipse.app4mc.amalthea.model.SWModel</code> the contained
+ <code>org.eclipse.app4mc.amalthea.model.Task</code> elements are checked if the preemption is set to cooperative. If this is the case, it will add between the elements of the
+ <code>org.eclipse.app4mc.amalthea.model.CallGraph</code> new elements of type
+ <code>org.eclipse.app4mc.amalthea.model.SchedulePoint</code>.
+ </p>
+ <p>
+ <img src="images/uml_add_schedule_points_mwe2.png"/>
+ </p>
+ <p>Sample configuration inside of a workflow:</p>
+ <pre xml:space="preserve"><code>component = AddSchedulePoints {
+}
+</code></pre>
+
+
+<h3><a id="section4.3.7">4.3.7 </a>Current Limitations / Open Points</h3>
+ <p>As there are two options available (Basic Java/EASE and MWE2 based) for running a workflow, there are currently also some limitations existent. The following table should help you to chose the right base:</p>
+ <table class="classic">
+ <tr>
+ <th colspan="1" rowspan="1">Use Case</th>
+ <th colspan="1" rowspan="1">Supported in MWE2</th>
+ <th colspan="1" rowspan="1">Supported in EASE</th>
+ <th colspan="1" rowspan="1">Reason</th>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Loading of AMALTHEA model files (with cross document references) using workflow/script file</td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:red">
+ <strong>no</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1"><ul><li>
+ <strong>MWE2</strong>: Separate Java runtime is started by MWE2, Sphinx relies in running Eclipse instance </li><li>
+ <strong>EASE</strong>: Makes use of the runtime from runtime workbench</li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Using workflow components which are available in the runtime (i.e. workflow component classes which are already available in plugins as a part of the runtime product)</td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1"><ul><li>
+ <strong>MWE2</strong>: Separate runtime is started by MWE2 and if plugin (containing workflow component) is added as dependency then its classes are loaded </li><li>
+ <strong>EASE</strong>: Makes use of the runtime from runtime workbench and has access to all classes </li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Defining custom workflow components (Java classes) and using them in the workflow/script file located in the same workspace</td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1"><ul><li>
+ <strong>MWE2</strong>: Custom workflow component objects can be directly created in MWE2 script file(as in Java) and there is no restriction [irrespective of whether there is constructor] </li><li>
+ <strong>EASE</strong>: As the runtime from the launched workbench (runtime workbench) is used, custom Java classes available in the workspace are not part of the classpath. For creation of objects of custom workflow components (Java classes): EASE JVM module
+ <code>createInstance</code> API should be used by specifying the absolute path of the Java class </li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Using Java classes (available in the runtime workspace from other plugins --> these classes are not part of runtime workbench) inside custom workflow component Java classes</td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1"><ul><li>
+ <strong>MWE2</strong>: works perfectly (just like native) </li><li>
+ <strong>EASE</strong>: works, for creation of object from custom Java classes, EASE JVM module is used, which compiles the used Java classes and creates objects of them </li></ul>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Using classes (API) from 3rd party libraries (added in the classpath of the plugin)inside custom workflow component java classes</td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:green">
+ <strong>yes</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align:center;color:red">no(*)</td>
+ <td colspan="1" rowspan="1"><ul><li>
+ <strong>MWE2</strong>: As new Java runtime is created, all the required plugins & jars are added in the classpath </li><li>
+ <strong>EASE</strong>: In the current implementation only the runtime from workbench is considered, jars from the classpath of a plugin (created newly in the runtime workbench) are not loaded in the runtime of EASE. Due to this reason, execution of the script fails with an exception java.lang.NoClassDefFoundError: <your used class from 3rd party lib> </li></ul>
+ </td>
+ </tr>
+ </table>
+ <p>*: This feature is already available in the master branch of EASE. Consider to update it to an newer version than 0.3.0 if it is needed.</p>
+ <p>Sample for using EASE JVM module to load a class from the same workspace:</p>
+ <pre xml:space="preserve"><code>var labelsCreationComponent = createInstance("workspace://com.ease.example/src/org/eclipse/app4mc/amalthea/example/workflow/components/CreateLabelsComponent.java")
+</code></pre>
+
+
+<h3><a id="section4.3.8">4.3.8 </a>Overall Sample</h3>
+ <p>A sample workflow is available in the AMALTHEA example projects inside of
+ <code>org.eclipse.app4mc.amalthea.example.democar.mapping/workflow/sample_workflow.js</code>. In general this workflow contains all steps as shown in the AMALTHEA examples tutorial
+ <a href="#example-task-creation" shape="rect">Task creation</a> and
+ <a href="#example-mapping-1" shape="rect">Mapping example</a>, but it can be executed in one script. Execute it by doing a right click and then
+ <i>Run As -> EASE Script</i>.
+ <br>The following steps are performed in the sample configuration:
+ </p>
+ <ol>
+ <li>Read the files
+ <i>AMALTHEA_Democar_MappingExample.amxmi</i> and
+ <i>AMALTHEA_Democar_MappingExample-hw.amxmi</i> inside if the model folder. Result model is saved in the default
+ <code>AMALTHEA_SLOT</code>.
+ </li>
+ <li>Perform the
+ <a href="#CreateTasks" shape="rect">Create Tasks</a> component
+ </li>
+ <li>Write the result model available in the
+ <i>createtasks</i> model slot to a single model file
+ <i>createtasks</i> in the directory
+ <i>workflow-output</i>.
+ </li>
+ <li>Perform the
+ <a href="#GenerateMapping" shape="rect">Generate Mapping</a> component with the dfg algorithm on the result of the Create Tasks component. This is done by specifying
+ <code>modelSlot = "createtasks"</code>.
+ </li>
+ <li>Write the result model available in the
+ <i>mapping</i> model slot to a single model file
+ <i>mapping_dfg</i> in the directory
+ <i>workflow-output</i>.
+ </li>
+ <li>Perform the
+ <a href="#GenerateMapping" shape="rect">Generate Mapping</a> component with the ilp algorithm on the result of the Create Tasks component. This is done by specifying
+ <code>modelSlot = "createtasks"</code>. In addition the result slot is overwritten by
+ <code>resultSlot = "mappingilp"</code>, as the previous run of Generate Mapping is already stored in the mapping slot.
+ </li>
+ <li>Write the result model available in the
+ <i>mapping_ilp</i> model slot to a single model file
+ <i>mapping_ilp</i> in the directory
+ <i>workflow-output</i>.
+ </li>
+ </ol>
+ <p>The following diagram shows a snippet of this workflow:</p>
+ <p>
+ <img src="images/sample_workflow.png"/>
+ </p>
+
+
+<h3><a id="section4.3.9">4.3.9 </a>Adding a new workflow component</h3>
+ <p>Below you will find a sample how to add and implement a new workflow component.</p>
+
+
+<h3><a id="section4.3.10">4.3.10 </a>Create project</h3>
+ <ol>
+ <li>Add a new plugin project with the name
+ <i>my.sample.workflow</i>
+ </li>
+ <li>Open the
+ <i>MANIFEST.MF</i> in the META-INF folder.
+ </li>
+ <li>Switch to the tab Dependencies to add the following plugin dependencies: org.eclipse.app4mc.amalthea.workflow.core</li>
+ <li>Add a new class
+ <code>my.sample.workflow.HelloWorld</code>, which is extending
+ <code>org.eclipse.app4mc.amalthea.workflow.core.WorkflowComponent</code>.
+ </li>
+ <li>Implement something in the
+ <code>runInternal(Context ctx) throws WorkflowException</code> method (see sample below).
+ </li>
+ </ol>
+ <pre xml:space="preserve"><code>@Override
+protected void runInternal(Context ctx) throws WorkflowException {
+ // some checking if sw model is available
+ if (null == getAmaltheaModel(ctx).getSwModel()) {
+ throw new WorkflowException("No proper SWModel available!");
+ }
+ this.log.info("Number of tasks in model: " + getAmaltheaModel(ctx).getSwModel().getTasks().size());
+}
+</code></pre>
+ <p><!-- --></p>
+
+
+<h4><a id="section4.3.10.1"></a>Execute the new component in the available sample</h4>
+ <p>The previous created class
+ <code>my.sample.workflow.HelloWorld</code> should be added to a workflow.
+ <br>Therefore we are using the provided sample project from APP4MC
+ <i>org.eclipse.app4mc.amalthea.example.democar.mapping</i>.
+ <br>Before starting with the next steps, we need to start a new runtime from the existing workspace, so that the plugin
+ <i>my.sample.workflow</i> is already loaded.
+ </p>
+ <p>
+ <strong>Note:</strong> If you want to use the classes from the plugin
+ <i>my.sample.workflow</i> in a EASE script located in the same workspace, you can create an instance of it at runtime using the JVM module of EASE. Please consider the EASE documentation for more details.
+ </p>
+ <ol>
+ <li>Add the AMALTHEA democar samples to your workspace (File – New – Example – Democar Examples)</li>
+ <li>Go to the project
+ <i>org.eclipse.app4mc.amalthea.example.democar.mapping</i>.
+ </li>
+ <li>Open the
+ <i>sample_workflow.js</i> located in the workflow folder.
+ </li>
+ <li>Add to the imports:
+ <code>importPackage(my.sample.workflow)</code>
+ </li>
+ <li>Add to the logger configs:
+ <code>addLoggerToConsole("my.sample.workflow")</code>
+ </li>
+ <li>Add the First snippet below after the first AmaltheaReader component and before the CreateTasks component.</li>
+ <li>Run the script by doing a right click -> Run As -> EASE Script</li>
+ </ol>
+ <pre xml:space="preserve"><code>var ctx = new DefaultContext()
+
+//Reader
+var reader = new ModelReader()
+reader.addFileName(MODEL_LOCATION1)
+reader.addFileName(MODEL_LOCATION2)
+reader.run(ctx)
+
+var hw = new HelloWorld()
+hw.run(ctx)
+
+//create tasks based on initial model
+//result is saved in modelslot createtasks
+var createTasks = new CreateTasks()
+createTasks.run(ctx)
+</code></pre>
+ <p><!-- --></p>
+
+
+<h2><a id="section4.4">4.4 </a>Model Migration</h2>
+
+
+<h3><a id="section4.4.1">4.4.1 </a>Technologies used</h3>
+ <p>For migration of AMALTHEA models, plane java approach has been used (
+ <em>non EMF</em>) along with the following 3rd party libraries :
+ </p>
+ <ul>
+ <li>JDOM 2</li>
+ <li>JAXEN</li>
+ <li>XALAN</li>
+ <li>XERCES</li>
+ </ul>
+
+
+<h3><a id="section4.4.2">4.4.2 </a>Framework for model migration</h3>
+ <p>Using the above specified technologies, eclipse plugin based framework for model migration is developed.</p>
+ <ul>
+ <li>
+ <em>
+ <strong>org.eclipse.app4mc.amalthea.converters.common</strong>
+ </em> plugin consists of
+ <em>Model migration framework</em>
+ </li>
+ </ul>
+
+
+<h3><a id="section4.4.3">4.4.3 </a>Components of Model Migration Framework</h3>
+ <ul>
+ <li>Converters</li>
+ <li>Cache Builders</li>
+ <li>Pre Processor</li>
+ <li>Post Processor</li>
+ </ul>
+ <p>All the above specified components are contributed as extension points in the plugin
+ <em>
+ <strong>org.eclipse.app4mc.amalthea.converters.common</strong>
+ </em>
+ </p>
+ <p>Detailed description of each component can be found below:</p>
+ <p>
+ <strong>Converters:</strong> This component is responsible for converting the model (xmi) content from one version to another. A Converter component is executed for selected model files and the corresponding referred model files for migration (
+ <em>each execution is w.r.t. specific model file</em>).
+ </p>
+ <p>Converter can be registered by adding extension definition for :
+ <code>org.eclipse.app4mc.amalthea.model.converters</code> and defining the following parameters :
+ </p>
+ <ul>
+ <li>ID : This is the unique identifier of a Converters component with which it is identified</li>
+ <li>Name : Name of the component</li>
+ <li>Input model version : AMALTHEA model version in which the input model content is present. </li>
+ <li>Output model version : AMALTHEA model version to which the input model content should be converted to.</li>
+ </ul>
+ <blockquote>
+ <p>All AMALTHEA/AMALTHEA4Public ITEA releases are specified with prefix
+ <strong>itea</strong> (e.g: itea.103, itea.110, itea.111) and APP4MC releases are specifeid with their version number (e.g: 0.7.0, 0.7.1)
+ </p>
+ </blockquote>
+ <ul>
+ <li>Converter Class : Java class implementing
+ <code>org.eclipse.app4mc.amalthea.converters.common.base.IConverter</code> interface and providing the definition for method :
+ <code>public void convert(final File targetFile, final Map<File, Document> fileName_documentsMap, final List<ICache> caches) throws Exception</code>
+ </li>
+ <li>enabled : By specifiying true/false - > specific converter invocation can be enabled or disabled</li>
+ </ul>
+ <p>
+ <img class="gray_scale" src="images/converters_content.png"/>
+ </p>
+ <ul>
+ <li>Converter dependencies : A Converter can be dependent on other Converter components. During the execution of a specific Converter component first its dependencies are invoked and then dependent converter is invoked.</li>
+ </ul>
+ <p>Converter dependencies can be specified at the extension level in the following way:</p>
+ <p>
+ <img class="gray_scale" src="images/converters_dependencies.png"/>
+ <br>
+ <img class="gray_scale" src="images/converters_dependencies_details.png"/>
+ </p>
+ <p>
+ <strong>Cache Builders:</strong> This component is responsible for building the required cache, by querying the input models or storing the necessary information - > before executing the Converters for specific migration step (
+ <em>e.g: itea.103 to itea.110</em>)
+ <br>Scope of each Cache Builder component is only during a step of model migration (
+ <em>e.g: itea.103 to itea.110</em>)
+ </p>
+ <p>Cache Builder can be registered by adding extension definition for :
+ <code>org.eclipse.app4mc.amalthea.model.converters.cachebuilders</code> and defining the following parameters :
+ </p>
+ <ul>
+ <li>ID : This is the unique identifier of a Cache Builder component with which it is identified</li>
+ <li>name : Name of the component</li>
+ <li>class : Java class implementing
+ <code>org.eclipse.app4mc.amalthea.converters.common.base.ICache</code> interface and providing implementation for following methods :
+ <code>public void buildCache(final Map<File, Document> fileName_documentsMap)</code>,
+ <code>public Map<File, Map<String, Object>> getCacheMap()</code>,
+ <code>public void clearCacheMap()</code>
+ </li>
+ <li>enabled : By specifiying true/false - > specific Cache Builder components invocation can be enabled or disabled</li>
+ <li>input-model-version : AMALTHEA model version in which the model content is present.</li>
+ </ul>
+ <blockquote>
+ <p>Each Cache Builder component is tightly coupled to a specific AMALTHEA model version </p>
+ </blockquote>
+ <p>
+ <img class="gray_scale" src="images/cache_builder.png"/>
+ </p>
+ <p>
+ <strong>Pre Processor:</strong> This component is responsible for fetching/modifying specific information before invocation of Cache Builders/Converters components.
+ </p>
+ <blockquote>
+ <p>This component is tighlty coupled to input version of the AMALTHEA model files which are selected (explicitly/implicitly) for model migration. Each Pre-Processor component is executed only once for the input model files, irrespective of number of migration steps.</p>
+ </blockquote>
+ <p>Pre Processor component can be registered by adding extension definition for :
+ <code>org.eclipse.app4mc.amalthea.model.converters.preprocessor</code> and defining the following parameters :
+ </p>
+ <ul>
+ <li>ID : This is the unique identifier of a Pre-Procssor component with which it is identified</li>
+ <li>class : Java class implementing
+ <code>org.eclipse.app4mc.amalthea.converters.common.base.IPreProcessor</code> interface and providing implementation for method :
+ <code>public void process(final File targetFile, final Map<File, Document> fileName_documentsMap) throws Exception</code>
+ </li>
+ <li>input-model-version : AMALTHEA model version in which the model content can be present. There is a possibility to specify multiple input-model-version's, during the runtime if the supplied AMALTHEA models version matches to atleast one of the specified versions - > then corresponding pre-processor is executed</li>
+ </ul>
+ <blockquote>
+ <p>Each Pre processor component is tightly coupled to the specified AMALTHEA model versions</p>
+ </blockquote>
+ <p>
+ <img class="gray_scale" src="images/pre_processor.png"/>
+ </p>
+ <p>
+ <strong>Post Processor:</strong> This component is responsible for adding/modifying specific information after invocation of Cache Builders/Converters components for a specific migration step (
+ <em>e.g: itea.103 to itea.110</em>)
+ </p>
+ <blockquote>
+ <p>This component is tighlty coupled to input and output version of the AMALTHEA model files which are selected (explicitly/implicitly) for model migration. Each Pre-Processor component is executed after the migration step if the below criteria is full filled:</p>
+ </blockquote>
+ <p>Post Processor component can be registered by adding extension definition for :
+ <code>org.eclipse.app4mc.amalthea.model.converters.postprocessor</code> and defining the following parameters :
+ </p>
+ <ul>
+ <li>ID : This is the unique identifier of a Post-Processor component with which it is identified</li>
+ <li>class : Java class implementing
+ <code>org.eclipse.app4mc.amalthea.converters.common.base.IPostProcessor</code> interface and providing implementation for method :
+ <code>public void process(final Map<File, Document> fileName_documentsMap, final AbstractHelper helper) throws Exception</code>
+ </li>
+ <li>input-model-version : AMALTHEA model version in which the model content can be present. There is a possibility to specify multiple input-model-version's.</li>
+ <li>output-model-version : AMALTHEA model version to which the model content is converted as a part of one of the migration step. There is a possibility to specify multiple output-model-version's.</li>
+ </ul>
+ <p>
+ <img class="gray_scale" src="images/post_processor.png"/>
+ </p>
+ <p>
+ <em>Example how Post-Processor's are invoked:</em>
+ </p>If Post-Processor is defined with input-model-versions : itea.103, itea.110 and outputversion 0.7.0.In case if the migration is invoked from itea.103 to 0.7.0 for the specified AMALTHEA models.Following migration steps are to be performed internally:
+ <ul>
+ <li>itea.103 to itea.110</li>
+ <li>itea.110 to itea.111</li>
+ <li>itea.110 to 0.7.0 (APP4MC)</li>
+ </ul>
+ <blockquote>
+ <p>In this case post-processor is invoked after migration step itea.110 to itea.111. </p>
+ </blockquote>
+ <p>Flexibility of post-processor's is, they are defined in a generalized way to specify in the direction which they should be invoked as a part of model migration.</p>
+
+
+<h4><a id="section4.4.3.1"></a>Model migration sequence</h4>
+ <p>Sequence in which various components are invoked during model migration</p>
+ <p>
+ <img class="gray_scale" src="images/model_migration_sequence_diagram.png"/>
+ </p>
+
+
+<h3><a id="section4.4.4">4.4.4 </a>How to add custom Model Migration components</h3>
+ <p>As described above, Model Migration framework is part of
+ <em>
+ <strong>org.eclipse.app4mc.amalthea.converters.common</strong>
+ </em> plugin. This plugin should be added as a dependency to the custom plugin which shall contain Model Migraiton components.
+ </p>
+ <p>Below are the various extension points available as a part of Model Migration framework: </p>
+ <p>
+ <img class="gray_scale" src="images/converters_extension_points.png"/>
+ </p>
+ <p>For defining custom Model Migration, minimum requirement is to define a extension for
+ <code>org.eclipse.app4mc.amalthea.model.converters</code> extension point and specify the class which has the implementation for migrating the model contents.
+ </p>
+ <p>CacheBuilders, PreProcessor, PostProcessor components are optional - > based on the scenarios to migrate the model elements, it must me decided if these components are required.</p>
+
+
+<h3 id="metamodel-changes"><a id="section4.4.5">4.4.5 </a>AMALTHEA meta model changes</h3>
+ <p>Based on the changes in AMALTHEA meta model across various releases, below description contains the differences in detail which are considered for model migration:</p>
+
+
+<h4><a id="section4.4.5.1"></a>Version ITEA 1.0.3 to ITEA 1.1.0</h4>
+ <p>Below are the changes in the metamodel from ITEA 1.1.0 version to ITEA 1.1.1</p>
+ <ul>
+ <li>
+ <strong>Changes in the namespaces:</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version ITEA 1.0.3)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (verison ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/sw</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/sw</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/stimuli</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/stimuli</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/propertyconstraints</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/propertyconstraints</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/os</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/os</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/mapping</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/mapping</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/hw</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/hw</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/events</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/events</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/constraints</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/constraints</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/config</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/config</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/common</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/common</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.1.0/central</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/central</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://amalthea.itea2.org/model/1.1.0/components</td>
+ <td colspan="1" rowspan="1">http://amalthea.itea2.org/model/1.2.0/components</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Following Class names are changed:</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>Class name in 1.0.3</strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>Changed Class name in 1.1.0</strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>Amalthea sub-model</strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">DeadlineMonotinic</td>
+ <td colspan="1" rowspan="1">DeadlineMonotonic</td>
+ <td colspan="1" rowspan="1">OS</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Below are the references which are removed:</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version ITEA 1.0.3)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>how migration is done from 1.0.3 models to 1.1.0</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">scheduler</td>
+ <td colspan="1" rowspan="1">OSModel</td>
+ <td colspan="1" rowspan="1">OS model</td>
+ <td colspan="1" rowspan="1"><div>"scheduler" elements contained inside OSModel element are converted into TaskScheduler elements in the following way: <ul><li>OperatingSystem element is created and associated to the OSModel element
+ <em>(Note: OperatingSystem class is newly introduced in 1.1.0)</em></li><li>All the Scheduler elements present inside the OSModel element are moved to the OperatingSystem element as TaskScheduler's </li><li>All the places where Scheduler elements were referred earlier, are updated so as to refer corresponding TaskScheduler element</li></ul></div>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">read, write</td>
+ <td colspan="1" rowspan="1">LabelAccessStatistic</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1"><div>"read" elements contained inside LabelAccessStatistic element are removed and "write" elements are replaced by tag name "value" based on the following criteria : <ul><li>If the LabelAccess element containing LabelAccessStatistic ->contains the access as "write", then all the "read" elements of LabelAccessStatistic are removed </li> </ul><br>"write" elements contained inside LabelAccessStatistic element are removed and "read" elements are replaced by tag name "value" based on the following criteria : <ul><li>If the LabelAccess element containing LabelAccessStatistic ->contains the access as "read", then all the "write" elements of LabelAccessStatistic are removed </li> </ul></div></td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Below are the changes in the reference names :</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version ITEA 1.0.3)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Changed Variable Name (version ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>how migration is done from 1.0.3 models to 1.1.0</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">readCacheMisses</td>
+ <td colspan="1" rowspan="1">cacheMisses</td>
+ <td colspan="1" rowspan="1">LabelAccessStatistic</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">"readCacheMisses" is changed to "cacheMisses" in all the places where LabelAccessStatistic definition is present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">executableAllocation</td>
+ <td colspan="1" rowspan="1">processAllocation, runnableAllocation</td>
+ <td colspan="1" rowspan="1">MappingModel</td>
+ <td colspan="1" rowspan="1">Mapping model</td>
+ <td colspan="1" rowspan="1"><div>Based on the content of the "executableAllocation", accordingly either "processAllocation" or "runnableAllocation" elements are created and the corresponding data of "exeuctableAllocation" is mapped. <br> Below are the criterions : <ul> <li>If "executableAllocation" consists of Task element and Scheduler mapping then - > "ProcessAllocation" of type "mapping:TaskAllocation" is created</li><li>If "executableAllocation" consists of ISR element and Scheduler mapping then - > "ProcessAllocation" of type "mapping:ISRAllocation" is created, and to it corresponding ISR element and "InterruptController" element are associated (
+ <em><b>Note:</b>If there is a mapping to "ISR" and "Scheduler" in "executableAllocation", InterruptController element is created and referred in the "executableAllocation". In this case previous mapping to the Scheduler element is lost</em>) </li><li>If "executableAllocation" consists of Runnable element and Scheduler mapping then - > "RunnableAllocation" of type "mapping:RunnableAllocation" is created</li></ul></div>
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section4.4.5.2"></a>Version ITEA 1.1.0 to ITEA 1.1.1</h4>
+ <p>Below are the changes in the metamodel from ITEA 1.1.0 version to ITEA 1.1.1</p>
+ <ul>
+ <li>
+ <strong>Changes in the namespaces:</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version ITEA 1.1.1)</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/sw</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/sw</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/stimuli</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/stimuli</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/propertyconstraints</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/propertyconstraints</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/os</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/os</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/mapping</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/mapping</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/hw</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/hw</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/events</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/events</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/constraints</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/constraints</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/config</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/config</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/common</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/common</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.2.0/central</td>
+ <td colspan="1" rowspan="1">http://www.amalthea.itea2.org/model/1.3.0/central</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://amalthea.itea2.org/model/1.2.0/components</td>
+ <td colspan="1" rowspan="1">http://amalthea.itea2.org/model/1.3.0/components</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Below are the changes in the reference names :</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Changed Variable Name (version ITEA 1.1.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>how migration is done from 1.1.0 models to 1.1.1</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">tagName</td>
+ <td colspan="1" rowspan="1">name</td>
+ <td colspan="1" rowspan="1">Tag</td>
+ <td colspan="1" rowspan="1">Software model, Components model</td>
+ <td colspan="1" rowspan="1">attribute "tagName" is changed to "name" in all the places where Tag definition is present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">elements</td>
+ <td colspan="1" rowspan="1">components, systems</td>
+ <td colspan="1" rowspan="1">ComponentsModel</td>
+ <td colspan="1" rowspan="1">Components model</td>
+ <td colspan="1" rowspan="1"><div> <ol><li>XML child elements of ComponentsModel having name as "elements" and attribute "xsi:type" as either "components:Component" or "components:Composite" are changed to "components"</li><li> XML child elements of ComponentsModel having name as "elements" and attribute "xsi:type" as "components:System" are changed to "systems" </li></ol></div></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">elements</td>
+ <td colspan="1" rowspan="1">connectors, componentInstances</td>
+ <td colspan="1" rowspan="1">System</td>
+ <td colspan="1" rowspan="1">Components model</td>
+ <td colspan="1" rowspan="1"><div> <ol><li>XML child elements of System having name as "elements" and attribute "xsi:type" as "components:Connector" are changed to "components"</li><li> XML child elements of ComponentsModel having name as "elements" and attribute "xsi:type" as "components:ComponentInstance" are changed to "componentInstances" </li></ol></div></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">maximumCyle</td>
+ <td colspan="1" rowspan="1">maximumCycle</td>
+ <td colspan="1" rowspan="1">DataAgeCycle</td>
+ <td colspan="1" rowspan="1">Constraints model</td>
+ <td colspan="1" rowspan="1">attribute "maximumCyle" is changed to "maximumCycle" in all the places where DataAgeCycle definition is present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">setLabelsList</td>
+ <td colspan="1" rowspan="1">setModeValueList</td>
+ <td colspan="1" rowspan="1">Stimulus</td>
+ <td colspan="1" rowspan="1">Stimuli model</td>
+ <td colspan="1" rowspan="1">XML node name is set as "setModeValueList"</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">enablingLabelsList</td>
+ <td colspan="1" rowspan="1">enablingModeValueList</td>
+ <td colspan="1" rowspan="1">Stimulus</td>
+ <td colspan="1" rowspan="1">Stimuli model</td>
+ <td colspan="1" rowspan="1">XML node name is set as "enablingModeValueList"</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">disablingLabelsList</td>
+ <td colspan="1" rowspan="1">disablingModeValueList</td>
+ <td colspan="1" rowspan="1">Stimulus</td>
+ <td colspan="1" rowspan="1">Stimuli model</td>
+ <td colspan="1" rowspan="1">XML node name is set as "disablingModeValueList"</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Below are the references which are removed:</strong>
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>how migration is done from 1.1.0 models to 1.1.1</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">deadline</td>
+ <td colspan="1" rowspan="1">Task, ISR, ProcessPrototype</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1"><div>"deadline" specified at the Process, ProcessPrototype is converted into a constraint element in the following way: <ul><li>with the name of corresponding Process/ProcessPrototype -> ProcessRequirement object is created and the object of Process/ProcessPrototype is linked to it</li><li>TimeRequirement object is created with the following properties and associated to the created ProcessRequirement: <br><ol><li>limitType as upperlimit</li><li>metric as responsetime</li><li>SignedTime elment is created with the following properties and associated to the TimeRequirement element : value and unit - > values for these elements are fetched from the "deadline" object available at Process/ProcessPrototype</li></ol> </li> <li> once the required content from the "deadline" element of Process/ProcessPrototype is fetched, "deadline" is removed </li></ul></div></td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">initialValue</td>
+ <td colspan="1" rowspan="1">Label</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Initial value attribute is removed from all the Label objects</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Below are the changes in the default values of Enums</strong> :
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Enum Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Default value (version ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Default value (version ITEA 1.1.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>behavior model migration to migrated 1.1.0 models to 1.1.1</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">TimeUnit</td>
+ <td colspan="1" rowspan="1">ps</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Common model</td>
+ <td colspan="1" rowspan="1">Attribute "unit" with value as "ps" is created (when it is missing in the input model) -> for all the XMI tags where TimeUnit defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">InterfaceKind</td>
+ <td colspan="1" rowspan="1">PROVIDES</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Components model</td>
+ <td colspan="1" rowspan="1">Attribute "kind" with value as "PROVIDES" is created (when it is missing in the input model) -> for all the XMI tags where InterfaceKind defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">RunnableOrderType</td>
+ <td colspan="1" rowspan="1">successor</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Constraints model</td>
+ <td colspan="1" rowspan="1">Attribute "orderType" with value as "successor" is created (when it is missing in the input model)-> for all the XMI tags where RunnableOrderType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">RunnableGroupingType</td>
+ <td colspan="1" rowspan="1">allOfThem</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Constraints model</td>
+ <td colspan="1" rowspan="1">Attribute "groupingType" with value as "allOfThem" is created (when it is missing in the input model)-> for all the XMI tags where RunnableGroupingType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">QType</td>
+ <td colspan="1" rowspan="1">DYNAMIC</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "type" with value as "DYNAMIC" is created (when it is missing in the input model)-> for all the XMI tags where QType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">MemoryType</td>
+ <td colspan="1" rowspan="1">RAM</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "type" with value as "RAM" is created (when it is missing in the input model)-> for all the XMI tags where MemoryType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">BusType</td>
+ <td colspan="1" rowspan="1">CAN</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "busType" with value as "CAN" is created (when it is missing in the input model)-> for all the XMI tags where BusType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">RWType</td>
+ <td colspan="1" rowspan="1">R</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "direction" with value as "R" is created (when it is missing in the input model)-> for all the XMI tags where RWType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SchedType</td>
+ <td colspan="1" rowspan="1">RROBIN</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "schedPolicy" with value as "RROBIN" is created (when it is missing in the input model)-> for all the XMI tags where SchedType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">PinType</td>
+ <td colspan="1" rowspan="1">ANALOG</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "type" with value as "ANALOG" is created (when it is missing in the input model)-> for all the XMI tags where PinType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">FeatureType</td>
+ <td colspan="1" rowspan="1">floatingPointUnit</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ <td colspan="1" rowspan="1">Attribute "value" with value as "floatingPointUnit" is created (when it is missing in the input model)-> for all the XMI tags where FeatureType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">MemoryAddressMappingType</td>
+ <td colspan="1" rowspan="1">none</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Mapping model</td>
+ <td colspan="1" rowspan="1">Attribute "addressMappingType" with value as "none" is created (when it is missing in the input model)-> for all the XMI tags where MemoryAddressMappingType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ComparatorType</td>
+ <td colspan="1" rowspan="1">equal</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Property Constraints model</td>
+ <td colspan="1" rowspan="1">Attribute "comparator" with value as "equal" is created (when it is missing in the input model)-> for all the XMI tags where ComparatorType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ConjunctionType</td>
+ <td colspan="1" rowspan="1">and</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Property Constraints model</td>
+ <td colspan="1" rowspan="1">Attribute "conjunction" with value as "and" is created (when it is missing in the input model)-> for all the XMI tags where ConjunctionType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">WaitEventType</td>
+ <td colspan="1" rowspan="1">AND</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Attribute "maskType" with value as "AND" is created (when it is missing in the input model)-> for all the XMI tags where WaitEventType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Waitingbehavior</td>
+ <td colspan="1" rowspan="1">unspecified</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">In sw:WaitEvent/ sw:SynchronousServerCall / sw:SynchronousServerCall -> if attribute "waitingbehavior" is with value as "unspecified", then attribute "waitingbehavior" and its value are removed in the XML, so that the default value for "waitingbehavior" as per 1.1.1 : "_
+ <em>unspecified</em> _" is consisdered
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">AccessPrecedenceType</td>
+ <td colspan="1" rowspan="1">ignoreWR</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Attribute "orderType" with value as "ignoreWR" is created (when it is missing in the input model)-> for all the XMI tags where AccessPrecedenceType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OrderType</td>
+ <td colspan="1" rowspan="1">order</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Attribute "orderType" with value as "order" is created (when it is missing in the input model)-> for all the XMI tags where OrderType defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">LabelAccessEnum</td>
+ <td colspan="1" rowspan="1">read</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Attribute "access" with value as "read" is created (when it is missing in the input model)-> for all the XMI tags where LabelAccessEnum defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SemaphoreAccessEnum</td>
+ <td colspan="1" rowspan="1">request</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Attribute "accessEnum" with value as "request" is created (when it is missing in the input model)-> for all the XMI tags where SemaphoreAccessEnum defintion should be present</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Preemption</td>
+ <td colspan="1" rowspan="1">cooperative</td>
+ <td colspan="1" rowspan="1">_undefined_</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ <td colspan="1" rowspan="1">Attribute "preemption" with value as "cooperative" is created (when it is missing in the input model)-> for all the XMI tags where Preemption defintion should be present</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>Below are the Class's/Enum's moved to different sub models</strong> :
+ </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Enum/Class Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Namespace (version ITEA 1.1.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Namespace (version ITEA 1.1.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>behavior model migration to migrated 1.1.0 models to 1.1.1</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SchedulingSWUnit</td>
+ <td colspan="1" rowspan="1">sw</td>
+ <td colspan="1" rowspan="1">os</td>
+ <td colspan="1" rowspan="1">Attribute "xsi:type" of XML node of TaskScheduler/InterruptController is updated to "os:SchedulingSWUnit"</td>
+ </tr>
+ </table>
+ <ul>
+ <li>
+ <strong>ITEA 1.1.0 Class's removed in ITEA 1.1.1, details how data of these class's is migrated</strong> :
+ </li>
+ </ul> <div style="margin-left:40px">
+ <dl>
+ <dt>
+ <strong>
+ <em>LabelSwitchEntry</em>
+ </strong>
+ <em>(present in Software model)</em>
+ </dt>
+ <dd>Class is removed in ITEA 1.1.1, and as replacement following Class is introduced: "ModeSwitchEntry"</dd>
+ <dt>
+ <strong>
+ <em>LabelSwitch</em>
+ </strong>
+ <em>(present in Software model)</em>
+ </dt>
+ <dd>Class is removed in ITEA 1.1.1, and as replacement following Class's are introduced: "ModeSwitch, ModeLabel"</dd>
+ <dt>
+ <strong>LabelValueEntry</strong>
+ <em>(present in Stimuli model)</em>
+ </dt>
+ <dd>Class is removed in ITEA 1.1.1, and as replacement following Class is introduced: "ModeValueListEntry"</dd>
+ </dl> </div>
+ <ul>
+ <li>
+ <strong>Model migration behavior</strong>:
+ <ul>
+ <li>
+ <strong>
+ <em>LabelSwitch</em>
+ </strong> : <div><ul><li>From the referred "Label" element inside "LabelSwitch", "ModeLabel" element is created with the same name -> and associated to the same Software Model where "Label" element is defined</li><li>"LabelSwitch" element is replaced with "ModeSwitch" element, and it refers to the "ModelLabel" (created in the above step)</li></ul></div>
+ </li>
+ <li>
+ <strong>
+ <em>LabelSwitchEntry</em>
+ </strong> : <div><ul><li>For all the LabelSwitchEntry objects inside a specific AMALTHEA model file, a single "Mode" element is created ( with the following naming convention : "mode_sw_&lt;counter&gt;_migration_generated" )</li><li>Based on the unique values of LabelSwitchEntry elements, ModeLiteral objects are created</li><li> LabelSwitchEntry is replaced by ModeSwitchEntry, based on the earlier "value" specified for LabelSwitchEntry -> corresponding ModeLiteral element is referred </li></ul></div>
+ <ul>
+ <li>For details refer to the below figure: <br><br>
+ <img class="gray_scale" src="images/labelswitch_migration.png"/> <br><br>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <strong>
+ <em>LabelValueEntry</em>
+ </strong> : <div><ul><li>For Label referred inside each LabelValueEntry, corresponding ModeLabel object is created in the software model and it is associated to the entry object.</li></ul></div><div><ul><li>For all the LabelValueEntry objects inside a specific AMALTHEA model file, a single "Mode" element is created ( with the following naming convention : "mode_stimuli_&lt;counter&gt;_migration_generated" )</li><li>Based on the unique values of LabelValueEntry elements, ModeLiteral objects are created</li><li> LabelValueEntry is replaced by ModeValueListEntry, based on the "value" specified for LabelValueEntry -> corresponding ModeLiteral element is referred instead of "value" </li><li><p style="color:#4D4DA3;">!! For LabelValueEntry migration to be successful, <b>it is mandatory to have SW-Model in the same model file</b>. In case SW-Model is not present, migration of LabelValueEntry objects will not be performed.</p></li></ul></div>
+ <ul>
+ <li>For details refer to the below figure: <br><br>
+ <img class="gray_scale" src="images/labelvalueentry_stimuli_migration.png"/> <br><br>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ </ul>
+
+
+<h4><a id="section4.4.5.3"></a>Version ITEA 1.1.1 to App4MC 0.7.0</h4>
+ <p>Below are the changes in the metamodel from ITEA 1.1.1 version to APP4MC 0.7.0</p>
+ <ul>
+ <li>Instead of multiple namespaces (e.g: sw,hw,constraints,components etc.,) a single namespace "am" is introduced
+ <ul>
+ <li>
+ <strong>Impact on 0.7.0 model file due to this change:</strong>
+ <ul>
+ <li>xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0 is included in the xmi file, instead of other namespaces (e.g: xmlns:hw, xmlns:sw etc.,)</li>
+ <li>xsi:type attributes will consists of namespace prefix as "am" in the value. Example: <br>
+ <code><ports xsi:type="am:ComplexPort" name="Mem_1_port" bitWidth="16" direction="R" writeCycles="10" readCycles="10"/></code>
+ </li>
+ <li>Root tag will have "am" as the prefix. Example: <br>
+ <code><am:HWModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0"/></code>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>Reference pattern is changed. <br> As there is single model namespace in 0.7.0, namespace prefix is removed before the class name (eg: "ABSMode?type=Label").
+ <ul>
+ <li>old:
+ <code><Element Name>?type=<NameSpace prefix>.<ElementClassName></code>
+ </li>
+ <li>new:
+ <code><Element Name>?type=<ElementClassName></code>
+ </li>
+ </ul>
+ </li>
+ <li>Root tag of the model, changed from
+ <strong>AMALTHEA</strong> to
+ <strong>Amalthea</strong>
+ </li>
+ <li>
+ <strong>IPort</strong> interface is changed to abstract class
+ <strong>Port</strong>
+ </li>
+ <li>FInterface reference (i.e. Franca Interface) is removed from class FInterfacePort
+ <ul>
+ <li>
+ <strong>Impact on 0.7.0 model file due to this change:</strong>
+ <ul>
+ <li>If AMALTHEA models from previous versions have the reference to Franca Interface ports, as a part of migration this reference is removed. (
+ <em>In this case, reference to the Franca Interface element is stored as a CustomProperty of type String inside FInterfacePort element</em>)
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>InterfaceKind ENUM literal values are changed from PROVIDES, REQUIRES to provides, requires</li>
+ <li>Following class names are changed <br><br> </li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <b>Class name from 1.1.1</b>
+ </td>
+ <td colspan="1" rowspan="1">
+ <b>Changed Class name in 0.7.0</b>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OSEvent</td>
+ <td colspan="1" rowspan="1">OsEvent</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">MemType</td>
+ <td colspan="1" rowspan="1">MemoryType</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">System</td>
+ <td colspan="1" rowspan="1">HwSystem</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Component</td>
+ <td colspan="1" rowspan="1">HwComponent</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Port</td>
+ <td colspan="1" rowspan="1">HwPort</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">AbstractionTypeDescription</td>
+ <td colspan="1" rowspan="1">AbstractionType</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">MemoryType</td>
+ <td colspan="1" rowspan="1">MemoryTypeEnum</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OSInstructions</td>
+ <td colspan="1" rowspan="1">OsInstructions</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Periodic</td>
+ <td colspan="1" rowspan="1">PeriodicActivation</td>
+ </tr>
+ </table>
+ <ul>
+ <li>Below references are removed inside ComplexNode and HardwareTypeDescription (
+ <em>both these class's are part of Hardware Model</em>)
+ <ul>
+ <li>AbstractType[] attribute , AbstractType[] features
+ <ul>
+ <li>
+ <strong>Impact on 0.7.0 model file due to this change:</strong> Content inside the attribute and features is stored as a CustomProperty elements inside the corresponding elements.
+ <ul>
+ <li>Content of "AbstractType[] attribute" is stored in the CustomProperty, with key as "attribute#<attribute name>" and value as <attribute value></li>
+ <li>Content of "AbstractType[] features" is stored in the CustomProperty, with key as "feature#<feature name>" and value as <feature value></li>
+ </ul>
+ </li>
+ <li>Below figure shows the changes between 1.1.1 model (
+ <em>containing attributes & features</em>) and the corresponding 0.7.0 model (
+ <em>created using model migration utility</em>)
+ <img class="gray_scale" src="images/hwmodel_attributes_features.png"/>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>ProcessAllocation class removed from MappingModel, instead ISRAllocation (
+ <em>maps ISR and InterruptController</em>) and TaskAllocation (
+ <em>maps Task and Scheduler</em>)
+ <ul>
+ <li>
+ <strong>Impact on 0.7.0 model file due to this change:</strong>
+ <ul>
+ <li>processAllocation tag is removed from mappingModel, and instead of this taskAllocation and isrAllocation tags will be generated accordingly. <br> For details refer to the image <br>
+ <img class="gray_scale" src="images/mappingmodel_processallocations.png"/>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>Below are the changes in the reference names :</li>
+ </ul>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version ITEA 1.1.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Changed Variable Name (version APP4MC 0.7.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isMaster</td>
+ <td colspan="1" rowspan="1">master</td>
+ <td colspan="1" rowspan="1">ComplexPort</td>
+ <td colspan="1" rowspan="1">Hardware model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">mem</td>
+ <td colspan="1" rowspan="1">memory</td>
+ <td colspan="1" rowspan="1">Mapping</td>
+ <td colspan="1" rowspan="1">Mapping model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">memTypeDefinitions</td>
+ <td colspan="1" rowspan="1">memoryTypeDefinitions</td>
+ <td colspan="1" rowspan="1">PropertyConstraintsModel</td>
+ <td colspan="1" rowspan="1">Property Constraints model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isDefault</td>
+ <td colspan="1" rowspan="1">default</td>
+ <td colspan="1" rowspan="1">ModeSwitchEntry</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isBuffered</td>
+ <td colspan="1" rowspan="1">buffered</td>
+ <td colspan="1" rowspan="1">Label</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isBuffered</td>
+ <td colspan="1" rowspan="1">buffered</td>
+ <td colspan="1" rowspan="1">LabelAccess</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">accessEnum</td>
+ <td colspan="1" rowspan="1">access</td>
+ <td colspan="1" rowspan="1">SemaphoreAccess</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isBuffered</td>
+ <td colspan="1" rowspan="1">buffered</td>
+ <td colspan="1" rowspan="1">SenderReceiverCommunication</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">isOrdered</td>
+ <td colspan="1" rowspan="1">ordered</td>
+ <td colspan="1" rowspan="1">Group</td>
+ <td colspan="1" rowspan="1">Software model</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section4.4.5.4"></a>Version APP4MC 0.7.0 to App4MC 0.7.1</h4>
+ <p>Below are the changes in the meta model from APP4MC 0.7.0 to APP4MC 0.7.1</p>
+ <p>
+ <strong>Change in the namespace:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version App4MC 0.7.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version App4MC 0.7.1)</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.7.0</td>
+ <td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.7.1</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Root Tag in AMALTHEA model amxmi file</strong>: It is recommended to have "Amalthea" as a root tag in amxmi file.
+ </p>
+ <p>Based on the above statement, if the AMALTHEA model file is having sub-model tag as root element (e.g: SWModel or HWModel etc.,), as a part of model migration -> root element is changed as "Amalthea" tag and the content of sub-model is copied inside it. </p>Input model (containing SWModel as the root tag):
+ <pre xml:space="preserve"><code> "<am:SWModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0">
+ <labels/>
+</am:SWModel>"
+</code></pre> Output model (after model migration):
+ <pre xml:space="preserve"><code><am:Amalthea xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0" xmlns:xmi="http://www.omg.org/XMI">
+ <swModel>
+ <labels />
+ </swModel>
+</am:Amalthea>
+</code></pre>
+ <p>
+ <strong>Below are the changes in the reference names:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version APP4MC 0.7.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Changed Variable Name (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">graphEntries</td>
+ <td colspan="1" rowspan="1">items</td>
+ <td colspan="1" rowspan="1">ModeSwitchEntry</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">xml tag "graphEntries" present inside "ModeSwitchEntry" object is changed to "items" in amxmi file</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">value</td>
+ <td colspan="1" rowspan="1">values</td>
+ <td colspan="1" rowspan="1">ModeSwitchEntry</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">xml tag "value" present inside "ModeSwitchEntry" object is changed to "values" in amxmi file</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below are the changes in the reference Types:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type (version APP4MC 0.7.0)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">size</td>
+ <td colspan="1" rowspan="1">Long</td>
+ <td colspan="1" rowspan="1">DataSize</td>
+ <td colspan="1" rowspan="1">MemoryType</td>
+ <td colspan="1" rowspan="1">HW Model, PropertyConstraintsModel</td>
+ <td colspan="1" rowspan="1">Attribute "size" is migrated as "DataSize" object. Long value of "size" is migrated to "value" of DataSize. As the DataSizeUnit info is not available, "unit" value is not set</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">size</td>
+ <td colspan="1" rowspan="1">DataUnit</td>
+ <td colspan="1" rowspan="1">DataSize</td>
+ <td colspan="1" rowspan="1">AbstractElementMemoryInformation</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">"size" of type "DataUnit" is migrated as "DataSize" object. Int value of "numberBits" attribute is migrated to "value" of DataSize, "unit" attribute is set as "bit" of type DataSizeUnit</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">size</td>
+ <td colspan="1" rowspan="1">DataUnit</td>
+ <td colspan="1" rowspan="1">DataSize</td>
+ <td colspan="1" rowspan="1">BaseTypeDefinition</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">"size" of type "DataUnit" is migrated as "DataSize" object. Int value of "numberBit" attribute is migrated to "value" of DataSize, "unit" attribute is set as "bit" of type DataSizeUnit</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">frequency</td>
+ <td colspan="1" rowspan="1">EInt</td>
+ <td colspan="1" rowspan="1">Frequency</td>
+ <td colspan="1" rowspan="1">Quartz</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">Attribute "frequency" of type EInt is migrated as "Frequency" object. "frequency" EInt value is migrated to "value" EDouble of DataSize. As the FrequencyUnit info is not available, "unit" value is not set</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below references are removed:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">size</td>
+ <td colspan="1" rowspan="1">DataUnit</td>
+ <td colspan="1" rowspan="1">Section</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model as size can't be specified for "Section" (considered as virtual memory section)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">labels</td>
+ <td colspan="1" rowspan="1">[0-*] Label</td>
+ <td colspan="1" rowspan="1">Section</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. As per APP4MC 0.7.1 semantics, Label object has the association to the Section inside which it can be allocated</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">runEntities</td>
+ <td colspan="1" rowspan="1">[0-*] Runnable</td>
+ <td colspan="1" rowspan="1">Section</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. As per APP4MC 0.7.1 semantics, Runnable object has the association to the Section inside which it can be allocated</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">groupingType</td>
+ <td colspan="1" rowspan="1">RunnableGroupingType</td>
+ <td colspan="1" rowspan="1">ProcessRunnableGroup</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">entries</td>
+ <td colspan="1" rowspan="1">[0-*] ProcessRunnableGroupEntry</td>
+ <td colspan="1" rowspan="1">ProcessRunnableGroup</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. Runnable object belonging to the ProcessRunnableGroupEntry is associated to the runnables list contained at the ProcessRunnableGroup object</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">default</td>
+ <td colspan="1" rowspan="1">EBoolean</td>
+ <td colspan="1" rowspan="1">ModeSwitchEntry</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">Content removed from the model. If several ModeSwitchEntry objects contain attribute "default" as "true", then first ModeSwitchEntry which has "default" as "true" is converted to "ModeSwitchDefault" object</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below Classes are removed:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SchedulerPairingConstraint</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SchedulerSeparationConstraint</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ProcessRunnableGroupEntry</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">This element is removed from the model, but the Runnables associated to it are associated to ProcessRunnableGroup object</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OrderConstraint</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.1</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">AgeConstraint</td>
+ <td colspan="1" rowspan="1">Constraints model</td>
+ <td colspan="1" rowspan="1">Content is migrated as EventChainLatencyConstraint element with LatencyType as "Age"</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ReactionConstraint</td>
+ <td colspan="1" rowspan="1">Constraints model</td>
+ <td colspan="1" rowspan="1">Content is migrated as EventChainLatencyConstraint element with LatencyType as "Reaction"</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SynchronisationConstraint</td>
+ <td colspan="1" rowspan="1">Constraints model</td>
+ <td colspan="1" rowspan="1">Content is migrated as EventSynchronizationConstraint element</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SectionMapping</td>
+ <td colspan="1" rowspan="1">Mapping Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. As per 0.7.1, there is a possibility to specify PhysicalSectionMapping element i.e. defining mapping of various Section elements to Memory</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">SectionMappingConstraint</td>
+ <td colspan="1" rowspan="1">Property Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model.As per 0.7.1, there is a possibility to specify PhysicalSectionConstraint element i.e. defining possibility of Section allocation across various Memories</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">DataUnit</td>
+ <td colspan="1" rowspan="1">Sw model</td>
+ <td colspan="1" rowspan="1">Content is migrated as DataSize. Attribute "unit" is set as DataSizeUnit of type "bit"</td>
+ </tr>
+ </table>
+
+
+<h4><a id="section4.4.5.5"></a>Version APP4MC 0.7.1 to APP4MC 0.7.2</h4>
+ <p>
+ <strong>Change in the namespace:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version App4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA Namespace (version App4MC 0.7.2)</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.7.1</td>
+ <td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.7.2</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below are the changes in the reference names:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Changed Variable Name (version APP4MC 0.7.2)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">runnables</td>
+ <td colspan="1" rowspan="1">group</td>
+ <td colspan="1" rowspan="1">RunnablePairingConstraint</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">xml tag "runnables" present inside "RunnablePairingConstraint" object is changed to "group" in amxmi file</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">processes</td>
+ <td colspan="1" rowspan="1">group</td>
+ <td colspan="1" rowspan="1">ProcessPairingConstraint</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">xml tag "processes" present inside "ProcessPairingConstraint" object is changed to "group" in amxmi file</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">labels</td>
+ <td colspan="1" rowspan="1">group</td>
+ <td colspan="1" rowspan="1">DataPairingConstraint</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">xml tag "labels" present inside "DataPairingConstraint" object is changed to "group" in amxmi file</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">initalValue</td>
+ <td colspan="1" rowspan="1">initialValue</td>
+ <td colspan="1" rowspan="1">Semaphore</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">xml attribute "initalValue" present inside "Semaphore" object is changed to "initialValue" in amxmi file</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">arrivalCurveEntries</td>
+ <td colspan="1" rowspan="1">entries</td>
+ <td colspan="1" rowspan="1">ArrivalCurve</td>
+ <td colspan="1" rowspan="1">Stimuli Model</td>
+ <td colspan="1" rowspan="1">xml tag "arrivalCurveEntries" present inside "ArrivalCurve" object is changed to "entries" in amxmi file</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below are the changes in the reference Types:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type (version APP4MC 0.7.2)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">instructions</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">SchedulingSWUnit</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the instructions tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiSendMessage</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiSendMessage tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiTerminateTask</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiTerminateTask tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiSchedule</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiSchedule tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiRequestResource</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiRequestResource tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiReleaseResource</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiReleaseResource tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiSetEvent</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiSetEvent tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiWaitEvent</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiWaitEvent tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiClearEvent</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiClearEvent tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiActivateTask</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiActivateTask tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">apiEnforcedMigration</td>
+ <td colspan="1" rowspan="1">OsExecutionInstructions</td>
+ <td colspan="1" rowspan="1">Instructions</td>
+ <td colspan="1" rowspan="1">OsAPIInstructions</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">type of the apiEnforcedMigration tag in amxmi is updated either to InstructionsConstant or InstructionsDeviation based on if the type in input is : OsExecutionInstructionsConstant or OsExecutionInstructionsDeviation</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below are the changes in the relation of elements:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Relation (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Relation (version APP4MC 0.7.2)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">memory</td>
+ <td colspan="1" rowspan="1">Memory</td>
+ <td colspan="1" rowspan="1">containment</td>
+ <td colspan="1" rowspan="1">association</td>
+ <td colspan="1" rowspan="1">HwMemoryProperty</td>
+ <td colspan="1" rowspan="1">PropertyConstraints model</td>
+ <td colspan="1" rowspan="1">memory objects containment is changed as association relation. As a result definition of Memory object should not be present inside HwMemoryProperty, rather only reference of memory should be present inside HwMemoryProperty. Model migration is performed in the following way for this change : Memory elements definition from HwMemoryProperty tag are moved to HW Model (Note: addition of Memory (from PropertyConstraints model) to HW model happens only if Memory with this name is not existing in the model scope)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">core</td>
+ <td colspan="1" rowspan="1">Core</td>
+ <td colspan="1" rowspan="1">containment</td>
+ <td colspan="1" rowspan="1">association</td>
+ <td colspan="1" rowspan="1">HwCoreProperty</td>
+ <td colspan="1" rowspan="1">PropertyConstraints model</td>
+ <td colspan="1" rowspan="1">core objects containment is changed as association relation. As a result definition of Core object should not be present inside HWCoreProperty, rather only reference of core should be present inside HWCoreProperty. Model migration is performed in the following way for this change : Core elements definition from HwCoreProperty tag are moved to HW Model (Note: addition of Memory (from PropertyConstraints model) to HW model happens only if Memory with this name is not existing in the model scope)</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below are the changes in Enum elements:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Enum Name</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Enum Literal (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Enum Literal (version APP4MC 0.7.2)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">Preemption</td>
+ <td colspan="1" rowspan="1">unknown</td>
+ <td colspan="1" rowspan="1">-</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">unknown literal is removed from Preemption. Model Migration will replace "unknown" literal with the default literal</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below references are removed:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Name (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Variable Type</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class containing Variable</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">samplingType</td>
+ <td colspan="1" rowspan="1">SamplingType</td>
+ <td colspan="1" rowspan="1">Deviation</td>
+ <td colspan="1" rowspan="1">Hardware Model Stimuli MOdel OS Model Software Model</td>
+ <td colspan="1" rowspan="1">In 0.7.2, samplingType attribute is shifted from Deviation to Boundaries element.As a part of Model migration -> samplingType content is removed from Deviation and associated to the corresponding Distribution of type Boundaries. If Boundaries element is not present inside Deviation as a distribution, corresponding samplingType data is skipped during model migration</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">coreTypeDefinitions</td>
+ <td colspan="1" rowspan="1">CoreType</td>
+ <td colspan="1" rowspan="1">PropertyConstraintsModel</td>
+ <td colspan="1" rowspan="1">Property Constraints Model</td>
+ <td colspan="1" rowspan="1">coreTypeDefinitions objects are removed from the PropertyConstraintsModel tag and are associated to HW Model (Note: addition of CoreType to HW model happens only if CoreType with this name is not existing in the model scope. If there exists CoreType element with the same name in "PropertyConstraintsModel" and in "HW Model" --> the one from PropertyConstraintsModel will be removed and the one from HW Model will be referred accordingly inside Core element etc.,)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">memoryTypeDefinitions</td>
+ <td colspan="1" rowspan="1">MemoryType</td>
+ <td colspan="1" rowspan="1">PropertyConstraintsModel</td>
+ <td colspan="1" rowspan="1">Property Constraints Model</td>
+ <td colspan="1" rowspan="1">memoryTypeDefinitions objects are removed from the PropertyConstraintsModel tag and are associated to HW Model (Note: addition of MemoryType to HW model happens only if MemoryType with this name is not existing in the model scope. If there exists MemoryType element with the same name in "PropertyConstraintsModel" and in "HW Model" --> the one from PropertyConstraintsModel will be removed and the one from HW Model will be referred accordingly inside MemoryElement element etc.,)</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">tags</td>
+ <td colspan="1" rowspan="1">Tag</td>
+ <td colspan="1" rowspan="1">ComponentsModel, HWModel, SWModel</td>
+ <td colspan="1" rowspan="1">Components Model, Hardware Model, Software Model</td>
+ <td colspan="1" rowspan="1">Tag objects are removed from the ComponentsModel,HWModel,SWModel tags and their content is shifted to CommonElements Model (Note: CommonElements model is contained inside Amalthea root node)</td>
+ </tr>
+ </table>
+ <p>
+ <strong>Below Classes are removed:</strong>
+ </p>
+ <table class="classic" style="margin-left:40px">
+ <tr>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Class Name (version APP4MC 0.7.1)</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>AMALTHEA sub model</em>
+ </strong>
+ </td>
+ <td colspan="1" rowspan="1">
+ <strong>
+ <em>Model Migration behavior</em>
+ </strong>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">TargetProcess</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">TargetCallSequence</td>
+ <td colspan="1" rowspan="1">Constraints Model</td>
+ <td colspan="1" rowspan="1">Content is removed from the model. There is no equivalent of this model element in APP4MC 0.7.2</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OsExecutionInstructions, OsExecutionInstructionsDeviation, OsExecutionInstructionsConstant</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">Replacement elements are : Instructions,InstructionsDeviation,InstructionsConstant. As there is no change in the content of these elements(when compared to previous elements) -> during model migration corresponding old type names are replaced with the new model elements</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ProbabilityGroup</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">ProbabilityGroup is replaced with RunnableProbabilitySwitch</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">ProbabilityRunnableItem</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">ProbabilityRunnableItem is replaced wtih ProbabilitySwitchEntry</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">DeviationRunnableItem</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">Content of DeviationRunnableItem i.e RunnableItem is moved directly inside the Group as a part of "items" list</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">EventConfigElement, EventConfigLink</td>
+ <td colspan="1" rowspan="1">Config Model</td>
+ <td colspan="1" rowspan="1">Both EventConfigElement and EventConfigLink objects are converted as EventConfig objects (As EventConfigElement & EventConfigLink classes are removed from the MetaModel – as per the semantics equivalent class for both of them is EventConfig). In case of migrating EventConfigElement – If definition of EntityEvent element is present as a sub-element -> it is moved to Events Model and the corresponding reference to EntityEvent is established inside EventConfig using attribute "event"</td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">OsBuffering</td>
+ <td colspan="1" rowspan="1">OS Model</td>
+ <td colspan="1" rowspan="1">OsBuffering elements are migrated as OsDataConsistency elements. Below steps describe the criteria considered for migration of data :
+ <img class="gray_scale" src="images/osbuffering_migration_071_072.png"/>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">LabelBufferring</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">LabelBufferring elements are migrated as DataStability elements. Below steps describe the criteria considered for migration of data :<br> - If LabelBuffering value is "buffered" then the corresponding value of "dataStability" is set as "CustomProtection"<br> - If LabelBuffering value is "notBuffered" then the corresponding value of "dataStability" is set as "noProtection" <br>- If LabelBuffering value is "
+ <em>undefined</em>" (default) then the corresponding value of "dataStability" is set as "
+ <em>undefined</em>" (default)
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">LabelAccessBufferring</td>
+ <td colspan="1" rowspan="1">SW Model</td>
+ <td colspan="1" rowspan="1">LabelAccessBufferring elements are migrated as DataStability elements. Below steps describe the criteria considered for migration of data :<br> - If LabelAccessBufferring value is "inherited" then the corresponding value of "dataStability" is set as "inherited"<br> - If LabelAccessBufferring value is "buffered" then the corresponding value of "dataStability" is set as "customProtection" <br> - If LabelAccessBufferring value is "notBuffered" then the corresponding value of "dataStability" is set as "noProtection" <br>- If LabelAccessBufferring value is "
+ <em>undefined</em>" (default) then the corresponding value of "dataStability" is set as "
+ <em>undefined</em>" (default)
+ </td>
+ </tr>
+ <tr/>
+ </table>
+
+
+<h2><a id="section4.5">4.5 </a>Partitioning</h2>
+ <p>The AMALTHEA partitioning approach supports various features, which can be combined and configured in order to exploit software parallelism in various ways. Besides mandatory model enhancements such as the label access analysis leading to a constraints model with
+ <code>RunnableSequencingConstraints</code> and the cycle elimination to provide directed acyclic graphs, features like activation grouping or the independent graph grouping can be optionally performed. Subsequently, one of two different partitioning approaches can be performed, that cut the created graphs into partitions (
+ <code>ProcessPrototypes</code>) that can later be transformed to tasks. These tasks can be efficiently executed in parallel on a target platform, since ordering constraints are considered and task execution time and inter task communications are minimized. On the one hand, the
+ <i>CPP</i> approach performs graph theoretical mechanisms to initially reveal a critical path of
+ <code>runnables</code> (also denoted as nodes) and dependencies (also denoted as edges) from a source node to a sink node. That initial path is assigned to the first partition and branch nodes are identified and assigned to additional tasks with respect to order constraints, execution cycles and communication overheads. This partitioning approach provides an automatic
+ <code>runnable</code> distribution resulting in an efficient parallelism factor with respect to an unbounded number of tasks and causal runnable orders i.e. dependencies. On the other hand, the
+ <i>ESSP</i> partitioning approach performs a timing based partitioning with respect to a bounded number of partitions (configurable by the user), since this case is often mandatory in order to meet system requirements. Both approaches therefore read, adapt and write AMALTHEA specific constraints and software models and express the first approaches within the AMALTHEA platform to automatically exploit system parallelism and utilize parallel resources. The user benefits from not manually assigning runnables to tasks through a complex, error prone and time consuming process but triggering a configurable partitioning approach, that automatically performs that assignment using different algorithms for various optimizing criteria in order to distribute existing software effectively.
+ </p>
+
+
+<h3><a id="section4.5.1">4.5.1 </a>Usage of Partitioning</h3>
+ <p>The following configuration window shows the different features, which are available for the partitioning process.</p>
+ <p>
+ <img src="images/config.png"/>
+ </p>
+ <p>Each process is described in the following sections.</p>
+ <p>In order to start the partitioning, the user is intended can rightclick on an
+ <i>.amxmi</i> file and select the
+ <i>Perform Partitioning</i> command as shown in the following figure.
+ <br>
+ <img src="images/click_small.png"/>
+ </p>
+ <p>Alternatively, a workflow can be written (using the MWE2 eclipse workflow engine) to start the partitioning process and further define various workflows for different inputs and outputs (see example at this partitioning help's end).</p>
+ <p>With regard to the partitioning configuration, the partitioning process will perform various model adaptations as shown in the following figure and described in the next sections.</p>
+ <p>
+ <img class="scale" src="images/psteps_small.png"/>
+ </p>
+
+
+<h3><a id="section4.5.2">4.5.2 </a>Prepartitioning</h3>
+ <p>In order to perform the actual partitioning based on __DAWG__s (directed acyclic weighted graphs), various processing needs to be performed on the given input i.e. a set of runnables with label accesses, execution cycles and activations. Required processing are creating a constraints model with
+ <code>RunnableSequencingConstraints</code> and cycle elimination that creates
+ <code>AccessPrecedences</code> for each dependency that needs to be decomposed from a
+ <code>RunnableSequencingConstraint</code> to eliminate one or more cycles. Further adaptations can create
+ <code>ProcessPrototypes</code> in order to group runnables based on activation references or based on independent graphs.
+ </p>
+
+
+<h4><a id="section4.5.2.1"></a>Activation Analysis</h4>
+ <p>Typical for embedded software, code fragments need to be executed within different intervals i.e. timers, interrupts or events. Sensors or actuators for example must often be read within short intervals for precise and accurate executions. Contrarily, certain processing fragments independent from the system's stability can be executed at greater intervals due to having less impact on the system's performance. Such activations can either be referenced by tasks via the stimulation model or by runnables via activations in the software model. By assessing these model entities and references, temporal classification can be implied. The activation analysis feature creates
+ <code>ProcessPrototypes</code> for each activation and assigns referencing runnables correspondingly via creating
+ <code>TaskRunnableCalls</code> within the
+ <code>ProcessPrototypes</code>.
+ </p>
+
+
+<h4><a id="section4.5.2.2"></a>Label Analysis</h4>
+ <p>The label analysis comprises the comparison of read and write accesses of all runnables for identifying dependencies. For example, in case runnable
+ <i>A</i> writes a label and another runnable
+ <i>B</i> reads the same label, runnable
+ <i>B</i> depends on runnable
+ <i>A</i>. This dependency is saved as a
+ <code>RunnableSequencingConstraint</code>. Such
+ <code>RunnableSequencingConstraint</code> is the basis for performing a
+ <i>DAG</i> (directed acyclic graph) analysis and allows the determination of concurrency due to giving information about fork and join dependencies respectively
+ <code>runnables</code> that can be calculated in parallel. Furthermore, the label access analysis allows deriving memory structure via common data accesses. The
+ <code>RunnableSequencingConstraints</code> are stored within a new or an existing constraints model. An example is given in the following picture:
+ </p>
+ <p>
+ <img src="images/dependency_new.png"/>
+ </p>
+
+
+<h4><a id="section4.5.2.3"></a>Cycle Elimination</h4>
+ <p>The cycle elimination is a mandatory step for all subsequent methods and features. Topological and graph theoretical calculations require
+ <i>DAWG__s, such that a cycle elimination has to be performed in advance. A cycle may occur in case two runnables share the same resource (label) in both directions, i.e. both runnables read and write the same label, or in case runnable __A</i> reads label
+ <i>BA</i> and writes label
+ <i>AB</i> and runnable
+ <i>B</i> reads label
+ <i>AB</i> and writes label
+ <i>BA</i>. Furthermore, a cycle may be formed across multiple runnables. For the purpose of finding such cycles, the external
+ <i>JgraphT</i> library has been added to the project, that supports finding all of these cycles. After all cycles have been identified, a specific mechanism (configurable through 'Minimal dependency decompositions for cycle elimination' in the preference page) detects edges (dependencies), which occur in multiple cycles. This mechanism iterates over edges within multiple cycles in descending order, i.e. it starts with an edge, that occurs in most cycles for ensuring minimal edge elimination. In order to retain a dependency that has been selected for elimination, such selected edges are transformed from a
+ <code>RunnableSequencingConstraint</code> to an
+ <code>AccessPrecedence</code>. After edge sharing cycles have been decomposed, all cycles that do not share any edges have to be decomposed as well. For each of these cycles an edge can be identified that provides an optimal retaining graph (configurable through 'Increase parallelization potential for cycle elimination result' in the preference page). The following figure shows 7 cycle elimination possibilities with an example graph.
+ <br>
+ <img class="scale" src="images/cycle_small.png"/>
+ <br>Red transitions indicate edges, that are decomposed into
+ <code>AccessPrecedences</code> for the corresponding solution. Rretaining graphs are shown on the right side of each solution indicated by a dashed rectangle. For illustration purposes, we assume equal execution time for each runnable (letter). Solution 1 and 5 (green dashed rectangles) feature the minimal runtime for two tasks. This assessment is made with respect to topological graph structure respectively the
+ <i>span</i> of a graph (critical path) compared with its
+ <i>parallelism</i>.
+ </p>
+
+
+<h3><a id="section4.5.3">4.5.3 </a>Partitioning Algorithms</h3>
+ <p>Each of the algorithms decribed in the following creates ProcessPrototypes i.e. task precursor.</p>
+
+
+<h4><a id="section4.5.3.1"></a>Independent Graph Partitioning (GGP)</h4>
+ <p>The independent graph identification process, or also denoted as global graph partitioning, can be executed after the cycle elimination in case the user selected the corresponding entry in the configurations ('Create independent graph partitions'). This methodology looks for graphs or single nodes, that do not share any label with other runnables or complete graphs that do not share labels with other graphs. Such methodology allows forming tasks, which can be totally distributed to either different cores or even to totally different systems as seen in the following figure:</p>
+ <p>
+ <img class="scale" src="images/ggp_small.png"/>
+ </p>
+
+
+<h4><a id="section4.5.3.2"></a>Critical Path Partitioning (CPP)</h4>
+ <p>The
+ <i>CPP</i> approach considers node weights (i.e. arbitrary computation / execution cycles / instructions of
+ <code>runnables</code>) and partitions __DAWG__s, whereas
+ <code>runnables</code> are equally distributed among an automatically determined number of partitions. The partitioning's objective is to reduce overall execution time and inter task communication. The subsequent mapping methodology further considers resource constraints (availability of hardware and software resources namely program and data memory). The system's critical path is assigned to the first partition and branches of the graph are subsequently assigned to additional partitions. The approach has been chosen, because the critical path features mandatory sequential ordering, that cannot be computed in parallel. Thus, the weight of a critical path provides a lower bound on the total time to perform all the jobs. A CPP example is shown in the following figure (left = input graph; right = partitioning result):
+ </p>
+ <p>
+ <img class="scale" src="images/lgp_small.png"/>
+ </p>
+
+
+<h4><a id="section4.5.3.3"></a>Earliest Start Schedule Partitioning (ESSP)</h4>
+ <p>The
+ <i>ESSP</i> partitioning is developed for allowing the user to restrict the number of partitiong. This may be important and useful in very large systems in order to keep the task creation and task inter communication costs low. The
+ <i>ESSP</i> partitioning balances runnables across partitions with respect to their causal orders. For this purpose, only runnable�s
+ <code>eit</code> (earliest initial time) -values are calculated, that define the sum of the longest preceding path�s instructions. The methodology picks the partition with the lowest schedule length, calculates a set of assignable
+ <code>runnables</code>, which predecessors are already scheduled, and assignes a runnable to the current partition, that minimizes the shedule length.
+ </p>
+
+
+<h4><a id="section4.5.3.4"></a>Partitioning Exmaple</h4>
+ <p>The following figure illustrates the resulting partitions of the previously described algorithms based on an example graph shown on the left. On the right, the partitioning results are shown for (top) - CPP, (middle) - ESSP configurated with 2 partitions and (bottom) - ESSP for 3 partitions.</p>
+ <p>
+ <img class="scale" src="images/partexample.png"/>
+ </p>
+
+
+<h3><a id="section4.5.4">4.5.4 </a>Further Features</h3>
+ <p>Two further features provide graph visualizations and a different graph representation through
+ <i>RunnableSequencingConstraints</i>.
+ </p>
+
+
+<h4><a id="section4.5.4.1"></a>Applet Generation</h4>
+ <p>The applet generation can be triggered with a different command in the context menu via rightclicking on an
+ <i>.amxmi</i> file. In case the file contains a software model with
+ <i>runnables</i> and a constraints model with
+ <i>RunnableSequencingConstraints</i>, a java file will be generated, that can be executed as an applet with the help of the
+ <i>JgraphT</i> library. Such an applet visualizes a graph and can be adapted in an applet viewer. The following figure shows such an applet.
+ </p>
+ <p>
+ <img class="scale" src="images/applet_small.png"/>
+ </p>
+
+
+<h4><a id="section4.5.4.2"></a>Dependency Alternative</h4>
+ <p>Thisfile generation feature focuses on a constraints model approach that features a different dependency representation compared with the result from the label access analysis that always features two
+ <i>RunnableGroups</i> with each one
+ <i>RunnableGroupEntry</i> entity within a
+ <i>RunnableSequencingConstraint</i>. The approach can be adapted to feature more
+ <i>RunnableGroups</i> and more
+ <i>RunnableGroupEntries</i> and a less amount of
+ <i>RunnableSequencingConstraints</i>, derived from the same graph. An example is expressed in the following figure.
+ </p>
+ <p>
+ <img src="images/ta_small.png"/>
+ </p>
+
+
+<h3><a id="section4.5.5">4.5.5 </a>Workflow example</h3>
+ <p>The described features can also be triggered by a workflow (Eclipse's MWE2 workflow engine), exemplarily shown in the following code.</p>
+ <pre xml:space="preserve"><code>Workflow {
+//basic setup
+loadModule('/System/Resources')
+loadModule('/APP4MC/Workflow')
+
+//Importing needed packages
+importPackage(org.eclipse.app4mc.amalthea.workflow.component)
+importPackage(org.eclipse.app4mc.amalthea.workflow.core)
+importPackage(org.eclipse.app4mc.multicore.partitioning.workflow)
+
+//Configure logging
+addLoggerToConsole("org.eclipse.app4mc.multicore")
+addLoggerToConsole("org.eclipse.app4mc.amalthea.workflow")
+
+print("Starting Workflow ...")
+//general setup
+const BASE = "platform:/resource"
+const PROJECT = BASE + "/org.eclipse.app4mc.amalthea.example.democar.mapping"
+const MODEL_LOCATION1 = PROJECT + "/model/AMALTHEA_Democar_MappingExample.amxmi"
+
+var ctx = new DefaultContext()
+
+//Reader
+var reader = new ModelReader()
+reader.addFileName(MODEL_LOCATION1)
+reader.run(ctx)
+
+//prepartitioning
+var prepart = new PrePartitioningWrkflw()
+prepart.setAa(false)
+prepart.setGgp(false)
+prepart.setMinimEdge(false)
+prepart.setEffEdge(false)
+prepart.run(ctx)
+//result is saved in modelslot prePartitioning
+
+//Writer
+var writer = new ModelWriter()
+writer.setModelSlot("prePartitioning")
+writer.setFileName("prePartitioning")
+writer.setSingleFile(true)
+writer.setOutputDir(PROJECT + "/workflow-output")
+writer.run(ctx)
+
+//partitioning
+var part = new GeneratePartitioning()
+part.setModelLoc(MODEL_LOCATION1);
+part.setModelSlot("prePartitioning")
+part.setPartitioningAlg("essp")
+part.setNumberOfPartitions("4")
+part.run(ctx)
+
+//Writer
+var writer = new ModelWriter()
+writer.setModelSlot("partitioning")
+writer.setFileName("partitioning")
+writer.setSingleFile(true)
+writer.setOutputDir(PROJECT + "/workflow-output")
+writer.run(ctx)
+
+print("Finished Workflow")
+ctx.clear()
+endWorkflow()
+</code></pre>
+ <p><!-- --></p>
+
+
+<h3><a id="section4.5.6">4.5.6 </a>Plugin dependencies</h3>
+ <pre xml:space="preserve"><code>org.eclipse.core.runtime,
+org.eclipse.emf.ecore,
+org.eclipse.emf.ecore.xmi,
+org.eclipse.sphinx.emf,
+org.eclipse.ui,
+org.jgrapht,
+org.eclipse.app4mc.amalthea.model,
+org.eclipse.app4mc.multicore.openmapping
+</code></pre>
+ <p><!-- --></p>
+
+
+<h2><a id="section4.6">4.6 </a>Model Details</h2>
+
+
+<h3><a id="section4.6.1">4.6.1 </a>Unique ID generation</h3>
+ <p>AMALTHEA uses a named based schema to reference other elements inside of a model.
+ <br>A custom implementation is used instead of the standard EMF mechanism, which uses an index based implementation.
+ <br>The target element id is identified by the following schema:
+ </p>
+ <pre xml:space="preserve"><code>java.net.URLEncoder.encode(<name of element>, StandardCharsets.UTF_8.toString)) + "?type=" + <element>.eClass.name
+</code></pre>
+ <p>Samples:</p>
+ <p>Referencing a Runnable element with name foo in a TaskRunnableCall looks like the following snippet:</p>
+ <pre xml:space="preserve"><code><calls xsi:type="am:TaskRunnableCall" runnable="foo?type=Runnable" />
+</code></pre>
+
+
+<h3><a id="section4.6.2">4.6.2 </a>Interfaces and base objects</h3>
+ <p>Several interfaces and abstract classes are defined in the common model.
+ <br>They provide basic common functionality for all objects, which are extending it, like the possibility to add
+ <i>CustomAttributes</i> or
+ <i>Tags</i>. Tags are available at different elements with the purpose to group them together or to annotate them.
+ </p>
+ <p>
+ <img class="scale" src="images/model_common_interfaces_base_objects.png"/>
+ </p>
+
+
+<h3><a id="section4.6.3">4.6.3 </a>Transient back pointers</h3>
+ <p>AMALTHEA maintains a (small) number of back pointers in the model. A transient reference of an object 'points back' to the object referring to it. This allows easier navigation, at the expense of greater memory use.</p>
+
+
+<h4><a id="section4.6.3.1"></a>Current back pointers</h4>
+ <p>The data model has some intermediate objects to express the call of a runnable or the access to a label.
+ <br>These objects are containments of
+ <i>Task</i> or
+ <i>Runnable</i> and can have additional attributes. The back pointers support an easy way to answer queries like "Which tasks call runnable x ?" or "Which functions read label y ?".
+ </p>
+ <table>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1">Back pointer (read only)</td>
+ <td colspan="1" rowspan="1" style="text-align: right;">Reference</td>
+ <td colspan="1" rowspan="1"/>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>LabelAccess</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>labelAccesses</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>data</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>Label</code>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>TaskRunnableCall</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>taskRunnableCalls</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>runnable</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>Runnable</code>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>RunnableCall</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>runnableCalls</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>runnable</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>Runnable</code>
+ </td>
+ </tr>
+ </table>
+ <p>All elements with memory representation (e.g. labels, runnables) can be mapped to exactly one memory. The back pointer provides a list of all elements that are assigned to a specific memory.</p>
+ <table>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1">Back pointer (read only)</td>
+ <td colspan="1" rowspan="1" style="text-align: right;">Reference</td>
+ <td colspan="1" rowspan="1"/>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>Mapping</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>mappings</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>memory</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>Memory</code>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>AbstractElementMapping</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>mappings</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>abstractElement</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>AbstractElementMemoryInformation</code>
+ </td>
+ </tr>
+ </table>
+ <p>Labels and runnables can be located in exactly one section. The back pointer provides a list of all elements that are assigned to a specific section.</p>
+ <table>
+ <tr>
+ <td colspan="1" rowspan="1"/>
+ <td colspan="1" rowspan="1">Back pointer (read only)</td>
+ <td colspan="1" rowspan="1" style="text-align: right;">Reference</td>
+ <td colspan="1" rowspan="1"/>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>Label</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>labels</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>section</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>Section</code>
+ </td>
+ </tr>
+ <tr>
+ <td colspan="1" rowspan="1">
+ <code>Runnable</code>
+ </td>
+ <td colspan="1" rowspan="1" style="color:green">←
+ <strong>runnables</strong>
+ </td>
+ <td colspan="1" rowspan="1" style="text-align: right;">
+ <strong>section</strong> →
+ </td>
+ <td colspan="1" rowspan="1">
+ <code>Section</code>
+ </td>
+ </tr>
+ </table>
+
+
+<h4><a id="section4.6.3.2"></a>Implementation</h4>
+ <p>
+ <b>Xcore:</b>
+ </p>
+ <p>In addition to a reference
+ <span>
+ <strong><reference></strong>
+ </span> there is a transient reference named
+ <span>
+ <strong><reference>LinkInt</strong>
+ </span>.
+ <br>The visiblity in the generated code and in the user interface is controlled by
+ <span>
+ <strong>@GenModel</strong>
+ </span> annotations.
+ </p>
+ <pre xml:space="preserve"><code>class TaskRunnableCall extends CallSequenceItem
+{ ...
+ refers Runnable[1] runnable
+
+ // hidden link (internal)
+ @GenModel(property="None", suppressedGetVisibility="true", suppressedSetVisibility="true"))
+ refers transient Runnable[1] runnableLinkInt opposite taskRunnableCalls
+}
+
+class Runnable extends AbstractElementMemoryInformation
+{ ...
+ // back pointer (readonly)
+ @GenModel(property="Readonly", suppressedSetVisibility="true")
+ @GenModel(propertyCategory="Read only", propertyFilterFlags="org.eclipse.ui.views.properties.expert")
+ refers transient TaskRunnableCall[] taskRunnableCalls opposite runnableLinkInt
+}
+</code></pre>
+ <p><!-- --></p>
+ <p>
+ <b>Classes and references:</b>
+ </p>
+ <p>
+ <img src="images/model_transient_backpointer.png"/>
+ </p>
+ <p>
+ <b>Generated code:</b>
+ </p>
+ <p>EMF code generation allows the use of dynamic templates. AMALTHEA uses this technology to additionally set the transient value in the setter code of the standard value. The dynamic template is triggered by the name pattern
+ <span>'<reference></span>' and
+ <span>'<reference>LinkInt'</span>.
+ </p>
+ <pre xml:space="preserve"><code>public class TaskRunnableCallImpl ... {
+ ...
+ public void setRunnable(org.eclipse.app4mc.amalthea.model.Runnable newRunnable) {
+ ...
+ //Additional setting transient value for transient bi-directional reference
+ setRunnableLinkInt(newRunnable);
+ }
+}
+</code></pre>
+ <p><!-- --></p>
+
+
+<h4><a id="section4.6.3.3"></a>User Interface</h4>
+ <p>
+ <img src="images/model_transient_backpointer_ui.png"/>
+ </p>
+
+
+<h2><a id="section4.7">4.7 </a>AMALTHEA Model XSD Schema</h2>
+ <p>The AMALTHEA model is specified with the Eclipse Modeling Framework (EMF). In EMF data-models are defined with the Ecore/Xcore format. Eclipse developers can use the AMALTHEA Platform to work with the model. For developers that are not using Java or Eclipse, the specification is also provided in the XSD format. A XSD file for each package can be found
+ <a href="zip/xml-schema-definitions.zip" shape="rect">here</a>.
+ </p>
+ <p>The AMALTHEA model references two external model definitions:
+ <br>- The Ecore model (http://www.eclipse.org/emf/2002/Ecore)
+ <br>- The Franca model (http://core.franca.org)
+ </p>
+ <p>The XSD file for the Ecore model can be found on the
+ <a href="http://www.eclipse.org/modeling/emf/downloads/" shape="rect">Eclipse EMF download page</a>
+ <br>Download the
+ <i>Models</i> package from
+ <i>Latest Releases</i>. The download contains a folder "org.eclipse.emf.ecore_*". This folder contains the XSD schema for Ecore.
+ </p>
+ <p>The Franca model is only available as Ecore file. To generate an XSD schema open the AMALTHEA Tool Platform and do the following steps:</p>
+ <p>Open the Plug-Ins View by selecting
+ <i>Window -> Show View -> Other</i> and select Plug-Ins View in the folder Plug-in Development:
+ </p>
+ <p>
+ <img src="images/show_plugins_view.png"/>
+ </p>
+ <p>Select the plug-in
+ <i>org.franca.core</i> and import it as
+ <i>Binary Project</i>:
+ </p>
+ <p>
+ <img src="images/import_franca-core.png"/>
+ </p>
+ <p>Open the model folder in the imported project, do a right click on the "franca.genmodel" file and select "Export Model".</p>
+ <p>
+ <img src="images/export_model.png"/>
+ </p>
+ <p>Select the entry "XML Schema for XMI" in the first wizard page.</p>
+ <p>
+ <img src="images/export_wizard1.png"/>
+ </p>
+ <p>Navigate to the last wizard page, select "org.franca.core.franca" and click finish.</p>
+ <p>
+ <img src="images/export_wizard2.png"/>
+ </p>
+ <p>Now there the file "francaXMI.xsd" in the model folder.</p>
+</article>
+
+
+<article>
+<h1><a id="section5">5 </a>Release Notes</h1>
+
+
+<h2><a id="section5.1">5.1 </a>Eclipse APP4MC 0.7.2 (Jan 2017)</h2>
+ <p>General</p>
+ <ul>
+ <li>Smaller product definition (optional parts can be installed via update sites)</li>
+ <li>Harmonized model API</li>
+ </ul>
+ <p>Model handling</p>
+ <ul>
+ <li>Model migration support (0.7.1 -> 0.7.2)</li>
+ <li>Improved back references</li>
+ </ul>
+ <p>Model changes</p>
+ <ul>
+ <li>New core-specific runtimes (instructions) for runnables</li>
+ <li>New model elements for streaming communication (Channels)*</li>
+ <li>New Transmission Policy for communication (e.g. label accesses) </li>
+ <li>New Event-based Stimulus</li>
+ <li>New Data Consistency needs</li>
+ <li>New Counters for InterProcessActivation and EventStimulus</li>
+ <li>Harmonized model elements to describe probability</li>
+ <li>Storage of common elements (e.g. tags) in one central location</li>
+ </ul>
+ <p>Bug fixes / Improvements</p>
+ <ul>
+ <li>Model migration (ISR call graph, Section names, cross document references)</li>
+ <li>Back references (Memory -> Mapping, Scheduler -> CoreAllocation)</li>
+ </ul>
+ <p>Documentation</p>
+ <ul>
+ <li>New model elements: Physical memory sections, Channels</li>
+ <li>New examples</li>
+ </ul>* =
+ <i>Experimental feature (first modeling attempt that may change in future versions)</i>.
+ <p>
+ <em>For details see
+ <a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.7.2/bugs" shape="rect">Release 0.7.2 issues</a>
+ </em>
+ </p>
+
+
+<h2><a id="section5.2">5.2 </a>Eclipse APP4MC 0.7.1 (Oct 2016)</h2>
+ <p>Model handling</p>
+ <ul>
+ <li>Model migration support (0.7.0 -> 0.7.1)</li>
+ <li>Improved update of opposite references</li>
+ <li>Storage of default values is enabled by default</li>
+ </ul>
+ <p>Model changes</p>
+ <ul>
+ <li>New distribution "Beta Distribution"</li>
+ <li>New stimuli type "Synthetic" (to "replay" activations from a hardware trace)</li>
+ <li>New DataStabilityGroup</li>
+ <li>Introduced SamplingType as new attribute for Deviation</li>
+ <li>Introduced physical memory sections (PhysicalSectionConstraint, PhysicalSectionMapping)</li>
+ <li>Reworked AffinityConstraints (removed Scheduler constraints, added Data constraints)</li>
+ <li>Reworked Event / Event-Chain Constraints</li>
+ <li>Reworked RunnableSequencingConstraints</li>
+ <li>New types for DataSizes and DataRates</li>
+ </ul>
+ <p>
+ <em>For details see
+ <a href="https://bugs.eclipse.org/bugs/buglist.cgi?product=App4mc&target_milestone=0.7.1" shape="rect">Bugzilla entries for 0.7.1</a>
+ </em>
+ </p>
+
+
+<h2><a id="section5.3">5.3 </a>Eclipse APP4MC 0.7.0 (Jul 2016)</h2>
+ <p>Model handling</p>
+ <ul>
+ <li>Model migration support (itea1.1.0 -> itea1.1.1 -> 0.7.0)</li>
+ <li>Simplified model creation wizard</li>
+ <li>One consolidated model</li>
+ <li>Additional opposite references (transient) to ease model navigation</li>
+ <li>Scripting support for workflows (based on Eclipse EASE)</li>
+ </ul>
+ <p>Model changes</p>
+ <ul>
+ <li>Removed 'attributes' and 'features' from hardware model</li>
+ <li>Replaced generic
+ <i>ProcessAllocation</i> with specific
+ <i>ISRAllocation</i> and
+ <i>TaskAllocation</i>
+ </li>
+ <li>New
+ <i>BigInteger</i> values for
+ <i>CustomAttributes</i>
+ </li>
+ <li>Some renamed classes and attributes (details in the help)</li>
+ </ul>
+ <p>Model structure</p>
+ <ul>
+ <li>Removed direct dependency to Franca (replaced by implicit reference by interface name)</li>
+ </ul>
+ <p>Documentation</p>
+ <ul>
+ <li>Updated model documentation / class diagrams</li>
+ <li>New developer guide regarding Model Migration Framework</li>
+ <li>New developer guide regarding Workflows</li>
+ </ul>
+
+
+<h2><a id="section5.4">5.4 </a>AMALTHEA 1.1.1 (Oct 2015)</h2>
+ <p>Model handling</p>
+ <ul>
+ <li>Changed serialized model references to
+ <i>name based references</i>
+ </li>
+ <li>Restricted
+ <i>model scope</i> to surrounding folder (without sub folders)
+ </li>
+ </ul>
+ <p>Model changes</p>
+ <ul>
+ <li>Added
+ <i>HwAccessPath</i> to hardware model to describe an access path either by using latencies or available hardware elements
+ </li>
+ <li>Added
+ <i>Modes</i> to common model and
+ <i>ModeLabels</i> to software model to describe alternative execution paths of tasks
+ </li>
+ <li>Added
+ <i>isBuffered</i> attribute to Labels and LabelAccesses to describe data consistency requirements
+ </li>
+ <li>Added
+ <i>Requirements</i> to constraints model to describe quality requirements for the dynamic architecture
+ </li>
+ <li>Added
+ <i>DataCoherencyGroups</i> to constraints model to describe data coherency requirements
+ </li>
+ <li>Added
+ <i>ProcessChains</i> to software model to describe data processing over multiple tasks
+ </li>
+ </ul>
+ <ul>
+ <li>Switched validations to Sphinx check based and added different model validations</li>
+ <li>New values for
+ <i>CustomAttributes</i> with
+ <i>Time</i> and
+ <i>SignedTime</i>
+ </li>
+ </ul>
+ <p>Features</p>
+ <ul>
+ <li>New
+ <i>AMALTHEA Trace Database (ATDB) Import</i> to create an AMALTHEA model from a trace
+ </li>
+ </ul>
+ <p>Documentation</p>
+ <ul>
+ <li>Updated model documentation / class diagrams</li>
+ <li>Updated user guide documentation to include steps for create a new AMALTHEA model with wizard</li>
+ <li>Updated user guide documentation to include a tutorial for using the AMALTHEA Trace Database (ATDB) Import</li>
+ </ul>
+
+
+<h2><a id="section5.5">5.5 </a>AMALTHEA 1.1.0 (Aug 2015)</h2>
+ <ul>
+ <li>Updated OS model to include now possibility to describe the operating system in more detail, like OS overhead</li>
+ <li>Added Event Sets to Event model to allow the definition of an unspecified order for events in an event chain</li>
+ <li>Added Data Age Constraints to constraints model</li>
+ <li>Added Label Value Lists to Stimulus model to enable and disable stimuli by label values or to set label values by the activation of a stimulus </li>
+ <li>Added Arrival Curve Stimulus to Stimulus model </li>
+ <li>Added Terminate Task for Call Graph in Software model to allow the termination of a task within a switch</li>
+ <li>Added a address attribute in the Mapping model to allow the definition of a memory address in the memory mapping</li>
+ <li>Added CustomAttributes to all model AMALTHEA model elements</li>
+ <li>Added first version of OSLC adapter</li>
+ <li>Replace of attribute read/write in LabelAccessStatistic with value and readCacheMisses with cacheMisses</li>
+ <li>Added documentation for Counter element in SW model</li>
+ </ul>
+</article>
+
+
+<article>
+<h1><a id="section6">6 </a>Roadmap</h1>
+ <p>Current topics:</p>
+ <ul>
+ <li>Enhanced model handling to exchange different model parts</li>
+ <li>Simplified hardware model</li>
+ <li>Interactive help (visualization of model and meta model structure)</li>
+ </ul>
+ <p>All new releases are provided by
+ <a href="https://projects.eclipse.org/projects/technology.app4mc" shape="rect">Eclipse APP4MC</a>.
+ </p>
+ <p>For details see:</p>
+ <ul>
+ <li>
+ <a href="https://bugs.eclipse.org/bugs/buglist.cgi?product=App4mc&target_milestone=0.8.0" shape="rect">Bugzilla entries for version 0.8.0</a>
+ </li>
+ </ul>
+</article>
+<!-- - - - - - - - - - - Articles - - - - - - - - - - -->
+ </div>
+ </div>
+
+</body>
+
+</html>
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/1.0.3_org.itea2.amalthea.urifragments.converter.zip b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/1.0.3_org.itea2.amalthea.urifragments.converter.zip
new file mode 100644
index 0000000..730858a
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/1.0.3_org.itea2.amalthea.urifragments.converter.zip
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/1.1.0_org.itea2.amalthea.urifragments.converter.zip b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/1.1.0_org.itea2.amalthea.urifragments.converter.zip
new file mode 100644
index 0000000..01d97ba
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/1.1.0_org.itea2.amalthea.urifragments.converter.zip
Binary files differ
diff --git a/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/xml-schema-definitions.zip b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/xml-schema-definitions.zip
new file mode 100644
index 0000000..a245284
--- /dev/null
+++ b/websites/www.eclipse.org-app4mc-hugo/site/static/help/app4mc-0.7.2/zip/xml-schema-definitions.zip
Binary files differ
