Google Git
Sign in
eclipse / app4mc / org.eclipse.app4mc.web / f8409c6fd0cc512fed82bd28516ff273c34f8e5e / . / websites / www.eclipse.org-app4mc-hugo / site / static / help / app4mc-0.9.9 / index.html
blob: de7eab9daebf3eae90128b8ba5a35cb9b22a62ce [file] [log] [blame]
<!DOCTYPE html>
<!--
! Copyright (c) 2017-2020 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 2.0
! which accompanies this distribution, and is available at
! https://www.eclipse.org/legal/epl-2.0/
-->
<html lang="en">
<head>
<meta charset="UTF-8">
<title>APP4MC 0.9.9 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><input type="checkbox" id="toc2.2.1" /><label for="toc2.2.1"><a href="#section2.2.1">Timing in Amalthea Primer</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.1.1">Different Levels of Model Detail</a></label></li>
<li><label class="leaf"><a href="#section2.2.1.2">Discrete-Event Simulation</a></label></li>
<li><label class="leaf"><a href="#section2.2.1.3">Execution Time</a></label></li>
<li><label class="leaf"><a href="#section2.2.1.4">Data Accesses</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.2" /><label for="toc2.2.2"><a href="#section2.2.2">Hardware</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.2.1">Structural Modeling of Heterogeneous Platforms</a></label></li>
<li><label class="leaf"><a href="#section2.2.2.2">Recipe and Feature concept: An outlook of an upcoming approach</a></label></li>
<li><label class="leaf"><a href="#section2.2.2.3">General Hardware Model Overview</a></label></li>
<li><label class="leaf"><a href="#section2.2.2.4">Current implementation with features and the connection to the SW Model</a></label></li>
<li><label class="leaf"><a href="#section2.2.2.5">Interpretation of latencies in the model</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.3" /><label for="toc2.2.3"><a href="#section2.2.3">Software (development)</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.3.1">Runnables</a></label></li>
<li><label class="leaf"><a href="#section2.2.3.2">Process Prototypes</a></label></li>
<li><label class="leaf"><a href="#section2.2.3.3">Constraints</a></label></li>
<li><label class="leaf"><a href="#section2.2.3.4">Activations</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.4" /><label for="toc2.2.4"><a href="#section2.2.4">Software (runtime)</a></label>
<ul>
<li><input type="checkbox" id="toc2.2.4.1" /><label for="toc2.2.4.1"><a href="#section2.2.4.1">Processes (Tasks or ISRs)</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.4.1.1">Runnables</a></label></li>
<li><label class="leaf"><a href="#section2.2.4.1.2">Labels</a></label></li>
<li><label class="leaf"><a href="#section2.2.4.1.3">Semaphore</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section2.2.4.2">Stimulation</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.5" /><label for="toc2.2.5"><a href="#section2.2.5">General Concepts</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.5.1">Grouping of elements (Tags, Tag groups)</a></label></li>
<li><label class="leaf"><a href="#section2.2.5.2">Custom Properties</a></label></li>
<li><input type="checkbox" id="toc2.2.5.3" /><label for="toc2.2.5.3"><a href="#section2.2.5.3">Support of Packages </a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.5.3.1">Example of using Package</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.5.4" /><label for="toc2.2.5.4"><a href="#section2.2.5.4">Support of Namespaces </a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.5.4.1">Example of using Namespace</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.6" /><label for="toc2.2.6"><a href="#section2.2.6">Scheduling</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.6.1">Scheduler to Core assignment</a></label></li>
<li><label class="leaf"><a href="#section2.2.6.2">Task to Scheduler assignment</a></label></li>
<li><label class="leaf"><a href="#section2.2.6.3">Scheduler hierarchies</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.7" /><label for="toc2.2.7"><a href="#section2.2.7">Communication via channels</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.7.1">Channel</a></label></li>
<li><input type="checkbox" id="toc2.2.7.2" /><label for="toc2.2.7.2"><a href="#section2.2.7.2">Channel Access</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.7.2.1">Sending</a></label></li>
<li><label class="leaf"><a href="#section2.2.7.2.2">Receiving</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section2.2.7.3">Transmission Policy</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.8" /><label for="toc2.2.8"><a href="#section2.2.8">Data Dependencies</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.8.1">Overview</a></label></li>
<li><label class="leaf"><a href="#section2.2.8.2">Internal Dataflow</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.2.9" /><label for="toc2.2.9"><a href="#section2.2.9">Memory Sections</a></label>
<ul>
<li><label class="leaf"><a href="#section2.2.9.1">Virtual Memory Section</a></label></li>
<li><label class="leaf"><a href="#section2.2.9.2">Physical Memory Section</a></label></li>
<li><label class="leaf"><a href="#section2.2.9.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">Hardware Examples</a></label></li>
<li><input type="checkbox" id="toc2.3.10" /><label for="toc2.3.10"><a href="#section2.3.10">Scheduler Examples</a></label>
<ul>
<li><label class="leaf"><a href="#section2.3.10.1">Hierarchical Scheduler</a></label></li>
<li><label class="leaf"><a href="#section2.3.10.2">Partitioned_FPP Scheduler</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.3.11" /><label for="toc2.3.11"><a href="#section2.3.11">Numeric Modes Example</a></label>
<ul>
<li><label class="leaf"><a href="#section2.3.11.1">Example description</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.3.12" /><label for="toc2.3.12"><a href="#section2.3.12">New AMALTHEA Trace Database (ATDB) Example</a></label>
<ul>
<li><label class="leaf"><a href="#section2.3.12.1">Source BTF Trace</a></label></li>
<li><label class="leaf"><a href="#section2.3.12.2">Equivalent ATDB Contents</a></label></li>
<li><label class="leaf"><a href="#section2.3.12.3">Adding Event Chains</a></label></li>
<li><label class="leaf"><a href="#section2.3.12.4">Metrics on the Trace</a></label></li>
</ul>
</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 Visualizer Example</a></label></li>
<li><label class="leaf"><a href="#section2.4.2">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><input type="checkbox" id="toc2.5.2" /><label for="toc2.5.2"><a href="#section2.5.2">Sirius Viewer</a></label>
<ul>
<li><label class="leaf"><a href="#section2.5.2.1">Activate capabilities for project</a></label></li>
<li><input type="checkbox" id="toc2.5.2.2" /><label for="toc2.5.2.2"><a href="#section2.5.2.2">Available Diagrams</a></label>
<ul>
<li><input type="checkbox" id="toc2.5.2.2.1" /><label for="toc2.5.2.2.1"><a href="#section2.5.2.2.1">Task View</a></label>
<ul>
<li><label class="leaf"><a href="#section2.5.2.2.1.1">Communication Layer</a></label></li>
<li><label class="leaf"><a href="#section2.5.2.2.1.2">Label Layer</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section2.5.2.2.2">Label View</a></label></li>
<li><label class="leaf"><a href="#section2.5.2.2.3">EventChain View</a></label></li>
<li><label class="leaf"><a href="#section2.5.2.2.4">Tasks View</a></label></li>
<li><label class="leaf"><a href="#section2.5.2.2.5">Mapping View</a></label></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc2.6" /><label for="toc2.6"><a href="#section2.6">Model Visualization</a></label>
<ul>
<li><label class="leaf"><a href="#section2.6.1">Usage of AMALTHEA Model Visualization</a></label></li>
<li><input type="checkbox" id="toc2.6.2" /><label for="toc2.6.2"><a href="#section2.6.2">Standard Visualizations</a></label>
<ul>
<li><label class="leaf"><a href="#section2.6.2.1">Hardware Model</a></label></li>
<li><label class="leaf"><a href="#section2.6.2.2">Software Model</a></label></li>
<li><label class="leaf"><a href="#section2.6.2.3">Runnable</a></label></li>
<li><label class="leaf"><a href="#section2.6.2.4">Deviation</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc2.7" /><label for="toc2.7"><a href="#section2.7">Model Validation</a></label>
<ul>
<li><label class="leaf"><a href="#section2.7.1">Usage of AMALTHEA Model Validation</a></label></li>
<li><input type="checkbox" id="toc2.7.2" /><label for="toc2.7.2"><a href="#section2.7.2">Included Validations</a></label>
<ul>
<li><label class="leaf"><a href="#section2.7.2.1">Amalthea Standard Validations</a></label></li>
<li><label class="leaf"><a href="#section2.7.2.2">Timing Architects Validations</a></label></li>
<li><label class="leaf"><a href="#section2.7.2.3">Inchron Validations</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc2.8" /><label for="toc2.8"><a href="#section2.8">Model Migration</a></label>
<ul>
<li><input type="checkbox" id="toc2.8.1" /><label for="toc2.8.1"><a href="#section2.8.1">AMALTHEA Model Migration</a></label>
<ul>
<li><label class="leaf"><a href="#section2.8.1.1">Why model migration is required ?</a></label></li>
<li><label class="leaf"><a href="#section2.8.1.2">AMALTHEA model migration</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section2.8.2">Supported versions for model Migration</a></label></li>
<li><input type="checkbox" id="toc2.8.3" /><label for="toc2.8.3"><a href="#section2.8.3">Pre-requisites for AMALTHEA model migration</a></label>
<ul>
<li><label class="leaf"><a href="#section2.8.3.1">VM arguments</a></label></li>
<li><label class="leaf"><a href="#section2.8.3.2">Linked files in eclipse project (virtual files)</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.8.4" /><label for="toc2.8.4"><a href="#section2.8.4">How to invoke AMALTHEA model migration</a></label>
<ul>
<li><label class="leaf"><a href="#section2.8.4.1">Simple migration</a></label></li>
<li><label class="leaf"><a href="#section2.8.4.2">Migration dialog</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section2.8.5">Additional details</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.9" /><label for="toc2.9"><a href="#section2.9">Partitioning</a></label>
<ul>
<li><label class="leaf"><a href="#section2.9.1">Usage of Partitioning</a></label></li>
<li><input type="checkbox" id="toc2.9.2" /><label for="toc2.9.2"><a href="#section2.9.2">Pre-Partitioning</a></label>
<ul>
<li><label class="leaf"><a href="#section2.9.2.1">Label Access Analysis</a></label></li>
<li><label class="leaf"><a href="#section2.9.2.2">Cycle Elimination</a></label></li>
<li><label class="leaf"><a href="#section2.9.2.3">Activation Partitioning</a></label></li>
<li><label class="leaf"><a href="#section2.9.2.4">Independent Graph Partitioning</a></label></li>
<li><label class="leaf"><a href="#section2.9.2.5">Tag Partitioning</a></label></li>
<li><label class="leaf"><a href="#section2.9.2.6">ASIL-level Partitioning</a></label></li>
<li><label class="leaf"><a href="#section2.9.2.7">Consideration of Runnable Pairing Constraints</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.9.3" /><label for="toc2.9.3"><a href="#section2.9.3">Partitioning Algorithms</a></label>
<ul>
<li><label class="leaf"><a href="#section2.9.3.1">Critical Path Partitioning (CPP)</a></label></li>
<li><label class="leaf"><a href="#section2.9.3.2">Earliest Start Schedule Partitioning (ESSP)</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.9.4" /><label for="toc2.9.4"><a href="#section2.9.4">Further Features</a></label>
<ul>
<li><label class="leaf"><a href="#section2.9.4.1">Applet Generation</a></label></li>
<li><label class="leaf"><a href="#section2.9.4.2">Dependency Alternative</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.9.5" /><label for="toc2.9.5"><a href="#section2.9.5">Partitioning Examples</a></label>
<ul>
<li><label class="leaf"><a href="#section2.9.5.1">Algorithm Comparison</a></label></li>
<li><label class="leaf"><a href="#section2.9.5.2">Workflow Example</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section2.9.6">Plugin dependencies</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc2.10" /><label for="toc2.10"><a href="#section2.10">Model Loading (Amalthea "no-load" nature)</a></label>
<ul>
<li><label class="leaf"><a href="#section2.10.1">How to add Amalthea "no-load" nature to the project?*</a></label></li>
<li><label class="leaf"><a href="#section2.10.2">How to identify if Amalthea "no-load" nature is added to the project?*</a></label></li>
<li><label class="leaf"><a href="#section2.10.3">If Amalthea "no-load" nature is added, can I still load Amalthea model files using a java program explicitly?*</a></label></li>
<li><label class="leaf"><a href="#section2.10.4">How to remove Amalthea "no-load" nature from the project?*</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">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">Model Basics</a></label>
<ul>
<li><label class="leaf"><a href="#section3.2.1">Custom Properties</a></label></li>
<li><label class="leaf"><a href="#section3.2.2">Time (and Time Unit)</a></label></li>
<li><label class="leaf"><a href="#section3.2.3">Frequency (and Frequency Unit)</a></label></li>
<li><label class="leaf"><a href="#section3.2.4">Data Size (and Data Size Unit)</a></label></li>
<li><label class="leaf"><a href="#section3.2.5">Data Rate (and Data Rate Unit)</a></label></li>
<li><input type="checkbox" id="toc3.2.6" /><label for="toc3.2.6"><a href="#section3.2.6">Deviation</a></label>
<ul>
<li><label class="leaf"><a href="#section3.2.6.1">Boundaries</a></label></li>
<li><label class="leaf"><a href="#section3.2.6.2">Uniform Distribution</a></label></li>
<li><label class="leaf"><a href="#section3.2.6.3">Gaussian/Normal Distribution</a></label></li>
<li><label class="leaf"><a href="#section3.2.6.4">Beta Distribution</a></label></li>
<li><label class="leaf"><a href="#section3.2.6.5">Weibull Distribution</a></label></li>
<li><label class="leaf"><a href="#section3.2.6.6">Histogram</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.2.7">Statistic Elements</a></label></li>
<li><label class="leaf"><a href="#section3.2.8">Ticks</a></label></li>
<li><label class="leaf"><a href="#section3.2.9">Counters</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.3" /><label for="toc3.3"><a href="#section3.3">Common Elements</a></label>
<ul>
<li><label class="leaf"><a href="#section3.3.1">Tags</a></label></li>
<li><label class="leaf"><a href="#section3.3.2">Classifiers</a></label></li>
<li><label class="leaf"><a href="#section3.3.3">Namespaces</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.4" /><label for="toc3.4"><a href="#section3.4">Components Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.4.1">Component Interfaces</a></label></li>
<li><label class="leaf"><a href="#section3.4.2">Architecture of Systems / Composites</a></label></li>
<li><input type="checkbox" id="toc3.4.3" /><label for="toc3.4.3"><a href="#section3.4.3">Components Model Elements</a></label>
<ul>
<li><label class="leaf"><a href="#section3.4.3.1">Component</a></label></li>
<li><label class="leaf"><a href="#section3.4.3.2">System and Composite</a></label></li>
<li><label class="leaf"><a href="#section3.4.3.3">ComponentInstance and Connector</a></label></li>
<li><label class="leaf"><a href="#section3.4.3.4">QualifiedPort</a></label></li>
<li><label class="leaf"><a href="#section3.4.3.5">ComponentPort</a></label></li>
<li><label class="leaf"><a href="#section3.4.3.6">Structures</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.4.4" /><label for="toc3.4.4"><a href="#section3.4.4">Example</a></label>
<ul>
<li><label class="leaf"><a href="#section3.4.4.1">Diagram</a></label></li>
<li><label class="leaf"><a href="#section3.4.4.2">Model Editor</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc3.5" /><label for="toc3.5"><a href="#section3.5">Configuration Model</a></label>
<ul>
<li><input type="checkbox" id="toc3.5.1" /><label for="toc3.5.1"><a href="#section3.5.1">Event Configuration</a></label>
<ul>
<li><label class="leaf"><a href="#section3.5.1.1">Sample</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc3.6" /><label for="toc3.6"><a href="#section3.6">Constraints Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.6.1">Requirements</a></label></li>
<li><label class="leaf"><a href="#section3.6.2">Runnable Sequencing Constraints</a></label></li>
<li><label class="leaf"><a href="#section3.6.3">Data Age Constraints</a></label></li>
<li><label class="leaf"><a href="#section3.6.4">Data Coherency Groups</a></label></li>
<li><label class="leaf"><a href="#section3.6.5">Data Stability Groups</a></label></li>
<li><label class="leaf"><a href="#section3.6.6">Event Chains</a></label></li>
<li><input type="checkbox" id="toc3.6.7" /><label for="toc3.6.7"><a href="#section3.6.7">Timing Constraints</a></label>
<ul>
<li><label class="leaf"><a href="#section3.6.7.1">Synchronization Constraints</a></label></li>
<li><label class="leaf"><a href="#section3.6.7.2">Repetition Constraint</a></label></li>
<li><label class="leaf"><a href="#section3.6.7.3">Delay Constraint</a></label></li>
<li><label class="leaf"><a href="#section3.6.7.4">Event Chain Latency Constraint</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.6.8" /><label for="toc3.6.8"><a href="#section3.6.8">Affinity Constraints</a></label>
<ul>
<li><label class="leaf"><a href="#section3.6.8.1">Data Affinity Constraints</a></label></li>
<li><label class="leaf"><a href="#section3.6.8.2">Process Affinity Constraints</a></label></li>
<li><label class="leaf"><a href="#section3.6.8.3">Runnable Affinity Constraints</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.6.9">Physical Section Constraints</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.7">Event Model</a></label></li>
<li><input type="checkbox" id="toc3.8" /><label for="toc3.8"><a href="#section3.8">Hardware Model</a></label>
<ul>
<li><input type="checkbox" id="toc3.8.1" /><label for="toc3.8.1"><a href="#section3.8.1">Class Diagrams</a></label>
<ul>
<li><label class="leaf"><a href="#section3.8.1.1">Hardware model elements</a></label></li>
<li><label class="leaf"><a href="#section3.8.1.2">Hardware definitions and features</a></label></li>
<li><label class="leaf"><a href="#section3.8.1.3">Hardware modules and access elements</a></label></li>
<li><label class="leaf"><a href="#section3.8.1.4">Hardware paths and destinations</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.8.2" /><label for="toc3.8.2"><a href="#section3.8.2">Element description</a></label>
<ul>
<li><label class="leaf"><a href="#section3.8.2.1">HwModel</a></label></li>
<li><input type="checkbox" id="toc3.8.2.2" /><label for="toc3.8.2.2"><a href="#section3.8.2.2">HwDefinition</a></label>
<ul>
<li><label class="leaf"><a href="#section3.8.2.2.1">ProcessingUnitDefinition</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.2.2">MemoryDefinition</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.2.3">CacheDefinition</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.2.4">ConnectionHandlerDefinition</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.8.2.3">HwStructure</a></label></li>
<li><input type="checkbox" id="toc3.8.2.4" /><label for="toc3.8.2.4"><a href="#section3.8.2.4">HwDomain</a></label>
<ul>
<li><label class="leaf"><a href="#section3.8.2.4.1">FrequencyDomain</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.4.2">PowerDomain</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.8.2.5" /><label for="toc3.8.2.5"><a href="#section3.8.2.5">HwFeature</a></label>
<ul>
<li><label class="leaf"><a href="#section3.8.2.5.1">HwFeatureCategory</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.8.2.6" /><label for="toc3.8.2.6"><a href="#section3.8.2.6">HwModule</a></label>
<ul>
<li><label class="leaf"><a href="#section3.8.2.6.1">ProcessingUnit</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.6.2">Memory</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.6.3">Cache</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.6.4">ConnectionHandler</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.8.2.7">HwAccessElement</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.8">HwPort</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.9">HwConnection</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.10">HwAccessPath</a></label></li>
<li><label class="leaf"><a href="#section3.8.2.11">Enumerations</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc3.9" /><label for="toc3.9"><a href="#section3.9">Mapping Model</a></label>
<ul>
<li><input type="checkbox" id="toc3.9.1" /><label for="toc3.9.1"><a href="#section3.9.1">Overview</a></label>
<ul>
<li><label class="leaf"><a href="#section3.9.1.1">MappingModel</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.9.2" /><label for="toc3.9.2"><a href="#section3.9.2">Allocations</a></label>
<ul>
<li><label class="leaf"><a href="#section3.9.2.1">SchedulerAllocation</a></label></li>
<li><label class="leaf"><a href="#section3.9.2.2">RunnableAllocation</a></label></li>
<li><label class="leaf"><a href="#section3.9.2.3">TaskAllocation</a></label></li>
<li><label class="leaf"><a href="#section3.9.2.4">ISRAllocation</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.9.3" /><label for="toc3.9.3"><a href="#section3.9.3">Mappings</a></label>
<ul>
<li><label class="leaf"><a href="#section3.9.3.1">MemoryMapping</a></label></li>
<li><label class="leaf"><a href="#section3.9.3.2">PhysicalSectionMapping</a></label></li>
</ul>
</li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.10">Measurement Model</a></label></li>
<li><input type="checkbox" id="toc3.11" /><label for="toc3.11"><a href="#section3.11">OS Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.11.1">Operating System</a></label></li>
<li><input type="checkbox" id="toc3.11.2" /><label for="toc3.11.2"><a href="#section3.11.2">Scheduler</a></label>
<ul>
<li><input type="checkbox" id="toc3.11.2.1" /><label for="toc3.11.2.1"><a href="#section3.11.2.1">Scheduling Algorithm</a></label>
<ul>
<li><label class="leaf"><a href="#section3.11.2.1.1">Further information</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.11.2.2">Scheduling Parameters</a></label></li>
<li><label class="leaf"><a href="#section3.11.2.3">Scheduler Association</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.11.3" /><label for="toc3.11.3"><a href="#section3.11.3">Os Overhead</a></label>
<ul>
<li><label class="leaf"><a href="#section3.11.3.1">ISR Overhead</a></label></li>
<li><label class="leaf"><a href="#section3.11.3.2">API Overhead</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.11.4">OS Data Consistency</a></label></li>
<li><label class="leaf"><a href="#section3.11.5">Semaphore</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.12" /><label for="toc3.12"><a href="#section3.12">PropertyConstraints Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.12.1">Structure</a></label></li>
<li><input type="checkbox" id="toc3.12.2" /><label for="toc3.12.2"><a href="#section3.12.2">CoreAllocationConstraint</a></label>
<ul>
<li><label class="leaf"><a href="#section3.12.2.1">RunnableAllocationConstraint</a></label></li>
<li><label class="leaf"><a href="#section3.12.2.2">ProcessAllocationConstraint</a></label></li>
<li><label class="leaf"><a href="#section3.12.2.3">ProcessPrototypeAllocationConstraint</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.12.3" /><label for="toc3.12.3"><a href="#section3.12.3">MemoryMappingConstraint</a></label>
<ul>
<li><label class="leaf"><a href="#section3.12.3.1">AbstractElementMappingConstraint</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.12.4">Classifications</a></label></li>
<li><label class="leaf"><a href="#section3.12.5">Example</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.13" /><label for="toc3.13"><a href="#section3.13">Stimuli Model</a></label>
<ul>
<li><input type="checkbox" id="toc3.13.1" /><label for="toc3.13.1"><a href="#section3.13.1">Stimuli</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.1.1">Single</a></label></li>
<li><label class="leaf"><a href="#section3.13.1.2">Arrival Curves</a></label></li>
<li><label class="leaf"><a href="#section3.13.1.3">Common properties of fixed periodic stimuli</a></label></li>
<li><label class="leaf"><a href="#section3.13.1.4">Periodic </a></label></li>
<li><label class="leaf"><a href="#section3.13.1.5">PeriodicSynthetic</a></label></li>
<li><label class="leaf"><a href="#section3.13.1.6">PeriodicBurst</a></label></li>
<li><label class="leaf"><a href="#section3.13.1.7">RelativePeriodic </a></label></li>
<li><label class="leaf"><a href="#section3.13.1.8">VariableRateStimulus</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.13.2" /><label for="toc3.13.2"><a href="#section3.13.2">Clocks</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.2.1">ClockFunction</a></label></li>
<li><label class="leaf"><a href="#section3.13.2.2">ClockStepList</a></label></li>
<li><label class="leaf"><a href="#section3.13.2.3">Example</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.13.3">Mode Value List and Execution Condition</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.14" /><label for="toc3.14"><a href="#section3.14">Software Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.14.1">Memory Information</a></label></li>
<li><label class="leaf"><a href="#section3.14.2">Labels</a></label></li>
<li><label class="leaf"><a href="#section3.14.3">Channels</a></label></li>
<li><input type="checkbox" id="toc3.14.4" /><label for="toc3.14.4"><a href="#section3.14.4">Data Types</a></label>
<ul>
<li><label class="leaf"><a href="#section3.14.4.1">General Information</a></label></li>
<li><label class="leaf"><a href="#section3.14.4.2">Sample</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.14.5">Activations</a></label></li>
<li><label class="leaf"><a href="#section3.14.6">Tasks / ISR</a></label></li>
<li><label class="leaf"><a href="#section3.14.7">Runnables and Services</a></label></li>
<li><label class="leaf"><a href="#section3.14.8">Runnables</a></label></li>
<li><label class="leaf"><a href="#section3.14.9">Activity Graph</a></label></li>
<li><input type="checkbox" id="toc3.14.10" /><label for="toc3.14.10"><a href="#section3.14.10">Activity Graph Items</a></label>
<ul>
<li><label class="leaf"><a href="#section3.14.10.1">Groups</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.2">Mode Switch</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.3">Probability Switch</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.4">Ticks</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.5">Execution Need</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.6">Calls and AUTOSAR communication</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.7">Label Access</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.8">Channel Access</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.9">Semaphore Access</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.10">Mode Label Access</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.11">Custom Event Trigger</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.12">Enforced Migration</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.13">Inter Process Trigger</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.14">Schedule Point</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.15">Terminate Process</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.16">Wait/Clear/Set Event</a></label></li>
<li><label class="leaf"><a href="#section3.14.10.17">Statistical Values</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.14.11" /><label for="toc3.14.11"><a href="#section3.14.11">Modes</a></label>
<ul>
<li><label class="leaf"><a href="#section3.14.11.1">Modes and Mode Labels</a></label></li>
<li><label class="leaf"><a href="#section3.14.11.2">Mode Changes</a></label></li>
<li><label class="leaf"><a href="#section3.14.11.3">Mode Conditions</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.14.12">Process Prototypes</a></label></li>
<li><label class="leaf"><a href="#section3.14.13">Process Chains</a></label></li>
<li><label class="leaf"><a href="#section3.14.14">Custom Entities</a></label></li>
<li><label class="leaf"><a href="#section3.14.15">Section</a></label></li>
<li><input type="checkbox" id="toc3.14.16" /><label for="toc3.14.16"><a href="#section3.14.16">Data Dependencies and Runnable Parameters</a></label>
<ul>
<li><label class="leaf"><a href="#section3.14.16.1">Overview</a></label></li>
<li><label class="leaf"><a href="#section3.14.16.2">Elements with data dependency</a></label></li>
<li><label class="leaf"><a href="#section3.14.16.3">Data Dependency</a></label></li>
</ul>
</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 Visualization</a></label>
<ul>
<li><label class="leaf"><a href="#section4.2.1">Visualization framework</a></label></li>
<li><label class="leaf"><a href="#section4.2.2">Contributing a new model visualization</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.3" /><label for="toc4.3"><a href="#section4.3">Model Validation</a></label>
<ul>
<li><label class="leaf"><a href="#section4.3.1">Validation framework</a></label></li>
<li><label class="leaf"><a href="#section4.3.2">Validations</a></label></li>
<li><label class="leaf"><a href="#section4.3.3">Profiles</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.4" /><label for="toc4.4"><a href="#section4.4">Model Workflow</a></label>
<ul>
<li><label class="leaf"><a href="#section4.4.1">Introduction</a></label></li>
<li><label class="leaf"><a href="#section4.4.2">General Structure</a></label></li>
<li><input type="checkbox" id="toc4.4.3" /><label for="toc4.4.3"><a href="#section4.4.3">Available Basic Components</a></label>
<ul>
<li><label class="leaf"><a href="#section4.4.3.1">Model Reader</a></label></li>
<li><label class="leaf"><a href="#section4.4.3.2">Model Writer</a></label></li>
<li><label class="leaf"><a href="#section4.4.3.3">Add Schedule Points</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.4.4" /><label for="toc4.4.4"><a href="#section4.4.4">EASE modules</a></label>
<ul>
<li><label class="leaf"><a href="#section4.4.4.1">Workflow Module</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.4.5" /><label for="toc4.4.5"><a href="#section4.4.5">MWE2 Workflow</a></label>
<ul>
<li><input type="checkbox" id="toc4.4.5.1" /><label for="toc4.4.5.1"><a href="#section4.4.5.1">MWE2 Components</a></label>
<ul>
<li><label class="leaf"><a href="#section4.4.5.1.1">Reader</a></label></li>
<li><label class="leaf"><a href="#section4.4.5.1.2">Writer</a></label></li>
<li><label class="leaf"><a href="#section4.4.5.1.3">Add Schedule Points</a></label></li>
</ul>
</li>
</ul>
</li>
<li><label class="leaf"><a href="#section4.4.6">Current Limitations / Open Points</a></label></li>
<li><label class="leaf"><a href="#section4.4.7">Adding a new workflow component</a></label></li>
<li><input type="checkbox" id="toc4.4.8" /><label for="toc4.4.8"><a href="#section4.4.8">Create project</a></label>
<ul>
<li><label class="leaf"><a href="#section4.4.8.1">Execute the new component in the available sample</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc4.5" /><label for="toc4.5"><a href="#section4.5">Model Migration</a></label>
<ul>
<li><label class="leaf"><a href="#section4.5.1">Technologies used</a></label></li>
<li><label class="leaf"><a href="#section4.5.2">Framework for model migration</a></label></li>
<li><input type="checkbox" id="toc4.5.3" /><label for="toc4.5.3"><a href="#section4.5.3">Components of Model Migration Framework</a></label>
<ul>
<li><label class="leaf"><a href="#section4.5.3.1">Model migration sequence</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.5.4" /><label for="toc4.5.4"><a href="#section4.5.4">AMALTHEA meta model changes</a></label>
<ul>
<li><label class="leaf"><a href="#section4.5.4.1">Version APP4MC 0.9.8 to APP4MC 0.9.9</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.2">Version APP4MC 0.9.7 to APP4MC 0.9.8</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.3">Version APP4MC 0.9.6 to APP4MC 0.9.7</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.4">Version APP4MC 0.9.5 to APP4MC 0.9.6</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.5">Version APP4MC 0.9.4 to APP4MC 0.9.5</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.6">Version APP4MC 0.9.3 to APP4MC 0.9.4</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.7">Version APP4MC 0.9.2 to APP4MC 0.9.3</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.8">Version APP4MC 0.9.1 to APP4MC 0.9.2</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.9">Version APP4MC 0.9.0 to APP4MC 0.9.1</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.10">Version APP4MC 0.8.3 to APP4MC 0.9.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.11">Version APP4MC 0.8.2 to APP4MC 0.8.3</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.12">Version APP4MC 0.8.1 to APP4MC 0.8.2</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.13">Version APP4MC 0.8.0 to APP4MC 0.8.1</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.14">Version APP4MC 0.7.2 to APP4MC 0.8.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.15">Version APP4MC 0.7.1 to APP4MC 0.7.2</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.16">Version APP4MC 0.7.0 to App4MC 0.7.1</a></label></li>
</ul>
</li>
</ul>
</li>
<li><label class="leaf"><a href="#section4.6">Model Utilities</a></label></li>
<li><input type="checkbox" id="toc4.7" /><label for="toc4.7"><a href="#section4.7">Model Details</a></label>
<ul>
<li><label class="leaf"><a href="#section4.7.1">Qualified name</a></label></li>
<li><label class="leaf"><a href="#section4.7.2">Unique ID generation</a></label></li>
<li><label class="leaf"><a href="#section4.7.3">Interfaces and base objects</a></label></li>
<li><label class="leaf"><a href="#section4.7.4">Derived references</a></label></li>
<li><input type="checkbox" id="toc4.7.5" /><label for="toc4.7.5"><a href="#section4.7.5">Transient back pointers</a></label>
<ul>
<li><label class="leaf"><a href="#section4.7.5.1">Container references</a></label></li>
<li><label class="leaf"><a href="#section4.7.5.2">References (via inverse index)</a></label></li>
<li><label class="leaf"><a href="#section4.7.5.3">Implementation</a></label></li>
<li><label class="leaf"><a href="#section4.7.5.4">User Interface</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc4.8" /><label for="toc4.8"><a href="#section4.8">AMALTHEA Model Definition</a></label>
<ul>
<li><label class="leaf"><a href="#section4.8.1">Ecore</a></label></li>
<li><label class="leaf"><a href="#section4.8.2">XML Schema Definition (XSD)</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9" /><label for="toc4.9"><a href="#section4.9">AMALTHEA Trace Database (preview of new version)</a></label>
<ul>
<li><input type="checkbox" id="toc4.9.1" /><label for="toc4.9.1"><a href="#section4.9.1">Database Structure</a></label>
<ul>
<li><input type="checkbox" id="toc4.9.1.1" /><label for="toc4.9.1.1"><a href="#section4.9.1.1">Core Tables</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.1.1.1">MetaInformation</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.1.2">Entity</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.1.3">EntityType</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.1.4">EntityInstance</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.1.5">EventType</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9.1.2" /><label for="toc4.9.1.2"><a href="#section4.9.1.2">Auxillary Data Tables</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.1.2.1">Property</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.2.2">PropertyValue</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.2.3">Event</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9.1.3" /><label for="toc4.9.1.3"><a href="#section4.9.1.3">Metric Tables</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.1.3.1">Metric</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.3.2">EntityMetricValue</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.3.3">EntityInstaneMetricValue</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.3.4">EntityMetricInstanceValue</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9.1.4" /><label for="toc4.9.1.4"><a href="#section4.9.1.4">Optional Tables</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.1.4.1">TraceEvent</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.4.2">RunnableInstanceTraceInfo</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.4.3">ProcessInstanceTraceInfo</a></label></li>
<li><label class="leaf"><a href="#section4.9.1.4.4">EventChainInstanceInfo</a></label></li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9.2" /><label for="toc4.9.2"><a href="#section4.9.2">Database Views</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.2.1">Core Views</a></label></li>
<li><input type="checkbox" id="toc4.9.2.2" /><label for="toc4.9.2.2"><a href="#section4.9.2.2">Auxillary Data Views</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.2.2.1">vProperty</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.2.2">vEvent</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.2.3">vEventChainEntity</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9.2.3" /><label for="toc4.9.2.3"><a href="#section4.9.2.3">Metric Views</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.2.3.1">vEntityMetricValue</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.3.2">vEntityInstanceMetricValue</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.3.3">vEntityMetricInstanceValue</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc4.9.2.4" /><label for="toc4.9.2.4"><a href="#section4.9.2.4">Optional Views</a></label>
<ul>
<li><label class="leaf"><a href="#section4.9.2.4.1">vTraceEvent</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.4.2">vRunnableInstanceRuntimeTraceEvent</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.4.3">vProcessInstanceRuntimeTraceEvent</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.4.4">vRunnableInstanceTraceInfo/vProcessInstanceTraceInfo</a></label></li>
<li><label class="leaf"><a href="#section4.9.2.4.5">vEventChainInstanceInfo</a></label></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><input type="checkbox" id="toc4.10" /><label for="toc4.10"><a href="#section4.10">AMALTHEA Trace Database (current version)</a></label>
<ul>
<li><label class="leaf"><a href="#section4.10.1">General information</a></label></li>
<li><input type="checkbox" id="toc4.10.2" /><label for="toc4.10.2"><a href="#section4.10.2">Database structure</a></label>
<ul>
<li><label class="leaf"><a href="#section4.10.2.1">MetaInformation</a></label></li>
<li><label class="leaf"><a href="#section4.10.2.2">Entity</a></label></li>
<li><label class="leaf"><a href="#section4.10.2.3">EntityType</a></label></li>
<li><label class="leaf"><a href="#section4.10.2.4">EventType</a></label></li>
<li><label class="leaf"><a href="#section4.10.2.5">EntitySource</a></label></li>
<li><label class="leaf"><a href="#section4.10.2.6">EntityInstance</a></label></li>
<li><label class="leaf"><a href="#section4.10.2.7">EventTables</a></label></li>
</ul>
</li>
</ul>
</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.9.9 (Jul 2020)</a></label></li>
<li><label class="leaf"><a href="#section5.2">Eclipse APP4MC 0.9.8 (Apr 2020)</a></label></li>
<li><label class="leaf"><a href="#section5.3">Eclipse APP4MC 0.9.7 (Jan 2020)</a></label></li>
<li><label class="leaf"><a href="#section5.4">Eclipse APP4MC 0.9.6 (Oct 2019)</a></label></li>
<li><label class="leaf"><a href="#section5.5">Eclipse APP4MC 0.9.5 (Jul 2019)</a></label></li>
<li><label class="leaf"><a href="#section5.6">Eclipse APP4MC 0.9.4 (Apr 2019)</a></label></li>
<li><label class="leaf"><a href="#section5.7">Eclipse APP4MC 0.9.3 (Jan 2019)</a></label></li>
<li><label class="leaf"><a href="#section5.8">Eclipse APP4MC 0.9.2 (Oct 2018)</a></label></li>
<li><label class="leaf"><a href="#section5.9">Eclipse APP4MC 0.9.1 (Jul 2018)</a></label></li>
<li><label class="leaf"><a href="#section5.10">Eclipse APP4MC 0.9.0 (Apr 2018)</a></label></li>
<li><label class="leaf"><a href="#section5.11">Eclipse APP4MC 0.8.3 (Jan 2018)</a></label></li>
<li><label class="leaf"><a href="#section5.12">Eclipse APP4MC 0.8.2 (Oct 2017)</a></label></li>
<li><label class="leaf"><a href="#section5.13">Eclipse APP4MC 0.8.1 (Jul 2017)</a></label></li>
<li><label class="leaf"><a href="#section5.14">Eclipse APP4MC 0.8.0 (Apr 2017)</a></label></li>
<li><label class="leaf"><a href="#section5.15">Eclipse APP4MC 0.7.2 (Jan 2017)</a></label></li>
<li><label class="leaf"><a href="#section5.16">Eclipse APP4MC 0.7.1 (Oct 2016)</a></label></li>
<li><label class="leaf"><a href="#section5.17">Eclipse APP4MC 0.7.0 (Jul 2016)</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 -&gt; Open Perspective -&gt; Other -&gt; 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> -&gt;
<i>New</i> -&gt;
<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. For example this can be used to find all elements in the model with "ABS" at the beginning of 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 show them as a plain list instead of a tree grouped by type.</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..." or use the right mouse button.</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>Timing in Amalthea Primer</h3>
<p>An Amalthea model per se is a static, structural model of a hardware/software system. The basic structural model consists of software model elements (tasks, runnables), hardware model elements (processing units, memories, connection handlers), stimuli that are used to activate execution, and mappings of software model elements to hardware model elements. Semantics of the model then allows for definite and clear interpretation of the static, structural model regarding its behavior over time.</p>
<h4><a id="section2.2.1.1"></a>Different Levels of Model Detail</h4>
<p>Amalthea provides a meta-model suitable for many different purposes in the design of hardware/software systems. Consequently, there is not
<em>the</em> level of Amalthea model detail – modeling often is purpose driven. Regarding timing analysis, we exemplary discuss three different levels of detail to clarify this aspect of Amalthea. Note that we focus on level of detail of the hardware model and assume other parts of the model (software, mapping, etc.) fixed.
</p>
<p>Essential software model elements are runnables, tasks, and data elements (labels and channels). Runnable items of a runnable specifies its runtime behavior. You may specify the runnable items as a directed, acyclic graph (DAG). Amalthea has different categories of runnable items, we focus on the following four:</p>
<ul>
<li>Items that
<strong>branch paths</strong> of the DAG (runnable mode switch, runnable probability switch).
</li>
<li>Items that
<strong>signal</strong> or call other parts of the model (custom event trigger, runnable call, etc.).
</li>
<li>Items that specify
<strong>data access</strong> of data elements (channel receive/send, label access).
</li>
<li>Items that specify
<strong>execution time</strong> (ticks, execution needs).
</li>
</ul>
<p>Tasks may call runnables in a activity graph. Note that a runnable can be called by several tasks. We then map tasks to task schedulers in the operating system model, and we map every task scheduler to one or more processing units of the hardware model. Further, we map data elements to memories of the hardware model.</p>
<p>This coarse level of hardware model detail – the hardware model consists only of
<strong>mapping targets</strong>, without routing or timing for data accesses – may already be sufficient for analysis focusing on event-chains or scheduling.
</p>
<p>As the second example of model detail, we now add access elements to all processing units of the hardware model,
<strong>modeling data access latencies or data rates</strong> when accessing data in memories – still ignoring routing and contention. This level of detail is sufficient, for example, for optimizing data placement in microcontrollers using static timing analysis.
</p>
<p>A more detailed hardware model, our third and last example of model detail, will contain information about
<strong>data routing and congestion handling</strong>. Therefore, we add connection handlers to the hardware model for every possible contention point, we add ports to the hardware elements, and we add connections between ports. For every access element of the processing units, we add an access path, modeling the access route over different connections and connectionHandlers. The combination of all access elements are able to represent the full address space of a processing unit. This level of detail is well suited for dynamic timing simulation considering arbitration effects for data accesses.
</p>
<p>In the following, we discuss 'timing' of Amalthea in context of level of detail of the last example and discrete-event simulation.</p>
<h4><a id="section2.2.1.2"></a>Discrete-Event Simulation</h4>
<p>For dynamic timing analysis, the
<em>initial</em> state of the static system model is the starting point, and a series of
<em>state changes</em> is subject to model analysis. The
<em>state</em> of a model mainly consist of states of HW elements (processing units and connection handlers). During analysis, a state change is then, for example, a processing unit changing from
<em>idle</em> to
<em>execute</em>.
</p>
<p>When we are interested in the
<em>timing</em> of a model, a common way is using discrete-event simulation. In discrete-event simulation, a series of
<em>events</em> changes the state of the system and a simulated clock. Such a simulation event is, for instance, a
<em>stimuli</em> event for a task to execute on a processing unit, what in turn may change the
<em>state</em> of this processing unit from
<em>idle</em> to
<em>execute</em>.
</p>
<p>Note that every event occurs at a specified point in simulated time; for instance, think of a new
<em>stimuli event</em> that shall activate a task in 10ms from the current value of the simulated clock. Unprocessed (future) events are stored in an event list. The simulator then continuously processes the event occurring next to the current simulated time, and forwards the simulated clock correspondingly, thereby removing the event from the event list. Note that this is a very simplified description. For instance, multiple events at the same point in simulated time are possible. Processing events may lead to generation of new events. For instance, processing an end
<em>task execution event</em> may lead to a new
<em>stimuli event</em> that shall occur 5ms from the current value of the simulation clock added to the event list.
</p>
<p>After sketching the basic idea of discrete-event simulation, we can be more precise with the term
<strong>Amalthea timing</strong>: we call the trace of state changes and events over time the
<em>dynamic behavior</em> or simply the
<em>timing</em> of the Amalthea model. This timing of the model than may be further analyzed, for instance, regarding timing constraints.
</p>
<p>Stimulation of task execution with corresponding stimuli events, and scheduling in general, is not further discussed here. In the following, we focus on timing of execution at processing units and data accesses.</p>
<h4><a id="section2.2.1.3"></a>Execution Time</h4>
<p>The basic mechanism to specify execution time at a processing unit is the modeling element
<em>ticks</em>.
<em>Ticks</em> are a generic abstraction of time for software, independent of hardware. Regarding hardware, one may think of
<em>ticks</em> as clock ticks or cycles of a processing unit. You can specify
<em>ticks</em> at several places in the model, most prominently as a runnable item of a runnable. The
<em>ticks</em> value together with a mapping to a specific processing unit that has a defined frequency then allows computation of an
<em>execution time</em>. For instance, 100 ticks require 62.5ns simulated time at a processing unit with 1.6GHz, while 100 ticks require 41.6ns at a processing unit with 2.4GHz.
</p>
<p>When the discrete-event simulator simulates execution of a runnable at a processing unit, it actually processes runnable items and translates their semantics into simulation events. We already discussed the runnable item
<em>ticks</em>: when
<em>ticks</em> are processed, we compute a corresponding simulation time value based on the executing processing unit's frequency, and store a simulation event in the list of simulation events for when the execution will finish.
</p>
<p>In that sense, ticks translate into a fixed or
<strong>static timing behavior</strong> - when execution starts, it is always clear when this execution will end. Note that the current version of Amalthea (0.9.3) also prepares an additional concept for specification of execution timing besides using
<em>ticks</em>:
<em>execution needs</em>. Execution needs will allow sophisticated ways of execution time specification, as required for heterogeneous systems.
<em>Execution needs</em> define the number of usages of user-defined needs; a later version of Amalthea (&gt; 0.9.3) then will introduce
<em>recipes</em> that translate such execution needs into ticks, taking
<em>hardware features</em> of the executing processing unit into account. Note that, by definition, a sound model for timing simulation always allows to compute ticks from execution needs. Consequently, for timing analysis using discrete-event simulation as described above, we first translate execution needs into ticks, resulting in a model we call
<em>ticks-only model</em>. Thus, we can ignore
<em>execution needs</em> for timing analysis.
</p>
<h4><a id="section2.2.1.4"></a>Data Accesses</h4>
<p>For data accesses, in contrast to ticks, the duration in simulation time is not always clear. A single data access may result in series of simulation events. Occurrence of these events in simulation time depends on several other model elements, for example, access paths, mapping of data to memory, and state of connection handlers. Thus, a data access may result in
<strong>dynamic timing behavior</strong>. Note that there are plenty of options in Amalthea for hardware modeling; consequently, options for modeling and simulation of data accesses are manifold (see above
<em>Different Levels of Model Detail</em>). In the following, we discuss some modeling patterns for data accesses.
</p>
<p>Consider a hardware model consisting of two processing units, a connection handler, and a single memory. We add a read and a write latency to all connections and the connection handler. Additionally, we add an access latency to the memory. There are no read or write latency added to access elements of the processing units. Only access paths specify the routes from the specific processing unit to the memory across the connection handler, see the following screenshot.</p>
<p>
<img class="scale" src="images/user_timing_model_example.png"/>
</p>
<p>As described in the beginning of this section, a single data access may result in a series of events. Expected simulation behavior is as follows: When the discrete-event simulator encounters a runnable item for a data read access at CPU0, we add an event for one tick later to the event queue of the simulator, denoting passing the connection from CPU0 to the connection handler MyConnectionHandler. (For simplicity, we do not use time durations calculated from the CPU0's frequency here, what would be required to determine the correct point in simulated time for the event). After passing the connection, the state of MyConnectionHandler is relevant for the next event: Either MyConnectionHandler is occupied by a data access (from CPU1), a data access arrives at the same time, or MyConnectionHandler is available.</p>
<ul>
<li>If MyConnectionHandler is available, we add an event for three ticks later-this is the read latency of the connection handler.</li>
</ul>
<ul>
<li>If a data access from CPU1 arrives at the same time, the connection handler handles this data access based on the selected arbitration mechanism (attribute not shown in the screen shot – we assume priority based with a higher priority for CPU1). We add an event for three ticks later, when MyConnectionHandler is available again. We then check again for data accesses from CPU1 at the same time and set a corresponding event.</li>
</ul>
<ul>
<li>If MyConnectionHandler is occupied, we add an event for whenever the connection handler is not occupied anymore. We then check for data accesses from CPU1 at the same time and set a corresponding event.</li>
</ul>
<p>Eventually, MyConnectionHandler may handle the read access from CPU0, and when the simulator reacts on the corresponding event, we add an event for one tick later, as this is the read latency for the connection between the connection handler and the memory. The final event for this read data access from CPU0 results from the access latency of the memory (twelve ticks). When the simulator reacts on that final event, the read access from CPU0 is completed and the simulator can handle the next runnable item at CPU0, if available.</p>
<p>Note that in the above example there is only one contention point. We thus could reduce the number of events for an optimized simulation. Further, note that we ignore size of data elements in this example. We could use
<strong>data rates</strong> instead of latencies at connections, the connection handler, and the memory to respect data sizes in timing simulation or work with the bit width of ports. Furthermore beside constant latency values it is also possible to use distributions, in this case the simulator role the dice regarding the distribution. At a last note, adding to the discussion of different detail levels: Depending on use-case, modeling purpose, and timing analysis tool, there may be best practice defined for modeling. For instance, one tool may rely on data rates, while other tools require latencies but only at memories and connection handlers, not connections. Tool specific model transformations and validation rules should handle and define such restrictions.
</p>
<h3 id="user-hw"><a id="section2.2.2">2.2.2 </a>Hardware</h3>
<h4><a id="section2.2.2.1"></a>Structural Modeling of Heterogeneous Platforms</h4>
<p>To master the rising demands of performance and power efficiency, hardware becomes more and more diverse with a wide spectrum of different cores and hardware accelerators. On the computation front, there is an emergence of specialized processing units that are designed to boost a specific kind of algorithm, like a cryptographic algorithm, or a specific math operation like "multiply and accumulate". As one result, the benefit of a given function from hardware units specialized in different kinds may lead to nonlinear effects between processing units in terms of execution performance of the algorithm: while one function may be processed twice as fast when changing the processing unit, another function may have no benefit at all from the same change. Furthermore the memory hierarchy in modern embedded microprocessor architectures becomes more complex due to multiple levels of caches, cache coherency support, and the extended use of DRAM. In addition to crossbars, modern SoCs connect different clusters of potentially different hardware components via a Network on Chip. Additionally, power and frequency scaling is supported by state of the art SoCs. All these characteristics of modern and performant SoCs (specialized processing units, complex memory hierarchy, network like interconnects and power and frequency scaling) were only partially supported by the former Amalthea hardware model. Therefore, to create models of modern heterogeneous systems, new concepts of representing hardware components in a flexible and easy way are necessary: Our approach supports modeling of manifold hierarchical structures and also domains for power and frequencies. Furthermore, explicit cache modules are available and the possibilities for modeling the whole memory subsystem are extended, the connection between hardware components can be modeled over different abstraction layers. Only with such an extended modeling approach, a more accurate estimation of the system performance of state of the art SoCs becomes feasible.</p>
<p>Our intention is allowing to create a hardware model once at the beginning of a development process. Ideally, the hardware model will be provided by the vendor. All performance relevant attributes regarding the different features of hardware components like a floating point unit or how hardware components are interconnected should be explicitly represented in the model. The main challenge for a hardware/software performance model is then to determine certain costs, e.g. the net execution time of a software functionality mapped to a processing unit. Costs such as execution time, in contrast to the hardware structure, may change during development time – either because the implementation details evolve from initial guess to real-world measurements, the implementation is changed, or the tooling is changed. Therefore, the inherent attributes of the hardware, e.g. latency of an access path, should be decoupled from the mapping or implementation dependent costs of executing functions. We know from experience that it is necessary to refine these costs constantly in the development process to increase accuracy of performance estimation. Refinement denotes incorporation of increasing knowledge about the system. Therefore, such a refinement should be possible in an efficient way and also support re-use of the hardware model. The corresponding concepts are detailed in the following section.</p>
<h4><a id="section2.2.2.2"></a>Recipe and Feature concept: An outlook of an upcoming approach</h4>
<p>
<em>Disclaimer: Please note that the following describes work in progress – what we call "recipes" later is not yet part of the meta-model, and the concept of "features" is not final.</em>
</p>
<p>The main driver of the concept described here is separation of implementation dependent details from structural or somehow "solid" information about a hardware/software system. This follows the separation of concerns paradigm, mainly to reduce refinement effort, and foster model re-use: As knowledge about a system grows during development, e.g. by implementing or optimizing functionality as software, the system model should be updated and refined efficiently, while inherent details shall be kept constant and not modified depending on the implementation.</p>
<p>An example should clarify this approach: For timing simulation, we require the net execution time of a software function executed on the processing unit it is mapped onto. This cost of the execution depends on the implementation of the algorithm, for instance, as C++ code, and the tool chain producing the binary code that eventually is executed. In that sense, the
<strong>execution needs</strong> of the algorithm (for instance, a certain number of "multiply and accumulate" operations for a matrix operation) are naturally fixed, as well as the
<strong>features</strong> provided by the processing unit (for instance, a dedicated MAC unit requiring one tick for one operation, and a generic integer unit requiring 0.5 ticks per operation). However is implementation- and tool-chain-dependent how the actual execution needs of the algorithm are served by the execution units. Without changing the algorithm or the hardware, optimization of the implementation may make better use of the hardware, resulting in reduced execution time. The above naturally draws the lines for our modeling approach: Execution needs (on an algorithmic level) are inherent, as well as features of the hardware. Keeping these information constant in the model is the key for re-use; implementation dependent change of costs, such as lower execution time by an optimized implementation in C++ or better compiler options, change during development and are modeled as
<strong>recipe</strong>. A "recipe" thus takes execution needs of software and features of the hardware as input and results in costs, such as the net execution time. Consequently, recipes are the main area of model refinement during development. The concept is illustrated below.
</p>
<p>
<img class="scale" src="images/user_recipe_concept.png"/>
</p>
<p>Note that flexibility is part of the design of this approach. Execution needs and features are not limited to a given set, and recipes can be almost arbitrary prescripts of computation. This allows to introduce new execution needs when required to favorable detail an algorithm. For instance, the execution need "convolution-VGG16" can be introduced to model a specific need for a deep learning algorithm. The feature "MAC" of the executing processing unit provides costs in ticks corresponding to perform a MAC operation. The recipe valid for the mapping then uses these two attributes to compute the net execution time of "convolution-VGG16" in ticks, for instance, by multiplying the costs of xyz MAC operations with a penalty factor of 0.8. Note that with this approach execution needs may be translated very differently into costs, using different features.</p>
<p>To further motivate this approach, we give some more benefits and examples of beneficial use of the model:</p>
<ul>
<li>Given execution needs of a software function that directly correspond the features of processing units, the optimal execution time may be computed (peak performance).</li>
<li>While net execution time is the prime example of execution needs, features, and recipes, the concept is not limited to "net execution time recipes", recipes for other performance numbers such as power consumption are possible.</li>
<li>Recipes can be attached at different "levels" in the model: At a processing unit and at a mapping. If present, the recipe at mapping level has precedence.</li>
</ul>
<h4 id="user-hw-overview"><a id="section2.2.2.3"></a>General Hardware Model Overview</h4>
<p>The design of the new hardware model is focusing on flexibility and variety to cover different kind of designs to cope with future extensions, and also to support different levels of abstraction. To reduce the complexity of the meta model for representing modern hardware architectures, as less elements as possible are introduced. For example, dependent of the abstraction level, a component called
<em>ConnectionHandler</em> can express different kind of connection elements, e.g. a crossbar within a SoC or a CAN bus within an E/E-architecture. A simplified overview of the meta model to specify hardware as a model is shown below. The components
<em>ConnectionHandler, ProcessingUnit, Memory</em> and
<em>Cache</em> are referred in the following as basic components.
</p>
<p>
<img class="scale" src="images/user_hw_model_class_diagram.png"/>
<br>Class diagram of the hardware model
</p>
<p>The root element of a hardware model is always the
<em>HwModel</em> class that contains all domains (power and frequency), definitions, and hardware features of the different component definitions. The hierarchy within the model is represented by the
<em>HwStructure</em> class, with the ability to contain further
<em>HwStructure</em> elements. Therewith arbitrary levels of hierarchy could be expressed. Red and blue classes in the figure are the definitions and the main components of a system like a memory or a core.
</p>
<p>The next figure shows the modeling of a processor. The
<em>ProcessingUnitDefiniton</em>, which is created once, specifies a processing unit with general information (which can be a CPU, GPU, DSP or any kind of hardware accelerator). Using a definition that may be re-used supports quick modeling for multiple homogeneous components within a heterogeneous architecture.
<em>ProcessingUnits</em> then represent the physical instances in the hardware model, referencing the
<em>ProcessingUnitDefiniton</em> for generic information, supplemented only with instance specific information like the
<em>FrequencyDomain</em>.
</p>
<p>
<img class="scale" src="images/user_hw_definition_example.png"/>
<br>Link between definitions and module instances (physical components)
</p>
<p>Yellow represents the power and frequency domains that are always created at the top level of the hardware model. It is possible to model different frequency or voltage values, e.g., when it is possible to set a systems into a power safe mode. All components that reference the domain are then supplied with the corresponding value of the domain.</p>
<p>All the green elements in the figure are related to communication (together with the blue base component
<em>ConnectionHandler</em>). Green modeling elements represent ports, static connections, and the access elements for the
<em>ProcessingUnits</em>. These
<em>ProcessingUnits</em> are the master modules in the hardware model. The following example shows two
<em>ProcessingUnits</em> that are connected via a
<em>ConnectionHandler</em> to a
<em>Memory</em>. There are two different possibilities to specify the access paths for
<em>ProcessingUnits</em> like it is shown for ProcessingUnit_2 in the next figure. Every time a
<em>HwAccessElement</em> is necessary to assign the destination e.g. a
<em>Memory</em> component. This
<em>HwAccessElement</em> can contain a latency or a data rate dependent on the use case. The second possibility is to create a
<em>HwAccessPath</em> within the
<em>HwAccessElement</em> which describes the detailed path to the destination by referencing all the
<em>HwConnections</em> and
<em>ConnectionHandlers</em>. It is even possible to reference a cache component within the
<em>HwAccessPath</em> to express if the access is cached or non-cached. Furthermore it is possible to set addresses for these
<em>HwAccessPath</em> to represent the whole address space of a
<em>ProcessingUnit</em>. A typical approach would be starting with just latency or data rates for the communication between components and enhance the model over time to by switching to the
<em>HwAccessPaths</em>.
</p>
<p>
<img class="scale" src="images/user_hw_access_paths.png"/>
<br>Access elements in the hardware model
</p>
<h4><a id="section2.2.2.4"></a>Current implementation with features and the connection to the SW Model</h4>
<p>In the previous chapter the long time goal of the feature and recipe concept is explained. As an intermediate step before introducing the recipes we decided to connect the HwModel and SwModel by referencing to the name of the hardware
<em>FeatureCategories</em> from the
<em>ExecutionNeed</em> element in a Runnable. The following figure shows this connection between the grey Runnable item block and the white Features block. Due to the mapping (Task or Runnable to ProcessingUnit) the corresponding feature value can be extracted out of the ProcessingUnitDefinition.
</p>
<p>
<img class="scale" src="images/user_hw_feature_runnable_connection.png"/>
</p>
<p>An example based on the old hardware model is the "instruction per cycle" value (IPC). To model an IPC with the new approach a
<em>HwFeatureCategory</em> is created with the name
<em>Instructions</em>. Inside this category multiple IPC values can be created for different
<em>ProcessingUnitDefinitions</em>.
</p>
<p>
<em>Note: In version 0.9.0 to 0.9.2 exists a default ExecutionNeed Instructions together with a the HwFeatre IPC the cycles can be calculated by dividing the Instructions by the IPC value.</em>
</p>
<p>
<img class="scale" src="images/user_hw_feature_runnable_example.png"/>
<br>Execution needs example
</p>
<h4><a id="section2.2.2.5"></a>Interpretation of latencies in the model</h4>
<p>In the model read and write access latencies are used. An alternative which is usually used in specifications or by measurements are request and response latencies. The following figure shows a typical communication between two components. The interpretation of a read and write latency for example at
<em>ConnectionHandlers</em> is the following:
</p>
<p>
<img class="scale" src="images/user_hw_latencies.png"/>
</p>
<ul>
<li>
<strong>readLatency</strong> = requestLatency + response Latency
</li>
</ul>
<ul>
<li>
<strong>writeLatency</strong> = requestLatency
</li>
</ul>
<p>The access latency of a
<em>Memory</em> component is always added to the read or write latency from the communication elements, independent if its one latency from an
<em>HwAccessElement</em> or multiple latencies from a
<em>HwAccessPath</em>.
</p>
<p>As example in case of using only read and write latencies:</p>
<ul>
<li>
<strong>totalReadLatency</strong> = readLatency (HwAccessElement) + accessLatency (Memory)
</li>
</ul>
<ul>
<li>
<strong>totalWriteLatency</strong> = writeLatency (HwAccessElement) + accessLatency (Memory)
</li>
</ul>
<p>An example in case of using an access element with a hardware access path:</p>
<p>
<em>n = Number of path elements</em>
</p>
<ul>
<li>
<strong>totalReadLatency</strong> = Sum 1..n ( readLatency(p) ) + accessLatency (Memory)
</li>
</ul>
<ul>
<li>
<strong>totalWriteLatency</strong> = Sum 1..n ( writeLatency(p) ) + accessLatency (Memory)
</li>
</ul>
<p>PathElements could be
<em>Caches</em>,
<em>ConnectionHandlers</em> and
<em>HwConnections</em>. In very special cases also a
<em>ProcessingUnit</em> can be a
<em>PathElement</em> the
<em>ProcessingUnit</em> has no direct effect on the latency. In case the user want to express a latency it has to be annotated as
<em>HwFeature</em>.
</p>
<h3><a id="section2.2.3">2.2.3 </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.3.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 activity graphs</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">Software (runtime)</a>.
</p>
<h4><a id="section2.2.3.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.3.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.3.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 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>
<li>Event: activation triggered by a
<i>TriggerEvent</i>
</li>
<li>Custom: custom activation (free textual description)</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.4">2.2.4 </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.4.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.4.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>Ticks: number of ticks (cycles) to be executed</li>
<li>...</li>
</ul>
<p>
<img src="images/user_sw_new_runnable_item.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.4.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.4.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.4.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 stimulation patterns are typically used for specification:</p>
<ul>
<li>Single: single activation of a process</li>
<li>Periodic: periodic activation of a process with a specific frequency</li>
<li>VariableRate: periodic activations based on other events, like rotation speed</li>
<li>Event: activation triggered by a
<i>TriggerEvent</i>
</li>
<li>InterProcess: activations based on an explicit inter-process trigger</li>
</ul>
<p>
<img src="images/model__stimuli.png"/>
</p>
<h3><a id="section2.2.5">2.2.5 </a>General Concepts</h3>
<h4><a id="section2.2.5.1"></a>Grouping of elements (Tags, Tag groups)</h4>
<p>It is possible to use
<a href="#common-tags">Tags</a> for grouping elements of the model.
</p>
<h4><a id="section2.2.5.2"></a>Custom Properties</h4>
<p>The AMALTHEA model provides
<a href="#basics-custom-props">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>
<h4><a id="section2.2.5.3"></a>Support of Packages </h4>
<p>In Amalthea model
<em>(from APP4MC 0.9.7 version)</em> there is a feature to support grouping of following model elements listed below in a package:
</p>
<ul>
<li>Component</li>
<li>Composite</li>
<li>MainInterface</li>
</ul>
<blockquote>
<p>Above mentioned classes are implementing interface
<strong>IComponentStructureMember</strong>
</p>
</blockquote>
<p>
<strong>ComponentStructure</strong> element in Amalthea model represents a package, and this can be referred by above mentioned elements.
</p>
<h5><a id="section2.2.5.3.1"></a>Example of using Package</h5>
<p>Amalthea model contains a parent ComponentStructure "BC" and two child ComponentStructure's "FC1", "FC2".</p>
<ul>
<li>Component element "Comp3" is associated to ComponentStructure "FC1" and the Component element "Comp4" is associated to ComponentStructure "FC2"</li>
</ul>
<p>This representation demonstrates the grouping of the elements into different packages.</p>
<p>
<img class="gray_scale" src="images/user_guide_package_support.png"/>
</p>
<h4><a id="section2.2.5.4"></a>Support of Namespaces </h4>
<p>In Amalthea model
<em>(from APP4MC 0.9.7 version)</em> there is a feature to have Namespace for the following model elements (
<i>which are implementing interface
<strong>INamespaceMember</strong>
</i>):
</p>
<ul>
<li>BaseTypeDefinition</li>
<li>Channel</li>
<li>Component</li>
<li>Composite</li>
<li>DataTypeDefinition</li>
<li>Label</li>
<li>MainInterface</li>
<li>Runnable</li>
<li>TypeDefinition</li>
</ul>
<p>Advantage of having Namespace is, there can be multiple elements defined with the same name but with different Namespace
<i>(this feature will also be helpful to support c++ source code generation )</i>. If Namspace is specified in Amalthea model for a specific model element, then its unique name is built by considering the "Namespace text + name of the element"
</p>
<h5><a id="section2.2.5.4.1"></a>Example of using Namespace</h5>
<p>As shown in the below screenshot, there are two Component elements with the name "Comp1" but referring to different Namespace objects, which is making them unique. In this case, display in the UI editor is also updated by showing the Namespace in the prefix for the Amalthea element name.</p>
<p>
<img class="gray_scale" src="images/user_guide_namespace_support.png"/>
</p>
<p>Below is the text representation of the Amalthea model which shows the ComponentInstance elements referring to different Component elements. As mentioned above, highlighted text shows that unique name of the Component element
<i class="built by including the associated Namespace to the Component element">__ is used all the places where it is referenced __(to make it unique)</i>
</p>
<p>
<img class="gray_scale" src="images/user_guide_namespace_support_xmlcontent.png"/>
</p>
<p>
<strong>Additional Information</strong>:
</p>
<ul>
<li>As soon as Namespace elements are used in Amalthea model, AMXMI file is updated with additional attribute xmi:id for all elements implementing IReferable interface.</li>
<li>On Amalthea model element implementing INamed interface, in addition to getName() API, getQualifiedName() API is available which returns &lt;namespace string value&gt;.getName()</li>
</ul>
<h3><a id="section2.2.6">2.2.6 </a>Scheduling</h3>
<h4><a id="section2.2.6.1"></a>Scheduler to Core assignment</h4>
<p>We distinguish between physical mapping and responsibility </p>
<ul>
<li>
<strong>Executing Core</strong> means a scheduler produces algorithmic overhead on a core
</li>
<li>
<strong>Responsibility</strong> means a scheduler controls the scheduling on core(s)
</li>
</ul>
<p>
<img src="images/user-scheduling-sched-allocation.png"/>
</p>
<h4><a id="section2.2.6.2"></a>Task to Scheduler assignment</h4>
<p>Tasks have a core affinity and are assigned to a scheduler</p>
<ul>
<li>
<strong>Core Affinity</strong> Specifies the possible cores the task can run on. If only one core is specified, the task runs on this core. If multiple cores are specified, the task can migrate between the cores.
</li>
<li>
<strong>Scheduler</strong> specifies the unique allocation of the task to a scheduler.
</li>
</ul>
<p>The scheduling parameters are determined by the scheduling algorithm and are only valid for a specific task – scheduler combination. Therefore the parameters are specified in the TaskAllocation object.</p>
<p>
<img src="images/user-scheduling-task-allocation.png"/>
</p>
<h4><a id="section2.2.6.3"></a>Scheduler hierarchies</h4>
<p>Schedulers can be arranged in a hierarchy. If set, the parent scheduler takes the initial decision and delegates to a child-scheduler. If the child-scheduler is not a grouping of tasks, it can take scheduling decisions if permission is granted by the parent.
<br>The scheduling parameters are determined by the scheduling algorithm of the parent scheduler. Therefore the relevant parameters in the hierarchical context are specified in the (intermediate) SchedulerAssociation object.
</p>
<p>
<img src="images/user-scheduling-hierarchy.png"/>
</p>
<h3><a id="section2.2.7">2.2.7 </a>Communication via channels</h3>
<h4><a id="section2.2.7.1"></a>Channel</h4>
<p>Sender and receiver communicating via a channel by issuing send and receive operations; read policy and transmission policy define communication details.</p>
<p>
<img src="images/user_channel.png"/>
</p>
<p>A channel is specified by three attributes:</p>
<ul>
<li>
<strong>elementType</strong>: the type that is sent to or read from the channel.
</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. In other words, no more than maxElements elements of the given element type may be stored in the channel.
</li>
</ul>
<h4><a id="section2.2.7.2"></a>Channel Access</h4>
<p>In the basic thinking model, all elements are stored as a sequential collection in the channel.</p>
<p>
<img src="images/user_channel_access.png"/>
</p>
<h5><a id="section2.2.7.2.1"></a>Sending</h5>
<p>A runnable may send elements to a channel by issuing send operations.
<br>The send operation has a single parameter:
</p>
<ul>
<li>
<strong>elements</strong> (integer): Number of elements that are written.
</li>
</ul>
<h5><a id="section2.2.7.2.2"></a>Receiving</h5>
<p>A runnable may receive elements from a channel by issuing receive operations.
<br>The receive operation is specified with a
<strong>receive policy</strong> that defines the main behaviour of the operation:
</p>
<ul>
<li>
<strong>LIFO</strong> (last-in, first-out) is chosen if processing the last written elements is the primary focus and thereby missing elements is tolerable.
</li>
<li>
<strong>FIFO</strong> (first-in, first-out) is chosen if every written element needs to be handled, that is, loss of elements is not tolerable.
</li>
<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>
<p>The receive policy defines the direction a receive operation takes effect with LIFO accesses are from top of the sequential collection, while with FIFO accesses are from bottom of the sequential collection-and they define if the receive operation is destructive (take) or non-destructive) read.</p>
<p>Each operation further has two parameters and two attributes specifying the exact behavior. The two parameters are:</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) or newest element (LIFO) in the channel.
</li>
</ul>
<p>In the following several examples are shown, of how to read or take elements out of a channel with the introduced parameters.</p>
<p>
<img src="images/user_channel_operations.png"/>
</p>
<p>Two attributes further detail 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 value of the parameter elements. 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 Runnable. Default value is false.
</li>
</ul>
<h4><a id="section2.2.7.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 the following attributes:</p>
<ul>
<li>
<strong>chunkSize</strong>: Size of a part of an element, maximum is the element size.
</li>
<li>
<strong>chunkProcessingTicks</strong> (integer): Number of ticks that will be executed to process one chunk (algorithmic overhead).
</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.8">2.2.8 </a>Data Dependencies</h3>
<h4><a id="section2.2.8.1"></a>Overview</h4>
<p>It is possible to specify potential data dependencies for written data. More specifically, it is now possible to annotate at write accesses what other data potentially have influenced the written data. A typical "influence" would be usage of data for computing a written value. As such data often comes from parameters when calling a runnable, it is now also possible to specify runnable parameters in Amalthea and their potential influence on written data.</p>
<p>Semantics of the new attributes in Amalthea is described in detail below. In general, these data dependency extensions are considered as a way to explicitly model details that help for visualization or expert reviews. For use cases such as timing simulation the data dependency extensions are of no importance and should be ignored. </p>
<h4><a id="section2.2.8.2"></a>Internal Dataflow</h4>
<p>In Embedded Systems, external dataflow is specified with reads and writes to labels, which are visible globally. This is sufficient for describing the inter-runnable communication and other use-cases like memory optimization. Nevertheless, for description of signal flows along an event chain, it is also necessary to specify the internal dataflow so that the connection between the read labels and the written labels in made.
<br>Internal dataflow is specified as dependency of label writes to other labels, parameters of the runnable or event return values of called runnables. With this information, the connection of reads to writes of label can be drawn.
</p>
<p>
<img src="images/user_sw_data_dependency_view.png"/>
</p>
<p>The internal dependencies are typically generated through source code analysis. The analysis parses the code and determines all writes to labels. For each of those positions, a backward slicing is made on the abstract syntax tree to derive all reads that influence this write. This collection is then stored as dependency at the write access.
<br>Based upon this data a developer can now track a signal flow along from the sensor over several other runnables to the actuator. Existing event-chains can be automatically validated to contain a valid flow by checking if the segments containing a read label event and write label event within the same runnable are connected by an internal dependency. Without internal dependencies, this would introduce a huge manual effort. Afterwards the event-chains can be simulated and their end-to-end latencies determined with the usual tools.
</p>
<h3 id="user-memsection"><a id="section2.2.9">2.2.9 </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.9.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.9.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>(defined in data specification and associated to memory elements)</em> and physical memory sections
<i>(generated after linker run)</i>.
</p>
<p>
<img class="scale" src="images/user_section_virtual_to_physical.png"/>
</p>
<h4><a id="section2.2.9.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" &lt;--&gt; "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 utilization 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 utilization 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 utilization 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<sub>1</sub> 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 utilization 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 utilization 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 utilization 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 utilization 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<sub>1</sub>. 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 utilization 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 utilization 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 utilization 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 utilization 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 utilization 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 utilization 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="https://oparu.uni-ulm.de/xmlui/handle/123456789/1770">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>Hardware Examples</h3>
<p>This example contains two simple hardware models:</p>
<p>
<strong>Example 1: Simple_ECU</strong>
</p>
<p>
<img class="scale" src="images/example_hw_example_1_diagram.png"/>
</p>
<p>The example shows a single structure with two identical cores with such an Instruction per cycle feature. The model includes only one frequency domain and no power domain. Each core is connected to all three different memory units via a
<em>HwAccessElement</em> with read and write latencies. The memory components include an access latency. This means the total latency for a read and a write access are calculated in the following way:
</p>
<p>
<em>TotalReadLatency = readLatency + accessLatency</em>
<br>
<em>TotalWriteLatency = writeLatency + accessLatency</em>
</p>
<p>This example shows a very simple hardware modeling approach where no interconnects and ports are necessary. Such a model can be used in a very early design phase where only rough estimations or a limited amount of informations about the system are available.</p>
<p>
<img src="images/example_hw_example_1_editor.png"/>
</p>
<p>
<strong>Example 2: Simple_E_E_Architecture</strong>
</p>
<p>
<img class="scale" src="images/example_hw_example_2_diagram.png"/>
</p>
<p>The second example shows a simple E/E-Architecture out of two identical ECUs. Each ECU contains two cores, one interconnect and a memory component. Both ECUs are connected via a CAN-Bus. In this example both possibilities for a
<em>HwAccessElement</em> are shown. The local memory is just connected with read and write latencies and the external memory of the other ECU is connected with the help of a
<em>HwAccessPath</em>. To use access paths hardware ports and connections between those ports are mandatory. The access paths itself is an ordered list of elements which are used for the connection. As an example for the access path between Core1EC1 and MainMemEC2 following access path elements are referred:
</p>
<p>con1 -&gt; internalCan_ECU1 -&gt; con4 -&gt; con9 -&gt; CAN -&gt; con10 -&gt; con8 -&gt; InterconnectEC2 -&gt; con7.</p>
<p>That means the complete access paths includes:</p>
<ul>
<li>3 x ConnectionHandler</li>
<li>6 x HwConnections</li>
</ul>
<p>The latency in this case is the sum of all elements of the path plus the access latency of the memory. However latencies at connections are usually only used to account an offset for a specific component. In case a data rate is used the maximum data rate is limited by the lowest data rate in the path. In case of a
<em>ConnectionHandler</em> the data rate is usually shared between different accesses.
<br>The hierarchical ports from both ECUs to connect the CAN Bus with the ECUs as block boxes are not mandatory but recommended. This concept of hierarchical ports increases the number of HwConnections but allows also the structuring of all internal modules within a HwStructure and only connect the hierarchical ports with the rest of the system.
</p>
<p>
<img src="images/example_hw_example_2_editor.png"/>
</p>
<h3><a id="section2.3.10">2.3.10 </a>Scheduler Examples</h3>
<p>The following elements are used to illustrate the structure of the example schedulers:</p>
<p>
<img src="images/example_scheduler_legend.png"/>
</p>
<h4><a id="section2.3.10.1"></a>Hierarchical Scheduler</h4>
<p>In this example the main scheduler realizes a
<strong>Priority Round Robin</strong> strategy. The main scheduler works as a global scheduler that schedules subsystems like virtual machines or hypervisor partitions. Each partition realizes an
<strong>OSEK</strong> scheduling system. In this case the main scheduler is responsible for both cores but only running on one core. Each
<strong>OSEK</strong> subsystem is responsible for exactly one core but only if the main scheduler grants the core usage. The
<strong>OSEK</strong> subsystems then decide on a FPP basis, which task can run. The coreAffinity for the tasks is not needed, since their scheduler is only responsible for one core.
</p>
<p>
<img src="images/example_scheduler_hierarchical.png"/>
</p>
<h4><a id="section2.3.10.2"></a>Partitioned_FPP Scheduler</h4>
<p>In this example a custom FPP scheduler named
<strong>Partitioned_FPP</strong> is representing a global scheduler. It schedules tasks on a FPP basis but with the additional constraint that its group must have budget left (has similarities to 'adaptive partitioned scheduling' of QNX). The scheduler "Grouping" is only there to assign budgets to a logical task group and define no mapping or responsibility at all. Therefore in the taskAllocation only priority and coreAffinity are specified. The coreAffinity of tasks in the same group can differ, even task migration is possible if a task affinity is
<strong>CoreA</strong> as well as
<strong>CoreB</strong>.
</p>
<p>
<img src="images/example_scheduler_partitioned_fpp.png"/>
</p>
<h3><a id="section2.3.11">2.3.11 </a>Numeric Modes Example</h3>
<p>Dynamic task activations and the execution of different control paths can depend on internal system states, external events and scheduling effects resulting in different execution sequences of tasks. In APP4MC modes can be used to steer different execution paths. The designer can define modes that execute different paths within runnables, tasks, and even control dynamic activation schemes of tasks with multiple dependencies. This page explains the concepts with a simple example. For the description of the basic model elements, we refer the reader to the chapters:</p>
<p>Data Models -&gt; Software Model -&gt; Modes
<br>Data Models -&gt; Software Model -&gt; Runnable Items -&gt; Runnable Mode Switch
<br>Data Models -&gt; Software Model -&gt; The Call Graph -&gt; Mode Switch
<br>Data Models -&gt; Stimuli Model -&gt; Mode Value List and Execution Condition
</p>
<h4><a id="section2.3.11.1"></a>Example description</h4>
<p>In this chapter, we show a small example how to use modes to steer the execution and the activation of tasks with modes. The following picture depicts the example:</p>
<p>
<img src="images/example_numeric_modes.png" style="width:750px"/>
</p>
<p>In this example, we have three modes, one _Enum__ and two
<i>Numeric</i>. The numeric modes are initialized with the value -1:
</p>
<p>
<img src="images/example_numeric_modes_modes.png"/>
</p>
<p>First, we have two data generators with Task
<i>genX</i> and Task
<i>genY</i> where each execution increases a numeric mode by 1. They are activated by a relative sporadic stimulus with an occurrence interval between 10ms and 50ms. The runnable
<i>counterForX</i> executes this for
<i>genX</i>:
</p>
<p>
<img src="images/example_numeric_modes_gen-x.png"/>
</p>
<p>On every execution, the generator tasks trigger the
<i>CustomEvent</i>
<i>check</i> to evaluate the
<i>EventStimulus</i>. This event stimulus checks the condition:
<br>
<strong>
<i>executionMode == ModeA &amp;&amp; countX &gt; 2 &amp;&amp; countY &gt; 4</i>
</strong>
<br>In this example, we do not describe the change of the
<i>executionMode</i> to keep the model simpler. This mode could be changed e.g. from within the system or by an external ISR trigger.
</p>
<p>
<img src="images/example_numeric_modes_event-stimuli.png"/>
</p>
<p>If this condition is true, both counting modes are set to zero and the Task
<i>doA</i> is called.
</p>
<p>Another way to steer the execution depending can be done via mode switches on task level. In
<i>doB</i> the mode check is done at task level as depicted in the following picture:
</p>
<p>
<img src="images/example_numeric_modes_do-b.png"/>
</p>
<p>Only if the condition is true runnable
<i>runB</i> is called. Within this runnable the counting modes are decremented by 3.
</p>
<p>
<img src="images/example_numeric_modes_runn-b.png"/>
</p>
<p>The last mechanisms is also possible at runnable level by using the
<i>runnableModeSwitch</i>.
</p>
<p>Beware of where to reset or change the modes. In
<i>doB</i> the modes are reseted directly in the beginning. If you by accident put these after the
<i>tick</i> element, it could result in an unintended behavior. In the generator tasks be aware of where to put the
<i>customEventTrigger</i>. This element activates the stimuli evaluation. If you put a tick element between the increment and the trigger, the evaluation is delayed.
</p>
<h3><a id="section2.3.12">2.3.12 </a>New AMALTHEA Trace Database (ATDB) Example</h3>
<p>The ATDB provides tables and view definitions to hold trace data and represent it in comprehensive views. In this section we will show a small example BTF trace, convert it to its ATDB equivalent, and enrich it with event chains. The relevant tables and views will given for better understanding.</p>
<h4><a id="section2.3.12.1"></a>Source BTF Trace</h4>
<p>The source BTF trace has two cores, three stimuli, three tasks, and four runnables.</p>
<pre xml:space="preserve"><code>#version 2.2.0
#timeScale ns
0,ECU_1,-1,SIM,SIM,-1,tag,ECU_INIT
0,Processor_1,-1,SIM,SIM,-1,tag,PROCESSOR_INIT
0,Core_1,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_2,-1,SIM,SIM,-1,tag,CORE_INIT
0,Core_1,0,C,Core_1,0,set_frequence,10000000
0,Core_2,0,C,Core_2,0,set_frequence,11000000
0,Stimulus_Task_1,0,STI,Stimulus_Task_1,0,trigger
0,Stimulus_Task_1,0,T,Task_1,0,activate
0,Stimulus_Task_2,0,STI,Stimulus_Task_2,0,trigger
0,Stimulus_Task_2,0,T,Task_2,0,activate
100,Core_1,0,T,Task_1,0,start
100,Task_1,0,R,Runnable_1_1,0,start
100,Core_2,0,T,Task_2,0,start
100,Task_2,0,R,Runnable_2_1,0,start
20800,Task_1,0,R,Runnable_1_1,0,terminate
20800,Task_1,0,R,Runnable_1_2,0,start
40900,Task_1,0,R,Runnable_1_2,0,terminate
40900,Core_1,0,T,Task_1,0,terminate
45000,Stimulus_Task_3,0,STI,Stimulus_Task_3,0,trigger
45000,Stimulus_Task_3,0,T,Task_3,0,activate
45100,Task_2,0,R,Runnable_2_1,0,suspend
45100,Core_2,0,T,Task_2,0,preempt
45100,Core_2,0,T,Task_3,0,start
45100,Task_3,0,R,Runnable_3_1,0,start
55800,Task_3,0,R,Runnable_3_1,0,terminate
55800,Core_2,0,T,Task_3,0,terminate
55900,Core_2,0,T,Task_2,0,resume
55900,Task_2,0,R,Runnable_2_1,0,resume
61000,Task_2,0,R,Runnable_2_1,0,terminate
61000,Core_2,0,T,Task_2,0,terminate
</code></pre>
<p>There is exacly one instance of each entity in the trace, so the tables in the database do not become to big for a small example. The visualized Gantt chart of the above trace is depicted in the following figure:</p>
<p>
<img class="scale" src="images/atdb_example_btf_visual.png"/>
</p>
<h4><a id="section2.3.12.2"></a>Equivalent ATDB Contents</h4>
<p>The tables and/or relevant views for the above BTF trace are listed in the following: Note that if the table's header starts with a "v" it is a view for better readability.</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="2" rowspan="1" style="text-align:center">
<strong>MetaInformation</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">name</th>
<th colspan="1" rowspan="1">value</th>
</tr>
<tr>
<td colspan="1" rowspan="1">timeBase</td>
<td colspan="1" rowspan="1">ns</td>
</tr>
</table>
<p><br></p>
<table class="classic" style="background:#f8f8f8;display:inline-table">
<tr style="background:#eee">
<td colspan="3" rowspan="1" style="text-align:center">
<strong>Entity</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">id</th>
<th colspan="1" rowspan="1">name</th>
<th colspan="1" rowspan="1">entityTypeId</th>
</tr>
<tr>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">SIM</td>
<td colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">ECU_1</td>
<td colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">Processor_1</td>
<td colspan="1" rowspan="1">3</td>
</tr>
<tr>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">Core_1</td>
<td colspan="1" rowspan="1">4</td>
</tr>
<tr>
<td colspan="1" rowspan="1">5</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">4</td>
</tr>
<tr>
<td colspan="1" rowspan="1">6</td>
<td colspan="1" rowspan="1">Stimulus_Task_1</td>
<td colspan="1" rowspan="1">5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">7</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">6</td>
</tr>
<tr>
<td colspan="1" rowspan="1">8</td>
<td colspan="1" rowspan="1">Stimulus_Task_2</td>
<td colspan="1" rowspan="1">5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">9</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">6</td>
</tr>
<tr>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">7</td>
</tr>
<tr>
<td colspan="1" rowspan="1">11</td>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">7</td>
</tr>
<tr>
<td colspan="1" rowspan="1">12</td>
<td colspan="1" rowspan="1">Runnable_1_2</td>
<td colspan="1" rowspan="1">7</td>
</tr>
<tr>
<td colspan="1" rowspan="1">13</td>
<td colspan="1" rowspan="1">Stimulus_Task_3</td>
<td colspan="1" rowspan="1">5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">14</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">6</td>
</tr>
<tr>
<td colspan="1" rowspan="1">15</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">7</td>
</tr>
</table>
<table class="classic" style="background:#f8f8f8;display:inline-table">
<tr style="background:#eee">
<td colspan="2" rowspan="1" style="text-align:center">
<strong>EntityInstance</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">entityId</th>
<th colspan="1" rowspan="1">sqcnr</th>
</tr>
<tr>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">-1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">-1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">-1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">-1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">5</td>
<td colspan="1" rowspan="1">-1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">5</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">6</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">7</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">8</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">9</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">11</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">12</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">13</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">14</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">15</td>
<td colspan="1" rowspan="1">0</td>
</tr>
</table>
<table class="classic" style="background:#f8f8f8;display:inline-table">
<tr style="background:#eee">
<td colspan="2" rowspan="1" style="text-align:center">
<strong>EntityType</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">id</th>
<th colspan="1" rowspan="1">name</th>
</tr>
<tr>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">SIM</td>
</tr>
<tr>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">ECU</td>
</tr>
<tr>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">Processor</td>
</tr>
<tr>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">C</td>
</tr>
<tr>
<td colspan="1" rowspan="1">5</td>
<td colspan="1" rowspan="1">STI</td>
</tr>
<tr>
<td colspan="1" rowspan="1">6</td>
<td colspan="1" rowspan="1">T</td>
</tr>
<tr>
<td colspan="1" rowspan="1">7</td>
<td colspan="1" rowspan="1">R</td>
</tr>
</table>
<table class="classic" style="background:#f8f8f8;display:inline-table">
<tr style="background:#eee">
<td colspan="3" rowspan="1" style="text-align:center">
<strong>Property</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">id</th>
<th colspan="1" rowspan="1">name</th>
<th colspan="1" rowspan="1">type</th>
</tr>
<tr>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">processors</td>
<td colspan="1" rowspan="1">entityIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">cores</td>
<td colspan="1" rowspan="1">entityIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">frequencyInHz</td>
<td colspan="1" rowspan="1">long</td>
</tr>
<tr>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">executingCore</td>
<td colspan="1" rowspan="1">entityIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">5</td>
<td colspan="1" rowspan="1">runnables</td>
<td colspan="1" rowspan="1">entityIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">6</td>
<td colspan="1" rowspan="1">ecItems</td>
<td colspan="1" rowspan="1">entityIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">7</td>
<td colspan="1" rowspan="1">ecStimulus</td>
<td colspan="1" rowspan="1">eventIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">8</td>
<td colspan="1" rowspan="1">ecResponse</td>
<td colspan="1" rowspan="1">eventIdRef</td>
</tr>
<tr>
<td colspan="1" rowspan="1">9</td>
<td colspan="1" rowspan="1">ecInstIsAge</td>
<td colspan="1" rowspan="1">boolean</td>
</tr>
<tr>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">ecInstIsReaction</td>
<td colspan="1" rowspan="1">boolean</td>
</tr>
</table>
<p>Note that in the entityInstance table there are actually two instances of the cores (entityIds 4 and 5). Also note, the event chain properties are already contained in the property table.</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="10" rowspan="1" style="text-align:center">
<strong>vTraceEvent</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">timestamp</th>
<th colspan="1" rowspan="1">sqcnr</th>
<th colspan="1" rowspan="1">entityName</th>
<th colspan="1" rowspan="1">entityType</th>
<th colspan="1" rowspan="1">entityInstance</th>
<th colspan="1" rowspan="1">sourceEntityName</th>
<th colspan="1" rowspan="1">sourceEntityType</th>
<th colspan="1" rowspan="1">sourceEntityInstance</th>
<th colspan="1" rowspan="1">eventType</th>
<th colspan="1" rowspan="1">value</th>
</tr>
<tr>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_1</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_1</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">trigger</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_1</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">activate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">Stimulus_Task_2</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_2</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">trigger</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_2</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">activate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">100</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_1</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">100</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">100</td>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">100</td>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">20800</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">20800</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Runnable_1_2</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">40900</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Runnable_1_2</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">40900</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_1</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">45000</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_3</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_3</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">trigger</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">45000</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Stimulus_Task_3</td>
<td colspan="1" rowspan="1">STI</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">activate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">45100</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">suspend</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">45100</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">preempt</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">45100</td>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">45100</td>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">55800</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">55800</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">55900</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">resume</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">55900</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">resume</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">61000</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">61000</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1"/>
</tr>
</table>
<p>The vTraceEvent table view intentionally resembles the original BTF trace. However, some information is omitted since it is extracted and stored in other tables (e.g. the frequency of the cores). All tags (eventType "tag") have been stored in property values.</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="5" rowspan="1" style="text-align:center">
<strong>vPropertyValue</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">entityName</th>
<th colspan="1" rowspan="1">entityType</th>
<th colspan="1" rowspan="1">propertyName</th>
<th colspan="1" rowspan="1">propertyType</th>
<th colspan="1" rowspan="1">value</th>
</tr>
<tr>
<td colspan="1" rowspan="1">ECU_1</td>
<td colspan="1" rowspan="1">ECU</td>
<td colspan="1" rowspan="1">processors</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Processor_1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Processor_1</td>
<td colspan="1" rowspan="1">Processor</td>
<td colspan="1" rowspan="1">cores</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Core_1, Core_2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Core_1</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">frequencyInHz</td>
<td colspan="1" rowspan="1">long</td>
<td colspan="1" rowspan="1">10000000</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Core_2</td>
<td colspan="1" rowspan="1">C</td>
<td colspan="1" rowspan="1">frequencyInHz</td>
<td colspan="1" rowspan="1">long</td>
<td colspan="1" rowspan="1">11000000</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">executingCore</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Core_1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">runnables</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Runnable_1_1, Runnable_1_2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">executingCore</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Core_2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">runnables</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Runnable_2_1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">executingCore</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Core_2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">runnables</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
</tr>
</table>
<p><br></p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="7" rowspan="1" style="text-align:center">
<strong>vRunnableInstanceTraceInfo</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">runnableName</th>
<th colspan="1" rowspan="1">entityInstance</th>
<th colspan="1" rowspan="1">startEventCount</th>
<th colspan="1" rowspan="1">resumeEventCount</th>
<th colspan="1" rowspan="1">terminateEventCount</th>
<th colspan="1" rowspan="1">suspendEventCount</th>
<th colspan="1" rowspan="1">isComplete</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_2</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">1</td>
</tr>
</table>
<p>All runnables instances are completely represented in the trace, as are the task instances. To keep it simple we leave out the vProcessInstanceTraceInfo table since it is too wide (it has more event types).</p>
<h4><a id="section2.3.12.3"></a>Adding Event Chains</h4>
<p>Thus far, all information contained in the database has been extracted from the original BTF trace. Event chains, however, are not actually visible in the trace. So we insert their specification (which may originate from an AMALTHEA model) manually. Our event chain is specified as follows:</p>
<p>
<strong>Runnable_1_1:start</strong> -&gt;
<strong>Runnable_1_1:terminate</strong> -&gt;
<strong>Runnable_3_1:start</strong> -&gt;
<strong>Runnable_3_1:terminate</strong>
</p>
<p>In order to define our event chain for the respective events (which must be present even without a trace), we define them in the event table:</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="6" rowspan="1" style="text-align:center">
<strong>vEvent</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">name</th>
<th colspan="1" rowspan="1">eventType</th>
<th colspan="1" rowspan="1">entityName</th>
<th colspan="1" rowspan="1">entityType</th>
<th colspan="1" rowspan="1">sourceEntityName</th>
<th colspan="1" rowspan="1">sourceEntityType</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_1_start</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_1_terminate</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_3_1_start</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_3_1_terminate</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
</tr>
</table>
<p>The following two tables then extend the existing ones by the event chains.</p>
<table class="classic" style="background:#f8f8f8;display:inline-table">
<tr style="background:#eee">
<td colspan="3" rowspan="1" style="text-align:center">
<strong>Entity</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">id</th>
<th colspan="1" rowspan="1">name</th>
<th colspan="1" rowspan="1">entityTypeId</th>
</tr>
<tr>
<td colspan="1" rowspan="1">16</td>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">8</td>
</tr>
<tr>
<td colspan="1" rowspan="1">17</td>
<td colspan="1" rowspan="1">EC1_segment1</td>
<td colspan="1" rowspan="1">8</td>
</tr>
<tr>
<td colspan="1" rowspan="1">18</td>
<td colspan="1" rowspan="1">EC1_segment2</td>
<td colspan="1" rowspan="1">8</td>
</tr>
<tr>
<td colspan="1" rowspan="1">19</td>
<td colspan="1" rowspan="1">EC1_segment3</td>
<td colspan="1" rowspan="1">8</td>
</tr>
</table>
<table class="classic" style="background:#f8f8f8;display:inline-table">
<tr style="background:#eee">
<td colspan="2" rowspan="1" style="text-align:center">
<strong>EntityType</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">id</th>
<th colspan="1" rowspan="1">name</th>
</tr>
<tr>
<td colspan="1" rowspan="1">8</td>
<td colspan="1" rowspan="1">EC</td>
</tr>
</table>
<p>In the values of properties, we employ event chain items to represent the segments. As the vPropertyValue view indicates, at this point we refer to the stimulus/response events we created in the event table.</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="5" rowspan="1" style="text-align:center">
<strong>vPropertyValue</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">entityName</th>
<th colspan="1" rowspan="1">entityType</th>
<th colspan="1" rowspan="1">propertyName</th>
<th colspan="1" rowspan="1">propertyType</th>
<th colspan="1" rowspan="1">value</th>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecItems</td>
<td colspan="1" rowspan="1">entityIdRef</td>
<td colspan="1" rowspan="1">EC1_segment1, EC1_segment2, EC1_segment3</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecStimulus</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_1_1_start</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecResponse</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_3_1_terminate</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecStimulus</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_1_1_start</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecResponse</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_1_1_terminate</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment2</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecStimulus</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_1_1_terminate</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment2</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecResponse</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_3_1_start</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment3</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecStimulus</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_3_1_start</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment3</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">ecResponse</td>
<td colspan="1" rowspan="1">eventIdRef</td>
<td colspan="1" rowspan="1">Runnable_3_1_terminate</td>
</tr>
</table>
<p>There is the additional view which explicitly combines event chains and their properties:</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="6" rowspan="1" style="text-align:center">
<strong>vEventChainInstanceInfo</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">eventChainName</th>
<th colspan="1" rowspan="1">stimulus</th>
<th colspan="1" rowspan="1">response</th>
<th colspan="1" rowspan="1">items</th>
<th colspan="1" rowspan="1">minItemsCompleted</th>
<th colspan="1" rowspan="1">isParallel</th>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">Runnable_1_1_start</td>
<td colspan="1" rowspan="1">Runnable_3_1_terminate</td>
<td colspan="1" rowspan="1">EC1_segment1, EC1_segment2, EC1_segment3</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment1</td>
<td colspan="1" rowspan="1">Runnable_1_1_start</td>
<td colspan="1" rowspan="1">Runnable_1_1_terminate</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment2</td>
<td colspan="1" rowspan="1">Runnable_1_1_terminate</td>
<td colspan="1" rowspan="1">Runnable_3_1_start</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment3</td>
<td colspan="1" rowspan="1">Runnable_3_1_start</td>
<td colspan="1" rowspan="1">Runnable_3_1_terminate</td>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">0</td>
</tr>
</table>
<p>Each event chain has exactly one instance in the EntityInstance table. So the derived view for event chain instances is as follows:</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="11" rowspan="1" style="text-align:center">
<strong>vEventChainInstanceInfo</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">eventChainName</th>
<th colspan="1" rowspan="1">ecInstance</th>
<th colspan="1" rowspan="1">stimulusTimestamp</th>
<th colspan="1" rowspan="1">stimulusEntityName</th>
<th colspan="1" rowspan="1">stimulusEntityInstance</th>
<th colspan="1" rowspan="1">stimulusEvent</th>
<th colspan="1" rowspan="1">responseTimestamp</th>
<th colspan="1" rowspan="1">responseEntityName</th>
<th colspan="1" rowspan="1">responseEntityInstance</th>
<th colspan="1" rowspan="1">responseEvent</th>
<th colspan="1" rowspan="1">latencyType</th>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">100</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">55800</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">age/reaction</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">100</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">20800</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">age/reaction</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment2</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">20800</td>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">45100</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">age/reaction</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment3</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">45100</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">55800</td>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">age/reaction</td>
</tr>
</table>
<h4><a id="section2.3.12.4"></a>Metrics on the Trace</h4>
<p>There are numerous metrics for entities. The most important ones include the times that each entity instance remains in a specific state (according to their corresponding BTF state automaton). In addition to these metrics, there are also some counting metrics (e.g. how often a specific task instance was preempted). Lastly, there are also metrics for specific entity tyopes and instances, e.g., the latency for a specific event chain instance (either age or reaction). The metrics themselfes and these entity instance specific metrics for our example are listed in the following:</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="3" rowspan="1" style="text-align:center">
<strong>Metric</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">id</th>
<th colspan="1" rowspan="1">name</th>
<th colspan="1" rowspan="1">dimension</th>
</tr>
<tr>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">startDelayTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">pollingTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">parkingTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">5</td>
<td colspan="1" rowspan="1">waitingTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">6</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">7</td>
<td colspan="1" rowspan="1">responseTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">8</td>
<td colspan="1" rowspan="1">coreExecutionTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">9</td>
<td colspan="1" rowspan="1">netExecutionTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">grossExecutionTime</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">11</td>
<td colspan="1" rowspan="1">activateToActivate</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">12</td>
<td colspan="1" rowspan="1">startToStart</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">13</td>
<td colspan="1" rowspan="1">endToEnd</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">14</td>
<td colspan="1" rowspan="1">endToStart</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">15</td>
<td colspan="1" rowspan="1">slack</td>
<td colspan="1" rowspan="1">time</td>
</tr>
<tr>
<td colspan="1" rowspan="1">61</td>
<td colspan="1" rowspan="1">activations</td>
<td colspan="1" rowspan="1">count</td>
</tr>
<tr>
<td colspan="1" rowspan="1">62</td>
<td colspan="1" rowspan="1">boundedMigrations</td>
<td colspan="1" rowspan="1">count</td>
</tr>
<tr>
<td colspan="1" rowspan="1">63</td>
<td colspan="1" rowspan="1">fullMigrations</td>
<td colspan="1" rowspan="1">count</td>
</tr>
<tr>
<td colspan="1" rowspan="1">64</td>
<td colspan="1" rowspan="1">mtaLimitExceeding</td>
<td colspan="1" rowspan="1">count</td>
</tr>
<tr>
<td colspan="1" rowspan="1">65</td>
<td colspan="1" rowspan="1">preemptions</td>
<td colspan="1" rowspan="1">count</td>
</tr>
<tr>
<td colspan="1" rowspan="1">66</td>
<td colspan="1" rowspan="1">latency</td>
<td colspan="1" rowspan="1">time</td>
</tr>
</table>
<p>As indicated by th id numbering, we omitted some of the metrics. These include the respective Min/Max/Avg of each metric with dimension "time". Here is the view of the entity instance metric values:</p>
<table class="classic" style="background:#f8f8f8">
<tr style="background:#eee">
<td colspan="5" rowspan="1" style="text-align:center">
<strong>vEntityInstanceMetricValue</strong>
</td>
</tr>
<tr style="background:#eee">
<th colspan="1" rowspan="1">entityName</th>
<th colspan="1" rowspan="1">entityType</th>
<th colspan="1" rowspan="1">entityInstance</th>
<th colspan="1" rowspan="1">metricName</th>
<th colspan="1" rowspan="1">value</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">startDelayTime</td>
<td colspan="1" rowspan="1">100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">40800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">pollingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">parkingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">waitingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">responseTime</td>
<td colspan="1" rowspan="1">40900</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">coreExecutionTime</td>
<td colspan="1" rowspan="1">40800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">netExecutionTime</td>
<td colspan="1" rowspan="1">40800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">grossExecutionTime</td>
<td colspan="1" rowspan="1">40800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">startDelayTime</td>
<td colspan="1" rowspan="1">100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">50100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">pollingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">parkingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">waitingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">10800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">responseTime</td>
<td colspan="1" rowspan="1">61000</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">coreExecutionTime</td>
<td colspan="1" rowspan="1">50100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">netExecutionTime</td>
<td colspan="1" rowspan="1">50100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">grossExecutionTime</td>
<td colspan="1" rowspan="1">60900</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">20700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">50100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_2_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">10800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_2</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">20100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_1_2</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">startDelayTime</td>
<td colspan="1" rowspan="1">100</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">10700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">pollingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">parkingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">waitingTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">responseTime</td>
<td colspan="1" rowspan="1">10800</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">coreExecutionTime</td>
<td colspan="1" rowspan="1">10700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">netExecutionTime</td>
<td colspan="1" rowspan="1">10700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">T</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">grossExecutionTime</td>
<td colspan="1" rowspan="1">10700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">runningTime</td>
<td colspan="1" rowspan="1">10700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable_3_1</td>
<td colspan="1" rowspan="1">R</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">readyTime</td>
<td colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">latency</td>
<td colspan="1" rowspan="1">55700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment1</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">latency</td>
<td colspan="1" rowspan="1">20700</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment2</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">latency</td>
<td colspan="1" rowspan="1">24300</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EC1_segment3</td>
<td colspan="1" rowspan="1">EC</td>
<td colspan="1" rowspan="1">0</td>
<td colspan="1" rowspan="1">latency</td>
<td colspan="1" rowspan="1">10700</td>
</tr>
</table>
<p>Note that since each event chain instance also is either age, reaction, or both, the latency metric does not distinguish between the two. There are also cumulated Min/Max/Avg values calculated from these entity instance metric values. Since there is only one instance of each entity in the example trace the values are all the same, so we omit the EntityMetricValue table here (it has roughly three times as many entries).</p>
<h2><a id="section2.4">2.4 </a>Tutorials</h2>
<h3 id="example-taskvis"><a id="section2.4.1">2.4.1 </a>Task Visualizer Example</h3>
<p>The following section describes how to visualize the execution of tasks along with their states on cores using the task visualizer plugin.</p>
<p>
<strong>Preparation</strong>
</p>
<p>In order to execute the task visualizer, it is necessary to describe the overall system in terms of an AMALTHEA Model file. The minimal amount of information consists of</p>
<ul>
<li>Tasks (Software Model) which contain Runnables (Software Model) and refer to Periodic Activations (Stimuli Model)</li>
<li>Cores (Hardware Model)</li>
<li>Allocations of Tasks to Cores (Mapping Model) </li>
</ul>
<p>Creating such a Model can either be done manually or by following the Tutorial on "Mapping example 1" </p>
<p>
<strong>Step 1</strong>
</p>
<p>
<img src="images/01-taskvis.png"/>
</p>
<p>Right-click the file containing the System you would like to visualize and select "Visualize Task Execution" from the "AMALTHEA Multicore Features" context menu to open the Task Visualization Overview.</p>
<p>
<strong>Step 2</strong>
</p>
<p>
<img src="images/02-taskvis-overview.png"/>
</p>
<p>The Task Visualization Overview provides basic information about the software as well as the hardware of the system. The upper part summarizes the allocations of Tasks to Cores, along with the number of total instructions per Task, the period between a tasks activation, the core these tasks are allocated to, as well as the Worst Case Execution Time (WCET) in terms of ps and percentages of the cores total utilization. THe lower part summaraizes the available cores along with the number of computatable instructions per second (IPS) and their utilization (with 1.0 being 100%). Continue by clicking next to advance to the the Task Dependencie Overview. </p>
<p>
<strong>Step 3</strong>
</p>
<p>
<img src="images/03-taskvis-dependencies.png"/>
</p>
<p>The Task Dependencies Overview visualizes the task graph with its inter-task dependencies as well as the communication delay. For simplicity, several restrictions are applied to the considered dependencies as illustrated in the box "Relations Filter". </p>
<p>If the check box "Consider task precedence" is deactivated, the tasks will be handled as batch tasks without any dependencies among each other.</p>
<p>For this tutorial, we activate the task precedence consideration and advance to the scheduling selection by clicking next.</p>
<p>
<strong>Step 4</strong>
</p>
<p>
<img src="images/04-taskvis-scheduling.png"/>
</p>
<p>The Scheduling Selection screen allows to fine-tune the execution visualization and to specify a scheduling algorithm. Until now, the following scheduling approaches are implemented:</p>
<ul>
<li>Preemptive Rate Monotonic Scheduling</li>
<li>Cooperative Earliest Deadline First</li>
<li>Preemptive Earliest Deadline First</li>
</ul>
<p>The scale allows configuring the "step" or "increment size" during the execution calculation, e.g. by setting this value to ms, each internal "tick" will increment the the execution model by one millisecond. If a task's total execution time is lower then the increment size, it will be round up to one millisecond. Consequently, the value should be set to a similar scale as the average execution time of the tasks.</p>
<p>Finally, the Simulation-Time allows specifying the time frame which should be visualized, e.g. with a task period of 15 ms, a value of 30.000.000.000 ps (30 ms) will visualize 2 periods. </p>
<p>To continue with this tutorial, set all values as shown in the figure and click "Finish" to plot the Execution Visualization.</p>
<p>
<strong>Step 5</strong>
</p>
<p>
<img src="images/05-taskvis-traceview.png"/>
</p>
<p>Finally, a Gantt-Chart illustrating the execution of each core is shown. By double-clicking the tab "TraceView", you can maximize the window to full-screen.</p>
<p>The top element of each chart illustrates the core's utilization, followed by the states of each task, which are defined as followed:</p>
<ul>
<li>Green: Running</li>
<li>Yellow: Ready</li>
<li>Red: Suspended</li>
<li>Orange: Waiting</li>
</ul>
<p>The description of the actual state as well as their start/end times can also been seen by hovering the cursor over a state.</p>
<h3><a id="section2.4.2">2.4.2 </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>
<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>Sirius Viewer</h3>
<p>Basic graphical viewers are realized using
<a href="https://www.eclipse.org/sirius/">Sirius</a>.
</p>
<p>The following viewers are treated as a POC (Proof of concept) and are not final.
<br>They can be extended and further developed to show additional parts of the model.
</p>
<h4><a id="section2.5.2.1"></a>Activate capabilities for project</h4>
<p>The following steps will activate the Sirius feature and AMALTHEA viewpoints:</p>
<p>To use Sirius, projects needs to have the
<i>Modeling Feature</i> enabled. This can be done by right clicking on the project and select
<strong>Configure – Convert to Modeling Project</strong>. Note that a new file
<i>representations.aird</i> is created at top level of the project. This file is containing the user created diagrams.
</p>
<p>
<img src="images/sirius_convert_project.png"/>
</p>
<p>Activate the AMALTHEA viewpoint by right click on the project and select
<strong>Viewpoint Selection</strong>.
</p>
<p>
<img src="images/sirius_viewpoints_selection.png"/>
</p>
<p>
<b>Note:</b> Using one of the available commands to open a view using a right click on an element automatically adds the Modeling Nature and selects the available AMALTHEA viewpoint.
</p>
<h4><a id="section2.5.2.2"></a>Available Diagrams</h4>
<h5><a id="section2.5.2.2.1"></a>Task View</h5>
<p>The current version of the Task View shows the Task as a container with the included Runnables.</p>
<p>Open/Create a view for a
<i>Task</i> element by right click on it and select
<i>Task View</i>.
</p>
<p>
<img src="images/sirius_task_view_create.png"/>
</p>
<p>A new diagram is shown based on the given
<i>Task</i> element.
</p>
<p>
<img src="images/sirius_task_view_1.png"/>
</p>
<h6><a id="section2.5.2.2.1.1"></a>Communication Layer</h6>
<p>The Communication Layer shows direct dependencies between
<i>Runnables</i>. Therefore the following requirement must be fulfilled:
</p>
<ol>
<li>Runnable R1 writes Label L1</li>
<li>Runnable R2 reads Label L1</li>
</ol>
<p>Enable it through the Layers option menu.</p>
<p>
<img src="images/sirius_task_view_comm_layer_enable.png"/>
</p>
<p>In this sample some of the available communications are fulfilling this requirement.</p>
<p>
<img src="images/sirius_task_view_comm_layer_show1.png"/>
</p>
<h6><a id="section2.5.2.2.1.2"></a>Label Layer</h6>
<p>The Label Layer shows all Read/Write dependencies between
<i>Runnables</i> and
<i>Labels</i>.
</p>
<p>Enable it through the Layers option menu.</p>
<p>
<img src="images/sirius_task_view_label_layer_enable.png"/>
</p>
<p>After some arrangement it can look like the following:</p>
<p>
<img src="images/sirius_task_view_label_layer_show.png"/>
</p>
<h5><a id="section2.5.2.2.2"></a>Label View</h5>
<p>The Label View shows a
<i>Label</i> element including read/write accesses from corresponding
<i>Runnables</i>.
</p>
<p>Open/Create a view for a
<i>Label</i> element by right click on it and select
<i>Label View</i>.
</p>
<p>
<img src="images/sirius_label_view_create.png"/>
</p>
<p>A new diagram is shown based on the given
<i>Label</i> element.
</p>
<p>
<img src="images/sirius_label_view_1.png"/>
</p>
<h5><a id="section2.5.2.2.3"></a>EventChain View</h5>
<p>The
<i>EventChain</i> view is the first version to show the included
<i>Events</i>.
<br>If there is a reference to a
<i>RunnableEvent</i>, the corresponding
<i>Runnable</i> is also shown.
<br>This behavior can be extended also for
<i>Labels</i> and
<i>Tasks</i> for example.
</p>
<p>Open/Create a view for an
<i>EventChain</i> element by right click on it and select
<i>Event Chain View</i>.
</p>
<p>
<img src="images/sirius_event_chain_view_create.png"/>
</p>
<p>A new diagram is opening showing the order of the included
<i>Events</i>.
<br>If there is a
<i>RunnableEvent</i>, the association to the
<i>Runnable</i> includes the configured
<i>EventType</i>.
</p>
<p>
<img src="images/sirius_event_chain_view_show.png"/>
</p>
<h5><a id="section2.5.2.2.4"></a>Tasks View</h5>
<p>The
<i>Tasks</i> view is in general the same view as the already mentioned
<i>Task</i> view above with the advantage to get an overview about all included
<i>Tasks</i> of a Software model.
</p>
<p>To open/create a Tasks view it is needed to switch to the Sirius perspective.</p>
<ul>
<li>This can be done by
<b>Window – Perspective – Open Perspective – Other</b> and select then Sirius.
</li>
<li>On the left side inside of the Model Explorer go to an AMALTHEA model, expand it and do a right click on the
<i>Software</i> model.
</li>
<li>Select
<b>New Representation – new Tasks Overview</b> to create a new diagram.
</li>
<li>Change the name if needed and click on ok.</li>
</ul>
<p>The same additional options are available as in the normal
<i>Task</i> view like the
<i>Label Layer</i> and
<i>Communication Layer</i>.
</p>
<p>
<img src="images/sirius_tasks_view_create.png"/>
</p>
<p>
<img src="images/sirius_tasks_view_show.png"/>
</p>
<h5><a id="section2.5.2.2.5"></a>Mapping View</h5>
<p>The
<i>Mapping</i> view gives an overview of the relation between
<i>Cores</i>,
<i>Schedulers</i> and
<i>Tasks</i>, which is defined in the
<i>Mapping Model</i> of AMALTHEA.
</p>
<p>To open/create a Tasks view it is needed to switch to the Sirius perspective.</p>
<ul>
<li>This can be done by
<b>Window – Perspective – Open Perspective – Other</b> and select then Sirius.
</li>
<li>On the left side inside of the Model Explorer go to an AMALTHEA model, expand it and do a right click on the
<i>Mapping</i> model.
</li>
<li>Select
<b>New Representation – new Tasks Overview</b> to create a new diagram.
</li>
<li>Change the name if needed and click on ok.</li>
</ul>
<p>
<img src="images/sirius_mapping_view_create.png"/>
</p>
<p>
<img src="images/sirius_mapping_view_show.png"/>
</p>
<h2><a id="section2.6">2.6 </a>Model Visualization</h2>
<h3><a id="section2.6.1">2.6.1 </a>Usage of AMALTHEA Model Visualization</h3>
<p>The AMALTHEA Visualization can be opened via</p>
<ul>
<li>
<i>Window → Show View → Other... → APP4MC → APP4MC Visualizations</i>,
</li>
<li> or via right click on an element and selecting
<i>Open APP4MC Visualization</i>.
</li>
</ul>
<p>Via the context menu it is also possible to open multiple visualization views.</p>
<p>On selecting a model element, the view will render a corresponding visualization. If multiple visualizations are available, the first one will be selected by default, unless the user has selected another visualization before.</p>
<p>The visualization view has 3 buttons in the toolbar:</p>
<ol>
<li>
<b>Visualization dropdown</b><br>The dropdown contains all available visualizations for the current active selection. A click on the image will reload the visualization.
</li>
<li>
<b>Pin visualization</b><br>The selection handling will be disabled so the visualization gets not updated on model selection changes.
</li>
<li>
<b>Select model element</b><br>Selects the current visualized model element in the model editor. Useful for example if a visualization is pinned and the selection in the model editor changed.
</li>
</ol>
<p>
<img src="images/visualization-view.png"/>
</p>
<h3><a id="section2.6.2">2.6.2 </a>Standard Visualizations</h3>
<p>APP4MC comes with a set of default model visualizations to show the options and possibilities the visualization framework provides.</p>
<h4><a id="section2.6.2.1"></a>Hardware Model</h4>
<ul>
<li>
<ins>HW Model Block Diagram</ins><br><br>This visualization is intended to provide an overview of the described and used hardware within the system.<br><br>It uses PlantUML and SVG for rendering. Therefore a Graphviz dot.exe needs to be configured via
<i>Window – Preferences – PlantUML – Path to the dot executable of Graphviz</i> in order to get the result shown.<br><br>
<img src="images/hwmodel_hwblockdiagram.png"/>
</li>
</ul>
<h4><a id="section2.6.2.2"></a>Software Model</h4>
<ul>
<li>
<ins>SWModel Statistics Visualization</ins><br><br>This is a simple visualization that shows some statistics on the selected Software Model. It is also a simple example to show how to implement a visualization with JavaFX and some animations.<br><br>
<img src="images/swmodel_statistics.png"/><br><br>
</li>
</ul>
<ul>
<li>
<ins>Shared Runnable Label Dependencies</ins><br><br>This visualization paints all
<i>Runnables</i> and the read/write dependencies on
<i>Labels</i> in a Software Model.<br>Via the buttons on the left edge you can
<i>Zoom in (+) / Zoom out (-) / Filter (F)</i> the currently visible
<i>Runnables</i>.<br><br>
<img src="images/swmodel_label_dependencies.png"/>
</li>
</ul>
<h4><a id="section2.6.2.3"></a>Runnable</h4>
<ul>
<li>
<ins>LabelAccess View</ins><br><br>A simple visualization of a
<i>Runnable</i> and its
<i>Label</i> read/write access. On the left side the
<i>Labels</i> are rendered that are accessed for a read operation. On the right side the
<i>Labels</i> are rendered that are accessed for a write operation.<br><br>
<img src="images/runnable_labelaccess.png"/><br><br>
</li>
</ul>
<ul>
<li>
<ins>Shared Runnable Label Dependencies</ins><br><br>Visualization of all selected
<i>Runnables</i> and their relationships based on
<i>Labels</i>. This visualization is an example to verify how to implement a visualization on multi-selection.<br>Via the buttons on the left edge you can
<i>Zoom in (+) / Zoom out (-) / Filter (F)</i> the currently visible
<i>Runnables</i>.<br><br>
<img src="images/runnable_sharedlabels.png"/><br><br>
</li>
</ul>
<ul>
<li>
<ins>Runnable Label Dependencies</ins><br><br>This visualization shows the current selected
<i>Runnable</i> and the
<i>Runnables</i> that have a direct dependency via
<i>Labels</i>. On the left side the
<i>Runnables</i> are rendered that
<ins>write</ins> to
<i>Labels</i> that are read by the selected
<i>Runnable</i>. On the right side the
<i>Runnables</i> are rendered that
<ins>read</ins> from
<i>Labels</i> that were modified by the selected
<i>Runnable</i>.<br>Via the buttons on the left edge you can
<i>Zoom in (+) / Zoom out (-)</i> the currently visible
<i>Runnables</i>.<br><br>
<img class="scale" src="images/runnable_labeldependencies.png"/>
</li>
</ul>
<h4><a id="section2.6.2.4"></a>Deviation</h4>
<ul>
<li>
<ins>Probability Density Diagram</ins><br><br>This visualization provides probability density diagrams for all subclasses of<br> - IContinuousValueDeviation<br> - IDiscreteValueDeviation<br> - ITimeDeviation<br><br>Markers (vertical lines) are shown for lower bound, upper bound and average.<br><br>Changed values in the Properties view lead to an update of the diagram.<br><br>
<img src="images/deviation_boundaries.png"/>
<img src="images/deviation_statistics.png"/>
<img src="images/deviation_histogram.png"/>
<img src="images/deviation_gauss.png"/>
<img src="images/deviation_beta.png"/>
<img src="images/deviation_weibull.png"/>
</li>
</ul>
<h2><a id="section2.7">2.7 </a>Model Validation</h2>
<h3><a id="section2.7.1">2.7.1 </a>Usage of AMALTHEA Model Validation</h3>
<p>The AMALTHEA model validation can be triggered by clicking on the "Validate" button of the Amalthea editor.</p>
<p>All elements of the model are included for validation. In the next window the list of profiles appears allowing the selection of specific validations.</p>
<p>
<img src="images/profile_selection_dialog.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. The validation distinguishes between three error types:
<i>errors</i>,
<i>warnings</i> and
<i>info</i>.
</p>
<h3><a id="section2.7.2">2.7.2 </a>Included Validations</h3>
<h4><a id="section2.7.2.1"></a>Amalthea Standard Validations</h4>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile</code><br>
<br>
<b>Amalthea Standard Validations</b>
<br>
<i>Standard validations for AMALTHEA models to ensure data consistency.</i>
</p>
<ul>
<li>Profiles:
<ul>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.BasicProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.ConstraintsProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.EMFProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.EMFScopeProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.HardwareProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.MappingProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.SoftwareProfile</code>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.BasicProfile</code><br>
<br>
<b>Basic Validations</b>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-Basic-CustomProperty-Key (WARNING – IAnnotatable)
<ul>
<li>Custom property keys have to be unique</li>
</ul>
</li>
<li>AM-Basic-Quantity (ERROR – Quantity)
<ul>
<li>Quantity unit has to be set (
<em>undefined</em> is an error)
</li>
</ul>
</li>
<li>AM-Basic-Frequency (ERROR – Frequency)
<ul>
<li>Some frequencies have to fulfill the condition &gt;0</li>
</ul>
</li>
<li>AM-Basic-Counter (ERROR – Counter)
<ul>
<li>The offset value of a counter must not be negative</li>
</ul>
</li>
<li>AM-Basic-Time-Range (ERROR – Time)
<ul>
<li>Some time ranges has to fulfill the condition &gt;0 or &gt;=0</li>
</ul>
</li>
<li>AM-Basic-Data-Size (ERROR – DataSize)
<ul>
<li>Some data sizes have to fulfill the condition &gt;0 or &gt;=0</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.ConstraintsProfile</code><br>
<br>
<b>Constraints Validations</b>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-Constraints-EventChain (ERROR – AbstractEventChain)
<ul>
<li>Stimulus and response shall not reference the same event</li>
<li>The stimulus of the first segment has to be the same as the stimulus of the event chain</li>
<li>The stimulus of other segments have to be equal to the response of the previous segment</li>
<li>The response of the last segment has to be the same as the response of the event chain</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.EMFProfile</code><br>
<br>
<b>Amalthea EMF Validations</b>
<br>
<i>Standard EMF validations for AMALTHEA models (generated).</i>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-EMF-INTRINSIC (UNDEFINED – EObject)
<ul>
<li>EMF extended metadata constraints (generated)</li>
<li>AMALTHEA invariants (generated)</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.EMFScopeProfile</code><br>
<br>
<b>Amalthea Scope Validations</b>
<br>
<i>Validations to ensure unique names in folder scope.</i>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-EMF-SCOPE (ERROR – Amalthea)
<ul>
<li>ID has to be unique in folder scope</li>
<li>ID has to be set for objects of type IReferable</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.HardwareProfile</code><br>
<br>
<b>Hardware Validations</b>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-HW-Port-BitWidth (WARNING – HwPort)
<ul>
<li>Bitwidth should be greater than zero</li>
</ul>
</li>
<li>AM-HW-Connection (ERROR – HwConnection)
<ul>
<li>HwConnections must refer to two HwPorts</li>
<li>HwConnections must be linked to HwPorts of the same Interface</li>
</ul>
</li>
<li>AM-HW-Structure (ERROR – HwStructure)
<ul>
<li>Connections must only refer to contained HwPorts</li>
<li>Inner connections always need one Initiator and one Responder HwPort</li>
<li>Delegated connections always connect HwPorts of the same type</li>
</ul>
</li>
<li>AM-HW-Module-Definition (WARNING – HwModule)
<ul>
<li>Memory definition must be set</li>
<li>ProcessingUnit definition must be set</li>
<li>ConnectionHandler definition must be set</li>
<li>Cache definition must be set</li>
</ul>
</li>
<li>AM-HW-Port-Definition (WARNING – HwPort)
<ul>
<li>PortType must be set</li>
<li>PortInterface must be set</li>
</ul>
</li>
<li>AM-HW-AccessPath (ERROR – HwAccessPath)
<ul>
<li>HwAccessPath ranges and memory size must be consistent</li>
<li>HwAccessPath elements must be consistent</li>
</ul>
</li>
<li>AM-HW-Port (ERROR – HwPort)
<ul>
<li>A HwPort can only have one (non internal) HwConnection</li>
</ul>
</li>
<li>AM-HW-Definition (ERROR – HwDefinition)
<ul>
<li>Only one feature of a category can be referred</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.MappingProfile</code><br>
<br>
<b>Mapping Validations</b>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-Mapping-Task-Scheduler (WARNING – Task)
<ul>
<li>A task should have an allocation to a task scheduler</li>
</ul>
</li>
<li>AM-Mapping-Scheduler-ProcessingUnit (WARNING – Scheduler)
<ul>
<li>A scheduler should be responsible for at least one processing unit</li>
</ul>
</li>
<li>AM-Mapping-ISR-Scheduler (WARNING – ISR)
<ul>
<li>An ISR should have an allocation to an interrupt controller</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.standard.SoftwareProfile</code><br>
<br>
<b>Software Validations</b>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-SW-DataDependency (ERROR – DataDependency)
<ul>
<li>A data dependency can only be defined for specific types of label accesses, parameters and call arguments</li>
<li>A data dependency can only refer to specific types of parameters and call arguments</li>
</ul>
</li>
<li>AM-SW-CallArgument (ERROR – CallArgument)
<ul>
<li>The referred runnable must contain the referred parameter</li>
</ul>
</li>
</ul>
</li>
</ul>
<h4><a id="section2.7.2.2"></a>Timing Architects Validations</h4>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.ta.TimingArchitectsProfile</code><br>
<br>
<b>Timing Architects Validations</b>
<br>
<i>Validations for AMALTHEA models used in a Timing Architects Simulation.</i>
</p>
<ul>
<li>Validations:
<ul>
<li>TA-Misc-Semaphore (ERROR – Semaphore)
<ul>
<li>Initial value must not be negative</li>
<li>Max value must be positive</li>
<li>Max value must not be smaller than the initial value</li>
</ul>
</li>
</ul>
</li>
<li>Profiles:
<ul>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.ta.TABasicProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.ta.TAConstraintsProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.ta.TAHardwareProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.ta.TASoftwareProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.ta.TAStimuliProfile</code>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.ta.TABasicProfile</code><br>
<br>
<b>Basic Validations (Timing Architects)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>TA-Basic-DiscreteValueGaussDistribution-mean (ERROR – DiscreteValueGaussDistribution)
<ul>
<li>Mean must not be less than the lower bound</li>
<li>Mean must not be greater than the upper bound</li>
</ul>
</li>
<li>TA-Basic-ContinuousValueGaussDistribution-mean (ERROR – ContinuousValueGaussDistribution)
<ul>
<li>Mean must not be less than the lower bound</li>
<li>Mean must not be greater than the upper bound</li>
</ul>
</li>
<li>TA-Basic-TimeGaussDistribution-mean (ERROR – TimeGaussDistribution)
<ul>
<li>Mean must not be less than the lower bound</li>
<li>Mean must not be greater than the upper bound</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.ta.TAConstraintsProfile</code><br>
<br>
<b>Constraints Validations (Timing Architects)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>TA-Constraints-DataAgeTime (ERROR – DataAgeTime)
<ul>
<li>Maximum time must not be smaller than minimum time</li>
</ul>
</li>
<li>TA-Constraints-EDFTaskMustHaveDeadline (ERROR – Task)
<ul>
<li>EDF tasks must have a deadline requirement</li>
</ul>
</li>
<li>TA-Constraints-RepetitionConstraint (ERROR – RepetitionConstraint)
<ul>
<li>Upper bound must not be smaller than lower bound</li>
</ul>
</li>
<li>TA-Constraints-DelayConstraint (ERROR – DelayConstraint)
<ul>
<li>Upper bound must not be smaller than lower bound</li>
</ul>
</li>
<li>TA-Constraints-RTLimitMustBePositive (ERROR – TimeRequirementLimit)
<ul>
<li>Response time must be positive</li>
</ul>
</li>
<li>TA-Constraints-ECLConstraint (ERROR – EventChainLatencyConstraint)
<ul>
<li>Maximum must not be smaller than minimum</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.ta.TAHardwareProfile</code><br>
<br>
<b>Hardware Validations (Timing Architects)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>TA-Hardware-HWFIPCMustBePositive (ERROR – HwFeature)
<ul>
<li>IPC (instructions per cycle) must be positive</li>
</ul>
</li>
<li>TA-Hardware-PUDIPCMissing (INFO – ProcessingUnitDefinition)
<ul>
<li>IPC (instructions per cycle) should be set, otherwise default (1.0) will be assumed</li>
<li>Only one IPC HwFeature should be specified for a processing unit definition</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.ta.TASoftwareProfile</code><br>
<br>
<b>Software Validations (Timing Architects)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>TA-Software-ModeConditionDisjunctionAlwaysTrue (WARNING – ModeConditionDisjunction)</li>
<li>TA-Stimuli-ArrivalCurveStimulus (ERROR – OsEvent)</li>
<li>TA-Software-RunnableCall (ERROR – RunnableCall)</li>
<li>TA-Software-ModeConditionConjunctionAlwaysFalse (WARNING – ModeConditionConjunction)</li>
<li>TA-Software-ServerCall (ERROR – ServerCall)</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.ta.TAStimuliProfile</code><br>
<br>
<b>Stimuli Validations (Timing Architects)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>TA-Stimuli-VariableRateStimulusScenario (ERROR – VariableRateStimulus)
<ul>
<li>Scenario must be set</li>
</ul>
</li>
</ul>
</li>
</ul>
<h4><a id="section2.7.2.3"></a>Inchron Validations</h4>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronProfile</code><br>
<br>
<b>Inchron Validations</b>
<br>
<i>Validation for Amalthea models used in Inchron Toolsuite</i>
</p>
<ul>
<li>Profiles:
<ul>
<li>
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronConstraintsProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronHWProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronOsProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronSoftwareProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronStimuliProfile</code>
</li>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.AmaltheaProfile</code>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronConstraintsProfile</code><br>
<br>
<b>Constraints Validations (INCHRON)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>Inchron-Constraints-LoadRequirementMissingResource (ERROR – CPUPercentageRequirementLimit)
<ul>
<li>CPU load requirement must have hardware context</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronHWProfile</code><br>
<br>
<b>Hardware Validations (INCHRON)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>AM-HW-Port-BitWidth (ERROR – HwPort)
<ul>
<li>Bitwidth should be greater than zero</li>
</ul>
</li>
<li>Inchron-HWModule-InconsistentPortWidths (ERROR – HwModule)
<ul>
<li>HW Module cannot have ports with unequal bitwidth</li>
</ul>
</li>
<li>Inchron-HW-Memory-PortTypeResponder (ERROR – Memory)
<ul>
<li>HW ports of memory should be of type responder</li>
</ul>
</li>
<li>Inchron-HW-PU-PortTypeInitiator (ERROR – ProcessingUnit)
<ul>
<li>HW ports of processing Unit should be of type initiator</li>
</ul>
</li>
<li>Inchron-HWModule-MissingClockReference (ERROR – HwModule)
<ul>
<li>HW Module must have 'Frequency Domain' reference</li>
</ul>
</li>
</ul>
</li>
<li>Profiles:
<ul>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.HardwareProfile</code>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronOsProfile</code><br>
<br>
<b>Operating Systems Validations (INCHRON)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>Inchron-OS-Scheduler-Allocation-DifferentCPU (ERROR – Scheduler)
<ul>
<li>OS Task scheduler should not be allocated to more than one HwStructure</li>
</ul>
</li>
<li>Inchron-Os-PU-Allocation-MustBeDisjunct (ERROR – OperatingSystem)
<ul>
<li>OS Scheduler to core mapping must be distinct</li>
</ul>
</li>
<li>Inchron-Os-UserSpecificSchedulerCheck (ERROR – UserSpecificSchedulingAlgorithm)
<ul>
<li>User specific task scheduler needs at least one task allocation</li>
</ul>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronSoftwareProfile</code><br>
<br>
<b>Software Validations (INCHRON)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>Inchron-SW-Task-EnforcedMigrationCheck (ERROR – Task)
<ul>
<li>Invalid Enforced Migration of a task to a task Scheduler</li>
</ul>
</li>
<li>Inchron-SW-Task-NotAllocated-DifferentSchedulers (ERROR – Task)
<ul>
<li>Task cannot be scheduled by more than one OS</li>
</ul>
</li>
<li>Inchron-SW-Runnable-MustHaveActivityGraph (ERROR – Runnable)
<ul>
<li>Runnable must have at least one ActivityGraph</li>
</ul>
</li>
<li>Inchron-SW-RunnableAllocation-Present (ERROR – RunnableAllocation)
<ul>
<li>Runnable allocation is not supported</li>
</ul>
</li>
<li>Inchron-SW-Runnable-NotAllocated-DifferentOS (ERROR – Runnable)
<ul>
<li>Runnable cannot be scheduled by more than one OS</li>
</ul>
</li>
<li>Inchron-SW-Task-MustHaveActivityGraph (ERROR – Task)
<ul>
<li>Task must have atleast one ActivityGraph</li>
</ul>
</li>
</ul>
</li>
<li>Profiles:
<ul>
<li>
<code>org.eclipse.app4mc.amalthea.validations.standard.SoftwareProfile</code>
</li>
</ul>
</li>
</ul>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<code>org.eclipse.app4mc.amalthea.validations.inchron.InchronStimuliProfile</code><br>
<br>
<b>Stimuli Validations (INCHRON)</b>
</p>
<ul>
<li>Validations:
<ul>
<li>Inchron-Stimuli-TypeCheck (ERROR – Stimulus)
<ul>
<li>Unsupported stimuli types</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2><a id="section2.8">2.8 </a>Model Migration</h2>
<h3><a id="section2.8.1">2.8.1 </a>AMALTHEA Model Migration</h3>
<h4><a id="section2.8.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 meta model, 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.8.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 APP4MC releases 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>
<p style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<em>
<span style="color:brown">
<b>Warning:</b><br>Migration of Amalthea models belonging to legacy versions (ITEA "1.0.3, 1.1.0, 1.1.1") is no longer supported.
</span>
</em>
<br>If there are Amalthea models belonging to legacy versions, use APP4MC version 0.9.2 (or older) and convert the models into a APP4MC model version. These models can still be used as input for model migration.
</p>
<h3><a id="section2.8.2">2.8.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 meta model versions information</b>
</p>
<ul>
<li>Oldest version to migrate is
<b>APP4MC 0.7.0</b><br><br>Beginning with that version, the AMALTHEA meta model is a part of the official Eclipse project
<a href="https://www.eclipse.org/app4mc/">APP4MC</a>.
</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 style="padding: 10px; background: #fafafa; border: 1px solid #888; border-radius: 5px">
<em>
<span style="color:brown">
<b>Hint for APP4MC 0.9.3 and newer:</b><br>Migration of Amalthea models belonging to legacy versions (ITEA "1.0.3, 1.1.0, 1.1.1") is no longer supported.
</span>
</em>
</p>
<p>Below figure represents the steps involved in the migration of model from 0.7.0 version to APP4MC 0.8.1 version:</p>
<p>
<img class="scale" src="images/migration_flow.png"/>
</p>
<h3><a id="section2.8.3">2.8.3 </a>Pre-requisites for AMALTHEA model migration</h3>
<h4 id="migration-vm-args"><a id="section2.8.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 &lt;application_name&gt;.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-linked-files"><a id="section2.8.3.2"></a>Linked files in eclipse project (virtual files)</h4>
<p>In case you want to have linked files in eclipse project, during the drag and drop of the files select
<strong>"Link to files"</strong> option in
<em>
<strong>File Operation</strong>
</em> dialog and uncheck
<em>
<strong>create link locations relative to</strong>
</em> option
</p>
<img class="gray_scale" src="images/linked_files_creation.png"/>
<h3><a id="section2.8.4">2.8.4 </a>How to invoke AMALTHEA model migration</h3>
<h4><a id="section2.8.4.1"></a>Simple migration</h4>
<p>An attempt to open an older model file in the model editor will show the following dialog.</p>
<p>
<img src="images/file-open-dialog.png"/>
</p>
<p>The default button will simply migrate the selected file ...</p>
<ul>
<li>provided it doesn't have any references (only allowing single file migration)</li>
<li>the original file is renamed (the version string is added, e.g. "model_0.9.2.amxmi")</li>
<li>a log file with the current date is created (e.g. "ModelMigration__2019-07-30_15_43_44.log")</li>
</ul>
<h4><a id="section2.8.4.2"></a>Migration dialog</h4>
<p>AMALTHEA model migration utility is developed as a eclipse plugin and it is part of APP4MC distribution</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>
<p>
<b>Step 1:</b> Selection of AMALTHEA models
</p>
<blockquote>
<p>Possible selections are:
<br>- a single .amxmi file
<br>- a folder that contains at least one .amxmi file
<br>- a project that contains at least one .amxmi file
</p>
</blockquote>
<p>
<strong>Step 2:</strong> Opening AMALTHEA Model Migration dialog and configuring migration inputs
</p>
<p>On click of AMALTHEA Model Migration action, the following Model Migration dialog is opened:</p>
<p>
<img class="gray_scale" src="images/migration-menu-dialog.png"/>
</p>
<p>Model Migration dialog consists of following information:</p>
<ol>
<li>Selected AMALTHEA model files: These are the models which are included in the selection<br>
<strong>
<em>Note:</em>
</strong> The check box "recursive" allows to include the contents of subfolders
</li>
<li>Input model versions are displayed in the second column of the table<br>
<strong>
<em>Note:</em>
</strong> In case of different AMALTHEA model versions in one folder, a warning will be shown.
</li>
<li>Output model version : This is the AMALTHEA model version to which the selected models files should be migrated to</li>
<li>If the check box "Create backup file" is checked then a backup file with the same name suffix as in "Simple migration" is created before the migration. Otherwise the migration will be executed in place.</li>
</ol>
<p>
<strong>Step 3:</strong> Model migration
</p>
<blockquote>
<p>Once the required parameters are configured in the model migration dialog, click on "Migrate Models" button in the dialog to invoke migration.</p>
</blockquote>
<p>The result of the migration will be shown in a new dialog:</p>
<p>
<img class="gray_scale" src="images/migration-result.png"/>
</p>
<p>Additionally a log file with the current date is created next to the migrated files (e.g. "ModelMigration__2019-07-30_15_43_44.log").</p>
<h3><a id="section2.8.5">2.8.5 </a>Additional details</h3>
<p>For details regarding the below topics, refer to the corresponding links:</p>
<ol>
<li>
<a href="#meta-model-changes">How model elements are migrated across various versions ?</a>
</li>
<li>
<a href="#migration-vm-args">How to update max heap memory used by the application ?</a>
</li>
</ol>
<h2><a id="section2.9">2.9 </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="section2.9.1">2.9.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 should right click 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 (e.g. using the
<i>EASE</i> script technology) 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="section2.9.2">2.9.2 </a>Pre-Partitioning</h3>
<p>In order to perform the actual partitioning based on <i>DAWG</i>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="section2.9.2.1"></a>Label Access Analysis</h4>
<p>The label access analysis comprises the comparison of
<i>read</i> and
<i>write</i> 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="section2.9.2.2"></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</i>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
<i>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>
<h4><a id="section2.9.2.3"></a>Activation Partitioning</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="section2.9.2.4"></a>Independent Graph Partitioning</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="section2.9.2.5"></a>Tag Partitioning</h4>
<p>Tags can be used to group runnables similar to the
<i>Activation Partitioning</i> approach. A typical use case of tags are software components. This mechanism provides the user with any type of grouping in order to keep related runnables within the same partition respectively task.
</p>
<h4><a id="section2.9.2.6"></a>ASIL-level Partitioning</h4>
<p>
<code>ASIL-levels</code> and
<code>Tags</code> (e.g., for software components) are equally considered such that separate groups are formed prior to the partitioning process, which always splits the most instructions consuming partition first. Consequently, generated partitions are aligned regarding their instruction sums as much as possible. In other words, all runnables referencing the same tag are grouped into a partition that may be split further if the sum of all runnables contained in this group is higher than other the instruction sums at other partitions. An important aspect of this mechanism is its influence of the overall software distribution. In order to keep the amount of generated
<code>AccessPrecedencs</code> (i.e., a dissolution of a direct cause and effect relation of two runnables) low, i.e., to keep the program's causality at a high level, existing groups can me merged with other groups or partitions.
</p>
<h4><a id="section2.9.2.7"></a>Consideration of Runnable Pairing Constraints</h4>
<p>The folowing figure outlines the consideration of
<code>RunnablePairingConstraints</code> via runnable cumulation.
<br>
<img class="scale" src="images/pairing_small.png"/>
<br>Any
<code>RunnablePairingConstraints</code> merges the corresponding runnables for the subsequent graph algorithms (cumulation) and decomposes (reconstruction) to the original structure after partitions have been formed. Consequently, causality, i.e., the runnable pairing positions and sequences within the partitions are considered.
</p>
<h3><a id="section2.9.3">2.9.3 </a>Partitioning Algorithms</h3>
<p>Each of the algorithms described in the following creates ProcessPrototypes i.e. task precursor. </p>
<h4><a id="section2.9.3.1"></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 <i>DAWG</i>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
<i>CPP</i> example is shown in the following figure (left = input graph; right = partitioning result):
</p>
<p>
<img class="scale" src="images/cpp_small.png"/>
</p>
<h4><a id="section2.9.3.2"></a>Earliest Start Schedule Partitioning (ESSP)</h4>
<p>The
<i>ESSP</i> partitioning is developed for allowing the user to restrict the number of partitioning. 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 assigns a runnable to the current partition that minimizes the schedule length.
</p>
<h3><a id="section2.9.4">2.9.4 </a>Further Features</h3>
<p>Two further features provide graph visualizations and a different graph representation through
<code>RunnableSequencingConstraints</code>.
</p>
<h4><a id="section2.9.4.1"></a>Applet Generation</h4>
<p>The applet generation can be triggered with a different command in the context menu via right-clicking on an
<i>.amxmi</i> file. In case the file contains a software model with runnables and a constraints model with
<code>RunnableSequencingConstraints</code>, 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="section2.9.4.2"></a>Dependency Alternative</h4>
<p>This file 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
<code>RunnableGroups</code> with each one
<code>RunnableGroupEntry</code> entity within a
<code>RunnableSequencingConstraint</code>. The approach can be adapted to feature more
<code>RunnableGroups</code> and more
<code>RunnableGroupEntries</code> and a less amount of
<code>RunnableSequencingConstraints</code>, 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="section2.9.5">2.9.5 </a>Partitioning Examples</h3>
<p>The following sections present some basic examples to illustrate the different
<i>CPP</i> and
<i>ESSP</i> results and further to provide an easy starting point for developers performing mutliple partitioning steps across mutlplie models via just a single start of an
<i>EASE</i> script.
</p>
<h4><a id="section2.9.5.1"></a>Algorithm Comparison</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) -
<code>CPP</code>, (middle) -
<code>ESSP</code> configured with 2 partitions and (bottom) -
<code>ESSP</code> for 3 partitions.
</p>
<p>
<img class="scale" src="images/partexample.png"/>
</p>
<h4><a id="section2.9.5.2"></a>Workflow Example</h4>
<p>The above described features can also be triggered via a workflow exemplarily shown in the following code (
<i>EASE</i> script):
</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="section2.9.6">2.9.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="section2.10">2.10 </a>Model Loading (Amalthea "no-load" nature)</h2>
<p>Use case for having "Amalthea no-load nature" is to avoid loading of Amalthea models present inside a project in certain cases like: </p>
<ul>
<li>File operations in workspace
<em>(rename of folders or rename of model files)</em>
</li>
<li>User is not working on Amalthea models </li>
<li>Also in the software build environments, where Amalthea models should be explicitly loaded instead of automatically getting loaded </li>
</ul>
<h3><a id="section2.10.1">2.10.1 </a>How to add Amalthea "no-load" nature to the project?*</h3>
<p>Nature can be added by following the steps shown in the below screenshot</p>
<p>
<img src="images/no-load-nature-add.png"/>
</p>
<blockquote>
<p>By adding this nature, Amalthea model loader will be de-activated and Amalthea model editor can not be opened in this case</p>
</blockquote>
<h3><a id="section2.10.2">2.10.2 </a>How to identify if Amalthea "no-load" nature is added to the project?*</h3>
<p>If Amalthea "no-load" nature is added to the project, in the Model Explorer,there is a decorator icon and a suffix is added to the project as shown below:</p>
<p>
<img src="images/no-load-nature-active.png"/>
</p>
<h3><a id="section2.10.3">2.10.3 </a>If Amalthea "no-load" nature is added, can I still load Amalthea model files using a java program explicitly?*</h3>
<p>Yes !!</p>
<p>By adding Amalthea "no-load" nature, only automatic model loading is disabled as a part of eclipse workspace build, user can explicitly load Amalthea model by using API's </p>
<h3><a id="section2.10.4">2.10.4 </a>How to remove Amalthea "no-load" nature from the project?*</h3>
<p>One can explicitly remove the nature by following the steps as shown in the below screenshot</p>
<p>
<img src="images/no-load-nature-remove_1.png"/>
</p>
<p>
<strong>Other option:</strong> If the user tries to open a Amalthea model file, a dialog box opens up as shown below and from here as well user can remove the Amalthea "no-load" nature from the project
</p>
<p>
<img src="images/no-load-nature-remove_2.png"/>
</p>
</article>
<article>
<h1><a id="section3">3 </a>Data Models</h1>
<h2><a id="section3.1">3.1 </a>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 ticks wherever possible 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>Model Basics</h2>
<p>The following classes are used all over the Amalthea model to define specific attributes of the model classes.</p>
<h3 id="basics-custom-props"><a id="section3.2.1">3.2.1 </a>Custom Properties</h3>
<p>The
<i>CustomProperty</i> element is used to define own properties that are not (yet) available in AMALTHEA. 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. It also provides the possibility to work with prototypical approaches that later (if established and more stable) can be integrated in the standard model.
</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.2">3.2.2 </a>Time (and Time Unit)</h3>
<p>The AMALTHEA data model includes a common element to describe time ranges in an easy way, the
<i>Time</i> element. The
<i>Time</i> class in general allows to define negative time values. If only positive values are expected the AMALTHEA validation will show a warning.
<br>The
<i>Time</i> element can be contained 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.3">3.2.3 </a>Frequency (and Frequency Unit)</h3>
<p>
<img class="scale" src="images/model_common_frequency.png"/>
</p>
<h3><a id="section3.2.4">3.2.4 </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.5">3.2.5 </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.6">3.2.6 </a>Deviation</h3>
<p>Deviations used to model constant values, histograms and statistical distributions within AMALTHEA. There is a wide variety of possible use cases, where such a distribution is needed. For example, the variation in runtime of functions can be imitated. Therefore, AMALTHEA currently supports the following statistical distributions:</p>
<p>
<img class="scale" src="images/model_common_deviations_abstract.png"/>
</p>
<p>The earlier implementation used Generics to support the different use cases. To simplify the usage (via Java API and in the editor) the new implementation provides three different top level interfaces for
<strong>Time Deviation</strong>,
<strong>Discrete Value Deviation</strong> (integer values) and
<strong>Continuous Value Deviation</strong> (float values). They provide specialized methods to handle their values and a common interface to access minimum, maximum and average.
<br>The following image shows the detailed hierarchy of time deviations, the other implementations are built accordingly.
</p>
<p>
<img class="scale" src="images/model_common_deviations_time.png"/>
</p>
<h4><a id="section3.2.6.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>CornerCase</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.6.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.6.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.6.4"></a>Beta Distribution</h4>
<p>The Beta distribution is a statistical distribution whose shape is defined by alpha &gt; 0 and beta &gt; 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.6.5"></a>Weibull Distribution</h4>
<p>The Weibull distribution is a statistical distribution whose shape is mathematically defined by kappa &gt; 0 and the scale of the distribution by lambda &gt; 0. In the model, it is parameterized using the mean value, the lower and upper bound, and the probability that a real-valued random variable of that distribution will not take a value less than or equal to a specific value. To calculate the scale and shape parameter for the Weibull distribution from the model parameters, the equation of the mean (see
<a href="https://en.wikipedia.org/wiki/Weibull_distribution)">Weibull distribution – Wikipedia</a> is solved for the scale parameter, first. Then, the resulting equation for lambda is plugged into the equation of the cumulative distribution function (CDF) for the Weibull distribution. Finally, the lower and upper bound allow to shift this function and the remaining unknown shape parameter in the equation is numerically approximated until the value of the parameter that constraints the distribution regarding the per mill of remaining values is reached.
</p>
<p>
<img src="images/model_common_deviation_weibull.png"/>
</p>
<h4><a id="section3.2.6.6"></a>Histogram</h4>
<p>A histogram represents a distribution containing a limited number of entries (e.g. extracted from a trace). Each entry thereby is an
<i>Interval</i> with the extra attribute
<i>occurrences</i> which holds the number instances within the interval. The intervals do not have to cover a continuous range nor do they need to have the same interval size. Histograms are useful if there is a limited number of possibilities of valuations, which covers most practical systems. See the following figure for an example of two runnables having a time histogram deviation of their execution times.
</p>
<p>
<img src="images/model_common_deviation_time_histogram.png"/>
</p>
<h3><a id="section3.2.7">3.2.7 </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 minimum and maximum values are set as a normal
<i>int</i> value, the average the single value as
<i>float</i>.
</p>
<p>
<img src="images/model_common_statistic.png"/>
</p>
<h3 id="basics-ticks"><a id="section3.2.8">3.2.8 </a>Ticks</h3>
<p>Ticks are used to express execution times in a basic way. The number of ticks characterizes the amount of computation that is necessary to execute e.g. a
<i>Runnable</i>. The corresponding execution time can be easily calculated if the frequency of the executing
<i>ProcessingUnit</i> (PU) is known.The corresponding execution time can be easily calculated if the frequency of the executing
<i>ProcessingUnit</i> (PU) is knownexecution time can be easily calculated if the frequency of the executing
<i>ProcessingUnit</i> (PU) is known. Depending on the capabilities of a PU the time to execute such an element will differ. If necessary the fundamentally different numbers for specific types of PUs can be stored as extended values in a map.
</p>
<p>In the next picture
<i>Ticks</i> are shown in more detail.
</p>
<p>
<img src="images/model_common_ticks.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>default</i>
</td>
<td colspan="1" rowspan="1">The default number of ticks. This value is used if (1) the executing PU is unknown or (2) no extended entry is available for the PU.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>extended</i>
</td>
<td colspan="1" rowspan="1">Possibility to store a PU-specific number of ticks.</td>
</tr>
</table>
<h3><a id="section3.2.9">3.2.9 </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>Activity graph 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>TerminateProcess</i>
</li>
<li>
<i>RunnableCall</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>Common Elements</h2>
<p>The
<i>CommonElements</i> model provides a central container for tags and classifiers. These elements are used in many sub models where references to
<i>Tags</i> or
<i>Classifiers</i> provide a mechanism to annotate objects.
</p>
<p>
<img src="images/model_common_elements.png"/>
</p>
<h3 id="common-tags"><a id="section3.3.1">3.3.1 </a>Tags</h3>
<p>Tags are a generic possibility to annotate objects in the AMALTHEA model.</p>
<p>
<img src="images/model_common_tag.png"/>
</p>
<h3 id="common-classifiers"><a id="section3.3.2">3.3.2 </a>Classifiers</h3>
<p>Classifiers are used to define specific features or abilities of a core or a memory. They are used in the
<i>PropertyConstraintsModel</i> to restrict the allocation to cores or the memory mapping.
</p>
<p>
<img src="images/model_common_classifier.png"/>
</p>
<h3 id="common-namespaces"><a id="section3.3.3">3.3.3 </a>Namespaces</h3>
<p>Some elements in the data model can refer to a
<i>Namespace</i>. A namespace provides a prefix to the name of the element.
</p>
<p>
<img src="images/model_common_elements_namespace_member.png"/>
</p>
<h2><a id="section3.4">3.4 </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>Components</strong> /
<strong>Composites</strong>
</li>
<li>
<strong>Systems</strong>
</li>
<li>
<strong>Interfaces</strong>
</li>
<li>
<strong>Structures</strong>
</li>
</ul>
<p>
<img class="scale" src="images/model_components.png"/>
</p>
<h3><a id="section3.4.1">3.4.1 </a>Component Interfaces</h3>
<p>
<img class="scale" src="images/model_components_interface.png"/>
</p>
<h3><a id="section3.4.2">3.4.2 </a>Architecture of Systems / Composites</h3>
<p>The inner architecture of a System or a Composite is defined with the ISystem interface. Both elements contain component instances and connectors. The ports of the instances and the containing architecture can be identified as QualifiedPort.</p>
<p>
<img class="scale" src="images/model_components_composition.png"/>
</p>
<h3><a id="section3.4.3">3.4.3 </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.4.3.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.4.3.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 architectures.
</p>
<p>System and Composite implement the interface 'ISystem'.
<br>The following diagram shows the main elements to represent the hierarchical architecture.
</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.4.3.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>
<p>
<img class="scale" src="images/model_components_connector.png"/>
</p>
<p>To specfiy the implementation details of a connection between ports it is possible to specify an interface/channel pair for each connector. This links additional information from the channel implementation like the access behavior to the connector. The connector can contain multiple interface/channel pairs since an interface can contain multiple sub-interfaces realized by multiple data types implemented by multiple channels.</p>
<h4><a id="section3.4.3.4"></a>QualifiedPort</h4>
<p>A 'qualified' port refers a 'ComponentInstance' and a 'ComponentPort'.
<br>If the 'instance' link is null then the QualifiedPort refers to a port of the enclosing composite.
</p>
<h4><a id="section3.4.3.5"></a>ComponentPort</h4>
<p>The 'ComponentPort' class contains the attribute 'kind' to set the port direction.
<br>The attribute 'interface name' can be used to refer to an external definition, e.g. described in detail with the Franca IDL.
</p>
<h4><a id="section3.4.3.6"></a>Structures</h4>
<p>Structures enables structuring/ordering of components, composites and interfaces. In contrasts to namespaces the structure does not add to the qualified name but supports the design of a hierarchical structure to order the elements in a package/folder like scheme.</p>
<h3><a id="section3.4.4">3.4.4 </a>Example</h3>
<h4><a id="section3.4.4.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.4.4.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>
<h2><a id="section3.5">3.5 </a>Configuration Model</h2>
<p>The purpose of the configuration model is to provide a common mechanism for configuration purposes. 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.5.1">3.5.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.5.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.6">3.6 </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.6.1">3.6.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 whether the value for the metric is an upper or a lower bound.
<br>Depending on the metric unit, the following Limits can be distinguished:
</p>
<ul>
<li>Count Requirement Limit for metrics that count system actions</li>
<li>CPU Percentage Requirement Limit for metrics that specify relative CPU characteristics</li>
<li>Frequency Requirement Limit for metrics that measure the frequency of system actions</li>
<li>Percentage Requirement Limit for metrics that specify relative system characteristics</li>
<li>Time Requirement Limit for metrics that describe time intervals</li>
</ul>
<p>
<img class="scale" src="images/model_constraints_requirements.png"/>
</p>
<p>Time Metric groups all metrics that describe time intervals of an individual process instance or between two succeeding process instances and are defined as follows:</p>
<ul>
<li>
<i>
<b>ActivateToActivate</b>
</i>: This metric indicates the distance between two successive activations of a task or isr. The
<i>ActivateToActivate</i> metric of process instance n quantifies the time between the activation moment of process instance n and that of instance n+1.<br>
<img src="images/model_constraints_metric_activatetoactivate.png"/>
</li>
<li>
<i>
<b>CoreExecutionTime</b>
</i>: This metric quantifies the amount of time of a process instance between its start and termination in which it is actively executed on a specific processing unit.
</li>
<li>
<i>
<b>EndToEnd</b>
</i>: This metric indicates the time interval between two successive ends of a process. The
<i>EndToEnd</i> metric of process instance n quantifies the time between the termination moment of process instance n and that of instance n+1.<br>
<img src="images/model_constraints_metric_endtoend.png"/>
</li>
<li>
<i>
<b>EndToStart</b>
</i>: This metric indicates the time interval between two successive process instances. The
<i>EndToStart</i> metric of process instance n quantifies the time between the termination moment of process instance n and the start moment of instance n+1.<br>
<img src="images/model_constraints_metric_endtostart.png"/>
</li>
<li>
<i>
<b>GrossExecutionTime</b>
</i>: This metric indicates the time interval between the start moment and the termination moment of a process instance.<br>
<img src="images/model_constraints_metric_grossexecutiontime.png"/>
</li>
<li>
<i>
<b>Lateness</b>
</i>: This metric indicates whether a process instance misses its deadline. It quantifies the amount of time between the termination moment of the process instance and its deadline. Thus, the resulting lateness is negative and indicates that no deadline miss occurred if the termination moment of the process instance is before the deadline and vice versa.<br>
<img src="images/model_constraints_metric_lateness.png"/>
</li>
<li>
<i>
<b>MemoryAccessTime</b>
</i>: This metric quantifies the amount of time that is required by a process for transferring data from or to the memory.
</li>
<li>
<i>
<b>NetExecutionTime</b>
</i>: The net execution time indicates the actual execution time of a process instance, i.e., the time it is occupying a processing unit. Thus, it quantifies the time from the start moment of a process instance to its termination moment excluding the time the process instance is interfered.<br>
<img src="images/model_constraints_metric_netexecutiontime.png"/>
</li>
<li>
<i>
<b>OsOverhead</b>
</i>: This metric indicates the amount of execution time that is consumed by functions that are part of the operating system.
</li>
<li>
<i>
<b>ParkingTime</b>
</i>: This metric quantifies the amount of time that a process instance spends between its start and termination passively waiting for the access of a resource.
</li>
<li>
<i>
<b>PollingTime</b>
</i>: This metric quantifies the amount of time that a process instance spends between its start and termination actively waiting for the access of a resource.<br>
<img src="images/model_constraints_metric_pollingtime.png"/>
</li>
<li>
<i>
<b>ReadyTime</b>
</i>: This metric quantifies the amount of time of a process instance between its start and termination in which it is not actively executed on any processing unit.<br>
<img src="images/model_constraints_metric_readytime.png"/>
</li>
<li>
<i>
<b>ResponseTime</b>
</i>: The response time of a task or ISR instance is defined as the time between the moment of its activation and its termination. Thus, it measures the whole life cycle of a process instance.<br>
<img src="images/model_constraints_metric_responsetime.png"/>
</li>
<li>
<i>
<b>RunningTime</b>
</i>: This metric quantifies the amount of time of a process instance between its start and termination in which it is actively executed on any processing unit.<br>
<img src="images/model_constraints_metric_runningtime.png"/>
</li>
<li>
<i>
<b>StartDelay</b>
</i>: This metric quantifies the delay of the start time of a process instance which is defined as the time interval between the activation moment of this process instance and its start moment.<br>
<img src="images/model_constraints_metric_startdelay.png"/>
</li>
<li>
<i>
<b>StartToStart</b>
</i>: This metric indicates the time interval between two successive starts of a process. The
<i>StartToStart</i> metric of process instance n quantifies the time between the start moment of process instance n and that of instance n+1.<br>
<img src="images/model_constraints_metric_starttostart.png"/>
</li>
<li>
<i>
<b>WaitingTime</b>
</i>: This metric quantifies the amount of time that a process instance spends between its start and termination passively waiting for an OS event.<br>
<img src="images/model_constraints_metric_waitingtime.png"/>
</li>
</ul>
<p>Count Metrics are metrics that describe absolutely how often system characteristics occur and are defined as follows:</p>
<ul>
<li>
<i>
<b>Activations</b>
</i>: This metric quantifies the number of times a process is activated.
</li>
<li>
<i>
<b>BoundedMigrations</b>
</i>: This metric quantifies the number of times a process instance starts executing on a processing unit that is different to the processing unit on which the previous process instance terminated.
</li>
<li>
<i>
<b>CacheHit</b>
</i>: This metric quantifies the amount of times that data requested by a process is found in the cache memory.
</li>
<li>
<i>
<b>CacheMiss</b>
</i>: This metric quantifies the amount of times that data requested by a process is not stored in the cache memory and has to be fetched from somewhere else.
</li>
<li>
<i>
<b>FullMigrations</b>
</i>: This metric quantifies the number of times a process instance migrates from one processing unit to another triggered by a schedule point.
</li>
<li>
<i>
<b>MtaLimitExceeding</b>
</i>: This metric quantifies the number of times a process is not activated during runtime because this would violate the maximum number of concurrently activated processes (MTA).
</li>
<li>
<i>
<b>Preemptions</b>
</i>: This metric quantifies the number of times a process is preempted by another task or ISR.
</li>
</ul>
<p>Frequency Metric groups all metrics that describe the rate in which system characteristics occur and are defined as follows:</p>
<ul>
<li>
<i>
<b>CacheHitFrequency</b>
</i>: This metric quantifies how often per unit of time data requested by a process is found in the cache memory.
</li>
<li>
<i>
<b>CacheMissFrequency</b>
</i>: This metric quantifies how often per unit of time data requested by a process is not found in the cache memory.
</li>
</ul>
<p>CPU Percentage Metric groups all metrics that describe a ratio between the amount of time a processing unit is in a certain state for a specific process and the maximum capacity of the considered processing unit and are defined as follows:</p>
<ul>
<li>
<i>
<b>CPUBuffering</b>
</i>: This metric quantifies the ratio between the amount of time a processing unit is in the state buffering for a specific process and the maximum capacity of the considered processing unit.
</li>
<li>
<i>
<b>CPULoad</b>
</i>: This metric quantifies the ratio of the load of a processing unit caused by a process and the maximum capacity of the considered processing unit.
</li>
<li>
<i>
<b>CPUParking</b>
</i>: This metric quantifies the ratio between the amount of time a processing unit is in the state parking for a specific process and the maximum capacity of the considered processing unit.
</li>
<li>
<i>
<b>CPUPolling</b>
</i>: This metric quantifies the ratio between the amount of time a processing unit is in the state polling for a specific process and the maximum capacity of the considered processing unit.
</li>
<li>
<i>
<b>CPUReady</b>
</i>: This metric quantifies the ratio between the amount of time a processing unit is in the state ready for a specific process and the maximum capacity of the considered processing unit.
</li>
<li>
<i>
<b>CPURunning</b>
</i>: This metric quantifies the ratio between the amount of time a processing unit is in the state running for a specific process and the maximum capacity of the considered processing unit.
</li>
<li>
<i>
<b>CPUWaiting</b>
</i>: This metric quantifies the ratio between the amount of time a processing unit is in the state waiting for a specific process and the maximum capacity of the considered processing unit.
</li>
</ul>
<p>Percentage Metric groups all metrics that describe a relationship between two system characteristics and are defined as follows: </p>
<ul>
<li>
<i>
<b>CacheHitRatio</b>
</i>: This metric quantifies how often data requested by a process is found in the cache memory in comparison to how often it is not found.
</li>
<li>
<i>
<b>CacheMissRatio</b>
</i>: This metric quantifies how often data requested by a process is not found in the cache memory in comparison to how often it is found.
</li>
<li>
<i>
<b>NormalizedLateness</b>
</i>: This metric quantifies the lateness of a process instance in comparison to the process's maximum response time which is defined by its deadline.
</li>
<li>
<i>
<b>NormalizedResponseTime</b>
</i>: This metric quantifies the response time of a process instance in comparison to the process's maximum response time which is defined by its deadline.
</li>
<li>
<i>
<b>OsOverheadRelative</b>
</i>: This metric quantifies the amount of execution time that is consumed by functions that are part of the operating system in comparison to net execution time of the process in whose context the functions are called.
</li>
</ul>
<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.6.2">3.6.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 that is not necessarily visible by other model parameters.</p>
<p>The following requirements can be specified with this constraint:</p>
<ul>
<li>Execution sequence of runnables A -&gt;B, meaning A has to be finished before B starts</li>
<li>Scope on certain process/processes, when a runnable is executed multiple times in different process contexts</li>
<li>Succession of runnables within a process (strict, loose)</li>
<li>Position of sequence within a process (start, end, any position)</li>
</ul>
<p>
<img src="images/model_constraints_runnable_sequencing.png"/>
</p>
<p>A
<i>RunnableSequencingConstraint</i> contains a list of
<i>ProcessRunnableGroup</i> elements and an enumeration
<i>RunnableOrderType</i> describing the basic rule for the sequencing. In general, a runnable sequencing constraint is independent of the processes that execute the runnables. Via the attribute "processScope" it is possible to define that a sequencing constraint is only valid for runnables within just one process or a set of processes.
</p>
<p>The
<i>ProcessRunnableGroups</i> contain references to runnables that should be sequenced. The sequence is defined by the order of the runnable groups within the sequencing constraint. The order of the runnable references within a group is undefined.
<br>To sequence two runnables it is consequently necessary to create a
<i>RunnableSequencingConstraint</i> with two
<i>ProcessRunnableGroups</i>, each referencing one of the runnables.
<br>To describe that a set of runnables have to be executed before or after another runnable or set of runnables, 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 following picture visualises a
<i>RunnableSequencingConstraint</i> and multiple possible runtime situations. The constraint has two runnable groups, each depicted by an ellipsis. In this example, there is just one runnable in each group. The runnables in the groups must be executed in the order of the group ("R1" before "R2"). There is no restriction in which process context 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. The exemplary runtime situations shown in the lower part of the figure visualise situations that satisfy this constraint (blue) and those who violate the constraint (red).
</p>
<p>
<img src="images/model_constraints_runnable_sequencing_basic.png"/>
</p>
<p>The
<i>RunnableSequencingConstraint</i> in the next figure has two processes set as a scope in its second group. That means that the runnable "R3" is allowed to be executed on the processes "P1" or "P3" (blue). But it is only expected to be executed one time in between (red)!
</p>
<p>
<img src="images/model_constraints_runnable_sequencing_scope.png"/>
</p>
<p>Each
<i>RunnableSequencingConstraint</i> has a
<i>RunnableOrderType</i>. It provides the following sequencing modes:
</p>
<ul>
<li>successor</li>
<li>immediateSuccessorAnySequence</li>
<li>immediateSuccessorEndSequence</li>
<li>immediateSuccessorStartSequence</li>
</ul>
<p>The meaning of the mode "successor" is that the runnable groups of a sequencing constraint do not have to follow each other directly, i.e., runnables that are not part of the constraint can be executed in between.
<br>In contrast to this, the modes starting with "immediateSuccessor" express that the runnables referenced by the runnable groups must execute in direct order, so without any runnable in between. With "StartSequence", "AnySequence" and "EndSequence" it is further constrained that the runnables of the constraint have to be executed at the beginning, at the end or at any position in a process.
<br>Assuming that all runnables are executed on the same process, the mode "immediateSuccessorStartSequence" means that all runnables of the constraint have to be executed in the correct order at the beginning of the process.
<br>The mode "immediateSuccessorEndSequence" is like "immediateSuccessorStartSequence", but here the runnable sequence must be executed at the end of the process.
</p>
<h3><a id="section3.6.3">3.6.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>
<ul class="validation-rule">
<li>DataAgeTime: The
<em>Time</em> object in the role of
<em>minimumTime</em> must not contain a negative value!
</li>
<li>DataAgeTime: The
<em>Time</em> object in the role of
<em>maximumTime</em> must not contain a negative value!
</li>
</ul>
<h3><a id="section3.6.4">3.6.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.6.5">3.6.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.6.6">3.6.6 </a>Event Chains</h3>
<p>The concept for event chains is based on the Timing Augmented Description Language. </p>
<p>
<img src="images/model_constraints_eventchain.png"/>
</p>
<p>The
<i class="Abstract">EventChain</i> consists of
<i>EventChainItems</i>. These items are classified in two types:
</p>
<ol>
<li>EventChainReferences -&gt; EventChain: Used to refer to already defined EvenChains.</li>
<li>EventChainContainers -&gt; SubEventChain: Inner anonymous EventChains, which are only available in the context of the current EventChain.</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>When adding
<i>EventChainItems</i> there are two properties that decide on the semantics of the SubEventChains:
</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>EventChainItemType</i>
</td>
<td colspan="1" rowspan="1">This property defines how to interpret the subEventChain. There exist two possibilities:
<i>sequence</i> and
<i>parallel</i>. Sequence means that all the subEventChains are evaluated in the defined order of the list. Parallel path can be alterantive paths or joins.
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>minItemsCompleted</i>
</td>
<td colspan="1" rowspan="1">Defines how the parallel execution is interpetated. The designer specifies how many elements of the subEventChains must be completed to go to the next step.
<i>1</i> represents alternative paths of the EventChain. If the number equals the number of elements in the
<i>EventChainItems</i> list all paths must be triggered to continue the event-chain tracking and represents a complete join of all subEventChains
</td>
</tr>
</table>
<p>
<strong>Simple structural example for sequence</strong>
</p>
<p>
<img src="images/model_constraints_eventchain_sequence.png" style="width: 750px"/>
</p>
<p>
<strong>Simple structural example for parallel paths</strong>
</p>
<p>
<img src="images/model_constraints_eventchain_parallel.png" style="width: 800px"/>
</p>
<p>
<strong>Structural example how to combine both</strong>
</p>
<p>
<img src="images/model_constraints_eventchain_example.png" style="width: 650px"/>
</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>sequence</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.6.7">3.6.7 </a>Timing Constraints</h3>
<h4><a id="section3.6.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>
<ul class="validation-rule">
<li>
<em>SynchronizationConstraint</em>: The
<em>Time</em> object in the role of
<em>tolerance</em> must not contain a negative value!
</li>
</ul>
<h4><a id="section3.6.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>
<ul class="validation-rule">
<li>
<em>RepetitionConstraint</em>: The
<em>Time</em> object in the role of
<em>lower</em> must not contain a negative value!
</li>
<li>
<em>RepetitionConstraint</em>: The
<em>Time</em> object in the role of
<em>upper</em> must not contain a negative value!
</li>
<li>
<em>RepetitionConstraint</em>: The
<em>Time</em> object in the role of
<em>period</em> must not contain a negative value!
</li>
<li>
<em>RepetitionConstraint</em>: The
<em>Time</em> object in the role of
<em>jitter</em> must not contain a negative value!
</li>
</ul>
<h4><a id="section3.6.7.3"></a>Delay Constraint</h4>
<p>
<img src="images/model_constraints_timing_delay.png"/>
</p>
<ul class="validation-rule">
<li>
<em>DelayConstraint</em>: The
<em>Time</em> object in the role of
<em>lower</em> must not contain a negative value!
</li>
<li>
<em>DelayConstraint</em>: The
<em>Time</em> object in the role of
<em>upper</em> must not contain a negative value!
</li>
</ul>
<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>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>
<ul>
<li>
<i>
<b>OneToOne</b>
</i>: According to page 18f of
<a href="https://itea3.org/project/workpackage/document/download/850/09033-TIMMO-2-USE-WP-2-D11Languagesyntax,semantics,metamodelV2">TIMMO-2-USE Deliverable D11 'Language Syntax, Semantics, Metamodel V2'</a>, a constraint with this mapping type is satisfied if and only if
<i>source</i> and
<i>target</i> have the same number of occurrences and for each index
<i>i</i>, if there is an
<i>i</i>-th occurrence of source at time
<i>x</i> there is also an
<i>i</i>-th occurrence of
<i>target</i> at time
<i>y</i> such that
<i>lower</i> ≤
<i>y</i> -
<i>x</i> ≤
<i>upper</i>.<br> This means that the source event and the target event have the same number of occurrences and no stray target occurrences are accepted.
</li>
</ul>
<p>
<img src="images/model_constraints_delayconstraint_onetoone.png"/>
</p>
<ul>
<li>
<i>
<b>Reaction</b>
</i>: According to page 17f of
<a href="https://itea3.org/project/workpackage/document/download/850/09033-TIMMO-2-USE-WP-2-D11Languagesyntax,semantics,metamodelV2">TIMMO-2-USE Deliverable D11 'Language Syntax, Semantics, Metamodel V2'</a>, a constraint with this mapping type is satisfied if and only if for each occurrence
<i>x</i> of
<i>source</i>, there is an occurrence
<i>y</i> of
<i>target</i> such that
<i>lower</i> ≤
<i>y</i> -
<i>x</i> ≤
<i>upper</i>.<br> This means that multiple source event occurrences may be mapped to the same target event and stray target event occurrences are ignored.
</li>
</ul>
<p>
<img src="images/model_constraints_delayconstraint_reaction.png"/>
</p>
<ul>
<li>
<i>
<b>UniqueReaction</b>
</i>: This mapping type is a mixture of the previous types by specifying that for every occurrence of the source event exactly one target event must occur within the defined time span. Thus, target events may not be shared between source events and stray target events violate the requirement. In contrast to the
<i>OneToOne</i> mapping case, the source event is not mapped to the first source event but is dropped as a violation, if a target event is missed.
</li>
</ul>
<p>
<img src="images/model_constraints_delayconstraint_uniquereaction.png"/>
</p>
<h4><a id="section3.6.7.4"></a>Event Chain Latency Constraint</h4>
<p>An
<i>EventChainLatencyConstraint</i> defines how long 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>
<ul class="validation-rule">
<li>
<em>EventChainLatencyConstraint</em>: The
<em>Time</em> object in the role of
<em>minimum</em> must not contain a negative value!
</li>
<li>
<em>EventChainLatencyConstraint</em>: The
<em>Time</em> object in the role of
<em>maximum</em> must not contain a negative value!
</li>
</ul>
<h3><a id="section3.6.8">3.6.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.6.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.6.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.6.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.6.9">3.6.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.7">3.7 </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">ProcessChain</td>
<td colspan="1" rowspan="1">ProcessChainEvent</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">Channel</td>
<td colspan="1" rowspan="1">ChannelEvent</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Semaphore</td>
<td colspan="1" rowspan="1">SemaphoreEvent</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Component</td>
<td colspan="1" rowspan="1">ComponentEvent</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>A description of the individual events can be found in the following table:</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Event Class</th>
<th colspan="1" rowspan="1">Event Type</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="12">ProcessEvent</td>
<td colspan="1" rowspan="1">activate</td>
<td colspan="1" rowspan="1">The process instance is activated by a stimulus.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">The process instance is allocated to the core and starts execution for the first time.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">resume</td>
<td colspan="1" rowspan="1">The preempted process instance continues execution on the same or other core.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">preempt</td>
<td colspan="1" rowspan="1">The executing process instance is stopped by the scheduler, e.g. because of a higher priority process which is activated.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">poll</td>
<td colspan="1" rowspan="1">The process instance has requested a resource by polling (active waiting) which is not available.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">run</td>
<td colspan="1" rowspan="1">The process instance resumes execution after polling (i.e. active waiting) for a resource.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">wait</td>
<td colspan="1" rowspan="1">The process has requested a non-set OS EVENT (see OSEK 2.2.3 Extended Task Model, WAIT_Event()).</td>
</tr>
<tr>
<td colspan="1" rowspan="1">poll_parking</td>
<td colspan="1" rowspan="1">The parking process instance is allocated to the core and again polls (i.e. actively waits) for a resource.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">park</td>
<td colspan="1" rowspan="1">The active waiting process instance is preemptedby another process.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">release_parking</td>
<td colspan="1" rowspan="1">The resource which is requested by a parking process instance becomes available, but the parking process stays preempted and changes to READY state.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">release</td>
<td colspan="1" rowspan="1">The OS EVENT which was requested by a process is set (see OSEK 2.2.3 Extended Task Model, SET_Event()) and the process is ready to proceed execution.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">The process instance has finished execution.</td>
</tr>
<tr>
<td colspan="1" rowspan="4">RunnableEvent</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">The runnable instance is allocated to the core and starts execution for the first time.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">suspend</td>
<td colspan="1" rowspan="1">The executing runnable instance is stopped, because the calling process is suspended.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">resume</td>
<td colspan="1" rowspan="1">The suspended runnable instance continues execution on the same or another core.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">terminate</td>
<td colspan="1" rowspan="1">The runnable instance has finished execution.</td>
</tr>
<tr>
<td colspan="1" rowspan="2">Component</td>
<td colspan="1" rowspan="1">start</td>
<td colspan="1" rowspan="1">The execution of the component started, i.e. the first runnable in the list of runnables of the component instance is started.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">end</td>
<td colspan="1" rowspan="1">The execution of the component completed, i.e. all runnables in the list of runnables of the component instance were executed at least once.</td>
</tr>
</table>
<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.8">3.8 </a>Hardware Model</h2>
<p>The AMALTHEA hardware model is used to describe hardware systems which usually consist of several hierarchical elements which contain processing units, memories, connections etc. It is accessible through the
<i>HWModel</i> element and contains following top level elements:
</p>
<ul>
<li>Definitions</li>
<li>Domains</li>
<li>Features</li>
<li>Structures</li>
</ul>
<h3><a id="section3.8.1">3.8.1 </a>Class Diagrams</h3>
<h4><a id="section3.8.1.1"></a>Hardware model elements</h4>
<p>
<img class="scale" src="images/model_hw_main.png"/>
</p>
<h4><a id="section3.8.1.2"></a>Hardware definitions and features</h4>
<p>
<img class="scale" src="images/model_hw_definition.png"/>
</p>
<h4><a id="section3.8.1.3"></a>Hardware modules and access elements</h4>
<p>
<img class="scale" src="images/model_hw_module.png"/>
</p>
<h4><a id="section3.8.1.4"></a>Hardware paths and destinations</h4>
<p>
<img class="scale" src="images/model_hw_access.png"/>
</p>
<h3><a id="section3.8.2">3.8.2 </a>Element description</h3>
<p>The following tables describe the different model elements and their attributes in detail. For several elements short examples are attached.</p>
<h4><a id="section3.8.2.1"></a>HwModel</h4>
<p>The
<em>HwModel</em> class is the root element of the hardware model. It always contains one or multiple
<em>HwStructures, PowerDomains</em> and
<em>FrequencyDomains</em> and optionally different
<em>HWFeaturesCategories</em> for the
<em>HwModule</em> definitions.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware model</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Definitions</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwDefinition</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Definitions of ProcessingUnits, Memories, Caches and ConnectionHandlers</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Domains</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwDomain</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Frequency- and PowerDomains</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FeatureCategories</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwFeatureCategory</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">FeatureCategory for the HwModel including HwFeatures</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Structures</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwStructure</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Hierarchical structure of the hardware model</td>
</tr>
</table>
<h4><a id="section3.8.2.2"></a>HwDefinition</h4>
<p>Additional information about the definition concept in general can be found in the User Guide (see <a href="#user-hw-overview">General Hardware Model Overview</a>).</p>
<h5><a id="section3.8.2.2.1"></a>ProcessingUnitDefinition</h5>
<p>For specifying a compute resource a
<em>ProcessingUnitDefinition</em> is created, which is afterwards referenced by the number of
<em>ProcessingUnit</em> instances of this kind. A
<em>ProcessingUnitDefinition</em> can reference multiple
<em>HwFeatures</em> to express different costs for different operations but only one
<em>HwFeature</em> per
<em>HwFeatureCategory</em>.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the processing unit definition</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PuType</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">PuType</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Type of the processing unit e.g. (Core, GPU, etc.)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Features</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">HwFeature</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Hardware features of the definition</td>
</tr>
</table>
<h5><a id="section3.8.2.2.2"></a>MemoryDefinition</h5>
<p>For specifying a memory, a
<em>MemoryDefinition</em> is created, which is afterwards referenced by the number of
<em>Memory</em> instances of this kind.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the memory definition</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AccessLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Constant or distribution of access latency in cycles</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Max. data rate for the memory</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Size</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">Size</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Size of the memory</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MemoryType</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">MemoryType</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">type of the memory (e.g. DRAM, Flash, SRAM, PCM)</td>
</tr>
</table>
<h5><a id="section3.8.2.2.3"></a>CacheDefinition</h5>
<p>For specifying a cache, a
<em>CacheDefinition</em> is created, which is afterwards referenced by the number of
<em>Cache</em> instances of this kind.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the memory definition</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AccessLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Constant or distribution of access latency in cycles</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Size</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">Size</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Size of the memory</td>
</tr>
<tr>
<td colspan="1" rowspan="1">CacheType</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">CacheType</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Cache type (e.g. data, instruction)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">WriteStrategy</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">WriteStrategy</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Cache write strategy (e.g. write-back)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Coherency</td>
<td colspan="1" rowspan="1">Bool</td>
<td colspan="1" rowspan="1">Bool</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Cache coherency (default = false)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Exclusive</td>
<td colspan="1" rowspan="1">Bool</td>
<td colspan="1" rowspan="1">Bool</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Exclusive cache (default = false)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Line Size</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Line size in bits</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Hit Rate</td>
<td colspan="1" rowspan="1">Double</td>
<td colspan="1" rowspan="1">Double</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Percentage hit rate of the cache(default = 0.0)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">NWays</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">N ways associative (default = 0)</td>
</tr>
</table>
<h5><a id="section3.8.2.2.4"></a>ConnectionHandlerDefinition</h5>
<p>For specifying a bus or Interconnect etc., a
<em>ConnectionHandlerDefinition</em> is created, which is afterwards referenced by the number of
<em>ConnectionHandler</em> instances of this kind.
</p>
<p>
<img class="scale" src="images/hw_connection_handler_parallel_accesses_1.png"/>
</p>
<p>The figures shows an example of the attribute
<em>MaxConcurrentTransfers</em> with the default value 1. This means that all
<em>ConnectionHandlers</em> which are referencing this
<em>ConnectionHandlerDefinition</em> can only handle 1 active transfer request at a time. All other requests have to wait until the current transfers has finished.
</p>
<p>The next figure shows an example with a number of
<em>MaxConcurrentTransfers</em> of 3. In this case the
<em>ConnectionHandler</em> can handle up to 3 concurrent requests.
</p>
<p>
<img class="scale" src="images/hw_connection_handler_parallel_accesses_3.png"/>
</p>
<p>The value for
<em>MaxConcurrentTransfers</em> has to be smaller or equal then the min(initiator ports, responder ports).
</p>
<p>The values for
<em>DataRate</em>,
<em>ReadLatency</em>, and WriteLatency are default values for all
<em>ConnectionHandlers</em> of this kind. For a specific
<em>InternalConnection</em> in a
<em>ConnectionHandler</em> instance other values can be assigned.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the memory definition</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SchedPolicy</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">SchedPolicy</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Enumeration of different scheduling policies</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ReadLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Constant or distribution in cycles for a read access</td>
</tr>
<tr>
<td colspan="1" rowspan="1">WriteLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Constant or distribution in cycles for a write access</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Max. data rate of the connection (value and unit)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MaxBurstSize</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Maximum burst size of a ConnectionHandler (default = 1)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MaxConcurrentTransfers</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Number of concurrent transfers from different initiator to responder ports (default = 1)</td>
</tr>
</table>
<h4><a id="section3.8.2.3"></a>HwStructure</h4>
<p>A
<em>HwStructure</em> is a hierarchical element which can contain all kind of
<em>HwModules</em>,
<em>HwConnections</em> and other
<em>HwStructures</em>. Different
<em>HwStructures</em> can be connected via one or more
<em>HwPorts</em> with other structures or modules of a top level
<em>HwStructures</em>. By combining different
<em>HwStructures</em> any kind of hierarchical system can be expressed. By setting the structure type attribute (e.g. Cluster, ECU) the structural level in the hardware is directly expressible.
</p>
<p>
<img class="scale" src="images/hw_structure_example.png"/>
</p>
<p>The figure shows an example for creating a hierarchy within an E/E-architecture. The
<em>HwStructure System</em> (which is called "System") is created as top level structure within the HwModel. It contains three other structures which represents different ECUs. The structures are connected via
<em>HwPorts</em>,
<em>HwConnections</em> and a
<em>ConnectionHandler</em>. Usually structures in the model can be viewed as black boxes which can be connected via
<em>HwPorts</em>.
<em>ECU3</em> allows a look inside, where additional structures for two SoCs are visible.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware structure</td>
</tr>
<tr>
<td colspan="1" rowspan="1">StructureType</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">StructureType</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Defines the type of the structure (e.g. ECU)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Modules</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwModule</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Modules of the structure (e.g. Memory)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Ports</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Ports to connect the structure (always delegated Ports)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Structures</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwStructure</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Hardware structure to build hierarchical designs</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Connections</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwConnection</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Connections within a structure</td>
</tr>
</table>
<h4><a id="section3.8.2.4"></a>HwDomain</h4>
<p>
<img class="scale" src="images/hw_domain_example.png"/>
</p>
<p>The figure shows an example for
<em>HwDomain</em> (
<em>FrequencyDomain</em> and a
<em>PowerDomain</em>). They are always created at the top level in the root element
<em>HwModel</em>. Every basic component is able to reference a
<em>FrequencyDomain</em> and a
<em>PowerDomain</em>.
<em>(Note: The link between domains and modules are only references, there are no visible connections inside the model)</em>
</p>
<h5><a id="section3.8.2.4.1"></a>FrequencyDomain</h5>
<p>A
<em>FrequencyDomain</em> is inherited from
<em>HwDomain</em>. This element describes a frequency domain which can be referenced by all elements of the type
<em>HwModule</em> to define the default frequency value for operation. In future the
<em>FrequencyDomain</em> should also contain possibleValues which should specify the different frequencies for different operation modes.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the frequency domain</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DefaultValue</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">Frequency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Default frequency value</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Clock Gating</td>
<td colspan="1" rowspan="1">Boolean</td>
<td colspan="1" rowspan="1">Boolean</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Possibility to power down the domain (default = false)</td>
</tr>
</table>
<h5><a id="section3.8.2.4.2"></a>PowerDomain</h5>
<p>A
<em>PowerDomain</em> is inherited from
<em>HwDomain</em>. This element describes a power domain which can be referenced by all elements of the type
<em>HwModule</em>, to define the default voltage value for operation. In future the
<em>PowerDomain</em> should also contain possibleValues which should specify the different voltages for different operation modes.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the power domain</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DefaultValue</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">Voltage</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Default voltage value</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PowerGating</td>
<td colspan="1" rowspan="1">Boolean</td>
<td colspan="1" rowspan="1">Boolean</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Possibility to power down the domain (default = false)</td>
</tr>
</table>
<h4><a id="section3.8.2.5"></a>HwFeature</h4>
<p>A
<em>HwFeature</em> is an abstract element to represent any kind of special functionality of a
<em>ProcessingUnitDefinition</em>.
<em>HwFeatures</em> could be reused several times by different definitions and organized within
<em>HwFeatureCategories</em>. Currently this
<em>HwFeatureCategories</em> are directly referenced out of the Software Model in future the cost function (
<em>Recipes</em>) of an algorithm will be placed in an additional intermediate layer.
<br>More information can be found in (see <a href="#user-hw">Hardware Concepts</a>).
</p>
<p>
<em>NOTE: The concepts "Recipe" and "Hardware Features" are work in progress. Changes to the already implemented HwFeatures are probable.</em>
</p>
<p>
<img class="scale" src="images/hw_feature_example.png"/>
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware feature</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Value</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">Value</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">assigned factor to the corresponding feature</td>
</tr>
</table>
<h5><a id="section3.8.2.5.1"></a>HwFeatureCategory</h5>
<p>The
<em>HwFeatureCategory</em> is an element to collect the same kind of
<em>HwFeatures</em> with different values.
<br>The
<em>HwFeatureCategories</em> can be referenced by the
<em>ExecutionNeeds</em> in the Software Model.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware feature</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Type</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">HwFeatureType</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Type to express the purpose of the feature (performance, power, performance_and_power)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Description</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Textual description of the hardware feature</td>
</tr>
<tr>
<td colspan="1" rowspan="1">HwFeature</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwFeature</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Hardware feature with a factor</td>
</tr>
</table>
<h4><a id="section3.8.2.6"></a>HwModule</h4>
<h5><a id="section3.8.2.6.1"></a>ProcessingUnit</h5>
<p>A
<em>ProcessingUnit</em> is a
<em>HwModule</em> that can be used to model a wide set of different hardware components like a GPU, hardware accelerator, CPU, etc. The capability and the functionality of a
<em>ProcessingUnit</em> are represented by different
<em>HwFeatures</em> within the
<em>ProcessingUnitDefinition</em>. The
<em>ProcessingUnits</em> are the master modules in the model and every
<em>ProcessingUnit</em> can has their own access space. The
<em>ProcessingUnit</em> can be referenced by
<em>AccessPaths</em> and
<em>HwAccessElements</em>.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the processing unit instance</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Ports</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Ports of the component</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Caches</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">Cache</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Included caches by the Processing Unit e.g. L1 Cache</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AccessElements</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">AccessElement</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Access element for a specific memory or processing unit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Frequency domain which supplies the module with a frequency</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Power domain which supplies the module with a voltage</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Definition</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">ProcessingUnitDefinition</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Definition with all features for the processing unit instance</td>
</tr>
</table>
<h5><a id="section3.8.2.6.2"></a>Memory</h5>
<p>A
<em>Memory</em> is a component of type
<em>HwModule</em> to express any kind memory like SRAM (Scratchpads), DRAM, Flash, etc. in the model, caches are modeled separately. The
<em>Memory</em> element can be referenced as destination by a
<em>HwAccessElement</em>.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the memory instance</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Ports</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Ports of the component</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Frequency domain which supplies the module with a frequency</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Power domain which supplies the module with a voltage</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Definition</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">MemoryDefinition</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Definition with all features for the memory instance</td>
</tr>
</table>
<h5><a id="section3.8.2.6.3"></a>Cache</h5>
<p>A
<em>Cache</em> is a component of type
<em>HwModule</em> to express the special behavior of a
<em>Cache</em>. It is used to create cache topologies within a system. The
<em>Cache</em> can be referenced by
<em>AccessPaths</em> to express if it is a cached or non-cached access. It is also the only
<em>HwModule</em> which can be directly contained by a
<em>ProcessingUnit</em>.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the cache instance</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Ports</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Ports of the component</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Frequency domain which supplies the module with a frequency</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Power domain which supplies the module with a voltage</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Definition</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">CacheDefinition</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Definition with all features for the cache instance</td>
</tr>
</table>
<h5><a id="section3.8.2.6.4"></a>ConnectionHandler</h5>
<p>A
<em>ConnectionHandler</em> is a component of type HwModule which can be used whenever multiple
<em>HwConnections, (HwPorts)</em> have to be combined. It is possible to represent whole bus systems or interconnects with a single
<em>ConnectionHandler</em>, or elements like small routers within a NoC.
</p>
<p>
<img class="scale" src="images/hw_connection_handler_example.png"/>
</p>
<p>The figure shows an example where a
<em>ConnectionHandler</em> is used as an interconnect within a SoC. Optional it is possible to model
<em>InternalConnections</em> inside a
<em>ConnectionHandler</em> to model explicit or restrict different connections. However it is also possible to use default read and write latencies of the whole
<em>ConnectionHandlerDefinition</em>, individual latencies can be attached to
<em>InternalConnections</em>. A short example where a
<em>ConnectionHandler</em> is used as a CAN bus is illustrated in the structure example. For detailed models where all modules connected via
<em>HwConnections</em> and different
<em>ConnectionHandlers</em>, the
<em>ConnectionHandlers</em> should be the only module where contentions in the hardware model can occur. A
<em>ConnectionHandler</em> can be referenced by
<em>HwAccessPaths</em>.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the connection handler instance</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Ports</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Ports of the component</td>
</tr>
<tr>
<td colspan="1" rowspan="1">InternalConnections</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwConnection</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Internal connection between the ports</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">FrequencyDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Frequency domain which supplies the module with a frequency</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">PowerDomain</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Power domain which supplies the module with a voltage</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Definition</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">ConnectionHandlerDefinition</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Definition with all features for the connection handler instance</td>
</tr>
</table>
<h4><a id="section3.8.2.7"></a>HwAccessElement</h4>
<p>A
<em>HwAccessElement</em> can be used to specify the access relationship between two
<em>ProcessingUnits</em> or a
<em>ProcessingUnit</em> and a
<em>Memory</em>. With multiple
<em>HwAccessElements</em> the whole access or even address space of a
<em>ProcessingUnit</em> can be represented. A
<em>HwAccessElement</em> represents always the view from a specific
<em>ProcessingUnit</em>. There exist two different approaches to express latency or a data rate for a
<em>HwAccessElement</em>: 1. directly using latencies or data rates or 2. modeling the exact path to the destination by attaching a
<em>HwAccessPath</em> which references the specific connection elements like
<em>ConnectionHandlers</em>,
<em>HwConnection</em>, etc. For the second approach it is also possible to work directly with addresses.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the address element</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Destination</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">HwDestination</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Destination for the processing unit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AccessPaths</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwAccessPath</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Access path to the destination</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ReadLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Read latency to the destination</td>
</tr>
<tr>
<td colspan="1" rowspan="1">WriteLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Write latency to the destination</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Max. data rate to the destination</td>
</tr>
</table>
<h4><a id="section3.8.2.8"></a>HwPort</h4>
<p>
<em>HwPorts</em> are elements which can be connected via
<em>HwConnections</em>. Every module can contain multiple
<em>HwPorts</em>. Every communication, input or output is handled via a
<em>HwPort</em> of a component. It is only allowed to have one
<em>HwConnection</em> per
<em>HwPort</em>, except the
<em>HwPort</em> is categorized as delegated port which means it is just a hierarchical connection between
<em>HwStructures</em>. In this case the ports can have two
<em>HwConnections</em>. The second exception is if inside a
<em>ConnectionHandler</em>,
<em>InternalConnections</em> are used.In this case a
<em>HwPort</em> can be directed with a
<em>HwConnection</em> and
<em>InternalConnections</em>. The following figure shows an example with delegated
<em>HwPorts</em> and
<em>InternalConnections</em>.
</p>
<p>
<img class="scale" src="images/hw_port_example.png"/>
</p>
<p>In case the
<em>BitWidth</em> becomes important (e.g. to calculate the amount of data which is transfered over an
<em>ConnectionHandler</em>) the minimum
<em>BithWidth</em> of all included Ports have to be accounted.
</p>
<p>For
<em>HwPorts</em> it's always possible to select if the port is an
<em>initiator</em> or a
<em>responder</em> port. The following example shows that an initiator port is always connected to a responder port (comparable to TLM modeling).
</p>
<p>
<img class="scale" src="images/hw_port_example_i_r.png"/>
</p>
<p>In case of a delegated port (which is used as hierarchical port at a
<em>HwStructure</em>) the
<em>PortType</em> of the module inside the structure is reflected. The following figure shows four different examples. The ports which are delegated are marked grey.
</p>
<p>
<img class="scale" src="images/hw_port_example_i_r_with_delegated_ports.png"/>
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware port</td>
</tr>
<tr>
<td colspan="1" rowspan="1">BitWidth</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Bit width e.g. 32 bit (default = 0)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Priority</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">Int</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Priority of the hardware port (default = 0)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Type</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">PortType</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Port type (initiator, responder)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Delegated</td>
<td colspan="1" rowspan="1">Bool</td>
<td colspan="1" rowspan="1">Bool</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Delegated ports are hierarchical structure ports</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PortInterface</td>
<td colspan="1" rowspan="1">Enum</td>
<td colspan="1" rowspan="1">PortInterface</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Type to express special interfaces for validation</td>
</tr>
</table>
<h4><a id="section3.8.2.9"></a>HwConnection</h4>
<p>A
<em>HwConnection</em> is an element to model structural connections between two
<em>HwPorts</em>.
<em>HwConnections</em> are always placed within
<em>HwStructures</em>. It is possible to directly annotate a read and write latency at a
<em>HwConnection</em>.
<em>HwConnections</em> can be referenced by
<em>HwAccessPaths</em>. The HwConnection do not have a reference to a
<em>FrequencyDomain</em>, the frequency is always provided by the element which is in front of the
<em>HwConnection</em> in the
<em>HwAccessPath</em>.
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware connection</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Port1</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Port1 for the connection</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Port2</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Port2 for the connection</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ReadLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Constant or distribution in cycles for a read access</td>
</tr>
<tr>
<td colspan="1" rowspan="1">WriteLatency</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">HwLatency</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Constant or distribution in cycles for a write access</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">Containment</td>
<td colspan="1" rowspan="1">DataRate</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Max. data rate of the connection (value and unit)</td>
</tr>
</table>
<h4><a id="section3.8.2.10"></a>HwAccessPath</h4>
<p>A
<em>HwAccessPath</em> is an element to describe the connection route of a
<em>ProcessingUnit</em> to its destination (
<em>Memory</em> or
<em>ProcessingUnit</em>). The
<em>HwAccessPath</em> is defined through an ordered list of IPaths interface elements (
<em>HWConnections, Caches</em> and
<em>ConnectionHandlers</em>) and is a containment of an
<em>HwAccessElement</em>. The figure shows an example of an
<em>HwAccessPath</em>, how a
<em>ProcessingUnit</em> is connected via two
<em>HwConnections</em> and a
<em>ConnectionHandler</em> with a
<em>Memory</em>.
</p>
<p>
<img class="scale" src="images/hw_access_path_example.png"/>
</p>
<p>In the following example the possible memOffset attribute is explained. Every
<em>ProcessingUnit</em> can access a
<em>Memory</em> or other
<em>ProcessingUnit</em> over a different address. The size of the
<em>Memory</em> has to be equal or greater than
<em>endAddress</em> minus the
<em>startAddress</em>.
</p>
<ul>
<li>memory_size &gt;= endAddress – startAddress</li>
</ul>
<p>In the case the the
<em>ProcessingUnit</em> should not start at address 0 (from the memory point of view) the
<em>memOffset</em> attribute can be used. With help of this attribute the access area for the memory can be changed, the following figure shows an example.
</p>
<p>
<img class="scale" src="images/hw_memory_address_example.png"/>
</p>
<table class="classic">
<tr>
<th colspan="1" rowspan="1">Attribute</th>
<th colspan="1" rowspan="1">Type</th>
<th colspan="1" rowspan="1">Value</th>
<th colspan="1" rowspan="1">Mul.</th>
<th colspan="1" rowspan="1">Description</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Name</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Name of the hardware access path</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PathElements</td>
<td colspan="1" rowspan="1">Reference</td>
<td colspan="1" rowspan="1">HwPath</td>
<td colspan="1" rowspan="1">*</td>
<td colspan="1" rowspan="1">Path elements for the access path</td>
</tr>
<tr>
<td colspan="1" rowspan="1">StartAddress</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Start address for the memory</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EndAddress</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">End address for the memory</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MemOffset</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">Offset for accessing only a partition of a memory</td>
</tr>
</table>
<h4><a id="section3.8.2.11"></a>Enumerations</h4>
<p>In the following all enums are listed. In the case an enum is used by any class the default value of that enum is always
<em>undefined</em>. That means that in case of an enum there are no default values for interfaces or other kind of types. Moreover only new enums are explicitly mentioned in this report. Enums and classes which are already part of the existing Amalthea meta model are not described.
</p>
<p>
<strong>StructureType:</strong>
</p>
<ul>
<li>_undefined_, System, ECU, Microcontroller, SoC, Cluster, Group, Array, Area, Region</li>
</ul>
<p>
<strong>CacheType:</strong>
</p>
<ul>
<li>_undefined_, instruction, data, unified</li>
</ul>
<p>
<strong>VoltageUnit:</strong>
</p>
<ul>
<li>_undefined_, V, mV, uV</li>
</ul>
<p>
<strong>PortType:</strong>
</p>
<ul>
<li>_undefined_, initiator, responder</li>
</ul>
<p>
<strong>SchedPolicy:</strong>
</p>
<ul>
<li>_undefined_, RoundRobin, FCFS, PriorityBased</li>
</ul>
<p>
<strong>WriteStrategy:</strong>
</p>
<ul>
<li>_undefined_, none, writeback, writethrough</li>
</ul>
<p>
<strong>PuType:</strong>
</p>
<ul>
<li>_undefined_, GPU, CPU, Accelerator</li>
</ul>
<p>
<strong>PortInterfaces:</strong>
</p>
<ul>
<li>_undefined_, custom, can, flexray, lin, most, ethernet, spi, i2c, axi, ahb, apb, swr</li>
</ul>
<p>
<strong>HwFeatureType:</strong>
</p>
<ul>
<li>_undefined_, performance, power, performance_and_power</li>
</ul>
<p>
<strong>MemoryType:</strong>
</p>
<ul>
<li>_undefined_, DRAM, SRAM, FLASH, PCM</li>
</ul>
<h2><a id="section3.9">3.9 </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 processing units</li>
<li>schedulers and processing units: A scheduler can manage one or more processing units 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>
<p>Note the mapping model is the only sub model of Amalthea with an attribute in the root element. The
<em>Address Mapping Type</em> defines the interpretation of used addresses in the mapping model. Additional information can be found in the
<em>MemoryMapping</em> section.
</p>
<h3><a id="section3.9.1">3.9.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.9.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 processing units which are allocated to schedulers) and
<i>Mappings</i> (labels and software which is mapped to memories).
</p>
<h3><a id="section3.9.2">3.9.2 </a>Allocations</h3>
<p>
<img class="scale" src="images/model_mapping_allocation.png"/>
</p>
<h4><a id="section3.9.2.1"></a>SchedulerAllocation</h4>
<p>The
<i>SchedulerAllocation</i> describes the allocation of a
<i>Scheduler</i> to processing units. This class consists of references to the respective
<i>Scheduler</i>, which is specified within an existing OS model, and a processing units, which is specified in a hardware model. Schedulers with algorithm "Grouping" are not allocated since they take no decisions and produce no overhead.
</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>scheduler</i>
</td>
<td colspan="1" rowspan="1">The scheduler (that is specified in more detail).</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>responsibility</i>
</td>
<td colspan="1" rowspan="1">Defines the processing units the scheduler is responsible for. On these units the scheduler takes decisions. Multiple schedulers can be responsible for one processing unit because of hierarchies. Child-schedulers only take decisions, if they parent-schedulers allows them to (e.g. hypervisors with virtual machines which execute an own operating system). Tasks allocated to this scheduler execute on the intersection between affinity and the responsibility of the scheduler. If this is null the configuration is invalid. If the intersection results in multiple cores, the task can migrate.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>executingPU</i>
</td>
<td colspan="1" rowspan="1">Defines on which processing unit the scheduling algorithm is actually executed to consider the overhead.</td>
</tr>
</table>
<h4><a id="section3.9.2.2"></a>RunnableAllocation</h4>
<p>The
<i>RunnableAllocation</i> is used to associate a
<i>Runnable</i>, specified within an existing software model, with a
<i>Scheduler</i>.
</p>
<h4><a id="section3.9.2.3"></a>TaskAllocation</h4>
<p>The
<i>TaskAllocation</i> is used to associate a
<i>Task</i> with its
<i>TaskScheduler</i>.
</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>task</i>
</td>
<td colspan="1" rowspan="1">The task (that is specified in more detail).</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>scheduler</i>
</td>
<td colspan="1" rowspan="1">Specifies the unique allocation to the scheduler of the task.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>affinity</i>
</td>
<td colspan="1" rowspan="1">Specifies the possible processing units the task can run. If only one unit is specified, the task runs on this core. If multiple cores are specified, the task can migrate between the units. The task executes on the intersection between affinity and the responsibility of the scheduler. If this is null the configuration is invalid. If the intersection results in multiple cores, the task can migrate.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>schedulingParameters</i>
</td>
<td colspan="1" rowspan="2">Used to assign scheduling parameters for this specific allocation. For details see chapter "Scheduling Parameters" in OS Model.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>parameterExtensions</i>
</td>
</tr>
</table>
<h4><a id="section3.9.2.4"></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 allocation.
</p>
<h3><a id="section3.9.3">3.9.3 </a>Mappings</h3>
<h4><a id="section3.9.3.1"></a>MemoryMapping</h4>
<p>The
<i>MemoryMapping</i> is a class, describing the mapping of parts of the software model to
<i>Memory</i>. It is used to associate specializations of the
<i>AbstractMemoryElement</i> (i.e.
<i>Label</i>,
<i>Runnable</i>,
<i>TaskPrototype</i> and
<i>Process</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.9.3.2"></a>PhysicalSectionMapping</h4>
<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>
<p>Note for additional information (see <a href="#user-memsection">User Guide &gt; Concepts &gt; Memory Sections</a>)</p>
<h2><a id="section3.10">3.10 </a>Measurement Model</h2>
<p>The measurement model provides the possibility to store runtime measurements. The main purpose is to exchange measured times, either as a series of single values or as derived statistical data.</p>
<p>
<b>Warning</b>: This model has no connections to the configuration and should not be used for any kind of timing simulation inputs or automatic configuration tools. Its main purpose is to document a specific situation that has to be exchanged between development partners. Therefore the origin of the data should be clearly identifiable using additional info like "creator", "date" or "hardware" entered as custom attributes of
<i>MeasurementModel</i>.
</p>
<p>Changing the model should result in an invalidation of the measurement model. For use cases such as timing simulation the measurement model is of no importance and should be ignored.</p>
<p>Measurements refer to given elements of other model parts and can easily be exchanged (added, removed, updated).</p>
<p>
<img src="images/model_measurement.png"/>
</p>
<h2><a id="section3.11">3.11 </a>OS Model</h2>
<p>This part of the AMALTHEA model describes the provided functionality of an operating system. 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.11.1">3.11.1 </a>Operating System</h3>
<p>The basic element in the OS Model is the operating system. There can be 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.11.2">3.11.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 computation items. These items (a subset of the runnable items) characterize the runtime behavior (algorithmic overhead) of the scheduler.</p>
<p>
<img src="images/model_os_scheduler.png"/>
</p>
<h4><a id="section3.11.2.1"></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">Grouping</td>
<td colspan="1" rowspan="1">This scheduler is a logical grouping of tasks/child-schedulers, e.g. a partition with attached budget for all tasks. This scheduler does not take any scheduling decisions and a parent scheduler is mandatory.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">UserSpecificSchedulingAlgorithm</td>
<td colspan="1" rowspan="1">This class contains a list of algorithm parameters. 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>
<tr>
<td colspan="2" rowspan="1" style="background:#e6ffe6;">Fixed Priority</td>
</tr>
<tr>
<td colspan="1" rowspan="1">OSEK</td>
<td colspan="1" rowspan="1">OSEK compliant Scheduling</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FixedPriorityPreemptive</td>
<td colspan="1" rowspan="1">Fixed Priority Preemptive Scheduling (e.g. AUTOSAR)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">FixedPriorityPreemptiveWithBudgetEnforcement</td>
<td colspan="1" rowspan="1">Fixed Priority Preemptive Scheduling (with budget enforcement)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DeadlineMonotonic</td>
<td colspan="1" rowspan="1">Deadline Monotonic Scheduling (DMS): Task with the shortest period gets the lowest priority.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">RateMonotonic</td>
<td colspan="1" rowspan="1">Rate Monotonic Scheduling (RMS): Task with the shortest period gets the highest priority.</td>
</tr>
<tr>
<td colspan="2" rowspan="1" style="background:#e6ffe6;">Dynamic Priority</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EarliestDeadlineFirst</td>
<td colspan="1" rowspan="1">Earliest Deadline First (EDF): Task with the earliest deadline gets the highest priority.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">LeastLocalRemainingExecutionTimeFirst</td>
<td colspan="1" rowspan="1">Least Local Remaining Execution-time First (LLREF): Task with the smallest local remaining execution time 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="2" rowspan="1" style="background:#e6ffe6;">Proportionate Fair (Pfair)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PfairPD2</td>
<td colspan="1" rowspan="1">Proportionate Fair PD<sup>2</sup> Scheduling (Pfair-PD<sup>2</sup>)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PartlyPfairPD2</td>
<td colspan="1" rowspan="1">Partly Proportionate Fair PD<sup>2</sup> Scheduling (PPfair-PD<sup>2</sup>)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">EarlyReleaseFairPD2</td>
<td colspan="1" rowspan="1">Early Release Fair PD<sup>2</sup> Scheduling (ERfair-PD<sup>2</sup>)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PartlyEarlyReleaseFairPD2</td>
<td colspan="1" rowspan="1">Partly Early Release Fair PD<sup>2</sup> Scheduling (P-ERfair-PD<sup>2</sup>)</td>
</tr>
<tr>
<td colspan="2" rowspan="1" style="background:#e6ffe6;">Reservation Based Server</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DeferrableServer</td>
<td colspan="1" rowspan="1">Deferrable Server (DS): provides a fixed budget, in which the budget replenishment is done periodically.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PollingPeriodicServer</td>
<td colspan="1" rowspan="1">Polling Server (PS): provides a fixed budget periodically that is only available at pre-defined times.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SporadicServer</td>
<td colspan="1" rowspan="1">Sporadic Server (SS): provides a fixed budget, in which the budget replenishment is performed only if it was consumed.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ConstantBandwidthServer</td>
<td colspan="1" rowspan="1">Constant Bandwidth Server (CBS): provides a fixed utilization for executing jobs, in which the deadline for execution is independent on the execution time of jobs.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ConstantBandwidthServerWithCASH</td>
<td colspan="1" rowspan="1">Constant Bandwidth Server (CBS) with capacity sharing (CASH). Consumes residual slack from other servers (work conserving).</td>
</tr>
</table>
<h5><a id="section3.11.2.1.1"></a>Further information</h5>
<p>Details regarding proportionate fair (
<strong>Pfair</strong>) scheduling and the variants of the
<strong>PD<sup>2</sup> Pfair</strong> algorithm can be found in the dissertation "Effcient and Flexible Fair Scheduling of Real-time Tasks on Multiprocessors" by Anand Srinivasan (see
<a href="https://www.cs.unc.edu/~anderson/diss/srinidiss.pdf">dissertation</a> at University of North Carolina at Chapel Hill).
</p>
<p>An overview regarding
<strong>Reservation Servers</strong> is given in the lecture "Resource Reservation Servers" by Jan Reineke (see
<a href="https://embedded.cs.uni-saarland.de/lectures/realtimesystems/resourceReservationServers.pdf">lecture</a> at Saarland University).
</p>
<h4><a id="section3.11.2.2"></a>Scheduling Parameters</h4>
<p>The class SchedulingParameters contains predefined parameters that are relevant for many scheduling algorithms. If a parameter is not used in a given context the value is null. Additional parameters can be added as key-value pairs of class ParameterExtensions.</p>
<p>
<img src="images/model_os_scheduling_parameters.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>priority</i>
</td>
<td colspan="1" rowspan="1">Specifies the priority for the child-scheduler for priority based scheduling algorithms like FPP.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>minBudget</i>
</td>
<td colspan="1" rowspan="2">In budget-based scheduling algorithms like sporadic servers the runtime in a periodic time-interval must be given. The budget can be defined via min/max budgets. If no intervals are possible, the maxBudget is the key value.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>maxBudget</i>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>replenishment</i>
</td>
<td colspan="1" rowspan="1">The replenishment time defines period in which the budget is restored.</td>
</tr>
</table>
<h4><a id="section3.11.2.3"></a>Scheduler Association</h4>
<p>A hierarchy of schedulers can be specified with intermediate objects of class
<i>SchedulerAssociation</i>. If set, the parent scheduler takes the initial decision who is executing. If the child-scheduler is not a grouping of tasks, it can take scheduling decisions if permission is granted by the parent. The association also contains the relevant parameters of the scheduler in the hierarchical context.
</p>
<p>
<img src="images/model_os_scheduler_association.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>parent</i>
</td>
<td colspan="1" rowspan="1">Refers to the parent scheduler</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>child</i>
</td>
<td colspan="1" rowspan="1">Derived attribute that is computed based on the containment reference "parentAssociation" from
<i>Scheduler</i> to
<i>SchedulerAssociation</i>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>schedulingParameters</i>
</td>
<td colspan="1" rowspan="2">See chapter "Scheduling Parameters"</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>parameterExtensions</i>
</td>
</tr>
</table>
<h3><a id="section3.11.3">3.11.3 </a>Os Overhead</h3>
<p>It is possible to define 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.11.3.1"></a>ISR Overhead</h4>
<ul>
<li>ISR category 1 &amp; 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.11.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>
</ul>
<ul>
<li>API Schedule: Runtime for task scheduling (on scheduling request)</li>
</ul>
<ul>
<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>
</ul>
<ul>
<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>
</ul>
<ul>
<li>API Send Message: Runtime overhead for cross-core process activation or event (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>
<ul>
<li>API Suspend OsInterrupts</li>
<li>API Resume OsInterrupts</li>
</ul>
<ul>
<li>API Request Spinlock</li>
<li>API Release Spinlock</li>
</ul>
<ul>
<li>API SenderReceiver Read</li>
<li>API SenderReceiver Write</li>
</ul>
<ul>
<li>API SynchronousServerCallPoint</li>
</ul>
<ul>
<li>API IOC Read</li>
<li>API IOC Write</li>
</ul>
<h3 id="os-data-consistency"><a id="section3.11.4">3.11.4 </a>OS Data Consistency</h3>
<p>The
<i>OsDataConsistency</i> class provides a way to configure an automatic data consistency mechanism of an operating system. 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. Furthermore, it can be stated whether all data is considered for stability or just those accessed multiple times.
</p>
<p>DataStabilityLevel:</p>
<ul>
<li>
<i>period</i> - between consecutive activations
</li>
<li>
<i>process</i> - within a Task or ISR
</li>
<li>
<i>scheduleSection</i> - between Schedule points (explizit schedule points, begin and end of process)
</li>
<li>
<i>runnable</i> - within a Runnable
</li>
</ul>
<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.11.5">3.11.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>semaphoreType</i>
</td>
<td colspan="1" rowspan="1">Defines how the semaphore is implemented</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>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>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.12">3.12 </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>Core allocation constraints, which describe the constraints on cores.</li>
<li>Memory mapping constraints, which describe the constraints on memories.</li>
</ul>
<h3><a id="section3.12.1">3.12.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>
<h3><a id="section3.12.2">3.12.2 </a>CoreAllocationConstraint</h3>
<p>The
<i>CoreAllocationConstraint</i> is an abstract class for describing constraints which affect the selection of a suitable
<i>Core</i>.
</p>
<h4><a id="section3.12.2.1"></a>RunnableAllocationConstraint</h4>
<p>The
<i>RunnableAllocationConstraint</i> is a specialization of the
<i>CoreAllocationConstraint</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.12.2.2"></a>ProcessAllocationConstraint</h4>
<p>The
<i>ProcessAllocationConstraint</i> is a specialization of the
<i>CoreAllocationConstraint</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.12.2.3"></a>ProcessPrototypeAllocationConstraint</h4>
<p>Tha same as ProcessAllocationConstraint but for process prototypes in an earlier phase of the development.</p>
<h3><a id="section3.12.3">3.12.3 </a>MemoryMappingConstraint</h3>
<p>The
<i>MemoryMappingConstraint</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>AbstractElementMappingConstraint</i>.
</p>
<h4><a id="section3.12.3.1"></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>AbstractMemoryElement</i> specializations (i.e.
<i>Label</i>,
<i>Runnable</i>,
<i>TaskPrototype</i> or
<i>Process</i>) to
<i>Memories</i>.
</p>
<h3><a id="section3.12.4">3.12.4 </a>Classifications</h3>
<p>The specializations
<i>CoreClassification</i> and
<i>MemoryClassification</i> are used to describe the features that a hardware element (
<i>Core</i> or
<i>Memory</i>) needs to provide in order to be a valid target. This is done by references to Classifiers, conditions (requires vs. excludes) and the kind of grouping (all of them vs. at least one of them).
</p>
<h3><a id="section3.12.5">3.12.5 </a>Example</h3>
<p>
<img src="images/model_propertyconstraints_example.png"/>
</p>
<h2><a id="section3.13">3.13 </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.13.1">3.13.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>SingleStimulus</strong>: Activates the process only once.
</li>
<li>
<strong>ArrivalCurveStimulus</strong>: A list of time-borders in which a specified number of occurrences are expected.
</li>
<li>
<strong>PeriodicStimulus</strong>: Periodic activations based on an offset, a recurrence and (optionally) a jitter.
</li>
<li>
<strong>PeriodicSyntheticStimulus</strong>: Defines a periodically triggered stimuli depending on a defined list of occurrence times.
</li>
<li>
<strong>PeriodicBurstStimulus</strong>: Defines a periodic burst pattern of the process.
</li>
<li>
<strong>RelativePeriodicStimulus</strong>: Periodic activation based on offset and a recurrence.<br>In contrast to PeriodicStimulus the recurrence is relative to the last occurrence and a deviation is mandatory.
</li>
<li>
<strong>VariableRateStimulus</strong>: Periodic activations based on other events, like rotation speed.
</li>
<li>
<strong>InterProcessStimulus</strong>: Activations based on an explicit inter-process activation.<br>Contains a Counter element if activation is either shifted and / or happening every n<sup>th</sup> time.
</li>
<li>
<strong>EventStimulus</strong>: Activation triggered by an event, defined in the event model.<br>Contains a Counter element if activation is either shifted and / or happening every n<sup>th</sup> time.
</li>
<li>
<strong>CustomStimulus</strong>: To describe own custom types of activations, including properties.
</li>
</ul>
<ul class="validation-rule">
<li>
<em>PeriodicStimulus</em>: The
<em>Time</em> object in the role of
<em>offset</em> must not contain a negative value!
</li>
<li>
<em>PeriodicStimulus</em>: The
<em>Time</em> object in the role of
<em>recurrence</em> must not contain a negative value!
</li>
<li>
<em>PeriodicBurstStimulus</em>: The
<em>Time</em> object in the role of
<em>offset</em> must not contain a negative value!
</li>
<li>
<em>PeriodicBurstStimulus</em>: The
<em>Time</em> object in the role of
<em>recurrence</em> must not contain a negative value!
</li>
<li>
<em>PeriodicSyntheticStimulus</em>: The
<em>Time</em> object in the role of
<em>offset</em> must not contain a negative value!
</li>
<li>
<em>PeriodicSyntheticStimulus</em>: The
<em>Time</em> object in the role of
<em>recurrence</em> must not contain a negative value!
</li>
<li>
<em>TimestampList</em>: The
<em>Time</em> objects in the role of
<em>timestamps</em> must not contain a negative value!
</li>
<li>
<em>SingleStimulus</em>: The
<em>Time</em> object in the role of
<em>occurrence</em> must not contain a negative value!
</li>
<li>
<em>ArrivalCurveEntry</em>: The
<em>Time</em> object in the role of
<em>lowerTimeBorder</em> must not contain a negative value!
</li>
<li>
<em>ArrivalCurveEntry</em>: The
<em>Time</em> object in the role of
<em>upperTimeBorder</em> must not contain a negative value!
</li>
</ul>
<h4><a id="section3.13.1.1"></a>Single</h4>
<p>
<em>Single</em> allows to specify an activation at a single relative point in time. The single activation occurs after the time units specified by
<em>occurrence</em>.
</p>
<p>
<img src="images/model_stimuli_single.png" style="width:600px"/>
</p>
<h4><a id="section3.13.1.2"></a>Arrival Curves</h4>
<p>An arrival curve is described as a list of time-borders in which a specified number of activations are expected. The picture below shows an example for this. In the first picture there is a number of occurrences on a timeline.</p>
<p>
<img src="images/model_stimuli_arrival_curve_1.png" style="width:500px"/>
</p>
<p>In the picture below every distance between two activations is measured. The minimum and the maximum distance is added to the table as time-border for the occurrence of two activations. This means that after one activations there has to be at least a gap of one time-unit before the next activations can occur. It also means that there will be always a second activations within eight time units after the last activations. 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 occurrences. 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 activations in the picture above is done here for three activations. Like already mentioned above, this is an additional restriction for occurrence of an activations. </p>
<p>
<img src="images/model_stimuli_arrival_curve_3.png" style="width:400px"/>
</p>
<p>And for four activations:</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 activations will occur. The green line shows the earliest possible time where the activations can occur. </p>
<p>
<img src="images/model_stimuli_arrival_curve_5.png" style="width:600px"/>
</p>
<h4><a id="section3.13.1.3"></a>Common properties of fixed periodic stimuli</h4>
<p>The abstract class
<em>FixedPeriodic</em> defines the common attributes of
<em>Periodic</em>,
<em>PeriodicSynthetic</em> and
<em>PeriodicBurst</em>. In general all period based Stimuli specify periodic occurrences based on an offset and a recurrence. The first occurrence happens after the time units specified by
<em>offset</em>, and then every following occurrence happens after the time units specified by
<em>recurrence</em>. This means, in general, an occurrence of instance i is happening at time t =
<em>offset</em> + i *
<em>recurrence</em>.
</p>
<p>The following figure shows a
<em>Periodic</em> Stimulus example with only a fix offset and recurrence time.
</p>
<p>
<img src="images/model_stimuli_periodic.png" style="width:650px"/>
</p>
<h4><a id="section3.13.1.4"></a>Periodic </h4>
<p>In addition to the standard periodic behavior the
<em>Periodic</em> Stimulus can be extended by a
<em>Jitter</em> e.g. an Gaussian deviation. The activation time of each occurrence jitters according to the values of the distribution as depicted in the following figure. Depending on the
<em>Jitter</em> distribution the upper bound of the current and the lower bound of the next activation can be close to each other or even overlap. The
<em>minDistance</em> value allows the user to define the minimum distance between the current and the next activation.
</p>
<p>
<img src="images/model_stimuli_periodic_jitter.png" style="width:650px"/>
</p>
<p>The recurrence of a
<em>Periodic</em> Stimulus is absolute. This means that a recurrence of 10ms points exactly to the next activation every 10ms. The
<em>Jitter</em> describes the deviation of the occurrence around this absolute value.
</p>
<h4><a id="section3.13.1.5"></a>PeriodicSynthetic</h4>
<p>
<em>PeriodicSynthetic</em> allows to specify a periodic activation of trigger patterns. It is defined by a list of List of
<em>occurrenceTimes</em>, a period
<em>recurrence</em>, and an
<em>offset</em>. Each time value in
<em>occurrenceTimes</em> specifies a single activation at a relative point in time. The moment in time these time values are relative and is defined the following way: an activation of instance i is triggered at time t =
<em>offset</em> + floor(i / m) *
<em>recurrence</em> +
<em>occurrenceTimes</em>[i modulo m].
</p>
<p>The following figure shows a
<em>Synthetic</em> Stimulus example with two periodic activations after the time units T1 and T2.
</p>
<p>
<img src="images/model_stimuli_synthetic.png"/>
</p>
<h4><a id="section3.13.1.6"></a>PeriodicBurst</h4>
<p>The
<em>PeriodicBurst</em> Stimulus specifies a set of burst activations that are periodically repeated. This means that multiple activations occur very close to each other and this recurs in a periodic matter. The burst pattern has a fixed recurrence period and every burst results in multiple activations.
</p>
<p>
<img src="images/model_stimuli_periodic_burst.png" style="width:700px"/>
</p>
<p>The number of occurrences per burst are specified via
<em>occurrenceCount</em>. The
<em>occurrenceMinDinstance</em> defines the minimal distance between them. The
<em>burstLength</em> defines the maximum time the burst pattern can last. If the number of occurrences multiplied with the minimum distance between activations is bigger than the
<em>burstLength</em> only the number of activations that fit into the
<em>burstLength</em> are executed.
</p>
<h4><a id="section3.13.1.7"></a>RelativePeriodic </h4>
<p>In contrast to the
<em>Periodic</em> Stimulus the
<em>RelativePeriodic</em> Stimulus allows to specify relative recurrences. The next activation depends on the current activation time and the added deviation for the next step. The
<em>lower</em> and
<em>upperBound</em> are specified in the
<em>nextOccurrence</em> deviation similar to the
<em>Jitter</em> specification in the
<em>Periodic</em> Stimulus.
</p>
<p>
<img src="images/model_stimuli_periodic_relative.png" style="width:700px"/>
</p>
<h4><a id="section3.13.1.8"></a>VariableRateStimulus</h4>
<p>With the
<em>VariableRate</em> Stimulus the description of task activation based on e.g. the crankshaft rotation speed or other adaptive variable rate activations.
</p>
<p>The
<em>step</em> has to be defined as a base value for the following specifications.<br>
<br>In the deviation
<em>occurrencesPerStep</em> the lower and upper frequency of the variable rate are described. The distribution can be used to describe the standard frequency occurrences. The user can describe that the frequency is distributed e.g. uniformly over the complete frequency band or as another example the occurrences happens mostly at the
<em>Boundaries</em> of the frequency band that can be specified with the
<em>CornerCase</em>
<em>samplingType</em> in the distribution.<br>
<br>The user can set
<em>maxDecrease</em> and
<em>maxIncrease</em> values to describe the number of additional respectively reduced task activations that can occur within a predefined time
<em>step</em>. With these values, the maximum acceleration and maximum deceleration of the stimuli can be calculated.
</p>
<p>
<img src="images/model_stimuli_variablerate.png" style="width:700px"/>
</p>
<p>An additional feature for the
<em>variableRate</em> Stimulus is the description of
<em>simulationScenario</em> that specifies the progression of the
<em>variableRate</em> over time.
<br>In contrast to the generic specification via statistical values the scenario defines the computation via the
<em>samplingOffset</em> and
<em>samplingRecurrence</em> property that is modified by a factor based on a
<em>clock</em>.
</p>
<h3><a id="section3.13.2">3.13.2 </a>Clocks</h3>
<p>The
<em>Clock</em> is triggered based on logical clocks rather than the simulation time, thus providing a dynamic trigger pattern for a simulation.
<em>Clock</em> defines the (variable) rate at which a stimulus will be fired. This rate follows a certain pattern defined by the subclasses:
<em>ClockFunction</em> and
<em>ClockStepList</em>.
</p>
<p>
<img class="scale" src="images/model_stimuli_clocks.png"/>
</p>
<h4><a id="section3.13.2.1"></a>ClockFunction</h4>
<p>A clock function defines the clock period change via a continuous function. There are two functions available:
<em>Sine</em> and
<em>Triangle</em>. They can be chosen by setting the
<em>curveType</em> property.
</p>
<p>In the sine clock function the clock period increases and decreases smoothly following a sine wave pattern. The figure below depicts the attributes used to define the sine wave. Note that the sine wave always lies above the x-axis. Adding a positive or negative
<em>x-Offset</em> will shift the wave horizontally. The clock fires a stimulus whenever the area under the sine curve is a multiple of one (an integral value). If used in a
<em>Scenario</em> this factor can be defined via the
<em>samplingRecurrence</em> attribute. As can be seen, the size of the area can be influenced by the
<em>yOffset</em> and
<em>peakToPeak</em> attributes. In the example shown in the figure the first stimulus is fired at 1.3s, second at 2.06s and so on.
</p>
<p>
<img src="images/model_stimuli_clocks_sine.png" style="width:850px"/>
</p>
<p>The triangle clock function increases and decreases at a constant rate. The shape of this clock function is governed by the same attributes as the sine wave, only the underlying mathematical definition is different. In the example figure below, the first activation occurs at 0.828s, the second at 1.464s and so on.</p>
<p>
<img src="images/model_stimuli_clocks_triangle.png" style="width:650px"/>
</p>
<h4><a id="section3.13.2.2"></a>ClockStepList</h4>
<p>The list of clock steps defines the clock period change via a step function. Each
<em>ClockStep</em> of that function is defined by a
<em>frequency</em> and a
<em>time</em> stamp. The optional period attribute of the clock step list can be used to repeat the pattern (exactly like the recurrence in the
<em>PeriodicSynthetic</em> stimulus). If the period is not set, the clock rate will remain the same after the last clock step change. Considering the clock steps: &lt;1Hz, 1s&gt;, &lt;3Hz, 3s&gt;, &lt;2Hz, 5s&gt;, &lt;0Hz, 6s&gt;, &lt;2Hz, 7s&gt;, a sampling recurrence of 2, and a period of 9s, the clock step function will result in the plot depicted in the following figure.
</p>
<p>
<img src="images/model_stimuli_clocks_steplist.png" style="width:750px"/>
</p>
<h4><a id="section3.13.2.3"></a>Example</h4>
<p>The engine crankshaft is a good example in which Clocks can be used to model the behavior. Let's suppose a scenario in which a stimulus is triggered each time the rotating crankshaft reaches a specific angle.</p>
<p>In this example, the engine speed steeply increases from 3000rpm to 6000rpm in 5s, then the speed again decreases to 3000rpm in 5s. An stimulus shall be triggered when the engine crankshaft reaches 30 degrees. Triggering should repeat every two rotations.</p>
<p>Steeply increasing and decreasing pattern fits to the triangle clock function. The equations below show the calculations for the triangle clock function.
<em>xOffset</em> is added to make the triangle wave begin at the desired engine speed of 3000rpm:
</p>
<ul>
<li>
<em>yOffset</em> = min.ticks = 3000rpm = 50rps = 50Hz
</li>
<li>
<em>peakToPeak</em> = max.ticks – min.ticks = 6000rpm – 3000rpm = 50Hz
</li>
<li>
<em>period</em> = 2 * risingSteepTime = 2 * 5s = 10s
</li>
<li>
<em>xOffset</em> = risingSteepTime / 2 = 2.5s
</li>
</ul>
<p>
<img src="images/model_stimuli_clocks_triangle_example.png" style="width:750px"/>
</p>
<p>Task shall be triggered when the engine crankshaft reaches 30 degrees. Triggering should repeat for every two rotations. The scenario configuration for this example can then be derived as follows:</p>
<ul>
<li>
<em>samplingOffset</em> = firstTriggerAngle = 30
<sup>o</sup> / 360
<sup>o</sup> = 0.0833
</li>
<li>
<em>samplingRecurrence</em> = everySecondRotation = 2
</li>
</ul>
<p>
<img src="images/model_stimuli_clocks_triangle_example_scenario.png" style="width:750px"/>
</p>
<p>The engine crankshaft reaches 30 degrees at 1.66ms. From then on, the crankshaft completes 2 rotations at 41.49ms and 4 rotations at 81ms.</p>
<h3><a id="section3.13.3">3.13.3 </a>Mode Value List and Execution Condition</h3>
<p>It is possible to change mode label values when a stimulus is executed. The mode labels and their new values are stored in the
<strong>set-mode-value-list</strong>. Via an
<strong>execution-condition</strong> modes also determine if a stimulus is executed.
</p>
<p>
<img class="scale" src="images/model_stimuli_modevaluelist.png"/>
</p>
<ul class="validation-rule">
<li>
<em>ModeValue</em>: The
<em>value</em> string must be a valid element of the corresponding
<em>Mode</em>!
</li>
</ul>
<p>The
<strong>set-mode-value-list</strong> indicates: Each time the stimulus is executed all mode labels in this list are set to the corresponding value.
</p>
<p>The
<strong>execution-condition</strong> is used to determine if a stimulus is executed.
</p>
<h2><a id="section3.14">3.14 </a>Software Model</h2>
<p>The AMALTHEA software model is central accessible through the
<i>SWModel</i> element.
</p>
<h3><a id="section3.14.1">3.14.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>AbstractMemoryElement</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>AbstractMemoryElement</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.14.2">3.14.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>OsDataConsistency</i>, otherwise it inherits them (see <a href="#os-data-consistency">OS Data Consistency</a>).
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>stabilityLevel</i>
</td>
<td colspan="1" rowspan="1">Enumeration value to represent the data stability level of the label. If set, it overwrites the global settings stated by the
<i>OsDataConsistency</i>, otherwise it inherits them (see <a href="#os-data-consistency">OS Data Stability</a>).
</td>
</tr>
</table>
<h3><a id="section3.14.3">3.14.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.14.4">3.14.4 </a>Data Types</h3>
<h4><a id="section3.14.4.1"></a>General Information</h4>
<p>The AMALTHEA data model supports meta information for data types. Therefore the element
<i>TypeDefinition</i> exists in the software part of the model. It consists of the name and size to define a data type.
<i>BaseTypeDefinition</i> has the additional possibility to define the representation of these data types in a target environment (e.g. AUTOSAR), represented by the
<i>Alias</i> element.
</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="https://en.wikipedia.org/wiki/Data_type">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.14.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 alias for AR (Boolean) and C (bool)</li>
<li>Char16 type with size of 16 bits and alias 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 (charArray) and valid (Boolean)</li>
</ul>
<p>Note: The picture shows the element types for better understanding!</p>
<p>
<img class="gray" src="images/model_sw_type_sample.png"/>
</p>
<h3><a id="section3.14.5">3.14.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, event or custom (free textual description only, no predefined semantic) 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>
<ul class="validation-rule">
<li>
<em>PeriodicActivation</em>: The
<em>Time</em> object in the role of
<em>min</em> must not contain a negative value!
</li>
<li>
<em>PeriodicActivation</em>: The
<em>Time</em> object in the role of
<em>max</em> must not contain a negative value!
</li>
<li>
<em>PeriodicActivation</em>: The
<em>Time</em> object in the role of
<em>offset</em> must not contain a negative value!
</li>
<li>
<em>PeriodicActivation</em>: The
<em>Time</em> object in the role of
<em>deadline</em> must not contain a negative value!
</li>
<li>
<em>SingleActivation</em>: The
<em>Time</em> object in the role of
<em>min</em> must not contain a negative value!
</li>
<li>
<em>SingleActivation</em>: The
<em>Time</em> object in the role of
<em>max</em> must not contain a negative value!
</li>
</ul>
<h3><a id="section3.14.6">3.14.6 </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 the activation that is at runtime level represented by a
<i>Stimulus</i>. A
<i>Task</i> or
<i>ISR</i> contains
<i>calls</i> either to other Tasks (via inter process activation) or Runnables. These types of
<i>calls</i> are included in the
<i>activityGraph</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>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>Process</i>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>activityGraph</i>
</td>
<td colspan="1" rowspan="1">List of activities (e.g. runnable calls, label accesses). 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>
</table>
<h3><a id="section3.14.7">3.14.7 </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>Unlike tasks, which are activated in the context for the operating system, runnables are called by tasks or other runnables.
</p>
<p>Runnables and Services in the AMALTHEA model can have call parameters. It is possible to specify the arguments of a service call and potential data dependencies. Based on these types of information, an additional analysis can be performed.</p>
<h3><a id="section3.14.8">3.14.8 </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>activations</i>
</td>
<td colspan="1" rowspan="1">Although runnables in the simulation can only be called by tasks, it is possible to specify activation patterns for a runnable.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>executionCondition</i>
</td>
<td colspan="1" rowspan="1">It is possible to specify an execution condition for a runnable (depending on modes).</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>activityGraph</i>
</td>
<td colspan="1" rowspan="1">Top level object containing
<i>ActivityGraphItem</i> objects, representing runtime, 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>
</table>
<h3><a id="section3.14.9">3.14.9 </a>Activity Graph</h3>
<p>A
<i>ActivityGraph</i> is the root container of
<i>ActivityGraphItems</i>. In addition some of the items can also contain sub items. These items are implementing the interface
<i>IActivityGraphItemContainer</i>.
</p>
<p>
<img src="images/model_sw_activitygraph_item_container.png"/>
</p>
<p>The following picture shows the structure of a
<i>Activity Graph</i>. The
<i>Activity Graph Items</i> are used to define detailed behavior. 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.
</p>
<p>
<img src="images/model_sw_activitygraph_structure.png"/>
</p>
<h3><a id="section3.14.10">3.14.10 </a>Activity Graph Items</h3>
<p>The
<i>ActivityGraphItems</i> are describing the detailed behavior of a
<i>Process</i> or
<i>Runnable</i>. This can be either an abstraction of runtime 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>
<p>
<img src="images/model_sw_activitygraph_items.png"/>
</p>
<h4><a id="section3.14.10.1"></a>Groups</h4>
<p>A
<i>Group</i> is used to structure the
<i>ActivityGraphItems</i>. The
<i>boolean</i> attribute
<i>isOrdered</i> indicates if the execution order of the contained elements is fixed or random.
</p>
<p>
<img src="images/model_sw_activity_graph_items__group.png"/>
</p>
<h4><a id="section3.14.10.2"></a>Mode Switch</h4>
<p>With the
<i>ModeSwitch</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>ModeSwitch</i> uses the value of mode labels to decide which entry has to be executed. The first fulfilled condition determines the path to execute.
<br>A
<i>ModeSwitchEntry</i> object is used to represent an execution path. A mode condition is defined for each entry (via ModeConditionDisjunction).
<br>At the
<i>ModeSwitch</i> it is also possible to define a default path, which is executed if no condition of the
<i>ModeSwitchEntries</i> fits to the current mode settings.
</p>
<p>
<img src="images/model_sw_activity_graph_items__mode_switch.png"/>
</p>
<h4><a id="section3.14.10.3"></a>Probability Switch</h4>
<p>Each entry (path) of a
<i>ProbabilitySwitch</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>ProbabilitySwitchEntries</i> in the surrounding switch.
</p>
<p>
<img src="images/model_sw_activity_graph_items__probability_switch.png"/>
</p>
<h4><a id="section3.14.10.4"></a>Ticks</h4>
<p>
<i>Ticks</i> allow to specify the required execution "time" in a basic way. They are the equivalent of cycles in the hardware domain and the execution time can easily be calculated if the frequency of the executing
<i>ProcessingUnit</i> (PU) is known.
<br>Detailed definition: see <a href="#basics-ticks">Ticks</a>
</p>
<h4><a id="section3.14.10.5"></a>Execution Need</h4>
<p>
<i>ExecutionNeed</i> allows to specify the required execution "time" in a more abstract way. Multiple
<i>NeedEntries</i> can be used to specify execution characteristics. There is a map of default entries and (optional) maps of entries for specific hardware types (e.g. FPGA). These extended entries are also implemented as a map with a processing unit definition as the key.
</p>
<p>
<img src="images/model_sw_activity_graph_items__execution_need.png"/>
</p>
<p>A simple approach (equivalent to the
<i>RunnableInstructions</i> in older versions of the AMALTHEA model) is the specification of the "number of generic instructions" that have to be executed. Together with the hardware feature "instructions per cycle (IPC)" and the frequency of a processing unit it permits the calculation of the execution time on a specific processing unit.
</p>
<p>
<img src="images/model_sw_hw_features_executionneed.png"/>
</p>
<p>With the generic concept of
<i>ExecutionNeeds</i> it is also possible to describe more detailed characteristics, e.g. instruction mixes of floating point operations, integer operations, load/store operations, etc., or any other relevant aspect.
</p>
<h4><a id="section3.14.10.6"></a>Calls and AUTOSAR communication</h4>
<p>
<img class="scale" src="images/model_sw_activity_graph_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/>
<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).</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>SynchronousServerCall</i>
</td>
<td colspan="1" rowspan="1">A synchronous server call with defined waiting behaviour.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>AsynchronousServerCall</i>
</td>
<td colspan="1" rowspan="1">An asynchronous server call with (optional) specification of result runnable.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>GetResultsServerCall</i>
</td>
<td colspan="1" rowspan="1">Get the result of a previous asynchronous server call (with defined blocking behaviour).</td>
</tr>
</table>
<h4><a id="section3.14.10.7"></a>Label Access</h4>
<p>
<img class="scale" src="images/model_sw_activity_graph_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">OS Data Consistency</a>).</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>implementation</i>
</td>
<td colspan="1" rowspan="1">Describes how a label access is implemented: <ul><li>
<strong>explicit</strong>: also known as "direct" </li><li>
<strong>implicit</strong>: also known as "optimized"</li><li>
<strong>timed</strong></li></ul>
</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>chunkProcessingTicks</strong>: Number of ticks that will be executed to process one chunk (algorithmic overhead). </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.14.10.8"></a>Channel Access</h4>
<p>
<img src="images/model_sw_activity_graph_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>chunkProcessingTicks</strong>: Number of ticks that will be executed to process one chunk (algorithmic overhead). </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.14.10.9"></a>Semaphore Access</h4>
<p>
<img src="images/model_sw_activity_graph_items__semaphore_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>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>
<tr>
<td colspan="1" rowspan="1">
<i>access</i>
</td>
<td colspan="1" rowspan="1">Defines the type of access (request, exclusive, release).</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>waitingBehaviour</i>
</td>
<td colspan="1" rowspan="1">Defines if the process is blocking the core when it waits (active) or not (passive).</td>
</tr>
</table>
<h4><a id="section3.14.10.10"></a>Mode Label Access</h4>
<p>
<img src="images/model_sw_activity_graph_items__mode_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>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>ModeLabelAccessEnum</i>: <ul><li>
<strong>read</strong>: indicates that the behavior of the runnable is influenced by the current value of the
<i>ModeLabel</i>.</li><li>
<strong>set</strong>: represents the change of a mode label. The defined
<i>value</i> is set.</li><li>
<strong>increment</strong> /
<strong>decrement</strong>: changes a mode label. The value is increased / decreased by
<i>step</i>. In case of an
<i>EnumMode</i> the next / previous literal is set (according to
<i>step</i> limited by the range of literals).</li></ul>
</td>
</tr>
</table>
<ul class="validation-rule">
<li>
<em>ModeLabelAccess</em>: The
<em>value</em> string must be a valid element of the corresponding
<em>Mode</em>!
</li>
</ul>
<h4><a id="section3.14.10.11"></a>Custom Event Trigger</h4>
<p>The
<i>Custom Event Trigger</i> references an event of type
<i>Custom Event</i>. The execution of a
<i>Custom Event Trigger</i> entry triggers the corresponding event that can be observed by an
<i>Event Stimulus</i>.
</p>
<p>
<img src="images/model_sw_activity_graph_items__triggers.png"/>
</p>
<h4><a id="section3.14.10.12"></a>Enforced Migration</h4>
<p>Each task is controlled by at least one task scheduler. A task scheduler is the resource owner of one or multiple processor cores (The task scheduler decides on which of its cores the task is executed). The
<i>Enforced Migration</i> forces the task to switch to another task scheduler. Therefore the
<i>Enforced Migration</i> entry contains a reference to the new task scheduler.
</p>
<p>This element is used as a short notation to simplify the simulation of different design possibilities. It should normally be modeled as two separate tasks and an inter process trigger.</p>
<h4><a id="section3.14.10.13"></a>Inter Process Trigger</h4>
<p>The
<i>Inter Process Trigger</i> references a stimulus of type
<i>Inter Process Stimulus</i>. The execution of an
<i>Inter Process Trigger</i> entry triggers the processes that are mapped to this stimulus.
</p>
<h4><a id="section3.14.10.14"></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.14.10.15"></a>Terminate Process</h4>
<p>If a
<i>Terminate Process</i> is reached during the execution of a
<i>Activity 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>Activity 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.14.10.16"></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. Elements are
<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 behaviour</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>
<h4><a id="section3.14.10.17"></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>RunnableCall</i>. 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>
</ul>
<h3><a id="section3.14.11">3.14.11 </a>Modes</h3>
<p>The next diagram shows the overall picture, the sub chapters describe the details.</p>
<p>
<img class="scale" src="images/model_sw_modes_overview.png"/>
</p>
<p>Modes are mainly used in
<i>Mode Conditions</i> to describe the conditional execution of a
<i>ModeSwitchEntry</i>, a
<i>Runnable</i> or a
<i>Stimulus</i>.
</p>
<h4><a id="section3.14.11.1"></a>Modes and Mode Labels</h4>
<p>
<img class="scale" src="images/model_sw_modes.png"/>
</p>
<p>The
<i>Mode</i> element denotes the type and the possible values of a specific system state. The subclasses
<i>EnumMode</i> and
<i>NumericMode</i> describe the values that are allowed for the corresponding
<i>ModeLabel</i>. In case of a
<i>EnumMode</i> the
<i>initialValue</i> has to be the name of one of the contained
<i>ModeLiterals</i>. For
<i>NumericMode</i> the
<i>initialValue</i> has to be the string representation of an integer.
</p>
<p>The
<i>Mode Label</i> element represents a concrete representation 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 to the corresponding
<i>Mode</i> definition
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<i>initialValue</i>
</td>
<td colspan="1" rowspan="1">String representation of the initial value</td>
</tr>
</table>
<h4><a id="section3.14.11.2"></a>Mode Changes</h4>
<p>The value of the mode label can be changed using the set-mode-value-list of a
<i>Stimulus</i>.
</p>
<p>Another possibility is a write access within a Runnable via a
<i>Mode Label Access</i>.
</p>
<h4><a id="section3.14.11.3"></a>Mode Conditions</h4>
<p>Mode conditions allow to specify dedicated states of the overall system.
<br>Depending on the condition evaluation (via
<i>isSatisfiedBy()</i>) switches can be executed or stimuli can be influenced.
<br>The ModeValueMap represents the system state that has to be provided as an external input, e.g. from a simulation or analysis tool.
</p>
<p>
<img class="scale" src="images/model_sw_modecondition.png"/>
</p>
<h3><a id="section3.14.12">3.14.12 </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 activity graph can be analyzed and computed to get the right order and parallelization of the elements and dependencies.
</p>
<h3><a id="section3.14.13">3.14.13 </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>
<img src="images/model_sw_process_chain.png"/>
</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.14.14">3.14.14 </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.14.15">3.14.15 </a>Section</h3>
<p>Section (Virtual Memory Section) is used to group the memory elements (Labels, Runnables). This is achieved by associating the
<strong>Section</strong> element to
<strong>Label</strong> &amp;
<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>
<h3><a id="section3.14.16">3.14.16 </a>Data Dependencies and Runnable Parameters</h3>
<h4><a id="section3.14.16.1"></a>Overview</h4>
<p>The purpose of following model elements is to describe a high level data flow. Parameters of runnables (or services) and specific call arguments allow to model a behavior that depends on the call tree but the detailed computation and the control flow within a runnable are not taken into account. Therefore only "potential" influences are modeled. The following picture shows this data flow with dashed lines.</p>
<p>
<img src="images/model_sw_dataflow_overview.png"/>
</p>
<h4><a id="section3.14.16.2"></a>Elements with data dependency</h4>
<p>The data flow is specified with "depends on" references. Elements that can specify a dependency are:</p>
<ul>
<li>
<i>
<b>LabelAccess</b>
</i> of type "WRITE"
</li>
<li>
<i>
<b>CallArgument</b>
</i> that refers to an "IN" (or "INOUT") parameter
</li>
<li>
<i>
<b>RunnableParameter</b>
</i> with direction "OUT" (or "INOUT")
</li>
</ul>
<p>
<img src="images/model_sw_depends_on.png"/>
</p>
<h4><a id="section3.14.16.3"></a>Data Dependency</h4>
<p>A data dependency defines the elements that can influence a value that is written or transferred. Possible origins are:</p>
<ul>
<li>
<i>
<b>Label</b>
</i>
</li>
<li>
<i>
<b>RunnableParameter</b>
</i> with direction "IN" (or "INOUT")
</li>
<li>
<i>
<b>CallArgument</b>
</i> that refers to an "OUT" (or "INOUT") parameter
</li>
</ul>
<p>
<img src="images/model_sw_data_dependency.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 development like partitioning and mapping.</li>
<li>APP4MC Tracing – Record, analyze and transform runtime traces of the embedded system.</li>
<li>APP4MC Validation – Model validations (can 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 ids 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 Visualization</h2>
<h3><a id="section4.2.1">4.2.1 </a>Visualization framework</h3>
<p>The plug-in
<code>org.eclipse.app4mc.visualization.ui</code> provides a small framework to visualize model elements. It contains a view part
<code>VisualizationPart</code> that can be opened via
</p>
<ul>
<li>
<i>Window → Show View → Other... → APP4MC → APP4MC Visualizations</i>,
</li>
<li> or via right click on an element and selecting
<i>Open APP4MC Visualization</i>.
</li>
</ul>
<p>Via the context menu it is also possible to open multiple instances of the
<code>VisualizationPart</code>.
</p>
<p>On selecting a model element, the VisualizationPart is updated to render a corresponding visualization. The visualization to render is searched in the ModelVisualizationRegistry OSGi service. If multiple visualizations are registered, the first one will be selected by default, unless the user has selected another visualization before.</p>
<p>The visualization view has 3 buttons in the toolbar:</p>
<ol>
<li>
<b>Visualization dropdown</b><br>The dropdown contains all available visualizations for the current active selection. A click on the image will reload the visualization.
</li>
<li>
<b>Pin visualization</b><br>The selection handling will be disabled so the visualization gets not updated on model selection changes.
</li>
<li>
<b>Select model element</b><br>Selects the current visualized model element in the model editor. Useful for example if a visualization is pinned and the selection in the model editor changed.
</li>
</ol>
<p>
<img src="images/visualization-view.png"/>
</p>
<p>The whole red area can be used to render the visualization.</p>
<h3><a id="section4.2.2">4.2.2 </a>Contributing a new model visualization</h3>
<p>To contribute a new visualization to the framework, the followings steps have to be done:</p>
<ol>
<li>Create a new plug-in for the visualization contribution.<br><br></li>
<li>Add at least the following dependencies:
<ul>
<li>Required Plug-ins
<ul>
<li>
<strong>org.eclipse.jface</strong><br>(to be able to contribute to the view)
</li>
</ul>
</li>
<li>Imported Packages
<ul>
<li>
<strong>org.eclipse.app4mc.amalthea.model</strong><br>(to get access to the model element that should be rendered)
</li>
<li>
<strong>org.eclipse.app4mc.visualization.ui.registry</strong><br>(needed to import the necessary interface)
</li>
<li>
<strong>org.osgi.service.component.annotations</strong>: In the properties, select Minimum Version as
<strong>1.3.0</strong> inclusive<br>(needed to get access to the OSGi DS annotations)<br><br>
</li>
</ul>
</li>
</ul>
</li>
<li>Create a new Visualization implementation that follows this pattern:</li>
</ol>
<pre xml:space="preserve"><code>@Component(property= {
"name=Runnable Visualization",
"description=Render the name of the Runnable"
})
public class SampleVisualization implements Visualization {
@PostConstruct
public void createVisualization(Runnable runnable, Composite parent) {
Label label = new Label(parent, SWT.NONE);
label.setText(runnable.getName());
}
}
</code></pre>
<p><!-- --></p>
<p>To register the Visualization implementation the framework utilizes OSGi DS. This means:</p>
<ul>
<li>The class needs to implement
<strong>Visualization</strong> (only a marker interface needed for OSGi service injection)
</li>
</ul>
<pre xml:space="preserve"><code>It is mandatory to place this class inside a user defined package (i.e., other than default package)
</code></pre>
<p><!-- --></p>
<ul>
<li>The class needs to be annotated with
<strong>@Component</strong> (ensure DS annotation support is enabled in your workspace)
</li>
</ul>
<pre xml:space="preserve"><code>To enable DS annotation for the entire workspace,enable the following option in your eclipse workspace at:
Window -&gt; Preferences -&gt; Plug-in Development -&gt; DS Annotations -&gt; "Enable descriptors from annotated sources"
</code></pre>
<p><!-- --></p>
<p>Once above steps are followed, visualization plugin contents should look like below:</p>
<p>
<img class="gray_scale" src="images/visualization-plugin-content.png"/>
</p>
<p>The Visualization will automatically be registered in the
<strong>ModelVisualizationRegistry</strong> with the appropriate meta-data. The meta-data is extracted from the class definition and the method annotated with
<strong>@PostConstruct</strong>. Additionally information can be provided via component properties on the
<strong>@Component</strong> annotation.
</p>
<p>The following component properties are supported:</p>
<dl>
<dt>id</dt>
<dd>Defaults to the fully qualified class name of the service.
<br>Used to uniquely identify the last selected visualization.
</dd>
</dl>
<dl>
<dt>name</dt>
<dd>Defaults to the simple class name of the service.
<br>Used in the visualization dropdown as label of the menu item.
</dd>
</dl>
<dl>
<dt>description</dt>
<dd>Defaults to null.
<br>Used in the visualization dropdown as tooltip of the menu item.
</dd>
</dl>
<dl>
<dt>type</dt>
<dd>Defaults to the type of the first parameter of the @PostConstruct method.
<br>Used to register the visualizations for a given model type.
<br>
<b>Note: It is not recommended to override the type configuration.</b>
</dd>
</dl>
<p>The rendering is triggered via Eclipse injection mechanisms. Therefore a method annotated with
<b>@PostConstruct</b> needs to be created. This method needs at least two parameters in the following order:
</p>
<ol>
<li>
<b>Model type</b> or
<b>java.util.List&lt;Model type&gt;</b><br>The first parameter needs to be the type or a List of the type that should be handled by this Visualization.
</li>
<li>
<b>Composite</b><br>The parent Composite on which the rendering should be performed.
</li>
</ol>
<p>So the following method signatures would be valid for Visualizations for Runnable model elements:</p>
<pre xml:space="preserve"><code>@PostConstruct
public void createVisualization(Runnable runnable, Composite parent) {}
@PostConstruct
public void createVisualization(List&lt;Runnable&gt; runnable, Composite parent) {}
</code></pre>
<p><!-- --></p>
<p>You can specify additional parameters that should be injected. Only the first parameter has a semantic to be able to extract the model type for which the Visualization is implemented.</p>
<p>Additionally a method annotated with
<strong>@PreDestroy</strong> can be added that gets called before the Visualization is disposed. This gives the opportunity to clean up resources if necessary.
</p>
<p>As the service instance creation is done by the OSGi Service Component Runtime, the following information needs to be considered with regards to injection:</p>
<ol>
<li>You can use @Reference to get other OSGi services injected.</li>
<li>There is no field or constructor injection available via Eclipse injection.<br>(usage of @Inject on fields or constructors will not work)</li>
<li>In general you should not use fields/members to store rendering related information on an instance level.</li>
</ol>
<h2><a id="section4.3">4.3 </a>Model Validation</h2>
<h3><a id="section4.3.1">4.3.1 </a>Validation framework</h3>
<p>APP4MC contains a flexible framework based on standard EMF validations.</p>
<p>The main plugins:</p>
<dl>
<dt>org.eclipse.app4mc.validation.core</dt>
<dd>Basic interfaces and helper classes to organize and execute validations.</dd>
</dl>
<dl>
<dt>org.eclipse.app4mc.validation.ui</dt>
<dd>User interface components: profile selection dialog, marker helper.</dd>
</dl>
<dl>
<dt>org.eclipse.app4mc.amalthea.validations</dt>
<dd>AMALTHEA standard profile and validations</dd>
</dl>
<h3><a id="section4.3.2">4.3.2 </a>Validations</h3>
<p>Validations have to implement the IValidation interface. Additional information is specified with annotations:</p>
<ul>
<li>@Validation</li>
</ul>
<p>Example:</p>
<p>
<img src="images/code_validation_1.png"/>
</p>
<h3><a id="section4.3.3">4.3.3 </a>Profiles</h3>
<p>Profiles have to implement the IProfile interface. Details are specified with the following annotations:</p>
<ul>
<li>@Profile</li>
<li>@ProfileGroup</li>
<li>@ValidationGroup</li>
</ul>
<p>Example:</p>
<p>
<img src="images/code_profile_1.png"/>
</p>
<p>
<img src="images/code_profile_2.png"/>
</p>
<h2><a id="section4.4">4.4 </a>Model Workflow</h2>
<h3><a id="section4.4.1">4.4.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.</p>
<p>The
<a href="https://www.eclipse.org/ease/">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.
</p>
<p>As an alternative APP4MC provides also an implementation for the
<a href="http://www.eclipse.org/Xtext/documentation/302_configuration.html">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.
</p>
<p>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.mwe2</dt>
<dd>Provides basic classes for usage with MWE2</dd>
</dl>
<h3><a id="section4.4.2">4.4.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>WorkflowComponent1</code> and configure it if needed with the proper setter methods
</li>
<li>Call the
<i>run</i> method of
<code>WorkflowComponent1</code> and pass the context
</li>
<li>Create an instance of
<code>WorkflowComponent2</code> and configure it if needed with the proper setter methods
</li>
<li>Call the
<i>run</i> method of
<code>WorkflowComponent2</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.4.3">4.4.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.4.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.4.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.4.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.4.4">4.4.4 </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/">EASE</a> scripting environment.
<br>The modules are provided by the plugin
<i>org.eclipse.app4mc.amalthea.workflow.
<strong>ease</strong>
</i>.
</p>
<h4><a id="section4.4.4.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 -&gt; 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.4.5">4.4.5 </a>MWE2 Workflow</h3>
<p>The plugin
<i>org.eclipse.app4mc.amalthea.workflow.
<strong>mwe2</strong>
</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">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.mwe2</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.4.5.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.4.5.1.1"></a>Reader</h5>
<p>The component
<code>org.eclipse.app4mc.amalthea.workflow.mwe2.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.4.5.1.2"></a>Writer</h5>
<p>The component
<code>org.eclipse.app4mc.amalthea.workflow.mwe2.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.4.5.1.3"></a>Add Schedule Points</h5>
<p>The component
<code>org.eclipse.app4mc.amalthea.workflow.mwe2.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.4.6">4.4.6 </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 --&gt; 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:green">
<b>yes(*)</b>
</td>
<td colspan="1" rowspan="1"><ul><li>
<strong>MWE2</strong>: As new Java runtime is created, all the required plugins &amp; jars are added in the classpath </li><li>
<strong>EASE</strong>: The runtime from workbench and the jars from the classpath of a plugin (created newly in the runtime workbench) are loaded by EASE. </li></ul>
</td>
</tr>
</table>
<p>*: This feature is only available for EASE versions newer than 0.3.0. Older versions will fail with an exception java.lang.NoClassDefFoundError: &lt;your used class from 3rd party lib&gt;</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.4.7">4.4.7 </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.4.8">4.4.8 </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.4.8.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 -&gt; Run As -&gt; 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.5">4.5 </a>Model Migration</h2>
<h3><a id="section4.5.1">4.5.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.5.2">4.5.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.5.3">4.5.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>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>
<blockquote>
<p>First version of APP4MC was 0.7.0</p>
</blockquote>
<blockquote>
<p>From version 0.9.3 of APP4MC, there will not be any support for migration of AMALTHEA models based on ITEA releases (itea.103, itea.110, itea.111).</p>
</blockquote>
<p>
<strong>Cache Builders:</strong> This component is responsible for building the required cache, by querying the input models or storing the necessary information - &gt; before executing the Converters for specific migration step (
<em>e.g. 0.9.0 to 0.9.1</em>)
<br>Scope of each Cache Builder component is only during a step of model migration (
<em>e.g. 0.9.0 to 0.9.1</em>)
</p>
<blockquote>
<p>Each Cache Builder component is tightly coupled to a specific AMALTHEA model version.</p>
</blockquote>
<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 tightly 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>
<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. 0.9.0 to 0.9.1</em>)
</p>
<blockquote>
<p>This component is tightly coupled to input and output version of the AMALTHEA model files which are selected (explicitly/implicitly) for model migration.</p>
</blockquote>
<p>
<em>Example how Post-Processor's are invoked:</em>
</p>If Post-Processor is defined with input-model-versions :0.9.0, 0.9.1 and output version 0.9.2.In case if the migration is invoked from 0.9.0 to 0.9.2 for the specified AMALTHEA models.Following migration steps are to be performed internally:
<ul>
<li>0.9.0 to 0.9.1</li>
<li>0.9.1 to 0.9.2</li>
</ul>
<blockquote>
<p>In this case post-processor is invoked after migration step 0.9.1 to 0.9.2 </p>
</blockquote>
<p>Flexibility of post-processors 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.5.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 id="meta-model-changes"><a id="section4.5.4">4.5.4 </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>
<p>
<em>
<span style="color:brown">Hint: Model extensions (that do not require migration) are not listed here.</span>
</em>
</p>
<h4><a id="section4.5.4.1"></a>Version APP4MC 0.9.8 to APP4MC 0.9.9</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.9.8)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.9)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.8</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.9</td>
</tr>
</table>
<h4><a id="section4.5.4.2"></a>Version APP4MC 0.9.7 to APP4MC 0.9.8</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.9.7)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.8)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.7</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.8</td>
</tr>
</table>
<h4><a id="section4.5.4.3"></a>Version APP4MC 0.9.6 to APP4MC 0.9.7</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.9.6)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.7)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.6</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.7</td>
</tr>
</table>
<p>
<strong>Following Classes behavior is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed behavior in 0.9.7</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Component</td>
<td colspan="1" rowspan="1">componentsModel</td>
<td colspan="1" rowspan="1">Component has reference to ports and its type is change to new type ComponentPort.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ComponentPort</td>
<td colspan="1" rowspan="1">componentsModel</td>
<td colspan="1" rowspan="1">ComponentPort has reference to ComponentInterface.</td>
</tr>
</table>
<p>
<strong>Following Classes are renamed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name in 0.9.6</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed Class name in 0.9.7</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">CallGraph</td>
<td colspan="1" rowspan="1">ActivityGraph</td>
<td colspan="1" rowspan="1">sw</td>
</tr>
<tr>
<td colspan="1" rowspan="1">CallGraphItem</td>
<td colspan="1" rowspan="1">ActivityGraphItem</td>
<td colspan="1" rowspan="1">sw</td>
</tr>
</table>
<p>
<strong>Below references are changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.6)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.7)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.6)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.7)</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">ports</td>
<td colspan="1" rowspan="1">ports</td>
<td colspan="1" rowspan="1">Port</td>
<td colspan="1" rowspan="1">ComponentPort</td>
<td colspan="1" rowspan="1">Component</td>
<td colspan="1" rowspan="1">componentsModel</td>
<td colspan="1" rowspan="1">ports reference is changed to new type ComponentPort</td>
</tr>
</table>
<p>
<strong>Below references are renamed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.6)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.7)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.6)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.7)</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">tasks</td>
<td colspan="1" rowspan="1">processes</td>
<td colspan="1" rowspan="1">AbstractProcess</td>
<td colspan="1" rowspan="1">AbstractProcess</td>
<td colspan="1" rowspan="1">Component</td>
<td colspan="1" rowspan="1">ComponentsModel</td>
<td colspan="1" rowspan="1">tasks reference is renamed to processes</td>
</tr>
<tr>
<td colspan="1" rowspan="1">callGraph</td>
<td colspan="1" rowspan="1">activityGraph</td>
<td colspan="1" rowspan="1">CallGraph</td>
<td colspan="1" rowspan="1">ActivityGraph</td>
<td colspan="1" rowspan="1">Process</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">callGraph reference is renamed to activityGraph</td>
</tr>
<tr>
<td colspan="1" rowspan="1">callGraph</td>
<td colspan="1" rowspan="1">activityGraph</td>
<td colspan="1" rowspan="1">CallGraph</td>
<td colspan="1" rowspan="1">ActivityGraph</td>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">callGraph reference is renamed to activityGraph</td>
</tr>
</table>
<h4><a id="section4.5.4.4"></a>Version APP4MC 0.9.5 to APP4MC 0.9.6</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.9.5)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.6)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.5</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.6</td>
</tr>
</table>
<p>
<strong>Following Classes behavior is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed behavior in 0.9.6</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">RunnableCall</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">RunnableCall has reintroduced the reference to Counter as an attribute.It is possible now to create counter for RunnableCall.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AbstractEventChain</td>
<td colspan="1" rowspan="1">constraints</td>
<td colspan="1" rowspan="1">Now only one type of EvenChainItems are possible.EventchainItemType indicates if it is sequence or parallel</td>
</tr>
</table>
<p>
<strong>Following Classes are renamed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name in 0.9.5</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed Class name in 0.9.6</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeCondition</td>
<td colspan="1" rowspan="1">ModeValueCondition</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
</tr>
</table>
<p>
<strong>Below references are changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.5)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.6)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.5)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.6)</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">segments</td>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">EventChainItem</td>
<td colspan="1" rowspan="1">EventChainItem</td>
<td colspan="1" rowspan="1">AbstractEventChain</td>
<td colspan="1" rowspan="1">constraints</td>
<td colspan="1" rowspan="1">segments reference is renamed to items</td>
</tr>
<tr>
<td colspan="1" rowspan="1">strands</td>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">EventChainItem</td>
<td colspan="1" rowspan="1">EventChainItem</td>
<td colspan="1" rowspan="1">AbstractEventChain</td>
<td colspan="1" rowspan="1">constraints</td>
<td colspan="1" rowspan="1">strands reference is renamed to items</td>
</tr>
</table>
<h4><a id="section4.5.4.5"></a>Version APP4MC 0.9.4 to APP4MC 0.9.5</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.9.4)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.5)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.4</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.5</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">runnableItems</td>
<td colspan="1" rowspan="1">RunnableItem</td>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">runnableItems reference has been removed and replaced with new attribute CallGraph to provide all child elements same as Task.</td>
</tr>
</table>
<p>
<strong>Following Classes are removed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name in 0.9.4</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">CallSequence</td>
<td colspan="1" rowspan="1">Equivalent element is Group in 0.9.5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">RunnableModeSwitch</td>
<td colspan="1" rowspan="1">Equivalent element is ModeSwitch in 0.9.5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">RunnableProbabilitySwitch</td>
<td colspan="1" rowspan="1">Equivalent element is ProbabilitySwitch in 0.9.5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">GraphEntryBase</td>
<td colspan="1" rowspan="1">Equivalent element is CallGraphItem in 0.9.5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">RunnableItem</td>
<td colspan="1" rowspan="1">Equivalent element is CallGraphItem in 0.9.5</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ClockSinusFunction</td>
<td colspan="1" rowspan="1">Equivalent is ClockFunction in 0.9.5 with a new attribute type curvetype=sine</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ClockTriangleFunction</td>
<td colspan="1" rowspan="1">Equivalent is ClockFunction in 0.9.5 with a new attribute type curvetype=triangle</td>
</tr>
</table>
<p>
<strong>Following Classes are renamed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name in 0.9.4</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed Class name in 0.9.5</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ClockMultiplierList</td>
<td colspan="1" rowspan="1">ClockStepList</td>
<td colspan="1" rowspan="1">stimuli</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ClockMultiplierListEntry</td>
<td colspan="1" rowspan="1">ClockStep</td>
<td colspan="1" rowspan="1">stimuli</td>
</tr>
</table>
<p>
<strong>Following Classes behavior is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed behavior in 0.9.5</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">Runnable class has a new attribute callGraph. It is now possible to have all the child elements same as Task or Process</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scenario</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">Reference
<em>recurrence</em> (Time) is replaced by
<em>samplingRecurrence</em> (non negative double)
</td>
</tr>
</table>
<p>
<strong>Below references are changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.4)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.5)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.4)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.5)</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">runnableItems</td>
<td colspan="1" rowspan="1">callGraph</td>
<td colspan="1" rowspan="1">RunnableItem</td>
<td colspan="1" rowspan="1">CallGraph</td>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">runnableItems reference has been removed and replaced with new attribute CallGraph to provide all child elements same as Task.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">graphEntries</td>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">GraphEntryBase</td>
<td colspan="1" rowspan="1">CallGraphItem</td>
<td colspan="1" rowspan="1">CallGraph</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">graphEntries reference has been changed to items of type CallGraphItem.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">RunnableItem</td>
<td colspan="1" rowspan="1">CallGraphItem</td>
<td colspan="1" rowspan="1">Group</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">items reference has been changed to elements of type CallGraphItem</td>
</tr>
<tr>
<td colspan="1" rowspan="1">entries</td>
<td colspan="1" rowspan="1">entries</td>
<td colspan="1" rowspan="1">ClockMultiplierListEntry</td>
<td colspan="1" rowspan="1">ClockStep</td>
<td colspan="1" rowspan="1">ClockStepList</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">entries reference has been changed to type ClockStep</td>
</tr>
</table>
<h4><a id="section4.5.4.6"></a>Version APP4MC 0.9.3 to APP4MC 0.9.4</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.9.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.4)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.3</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.4</td>
</tr>
</table>
<p>
<strong>Below Enum Literals are changed:</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>Literal name (version APP4MC 0.9.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Literal name (version APP4MC 0.9.4)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PortInterface</td>
<td colspan="1" rowspan="1">ABH</td>
<td colspan="1" rowspan="1">AHB</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">deadine</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">deadline attribute has been removed and an equivalent RunnableRequirement object is created in the ConstraintsModel.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">disablingModeValueList</td>
<td colspan="1" rowspan="1">ModeValueDisjunction</td>
<td colspan="1" rowspan="1">Stimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">disablingModeValueList reference has been completely removed.</td>
</tr>
</table>
<p>
<strong>Following Classes are renamed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name in 0.9.3</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed Class name in 0.9.4</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeValueDisjunction</td>
<td colspan="1" rowspan="1">ModeConditionDisjunction</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeValueDisjunctionEntry</td>
<td colspan="1" rowspan="1">ModeConditionDisjunctionEntry</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeValueConjunction</td>
<td colspan="1" rowspan="1">ModeConditionConjunction</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
</tr>
<tr>
<td colspan="1" rowspan="1">DataPlatformMapping</td>
<td colspan="1" rowspan="1">Alias</td>
<td colspan="1" rowspan="1">sw</td>
</tr>
</table>
<p>
<strong>Following Classes behavior is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed behavior in 0.9.4</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Mode</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">Mode is changed as abstract class. Mode has two subclasses NumericMode and EnumMode. All the Mode objects from Amalthea 0.9.3 are converted as EnumMode objects in 0.9.4</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeValue</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
<td colspan="1" rowspan="1">ModeValue is an abstract class derived into ModeAssignment and ModeCondition</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeValueDisjunctionEntry</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
<td colspan="1" rowspan="1">It is now changed as an interface ModeConditionDisjunctionEntry. This interface is realized as ModeCondition &amp; ModeConditionConjunction.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">Runnable class has a new attribute executionCondition.</td>
</tr>
</table>
<p>
<strong>Below references are changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.9.4)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.4)</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">enablingModeValueList</td>
<td colspan="1" rowspan="1">executionCondition</td>
<td colspan="1" rowspan="1">ModeValueDisjunction</td>
<td colspan="1" rowspan="1">ModeConditionDisjunction</td>
<td colspan="1" rowspan="1">Stimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">enablingModeValueList reference is now changed to executionCondition.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">entries</td>
<td colspan="1" rowspan="1">entries</td>
<td colspan="1" rowspan="1">ModeValue</td>
<td colspan="1" rowspan="1">ModeCondition</td>
<td colspan="1" rowspan="1">ModeValueDisjunction(in 0.9.3), ModeConditionDisjunction(in 0.9.4)</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
<td colspan="1" rowspan="1">ModeValue is now changed to ModeCondition.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">value</td>
<td colspan="1" rowspan="1">value</td>
<td colspan="1" rowspan="1">ModeLiteral</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">ModeValueMapEntry, ModeValue</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
<td colspan="1" rowspan="1">value is changed from ModeLiteral reference to a String (containing only modeLiteral name)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">valueProvider</td>
<td colspan="1" rowspan="1">label</td>
<td colspan="1" rowspan="1">ModeLabel</td>
<td colspan="1" rowspan="1">ModeLabel</td>
<td colspan="1" rowspan="1">ModeValue (can be ModeCondition or ModeAssignment)</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
<td colspan="1" rowspan="1">valueProvider reference is changed to a label</td>
</tr>
<tr>
<td colspan="1" rowspan="1">condition</td>
<td colspan="1" rowspan="1">condition</td>
<td colspan="1" rowspan="1">ModeValueDisjunction</td>
<td colspan="1" rowspan="1">ModeConditionDisjunction</td>
<td colspan="1" rowspan="1">ModeSwitchEntry</td>
<td colspan="1" rowspan="1">sw, stimuli</td>
<td colspan="1" rowspan="1">condition type is changed to new reference class type ModeConditionDisjunction</td>
</tr>
<tr>
<td colspan="1" rowspan="1">initialValue</td>
<td colspan="1" rowspan="1">initialValue</td>
<td colspan="1" rowspan="1">ModeLiteral</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">ModeLabel</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">initialValue is changed from ModeLiteral reference to a String (containing only modeLiteral name) additional attribute mode is created and it is referring to the Mode which was containing ModeLiteral</td>
</tr>
<tr>
<td colspan="1" rowspan="1">access</td>
<td colspan="1" rowspan="1">access</td>
<td colspan="1" rowspan="1">LabelAccessEnum</td>
<td colspan="1" rowspan="1">ModeLabelAccessEnum</td>
<td colspan="1" rowspan="1">ModeLabelAccess</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">access is now a reference to enum type ModeLabelAccessEnum enhanced to support Enum mode.If literal "write" was used now it is changed to "set".</td>
</tr>
<tr>
<td colspan="1" rowspan="1">modeValue</td>
<td colspan="1" rowspan="1">value</td>
<td colspan="1" rowspan="1">ModeLiteral</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">ModeLabelAccess</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">value is changed from ModeLIteral reference to a String (containing only modeLiteral name)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">dataMapping</td>
<td colspan="1" rowspan="1">aliases</td>
<td colspan="1" rowspan="1">DataPlatformMapping</td>
<td colspan="1" rowspan="1">Alias</td>
<td colspan="1" rowspan="1">BaseTypeDefinition</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">dataMapping is renamed to avoid mixup with mapping to memory</td>
</tr>
<tr>
<td colspan="1" rowspan="1">platformName</td>
<td colspan="1" rowspan="1">target</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">DataPlatformMapping (in 0.9.3), Alias (in 0.9.4)</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">platformName attribute is renamed to target</td>
</tr>
<tr>
<td colspan="1" rowspan="1">platformType</td>
<td colspan="1" rowspan="1">alias</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">String</td>
<td colspan="1" rowspan="1">DataPlatformMapping (in 0.9.3), Alias (in 0.9.4)</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">platformType attribute is renamed to alias</td>
</tr>
</table>
<h4><a id="section4.5.4.7"></a>Version APP4MC 0.9.2 to APP4MC 0.9.3</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.9.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.3)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.2</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.3</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.9.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">Depending on the type of generic used for Deviation element, contents are migrated as IContinuousValueDeviation or IDiscreteValueDeviation or ITimeDeviation</td>
</tr>
</table>
<p>
<strong>Following Class names are changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name in 0.9.2</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed Class name in 0.9.3</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">OsInstructions</td>
<td colspan="1" rowspan="1">OsOverhead</td>
<td colspan="1" rowspan="1">os</td>
</tr>
<tr>
<td colspan="1" rowspan="1">OsAPIInstructions</td>
<td colspan="1" rowspan="1">OsAPIOverhead</td>
<td colspan="1" rowspan="1">os</td>
</tr>
<tr>
<td colspan="1" rowspan="1">OsISRInstructions</td>
<td colspan="1" rowspan="1">OsISROverhead</td>
<td colspan="1" rowspan="1">os</td>
</tr>
<tr>
<td colspan="1" rowspan="1">LatencyConstant</td>
<td colspan="1" rowspan="1">DiscreteValueConstant</td>
<td colspan="1" rowspan="1">hw</td>
</tr>
<tr>
<td colspan="1" rowspan="1">LatencyDeivation</td>
<td colspan="1" rowspan="1">DiscreteValueBetaDistribution DiscreteValueBoundaries DiscreteValueGaussDistribution DiscreteValueStatistics DiscreteValueUniformDistribution DiscreteValueWeibullEstimatorsDistribution</td>
<td colspan="1" rowspan="1">os</td>
</tr>
</table>
<p>
<strong>Following Classes behavior is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>Class name</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Amalthea sub-model</strong>
</td>
<td colspan="1" rowspan="1">
<strong>Changed behavior in 0.9.3</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ExecutionNeed</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">Till 0.9.2 ExecutionNeed element was used to specify the runtime information and also additional behaviour e.g: Performance etc., <br>Based on the latest change in 0.9.3, runtime information should be represented with Ticks element and additional information w.r.t. Performance etc., can be represented using ExecutionNeed element</td>
</tr>
</table>
<p>
<strong>Below references are changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name(version APP4MC 0.9.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name(version APP4MC 0.9.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Type (in 0.9.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>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">occurencesPerStep</td>
<td colspan="1" rowspan="1">occurencesPerStep</td>
<td colspan="1" rowspan="1">Deviation&lt;DoubleObject&gt;</td>
<td colspan="1" rowspan="1">IContinuousValueDeviation</td>
<td colspan="1" rowspan="1">VariableRateActivation</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">As there is a change in the Type of this reference from Deviation&lt;DoubleObject&gt; to IContinousValueDeviation. Content is migrated to the new elements.<br> Following elemenets are supported as Type: BoundedContinuousValueDistribution ContinuousValueBetaDistribution ContinuousValueBoundaries ContinuousValueConstant ContinuousValueGaussDistribution ContinuousValueHistogram ContinuousValueStatistics ContinuousValueUniformDistribution ContinuousValueWeibullEstimatorsDistribution TruncatedContinuousValueDistribution</td>
</tr>
<tr>
<td colspan="1" rowspan="1">activationDeviation</td>
<td colspan="1" rowspan="1">activation</td>
<td colspan="1" rowspan="1">Deviation&lt;Time&gt;</td>
<td colspan="1" rowspan="1">ITimeDeviation</td>
<td colspan="1" rowspan="1">SporadicActivation</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">As there is a change in the Type of this reference from Deviation&lt;Time&gt; to ITimeDeviation. Content is migrated to the new elements.<br> Following elements are supported as Type : TimeBetaDistribution TimeBoundaries TimeConstant TimeGaussDistribution TimeHistogram TimeStatistics TimeUniformDistribution TimeWeibullEstimatorsDistribution</td>
</tr>
<tr>
<td colspan="1" rowspan="1">chunkProcessingInstructions</td>
<td colspan="1" rowspan="1">chunkProcessingTicks</td>
<td colspan="1" rowspan="1">EInt</td>
<td colspan="1" rowspan="1">EInt</td>
<td colspan="1" rowspan="1">ChannelReceive ChannelSend LabelAccess</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">reference name changed from chunkProcessingInstructions to chunkProcessingTicks</td>
</tr>
<tr>
<td colspan="1" rowspan="1">computationItems</td>
<td colspan="1" rowspan="1">computationItems</td>
<td colspan="1" rowspan="1">ExecutionNeed</td>
<td colspan="1" rowspan="1">Ticks</td>
<td colspan="1" rowspan="1">TaskScheduler InterruptController</td>
<td colspan="1" rowspan="1">os</td>
<td colspan="1" rowspan="1">ExecutionNeed elements with HwFeatureCategory Instructions, are converted as Ticks with default or extended (based on the way ExecutionNeed was defined earlier)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">items</td>
<td colspan="1" rowspan="1">ExecutionNeed</td>
<td colspan="1" rowspan="1">ExecutionNeed</td>
<td colspan="1" rowspan="1">Group</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">ExecutionNeed elements with HwFeatureCategory Instructions are converted as Ticks. If HwFeatureCategory is other than Instructions, then content of the specific entry is retained as ExecutionNeed <br>(In 0.9.3 ExecutionNeed does not support Extended entries )</td>
</tr>
<tr>
<td colspan="1" rowspan="1">runnableitems</td>
<td colspan="1" rowspan="1">runnableitems</td>
<td colspan="1" rowspan="1">ExecutionNeed</td>
<td colspan="1" rowspan="1">ExecutionNeed</td>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">sw</td>
<td colspan="1" rowspan="1">ExecutionNeed elements with HwFeatureCategory Instructions are converted as Ticks. If HwFeatureCategory is other than Instructions, then content of the specific entry is retained as ExecutionNeed <br>(In 0.9.3 ExecutionNeed does not support Extended entries )</td>
</tr>
<tr>
<td colspan="1" rowspan="1">jitter</td>
<td colspan="1" rowspan="1">jitter</td>
<td colspan="1" rowspan="1">Deviation&lt;Time&gt;</td>
<td colspan="1" rowspan="1">ITimeDeviation</td>
<td colspan="1" rowspan="1">PeriodicStimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">As there is a change in the Type of this reference from Deviation&lt;Time&gt; to ITimeDeviation. Content is migrated to the new elements.<br> Following elemenets are supported as Type : TimeBetaDistribution TimeBoundaries TimeConstant TimeGaussDistribution TimeHistogram TimeStatistics TimeUniformDistribution TimeWeibullEstimatorsDistribution</td>
</tr>
<tr>
<td colspan="1" rowspan="1">nextOccurrence</td>
<td colspan="1" rowspan="1">nextOccurrence</td>
<td colspan="1" rowspan="1">Deviation&lt;Time&gt;</td>
<td colspan="1" rowspan="1">ITimeDeviation</td>
<td colspan="1" rowspan="1">RelativePeriodicStimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">As there is a change in the Type of this reference from Deviation&lt;Time&gt; to ITimeDeviation. Content is migrated to the new elements.<br> Following elemenets are supported as Type : TimeBetaDistribution TimeBoundaries TimeConstant TimeGaussDistribution TimeHistogram TimeStatistics TimeUniformDistribution TimeWeibullEstimatorsDistribution</td>
</tr>
<tr>
<td colspan="1" rowspan="1">occurencesPerStep</td>
<td colspan="1" rowspan="1">occurencesPerStep</td>
<td colspan="1" rowspan="1">Deviation&lt;DoubleObject&gt;</td>
<td colspan="1" rowspan="1">IContinuousValueDeviation</td>
<td colspan="1" rowspan="1">VariableRateStimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">As there is a change in the Type of this reference from Deviation&lt;DoubleObject&gt; to IContinousValueDeviation. Content is migrated to the new elements.<br> Following elements are supported as Type: BoundedContinuousValueDistribution ContinuousValueBetaDistribution ContinuousValueBoundaries ContinuousValueConstant ContinuousValueGaussDistribution ContinuousValueHistogram ContinuousValueStatistics ContinuousValueUniformDistribution ContinuousValueWeibullEstimatorsDistribution TruncatedContinuousValueDistribution</td>
</tr>
<tr>
<td colspan="1" rowspan="1">maxIncreasePerStep</td>
<td colspan="1" rowspan="1">maxIncreasePerStep</td>
<td colspan="1" rowspan="1">DoubleObject</td>
<td colspan="1" rowspan="1">Double</td>
<td colspan="1" rowspan="1">VariableRateStimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">Double value is migrated as a attribute</td>
</tr>
<tr>
<td colspan="1" rowspan="1">maxDecreasePerStep</td>
<td colspan="1" rowspan="1">maxDecreasePerStep</td>
<td colspan="1" rowspan="1">DoubleObject</td>
<td colspan="1" rowspan="1">Double</td>
<td colspan="1" rowspan="1">VariableRateStimulus</td>
<td colspan="1" rowspan="1">stimuli</td>
<td colspan="1" rowspan="1">Double value is migrated as a attribute</td>
</tr>
<tr>
<td colspan="1" rowspan="1">osOverheads</td>
<td colspan="1" rowspan="1">osOverheads</td>
<td colspan="1" rowspan="1">OsInstructions</td>
<td colspan="1" rowspan="1">OsOverhead</td>
<td colspan="1" rowspan="1">OSModel</td>
<td colspan="1" rowspan="1">os</td>
<td colspan="1" rowspan="1">References are updated accordingly</td>
</tr>
<tr>
<td colspan="1" rowspan="1">apiSendMessage apiTerminateTask apiSchedule apiRequestResource apiReleaseResource apiSetEvent apiWaitEvent apiClearEvent apiActivateTask apiEnforcedMigration apiSuspendOsInterrupts apiResumeOsInterrupts apiRequestSpinlock apiReleaseSpinlock apiSenderReceiverRead apiSenderReceiverWrite apiSynchronousServerCallPoint apiIocRead apiIocWrite</td>
<td colspan="1" rowspan="1">apiSendMessage apiTerminateTask apiSchedule apiRequestResource apiReleaseResource apiSetEvent apiWaitEvent apiClearEvent apiActivateTask apiEnforcedMigration apiSuspendOsInterrupts apiResumeOsInterrupts apiRequestSpinlock apiReleaseSpinlock apiSenderReceiverRead apiSenderReceiverWrite apiSynchronousServerCallPoint apiIocRead apiIocWrite</td>
<td colspan="1" rowspan="1">Instructions</td>
<td colspan="1" rowspan="1">Ticks</td>
<td colspan="1" rowspan="1">OsAPIInstructions</td>
<td colspan="1" rowspan="1">os</td>
<td colspan="1" rowspan="1">Instructions elements are converted to Ticks. <br>InstructionsConstant is converted to DiscreteValueConstant. <br>InstructionsDeviation is converted to one of the following type
<em>(based on conversion criteria)</em>: <br> DiscreteValueBetaDistribution DiscreteValueBoundaries DiscreteValueGaussDistribution DiscreteValueStatistics DiscreteValueUniformDistribution DiscreteValueWeibullEstimatorsDistribution
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">preExecutionOverhead postExecutionOverhead</td>
<td colspan="1" rowspan="1">preExecutionOverhead postExecutionOverhead</td>
<td colspan="1" rowspan="1">Instructions</td>
<td colspan="1" rowspan="1">Ticks</td>
<td colspan="1" rowspan="1">OsISRInstructions</td>
<td colspan="1" rowspan="1">os</td>
<td colspan="1" rowspan="1">Instructions elements are converted to Ticks. <br>InstructionsConstant is converted to DiscreteValueConstant. <br>InstructionsDeviation is converted to one of the following type
<em>(based on conversion criteria)</em>: <br> DiscreteValueBetaDistribution DiscreteValueBoundaries DiscreteValueGaussDistribution DiscreteValueStatistics DiscreteValueUniformDistribution DiscreteValueWeibullEstimatorsDistribution
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">runtimeDeviation</td>
<td colspan="1" rowspan="1">runtimeDeviation</td>
<td colspan="1" rowspan="1">Deviation&lt;Time&gt;</td>
<td colspan="1" rowspan="1">ITimeDeviation</td>
<td colspan="1" rowspan="1">Measurement</td>
<td colspan="1" rowspan="1">MeasurementModel</td>
<td colspan="1" rowspan="1">As there is a change in the Type of this reference from Deviation&lt;Time&gt; to ITimeDeviation. Content is migrated to the new elements.<br> Following elemenets are supported as Type : TimeBetaDistribution TimeBoundaries TimeConstant TimeGaussDistribution TimeHistogram TimeStatistics TimeUniformDistribution TimeWeibullEstimatorsDistribution</td>
</tr>
<tr>
<td colspan="1" rowspan="1">cycles</td>
<td colspan="1" rowspan="1">value</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">Long</td>
<td colspan="1" rowspan="1">LatencyConstant</td>
<td colspan="1" rowspan="1">hw</td>
<td colspan="1" rowspan="1">LatencyConstant is changed to DiscreteValueConstant, reference name changed from cycles to value</td>
</tr>
<tr>
<td colspan="1" rowspan="1">cycles</td>
<td colspan="1" rowspan="1">value</td>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">Deviation&lt;DoubleObject&gt;</td>
<td colspan="1" rowspan="1">LatencyDeviation</td>
<td colspan="1" rowspan="1">hw</td>
<td colspan="1" rowspan="1">LatencyDeviation is changed to DiscreteValueBetaDistribution DiscreteValueBoundaries DiscreteValueGaussDistribution DiscreteValueStatistics DiscreteValueUniformDistribution DiscreteValueWeibullEstimatorsDistribution. In 0.9.3, intermediate cycles element is removed. Content of it is merged as a part of the Distribution</td>
</tr>
</table>
<h4><a id="section4.5.4.8"></a>Version APP4MC 0.9.1 to APP4MC 0.9.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.9.1)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.2)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.1</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.2</td>
</tr>
</table>
<h4><a id="section4.5.4.9"></a>Version APP4MC 0.9.0 to APP4MC 0.9.1</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.9.0)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.1)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.0</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.1</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.9.0)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">TimeObject</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.1 is Time</td>
</tr>
</table>
<h4><a id="section4.5.4.10"></a>Version APP4MC 0.8.3 to APP4MC 0.9.0</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.8.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.9.0)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.3</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.9.0</td>
</tr>
</table>
<p>
<strong>Below Classes/Interfaces behaviour is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Class Name (version APP4MC 0.8.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA sub model</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Changes in behavior (as per 0.9.0)</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">HWModel</td>
<td colspan="1" rowspan="1">Memory and Cache are two different elements. Memory can be defined only inside a HwStructure where as Cache can be defined inside HwStructure and ProcessingUnit</td>
<td colspan="1" rowspan="1">Memory element of 0.8.3 is converted either as a Memory element or Cache element based on the type specified for MemoryType element. If the type is specified as
<strong>CACHE</strong>, then Memory object
<em class="from 0.8.3">_ is converted as
<strong>Cache</strong> element and in other cases it is converted as
<strong>Memory</strong>. <br>
<strong>Note:</strong> _In 0.8.3, Memory element could be contained inside a ComplexNode, as a part of migration : If there is not a possibility to define either a Cache or Memory inside a specific element then it is added as a part of the corresponding parent HwStructure element
</em>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">HwPort</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">HwPort and ComplexPort elements from 0.8.3 are represented as HwPort in 0.9.0.</td>
<td colspan="1" rowspan="1">For both HwPort and ComplexPort elements, HwPort object is created. Based on the value of attribute master on HwPort or ComplexPort : portType is set either as initiator
<em class="if master=true">_ or responder _(if master=false)</em>
</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.8.3)</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">RunnableInstructions</td>
<td colspan="1" rowspan="1">SWModel, OSModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is ExecutionNeed.
<strong>default</strong> InstructionsConstant,InstructionsDeviation are converted as NeedEntry and the key refers to HwFeatureCategory "Instructions"
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">RunnableInstructionsEntry</td>
<td colspan="1" rowspan="1">SWModel, OSModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is ExecutionNeedExtended. Key attribute of ExecutionNeedExtended refer to
<strong>ProcessingUnitDefintion</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ECUType</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MicroControllerType</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SystemType</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">HWAccessPath</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0. Only LatencyAccessPath is migrated</td>
</tr>
<tr>
<td colspan="1" rowspan="1">HWComponent</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">NestedComponent</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PreScaler</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0. Based on to which HW element PreScaler is added ,Quartz of the corresponding element is fetched : value of
<strong>clockRatio</strong> is multiplied with the Frequency value of the Quartz and a new FrequencyDomain object is created which contains the obtained Frequency value. Created FrequencyDomain will contain clockratio value in suffix of the name
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Quartz</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is FrequencyDomain.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Pin</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MemoryType</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is MemoryDefinition. If type is specified as
<strong>Cache</strong>, then corresponding element is migrated as
<strong>CacheDefinition</strong>, in other cases it will be MemoryDefinition
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">CoreType</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is ProcessingUnitDefinition.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">NetworkType, Bus, Bridge, CrossbarSwitch</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of these classes in 0.9.0 is ConnectionHandlerDefinition.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">LatencyAccessPath</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is HwAccessElement. If the source element of the LatencyAccessPath is Core, in the corresponding ProcessingUnit : HwAccessElement is created and the destination of it is set based on the destination of LatencyAccessPath
<em>(Note: Destination of HwAccessElement can only be Memory or ProcessingUnit)</em>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">System</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is HwStructure. StructureType is set as System</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ECU</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is HwStructure. StructureType is set as ECU</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MicroController</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is HwStructure. StructureType is set as Microcontroller</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Network</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">Equivalent element of this class in 0.9.0 is ConnectionHandler</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ComplexPort</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">There is no equivalent element in 0.9.0</td>
</tr>
</table>
<p>
<strong>Below references are removed/changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name(version APP4MC 0.8.3)</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">memories</td>
<td colspan="1" rowspan="1">Memory</td>
<td colspan="1" rowspan="1">TargetMemory</td>
<td colspan="1" rowspan="1">ConstraintsModel</td>
<td colspan="1" rowspan="1">If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
<em>(as CACHE in 0.8.3)</em> , corresponding reference is removed
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">memories</td>
<td colspan="1" rowspan="1">Memory</td>
<td colspan="1" rowspan="1">PhysicalSectionConstraint</td>
<td colspan="1" rowspan="1">ConstraintsModel</td>
<td colspan="1" rowspan="1">If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
<em>(as CACHE in 0.8.3)</em> , corresponding reference is removed
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">memory</td>
<td colspan="1" rowspan="1">Memory</td>
<td colspan="1" rowspan="1">PhysicalSectionMapping</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
<em>(as CACHE in 0.8.3)</em> , corresponding reference is removed
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">memory</td>
<td colspan="1" rowspan="1">Memory</td>
<td colspan="1" rowspan="1">MemoryMapping</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">If the Memory object as per 0.8.3 is still Memory in 0.9.0, then reference is unchanged. If Memory in 0.8.3 is migrated as Cache based on the type of MemoryType
<em>(as CACHE in 0.8.3)</em> , corresponding reference is removed
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">cores</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">TargetCore</td>
<td colspan="1" rowspan="1">ConstraintsModel</td>
<td colspan="1" rowspan="1">instead of Core object, variable Type is updated to corresponding ProcessingUnit element</td>
</tr>
<tr>
<td colspan="1" rowspan="1">hardwareContext</td>
<td colspan="1" rowspan="1">ComplexNode</td>
<td colspan="1" rowspan="1">CPUPercentageRequirementLimit</td>
<td colspan="1" rowspan="1">ConstraintModel</td>
<td colspan="1" rowspan="1">variable Type is changed to ProcessingUnit. In 0.8.3 models if an element was referring to any other ComplexNode other than Core, corresponding reference will be removed</td>
</tr>
<tr>
<td colspan="1" rowspan="1">core</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">ProcessEvent</td>
<td colspan="1" rowspan="1">EventModel</td>
<td colspan="1" rowspan="1">variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">core</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">ProcessChainEvent</td>
<td colspan="1" rowspan="1">EventModel</td>
<td colspan="1" rowspan="1">variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">core</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">RunnableEvent</td>
<td colspan="1" rowspan="1">EventModel</td>
<td colspan="1" rowspan="1">variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">core</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">SemaphoreEvent</td>
<td colspan="1" rowspan="1">EventModel</td>
<td colspan="1" rowspan="1">variable name is changed from core to processingUnit.Type of the reference is changed to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">cores</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">MicroController</td>
<td colspan="1" rowspan="1">HWModel</td>
<td colspan="1" rowspan="1">variable name is changed from cores to modules.Type of the reference is changed to ProcessingUnit. MicroController class is changed to HwStructure</td>
</tr>
<tr>
<td colspan="1" rowspan="1">responsibility</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">SchdulerAllocation</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">Type is changed from Core to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">executingCore</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">SchdulerAllocation</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">variable name is changed from executingCore to executingPU. Type is changed from Core to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">coreAffinity</td>
<td colspan="1" rowspan="1">Core</td>
<td colspan="1" rowspan="1">TaskAllocation</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">variable name is changed from coreAffinity to affinity. Type is changed from Core to ProcessingUnit</td>
</tr>
<tr>
<td colspan="1" rowspan="1">items, runnableItems, computationItems</td>
<td colspan="1" rowspan="1">RunnableInstructions</td>
<td colspan="1" rowspan="1">Group, Runnable, Scheduler</td>
<td colspan="1" rowspan="1">SWModel, OSModel</td>
<td colspan="1" rowspan="1">Type is changed from RunnableInstructions to ExecutionNeed</td>
</tr>
</table>
<h4><a id="section4.5.4.11"></a>Version APP4MC 0.8.2 to APP4MC 0.8.3</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.8.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.8.3)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.2</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.3</td>
</tr>
</table>
<p>
<strong>Below Classes/Interfaces behaviour is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Class Name (version APP4MC 0.8.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA sub model</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Changes in behavior (as per 0.8.3)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeSwitch, RunnableModelSwitch</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">valueProvider (
<em>of ModeLabel reference</em>) is removed and is associated to ModeValue element.
</td>
<td colspan="1" rowspan="1">valueProvider (
<em>of ModeLabel reference</em>) is removed and is associated to ModeValue element, which is created inside ModeValueDisjunction element contained in ModeSwitch, RunnableModeSwitch
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeSwitchEntry</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">values (
<em>of type list of ModeLiteral</em>) is removed and is as ModeValue element inside ModeValueDisjunction class.
</td>
<td colspan="1" rowspan="1">values (
<em>of type list of ModeLiteral</em>) is removed and each element in the list is associated as ModeValue element, which is created inside ModeValueDisjunction element contained in ModeSwitch, RunnableModeSwitch
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PeriodicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">stimulusDevaiation, offset, clock elements are removed</td>
<td colspan="1" rowspan="1">For migration, below points are to be considered:<ul><li>If
<strong>clock value is set</strong> for PeriodicStimuls, then this PeriodicStimulus will be migrated as VariableRateStimulus. <ul><li>clock, recurrence elements are moved from PeriodicStimulus to Scenario element, contained inside VariableRateStimulus.</li> <li>offset element value is moved as a customProperty for Scenario element</li> </ul> </li><li>If
<strong>clock value is not set</strong> for PeriodicStimuls, then type of the element will not be changed. <ul><li>stimulsDeviation element is renamed as jitter.</li></ul> </li></ul>
</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.8.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">FInterfacePort</td>
<td colspan="1" rowspan="1">Components Model</td>
<td colspan="1" rowspan="1">FinterfacePort is replaced by InterfacePort class. As a part of model migration, in Components model -&gt; type attribute for the definition of FInterfacePort is changed from "am:FInterfacePort" to "am:InterfacePort", and new type (InterfacePort) is also updated for references of FInterfacePort</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SyntheticStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">SyntheticStimulus is replaced by PeriodicSyntheticStimulus class. As a part of model migration, in Stimuli model -&gt; type attribute for the definition of FInterfacePort is changed from "am:SyntheticStimulus" to "am:PeriodicSyntheticStimulus", and new type (PeriodicSyntheticStimulus) is also updated for references of SyntheticStimulus</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SporadicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">SporadicStimulus is replaced by RelativePeriodicStimulus class. As a part of model migration, in Stimuli model -&gt; type attribute for the definition of SporadicStimulus is changed from "am:SporadicStimulus" to "am:RelativePeriodicStimulus", and new type (RelativePeriodicStimulus) is also updated for references of SporadicStimulus</td>
</tr>
</table>
<p>
<strong>Below references are removed/changed:</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">activationDeviation</td>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">VariableRateActivation</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">activationDeviation element is removed from the VariableRateActivation element</td>
</tr>
<tr>
<td colspan="1" rowspan="1">valueProvider</td>
<td colspan="1" rowspan="1">ModeLabel</td>
<td colspan="1" rowspan="1">ModeSwitch, RunnableModeSwitch</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">valueProvider (
<em>ModeLabel reference</em>) is removed directly from
<em>
<strong>ModeSwitch, RunnableModelSwitch</strong>
</em> elements and associated to each ModeValue element -&gt;&gt; which is created inside condition element (
<em>of type ModeValueDisJunction</em>)
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">values</td>
<td colspan="1" rowspan="1">ModeLiteral</td>
<td colspan="1" rowspan="1">ModeSwitch, RunnableModeSwitch</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">values list is removed directly from
<em>
<strong>ModeSwitch, RunnableModelSwitch</strong>
</em> and associated inside condition element (
<em>of type ModeValueDisJunction</em>) as different ModeValue elements (
<em>Note: Each element in values List is created a separate ModeValue element inside condition element</em>)
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">period</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">SyntheticStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">period element is changed to recurrence</td>
</tr>
<tr>
<td colspan="1" rowspan="1">triggerTimes</td>
<td colspan="1" rowspan="1">TimeStampList</td>
<td colspan="1" rowspan="1">SyntheticStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">triggerTimes element is removed from SyntheticStimulus. Content of TriggerTimes element -&gt;
<strong>timeStamps list</strong> is migrated as occurrenceTimes element inside SyntheticStimulus
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">stimulusDeviation</td>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">SporadicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">stimulusDeviation element is changed as nextOccurrence</td>
</tr>
<tr>
<td colspan="1" rowspan="1">numberOfEvents</td>
<td colspan="1" rowspan="1">Integer</td>
<td colspan="1" rowspan="1">ArrivalCurveEntry</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">numberOfEvents element is changed as numberOfOccurrences</td>
</tr>
<tr>
<td colspan="1" rowspan="1">stimulusDeviation</td>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">ArrivalCurveStimulus, SingleStimulus, CustomStimulus, InterProcessStimulus, EventStimulus, SyntheticStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">stimulusDeviation element is removed from SingleStimulus</td>
</tr>
<tr>
<td colspan="1" rowspan="1">activation</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">SingleStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">activation element is changed as occurrence</td>
</tr>
<tr>
<td colspan="1" rowspan="1">stimulusDeviation</td>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">PeriodicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">If clock value is
<strong>not set</strong> for PeriodicStimulus, in this case stimulusDeviation element is changed as jitter.
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">recurrence, clock</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">PeriodicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">If clock value is
<strong>set</strong> for PeriodicStimulus, in this case both recurrence and clock are removed directly from PeriodicStimulus and their values are added inside Scenario element -&gt; contained inside PeriodicStimulus(
<em>which will be migrated to VariableRateStimulus as a part of migration</em>)
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">offset</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">PeriodicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">If clock value is
<strong>set</strong> for PeriodicStimulus, in this case offset element is removed directly from PeriodicStimulus and its value is added inside Scenario element -&gt; contained inside PeriodicStimulus(
<em>which will be migrated to VariableRateStimulus as a part of migration</em>) as a CustomProperty with name "offset"
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">stimulusDeviation</td>
<td colspan="1" rowspan="1">Deviation</td>
<td colspan="1" rowspan="1">PeriodicStimulus</td>
<td colspan="1" rowspan="1">Stimuli Model</td>
<td colspan="1" rowspan="1">If clock value is
<strong>set</strong> then stimulusDeviation element is removed from PeriodicStimulus
</td>
</tr>
</table>
<h4><a id="section4.5.4.12"></a>Version APP4MC 0.8.1 to APP4MC 0.8.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.8.1)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.8.2)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.1</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.2</td>
</tr>
</table>
<h4><a id="section4.5.4.13"></a>Version APP4MC 0.8.0 to APP4MC 0.8.1</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.8.0)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.8.1)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.0</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.1</td>
</tr>
</table>
<p>
<strong>Below Classes/Interfaces behaviour is changed:</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Class Name (version APP4MC 0.8.0)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA sub model</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Changes in behavior (as per 0.8.1)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SubEventChain</td>
<td colspan="1" rowspan="1">Constraints Model</td>
<td colspan="1" rowspan="1">SubEventChain class (in 0.8.0) is replaced by EventChainContainer class (in 0.8.1). EventChainContainer class is modelled to contain SubEventChain elements (in 0.8.1) which are non referable child EventChain elements.</td>
<td colspan="1" rowspan="1"><ul><li>In amxmi file, xsi:type with "am:SubEventChain" is replaced with "am:EventChainContainer".</li><li>If sub EventChain elements are referred inside EventChainReference or inside TimingConstraints
<i>(e.g: EventChainLatencyConstraint or EventChainSynchronizationConstraint)</i>:<ul><li> Then corresponding reference is removed and the reference String is stored in a CustomProperty of the corresponding element</li></ul></li></ul>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Quartz</td>
<td colspan="1" rowspan="1">Hardware Model</td>
<td colspan="1" rowspan="1">Quartz is not extending ComplexNode class. In addition below are the other changes w.r.t. Quartz: <ul><li>It is no longer possible to have nested Quartz elements</li><li>All Quartz elements should be present in single list, which is part of HwSystem class</li></ul></td>
<td colspan="1" rowspan="1"><ul><li>Per each amxmi file, from HWModel all Quartz elements are collected (
<i>both root and sub Quartz elements</i>) and are added in a central list which is part of HwSystem.</li><ul><li> Quartz element definitions are removed from the other HW elements
<i>(which are sub-classes of ComplexNode)</i> </li></ul></ul>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ModeValueListEntry</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">ModeValueListEntry class is having two sub-classes ModeValue and ModeValueConjunction</td>
<td colspan="1" rowspan="1">ModeValue type is associated to all the ModeValueListEntry elements</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.8.0)</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">CoreAllocation</td>
<td colspan="1" rowspan="1">Mapping Model</td>
<td colspan="1" rowspan="1">CoreAllocation is replaced by SchedulerAllocation. As a part of model migration, In Mapping model references of CoreAllocation are changed as SchedulerAllocation. Also the "core" attribute/tag of it is renamed to "responsibility"</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SchedulingHWUnit</td>
<td colspan="1" rowspan="1">OS model</td>
<td colspan="1" rowspan="1">SchedulingHWUnit reference is removed from Scheduler</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SchedulingSWUnit</td>
<td colspan="1" rowspan="1">OS model</td>
<td colspan="1" rowspan="1">SchedulingSWUnit reference is removed from Scheduler and content of Instructions is copied to the corresponding ComputationItem elements of type RunnableInstructions</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ArrivalCurve</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to ArrivalCurveStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">InterProcess</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to InterProcessStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Periodic</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to PeriodicStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">PeriodicEvent</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to VariableRateStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Single</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to SingleStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Sporadic</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to SporadicStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Synthetic</td>
<td colspan="1" rowspan="1">Stimuli model</td>
<td colspan="1" rowspan="1">This class is renamed to SyntheticStimulus. Element type is updated at both definition and references in amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">InterProcessActivation</td>
<td colspan="1" rowspan="1">SW model</td>
<td colspan="1" rowspan="1">This class is renamed to InterProcessTrigger. Element type is updated at both definition and references in amxmi file</td>
</tr>
</table>
<p>
<strong>Below references are removed/changed:</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">coreAllocation</td>
<td colspan="1" rowspan="1">CoreAllocation</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">Mapping Model</td>
<td colspan="1" rowspan="1">coreAllocation tag name is renamed to schedulerAllocation. Equivalent of CoreAllocation is SchedulerAllocation element</td>
</tr>
<tr>
<td colspan="1" rowspan="1">priority</td>
<td colspan="1" rowspan="1">integer</td>
<td colspan="1" rowspan="1">TaskAllocation</td>
<td colspan="1" rowspan="1">Mapping Model</td>
<td colspan="1" rowspan="1">priority attribute is removed from TaskAllocation and its corresponding value is copied to priority attribute of the SchedulingParameters</td>
</tr>
<tr>
<td colspan="1" rowspan="1">xAccessPattern</td>
<td colspan="1" rowspan="1"> String</td>
<td colspan="1" rowspan="1">MemoryType</td>
<td colspan="1" rowspan="1">HW model</td>
<td colspan="1" rowspan="1">xAccessPattern attribute and its value present in MemoryType element are removed from the amxmi file</td>
</tr>
<tr>
<td colspan="1" rowspan="1">parameter</td>
<td colspan="1" rowspan="1">AlgorithmParameter</td>
<td colspan="1" rowspan="1">Scheduler</td>
<td colspan="1" rowspan="1">OS model</td>
<td colspan="1" rowspan="1">parameter tag name is changed to parameterExtensions (
<em>Also changed variable Type here is : ParameterExtensions</em>)
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">scheduleUnitPriority</td>
<td colspan="1" rowspan="1">integer</td>
<td colspan="1" rowspan="1">Scheduler</td>
<td colspan="1" rowspan="1">OS model</td>
<td colspan="1" rowspan="1">scheduleUnitPriority attribute is removed</td>
</tr>
<tr>
<td colspan="1" rowspan="1">delay</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">SchedulingHWUnit</td>
<td colspan="1" rowspan="1">OS model</td>
<td colspan="1" rowspan="1">delay tag is removed</td>
</tr>
<tr>
<td colspan="1" rowspan="1">instructions</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">"instructions" tag is removed from the SchedulingSWUnit and each "instructions" tag content is copied as a "default" tag of computationItems (of type RunnableInstructions)</td>
</tr>
<tr>
<td colspan="1" rowspan="1">schedulingUnit</td>
<td colspan="1" rowspan="1">SchedulingUnit</td>
<td colspan="1" rowspan="1">Scheduler</td>
<td colspan="1" rowspan="1">OS model</td>
<td colspan="1" rowspan="1">schedulingUnit tag is removed. And the contents of SchedulingSWUnit are migrated to ComputationItem's</td>
</tr>
<tr>
<td colspan="1" rowspan="1">trigger</td>
<td colspan="1" rowspan="1">TriggerEvent</td>
<td colspan="1" rowspan="1">EventStimulus</td>
<td colspan="1" rowspan="1">Event model</td>
<td colspan="1" rowspan="1">renamed to triggeringEvents</td>
</tr>
<tr>
<td colspan="1" rowspan="1">activation</td>
<td colspan="1" rowspan="1">Activation</td>
<td colspan="1" rowspan="1">Runnable</td>
<td colspan="1" rowspan="1">SW model</td>
<td colspan="1" rowspan="1">renamed to activations</td>
</tr>
<tr>
<td colspan="1" rowspan="1">deadline</td>
<td colspan="1" rowspan="1">Time</td>
<td colspan="1" rowspan="1">PeriodicActivation</td>
<td colspan="1" rowspan="1">SW model</td>
<td colspan="1" rowspan="1">deadline attribute is removed</td>
</tr>
<tr>
<td colspan="1" rowspan="1">trigger</td>
<td colspan="1" rowspan="1">TriggerEvent</td>
<td colspan="1" rowspan="1">EventActivation</td>
<td colspan="1" rowspan="1">SW model</td>
<td colspan="1" rowspan="1">renamed to triggeringEvents</td>
</tr>
<tr>
<td colspan="1" rowspan="1">priority</td>
<td colspan="1" rowspan="1">integer</td>
<td colspan="1" rowspan="1">Process</td>
<td colspan="1" rowspan="1">SW model</td>
<td colspan="1" rowspan="1">priority attribute is removed</td>
</tr>
<tr>
<td colspan="1" rowspan="1">osekTaskGroup</td>
<td colspan="1" rowspan="1">integer</td>
<td colspan="1" rowspan="1">Task</td>
<td colspan="1" rowspan="1">SW model</td>
<td colspan="1" rowspan="1">osekTaskGroup attribute is removed</td>
</tr>
<tr>
<td colspan="1" rowspan="1">quartzes</td>
<td colspan="1" rowspan="1">List of Quartz</td>
<td colspan="1" rowspan="1">Core<br>ECU<br>HwComponent<br>Memory<br>Microcontroller<br>Network</td>
<td colspan="1" rowspan="1">Hardware Model</td>
<td colspan="1" rowspan="1">All Quartz elements from these model elements are moved to HwSystem element. <br><b>Note:</b>If there are nested Quartz elements, they are flattened and stored inside a single list</td>
</tr>
</table>
<h4><a id="section4.5.4.14"></a>Version APP4MC 0.7.2 to APP4MC 0.8.0</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.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>AMALTHEA Namespace (version App4MC 0.8.0)</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.7.2</td>
<td colspan="1" rowspan="1">http://app4mc.eclipse.org/amalthea/0.8.0</td>
</tr>
</table>
<p>
<strong>Below references are removed from storage format (amxmi):</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.7.2)</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">mode</td>
<td colspan="1" rowspan="1">Mode</td>
<td colspan="1" rowspan="1">ModeValueProvider</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">mode is made as a derived variable and transient property is set to it, as a result it will not be serialized into the model file. Based on the selection of ModeLiteral (in ModeValueProvider element) mode element will be considered accordingly.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">osDataConsistency</td>
<td colspan="1" rowspan="1">OsDataConsistency</td>
<td colspan="1" rowspan="1">OSModel</td>
<td colspan="1" rowspan="1">OS Model</td>
<td colspan="1" rowspan="1">OsDataConsistency element is shifted from OSModel to OperatingSystem element. As a part of migration, osDataConsistency element content is copied inside each OperatingSystem element</td>
</tr>
</table>
<p>
<strong>Below references names are changed :</strong>
</p>
<table class="classic" style="margin-left:40px">
<tr>
<td colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.7.2)</em>
</strong>
</td>
<th colspan="1" rowspan="1">
<strong>
<em>Variable Name (version APP4MC 0.8.0)</em>
</strong>
</th>
<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">mapping</td>
<td colspan="1" rowspan="1">memoryMapping</td>
<td colspan="1" rowspan="1">Mapping (in 0.7.2) -&gt; MemoryMapping (in 0.8.0)</td>
<td colspan="1" rowspan="1">MappingModel</td>
<td colspan="1" rowspan="1">Mapping model</td>
<td colspan="1" rowspan="1">As there is a change in the reference name (from mapping to memoryMapping) in metamodel --&gt; corresponding XML tag names in amxmi are changed from mapping to memoryMapping, type attribute is removed from memoryMapping XML tag as MemoryMapping is a concrete class</td>
</tr>
</table>
<p>
<strong>Below Classes/Interfaces 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.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">ModeValueProvider (Interface)</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">Content present inside ModeValueProvider class is moved to ModeLabel. Reference to Mode element is made as derived variable, and it automatically populated based on the selection of ModeLiteral.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SignedTimeObject</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">Equivalent of this element is TimeObject in APP4MC 0.8.0. There is no change in the storage format.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">SignedTime</td>
<td colspan="1" rowspan="1">SW Model</td>
<td colspan="1" rowspan="1">Equivalent of this element is Time in APP4MC 0.8.0. There is no change in the storage format.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Mapping</td>
<td colspan="1" rowspan="1">Mapping Model</td>
<td colspan="1" rowspan="1">This interface is removed from the model. MemoryMapping is equivalent of this model element in APP4MC 0.8.0. As a part of model migration type attribute is removed from the tag which is defining MemoryMapping.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AbstractElementMapping</td>
<td colspan="1" rowspan="1">Mapping Model</td>
<td colspan="1" rowspan="1">MemoryMapping is equivalent of this model element in APP4MC 0.8.0. As a part of model migration type attribute is removed from the tag which is defining MemoryMapping.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AbstractElementMemoryInformation</td>
<td colspan="1" rowspan="1">HW Model</td>
<td colspan="1" rowspan="1">AbstractMemoryElement is the equivalent of this model element in APP4MC 0.8.0. There is no change in the storage format.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">ProbabiltitySwitch</td>
<td colspan="1" rowspan="1">HW Model</td>
<td colspan="1" rowspan="1">ProbabiltitySwitch class is changed to ProbabilitySwitch (typo corrected in the class name). ProbabilitySwitch is the equivalent of this model element in APP4MC 0.8.0</td>
</tr>
<tr>
<td colspan="1" rowspan="1">AllocationConstraint</td>
<td colspan="1" rowspan="1">PropertyConstraints Model</td>
<td colspan="1" rowspan="1">AllocationConstraint class is changed to CoreAllocationConstraint. In CoreAllocationConstraint -&gt; reference to HwCoreConstraint element is removed, based on this change -&gt; during model migration CustomProperty is created with key as "hwConstraint (element removed during Migration of Model to 0.8.0 version)" and value as the XML content of "hwConstraint" element.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">MappingConstraint</td>
<td colspan="1" rowspan="1">PropertyConstraints Model</td>
<td colspan="1" rowspan="1">MappingConstraint class is changed to MemoryMappingConstraint. In MemoryMappingConstraint -&gt; reference to HwMemmoryConstraint element is removed, based on this change -&gt; during model migration CustomProperty is created with key as "hwConstraint (element removed during Migration of Model to 0.8.0 version)" and value as the XML content of "hwConstraint" element.</td>
</tr>
<tr>
<td colspan="1" rowspan="1">HwCoreConstraint, HwCoreConjunction, HwCoreProperty</td>
<td colspan="1" rowspan="1">PropertyConstraints Model</td>
<td colspan="1" rowspan="1">These elements are removed from the model. As a reference XML content is stored as a CustomProperty inside CoreAllocationConstraint</td>
</tr>
<tr>
<td colspan="1" rowspan="1">HwMemoryConstraint, HwMemoryConjunction, HwMemoryProperty</td>
<td colspan="1" rowspan="1">PropertyConstraints Model</td>
<td colspan="1" rowspan="1">These elements are removed from the model. As a reference XML content is stored as a CustomProperty inside MemoryMappingConstraint</td>
</tr>
</table>
<p>
<strong>Below are the changes in the datatype 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 datatype (version APP4MC 0.7.2)</em>
</strong>
</td>
<td colspan="1" rowspan="1">
<strong>
<em>Variable datatype (version APP4MC 0.8.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>Model Migration behavior</em>
</strong>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">instructionsPerCycle</td>
<td colspan="1" rowspan="1">int</td>
<td colspan="1" rowspan="1">float</td>
<td colspan="1" rowspan="1">CoreType</td>
<td colspan="1" rowspan="1">HW model</td>
<td colspan="1" rowspan="1">int is converted to float</td>
</tr>
</table>
<h4><a id="section4.5.4.15"></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 -&gt; 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" --&gt; 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" --&gt; 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) -&gt; 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 &amp; 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 -&gt; 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>
<h4><a id="section4.5.4.16"></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 -&gt; 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> "&lt;am:SWModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0"&gt;
&lt;labels/&gt;
&lt;/am:SWModel&gt;"
</code></pre> Output model (after model migration):
<pre xml:space="preserve"><code>&lt;am:Amalthea xmlns:am="http://app4mc.eclipse.org/amalthea/0.7.0" xmlns:xmi="http://www.omg.org/XMI"&gt;
&lt;swModel&gt;
&lt;labels /&gt;
&lt;/swModel&gt;
&lt;/am:Amalthea&gt;
</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>
<h2><a id="section4.6">4.6 </a>Model Utilities</h2>
<p>The model utilities provide implementations for typical usage scenarios:</p>
<dl>
<dt>
<strong>
<a href="javadoc/model/package-summary.html">General Helper Classes</a>
</strong>
</dt>
<dd>Support for search and delete</dd>
</dl>
<dl>
<dt>
<strong>
<a href="javadoc/model/builder/package-summary.html">Builder Classes</a>
</strong>
</dt>
<dd>Support for Groovy-like builders (Xtend2)</dd>
</dl>
<dl>
<dt>
<strong>
<a href="javadoc/model/io/package-summary.html">I/O Classes</a>
</strong>
</dt>
<dd>Support for loading and storing of models</dd>
</dl>
<dl>
<dt>
<strong>
<a href="javadoc/model/util/package-summary.html">Utilities</a>
</strong>
</dt>
<dd>Model utilities</dd>
</dl>
<p>
<i>Common</i>
</p>
<ul>
<li>
<a href="javadoc/model/util/ModelUtil.html">ModelUtil</a>
</li>
<li>
<a href="javadoc/model/util/FactoryUtil.html">FactoryUtil</a>
</li>
<li>
<a href="javadoc/model/util/CustomPropertyUtil.html">CustomPropertyUtil</a>
</li>
<li>
<a href="javadoc/model/util/TimeUtil.html">TimeUtil</a>
</li>
</ul>
<p>
<i>Specific</i>
</p>
<ul>
<li>
<a href="javadoc/model/util/SoftwareUtil.html">Software Utilities</a> - Activity graph traversal, accesses, calls
</li>
<li>
<a href="javadoc/model/util/RuntimeUtil.html">Runtime Utilities</a> - Runtime, utilization, ticks
</li>
<li>
<a href="javadoc/model/util/DeploymentUtil.html">Deployment Utilities</a> - Mapping of tasks to cores and data to memory
</li>
<li>
<a href="javadoc/model/util/HardwareUtil.html">Hardware Utilities</a> - Access paths and latencies
</li>
</ul>
<p>
<b>
<i>Scope</i>
</b>
</p>
<p>The model utilities are part of the model plugin.</p>
<h2><a id="section4.7">4.7 </a>Model Details</h2>
<h3><a id="section4.7.1">4.7.1 </a>Qualified name</h3>
<p>The following image shows the logical dependency between the name segments and describe the used notations. The details differ in terms of delimiters and encoding of the segments.</p>
<p>
<img src="images/dev_model_qualified_name.png"/>
</p>
<h3><a id="section4.7.2">4.7.2 </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(&lt;name of element&gt;, StandardCharsets.UTF_8.toString)) + "?type=" + &lt;element&gt;.eClass.name
</code></pre>
<p>Samples:</p>
<p>Refering to a Runnable element with name foo in a RunnableCall looks like the following snippet:</p>
<pre xml:space="preserve"><code>&lt;items xsi:type="am:RunnableCall" runnable="foo?type=Runnable" /&gt;
</code></pre>
<h3><a id="section4.7.3">4.7.3 </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.7.4">4.7.4 </a>Derived references</h3>
<p>Some derived references are introduces to simplify a multi-level navigation. They are read only.</p>
<table>
<tr>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1" style="text-align:center">Reference</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ISystem</code>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>innerPorts</strong> →
</td>
<td colspan="1" rowspan="1">
<code>QualifiedPort</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwStructure</code>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>innerPorts</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwPort</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwPath</code>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>source</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ProcessingUnit</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwPath</code>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>destination</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwDestination</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>childSchedulers</strong> →
</td>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>parentScheduler</strong> →
</td>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
</tr>
</table>
<h3><a id="section4.7.5">4.7.5 </a>Transient back pointers</h3>
<p>AMALTHEA maintains a number of back pointers in the model. These transient references of an object 'point back' to the object referring to it. </p>
<h4><a id="section4.7.5.1"></a>Container references</h4>
<p>Container references provide an easier access to the eContainer of an object.</p>
<p>The following references are specified as opposite references and can be modified.
<br>By the prefix "containing" they clearly indicate that a containment is changed.
</p>
<table>
<tr>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">Container reference</td>
<td colspan="1" rowspan="1" style="text-align: right;">Containment reference</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Component</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingComponent</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>ports</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ComponentPort</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>EnumMode</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingMode</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>literals</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ModeLiteral</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwFeatureCategory</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingCategory</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>features</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwFeature</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwAccessElement</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingAccessElement</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>accessPath</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwAccessPath</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>RunnableCall</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingCall</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>arguments</strong> →
</td>
<td colspan="1" rowspan="1">
<code>CallArgument</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ISystem</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingSystem</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>componentInstances</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ComponentInstance</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ISystem</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingSystem</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>connectors</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Connector</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Namespace</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>previousSegment</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>nextSegments</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Namespace</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Runnable</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingRunnable</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>parameters</strong> →
</td>
<td colspan="1" rowspan="1">
<code>RunnableParameter</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ComponentInterface</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingInterface</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>subInterfaces</strong> →
</td>
<td colspan="1" rowspan="1">
<code>SubInterface</code>
</td>
</tr>
</table>
<p>The following references are specified as opposite references.</p>
<table>
<tr>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">Container reference (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>ProcessingUnit</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>source</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>accessElements</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwAccessElement</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>child</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>parentAssociation</strong> →
</td>
<td colspan="1" rowspan="1">
<code>SchedulerAssociation</code>
</td>
</tr>
</table>
<p>The following container references are a special case. Because of the nested structure of sub elements the access to a dedicated container object is computed by traversing multiple eContainer references.</p>
<table>
<tr>
<td colspan="1" rowspan="1"/>
<td colspan="1" rowspan="1">Container reference (read only)</td>
<td colspan="1" rowspan="1" style="text-align: right;">Containment reference</td>
<td colspan="1" rowspan="1"/>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Runnable</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingRunnable</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>activityGraph ...</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ActivityGraphItem</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Process</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingProcess</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>activityGraph ...</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ActivityGraphItem</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ActivityGraph</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingActivityGraph</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>items ...</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ActivityGraphItem</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Runnable</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>containingRunnable</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>...</strong> →
</td>
<td colspan="1" rowspan="1">
<code>DataDependency</code>
</td>
</tr>
</table>
<h4><a id="section4.7.5.2"></a>References (via inverse index)</h4>
<p>The inverse index allows easier and faster navigation, at the expense of greater memory consumption.
<br>The index is built on demand.
</p>
<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>ChannelAccess</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>channelAccesses</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>data</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Channel</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>SemaphoreAccess</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>semaphoreAccesses</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>semaphore</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Semaphore</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 a memory via a MemoryMapping. The back pointers provides a list of all mapping elements that refer to a specific memory or a specific MemoryElement.</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>MemoryMapping</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>MemoryMapping</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>AbstractMemoryElement</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>
<p>CustomEvent and InterProcessStimulus can have explicit triggers. The pointer is established from CustomEventTrigger and InterProcessTrigger. The back pointers provides easier access to the triggering runnables / processes.</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>CustomEventTrigger</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>explicitTriggers</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>event</strong> →
</td>
<td colspan="1" rowspan="1">
<code>CustomEvent</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>InterProcessTrigger</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>explicitTriggers</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>stimulus</strong> →
</td>
<td colspan="1" rowspan="1">
<code>InterProcessStimulus</code>
</td>
</tr>
</table>
<p>Components define lists of included software elements (e.g. labels, runnables, semaphores). The back pointer provides access to all referring components.</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>Component</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>referringComponents</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>labels</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Label</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Component</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>referringComponents</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>runnables</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Runnable</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Component</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>referringComponents</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>processes</strong> →
</td>
<td colspan="1" rowspan="1">
<code>AbstractProcess</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Component</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>referringComponents</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>semaphores</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Semaphore</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>Component</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>referringComponents</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>osEvents</strong> →
</td>
<td colspan="1" rowspan="1">
<code>OsEvent</code>
</td>
</tr>
</table>
<p>Allocations refer to a scheduler (Scheduler, TaskScheduler, InterruptController). The back pointer provides access from the scheduler to the allocations.</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>SchedulerAllocation</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>schedulerAllocations</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>scheduler</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Scheduler</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>RunnableAllocation</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>runnableAllocations</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>scheduler</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Scheduler</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>TaskAllocation</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>taskAllocations</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>scheduler</strong> →
</td>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ISRAllocation</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>isrAllocations</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>controller</strong> →
</td>
<td colspan="1" rowspan="1">
<code>InterruptController</code>
</td>
</tr>
</table>
<p>Some other useful back references.</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>Process</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>affectedProcesses</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>stimuli</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Stimulus</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>ITaggable</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>taggedObjects</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>tags</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Tag</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>SchedulerAssociation</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>childAssociations</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>parent</strong> →
</td>
<td colspan="1" rowspan="1">
<code>TaskScheduler</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>INamespaceMember</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>memberObjects</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>namespace</strong> →
</td>
<td colspan="1" rowspan="1">
<code>Namespace</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>IComponentStructureMember</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>memberObjects</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>structure</strong> →
</td>
<td colspan="1" rowspan="1">
<code>ComponentStructure</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwConnection</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>connections</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>port1</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwPort</code>
</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<code>HwConnection</code>
</td>
<td colspan="1" rowspan="1" style="color:green">←
<strong>connections</strong>
</td>
<td colspan="1" rowspan="1" style="text-align: right;">
<strong>port2</strong> →
</td>
<td colspan="1" rowspan="1">
<code>HwPort</code>
</td>
</tr>
</table>
<h4><a id="section4.7.5.3"></a>Implementation</h4>
<p>
<b>Xcore:</b>
</p>
<p>A derived back pointer is computed by
<span>
<strong>AmaltheaIndex.getInverseReferences(...)</strong>
</span>.
<br>The visiblity in the generated code and in the user interface is controlled by
<span>
<strong>@GenModel</strong>
</span> annotations.
</p>
<p>Example</p>
<pre xml:space="preserve"><code>class Runnable extends AbstractMemoryElement
{ ...
// back pointer (readonly)
@GenModel(documentation="&lt;p&gt;&lt;b&gt;Returns an &lt;em&gt;immutable&lt;/em&gt; list of callers (RunnableCalls).&lt;/b&gt;&lt;/p&gt;")
@GenModel(propertyCategory="Read only", propertyFilterFlags="org.eclipse.ui.views.properties.expert")
refers transient readonly volatile derived RunnableCall[] runnableCalls get {
AmaltheaIndex.getInverseReferences(this, AmaltheaPackage.eINSTANCE.runnable_RunnableCalls,
#{AmaltheaPackage.eINSTANCE.runnableCall_Runnable} )
}
</code></pre>
<p><!-- --></p>
<h4><a id="section4.7.5.4"></a>User Interface</h4>
<p>
<img src="images/model_transient_backpointer_ui.png"/>
</p>
<h2><a id="section4.8">4.8 </a>AMALTHEA Model Definition</h2>
<h3><a id="section4.8.1">4.8.1 </a>Ecore</h3>
<p>The AMALTHEA model is specified with the Eclipse Modeling Framework (EMF). Eclipse/Java developers can use the AMALTHEA Platform where the generated Java classes of the model are included. The underlying Xcore definition of the model is part of the model plugin.</p>
<p>Both definitions (the original
<strong>Xcore file</strong> and the derived
<strong>Ecore files</strong>) can be found
<a href="zip/ecore-definitions.zip">here</a>.
</p>
<h3><a id="section4.8.2">4.8.2 </a>XML Schema Definition (XSD)</h3>
<p>For developers that are not using Java or Eclipse, the specification is also provided in the XML and XSD format. The
<strong>XML related files</strong> can be found
<a href="zip/xml-definitions.zip">here</a>.
</p>
<p>The AMALTHEA model refers to the Ecore model definition (http://www.eclipse.org/emf/2002/Ecore).
<br>This definition (generated automatically during conversion) is also stored in the archive.
</p>
<p>---</p>
<p>The Franca model has no longer a direct connection but still can be used to describe interfaces.</p>
<p>Franca 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 -&gt; Show View -&gt; 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>
<h2><a id="section4.9">4.9 </a>AMALTHEA Trace Database (preview of new version)</h2>
<p>The new AMALTHEA Trace DataBase (ATDB) primarily used to represent a runtime trace in a database format. As part of the rework, ATDB can also be used to calculate derived metrics from the trace data it holds. Since it is intended to be used in conjunction with AMALTHEA, the calculable metrics are a subset of the metrics found in AMALTHEA. However, the database schema allows for arbitrary events, entities, properties, and metrics.</p>
<p>The database is stored as
<a href="http://www.sqlite.org/">SQLite Database</a> with extension
<strong>.atdb</strong>. It provides the data tables and several views to make the data contained in the data base more user-accessible. For performance reasons, there are some indices to speed up the access times. The general database structure and views will be described in the following sections.
</p>
<h3><a id="section4.9.1">4.9.1 </a>Database Structure</h3>
<p>The database schema is defined completely static. Depending on the detail of data to be stored some of the tables are optional (they can be temporary to calculate metrics and do not need to be persisted). The following tables are defined:</p>
<ul>
<li>Default:
<ul>
<li>MetaInformation</li>
<li>Entity</li>
<li>EntityType</li>
<li>EntityInstance</li>
<li>EventType</li>
<li>Property</li>
<li>PropertyValue</li>
<li>Event</li>
<li>Metric</li>
<li>EntityMetricValue</li>
<li>EntityInstanceMetricValue</li>
<li>EntityMetricInstanceValue</li>
</ul>
</li>
<li>Optional:
<ul>
<li>TraceEvent</li>
<li>RunnableInstanceEventInfo</li>
<li>ProcessInstanceEventInfo</li>
<li>EventChainInstanceInfo</li>
</ul>
</li>
</ul>
<p>The database schema as Entity Relationship diagram:</p>
<p>
<img src="images/atdb_db_schema.svg"/>
</p>
<h4><a id="section4.9.1.1"></a>Core Tables</h4>
<p>The core tables refer to all white tables from the picture, without them, the database would not be meaningful. So these are mandatory to contain datasets.</p>
<h5><a id="section4.9.1.1.1"></a>MetaInformation</h5>
<p>This table contains simple key-value pairs containing information about the trace, how it was recorded, how long it is, etc. It may also contain other information, e.g., the file name(s) of the related AMALTHEA model.</p>
<ul>
<li>Columns
<ul>
<li>name: text – Primary Key</li>
<li>value: text – unique</li>
</ul>
</li>
</ul>
<p>So far, commonly used names include the following:</p>
<ul>
<li>
<strong>dbVersion</strong>: version of the ATDB schema with syntax "v#.#.#". Current version is "v1.0.0"
</li>
<li>
<strong>eventsWritten</strong>: number of events stored in the database
</li>
<li>
<strong>input</strong>: path to the file, from which the information was produced
</li>
<li>
<strong>timeBase</strong>: time unit in which time-values are stored
</li>
</ul>
<h5><a id="section4.9.1.1.2"></a>Entity</h5>
<p>The entity table contains information about all artifacts used in the database. This may include things that are not visible in the underlying trace, e.g., event chains.</p>
<ul>
<li>Columns
<ul>
<li>id: integer – Primary Key</li>
<li>name: text – unique, the name of the entity</li>
<li>entityTypeId: integer – Foreign Key, reference to entityType.id</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.1.3"></a>EntityType</h5>
<p>In order to classify entities, this table contains datasets about their types. These types can be referenced in the entityTypeId column of the entity table.</p>
<ul>
<li>Columns
<ul>
<li>id: integer – Primary Key</li>
<li>name: text – unique, the name of the entity type</li>
</ul>
</li>
</ul>
<p>Currently, the following type names are commonly used (also see BTF specification):</p>
<ul>
<li>
<strong>T</strong>: task
</li>
<li>
<strong>I</strong>: interrupt service routine
</li>
<li>
<strong>R</strong>: runnable
</li>
<li>
<strong>EC</strong>: event chain
</li>
<li>
<strong>SIM</strong>: simulation
</li>
<li>
<strong>STI</strong>: stimulus
</li>
<li>
<strong>ECU</strong>: electronic control unit
</li>
<li>
<strong>Processor</strong>: micro controller
</li>
<li>
<strong>C</strong>: core
</li>
<li>
<strong>M</strong>: memory
</li>
<li>
<strong>SCHED</strong>: scheduler
</li>
<li>
<strong>SIG</strong>: label/signal
</li>
<li>
<strong>SEM</strong>: semaphore
</li>
<li>
<strong>EVENT</strong>: operating system event (used for synchronization)
</li>
</ul>
<p>This table may contain more entity types as long as they are unique within this table.</p>
<h5><a id="section4.9.1.1.4"></a>EntityInstance</h5>
<p>Entities may be instantiated multiple times. In a trace this may be the time span between the start and terminate event of a runnable entity. For a periodic time stimulus an instance represents the nth occurence of the time stimulus. In order to differentiate between these instances this table holds two values which act as a unique identification for entity instances. They will be referenced from various entity-instance-specific tables.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – Foreign Key, references an entity</li>
<li>sqcnr: integer – strictly sequential counting number (starting with 0) that will be counted up per unique entityId</li>
<li>
<strong>Compound Primary Key</strong>: entityId, sqcnr
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.1.5"></a>EventType</h5>
<p>Similar to entity types this table contains types of events that can be referenced from the event and trace event tables. This also represents the connection between which events shall be observed (the ones in the event table) and which events are actually in the trace (the ones in the trace event table). The commonly used event type names are the intersection between the events from AMALTHEA and the events from the BTF specification. Just like for entity types, this table may contain additional event types (unique).</p>
<ul>
<li>Columns
<ul>
<li>id: integer – Primary Key</li>
<li>name: text – unique, the name of the event type</li>
</ul>
</li>
</ul>
<h4><a id="section4.9.1.2"></a>Auxillary Data Tables</h4>
<p>Additional information about entities which may help to understand and analyze the trace can be provided in auxillary tables. They are represented in yellow in the above data base schema diagram. Some information in these tables can be derived from the trace, e.g., the runnable to task mapping, other data (like event chains and events) will be sourced from the original AMALTHEA model.</p>
<h5><a id="section4.9.1.2.1"></a>Property</h5>
<p>A table for all possible properties that an entity may have in the database.</p>
<ul>
<li>Columns
<ul>
<li>id: integer – Primary Key</li>
<li>name: text – unique, the name of the property</li>
<li>type: text – the type of the property</li>
</ul>
</li>
</ul>
<p>Currently, the following property names with their types are used:</p>
<ul>
<li>
<strong>simultionDuration</strong>: time – the duration of the simulation that produced the trace, time is a double value, the global time unit can be specified in MetaInformation, if not specified defaults to nano seconds
</li>
<li>
<strong>initValue</strong>: object – the initial value of a signal/label at the begin of the trace
</li>
<li>
<strong>processors</strong>: entityIdRef – multi-valued reference to other entities acting as processors for this entity
</li>
<li>
<strong>cores</strong>: entityIdRef – multi-valued reference to other entities acting as cores for this entity
</li>
<li>
<strong>frequencyInHz</strong>: long – the clock frequency, e.g. of a core, usually an integer
</li>
<li>
<strong>executingCore</strong>: entityIdRef – reference to an other entity acting as the executing core for this entity
</li>
<li>
<strong>runnables</strong>: entityIdRef – multi-valued reference to other entities acting as runnables for this entity
</li>
<li>
<strong>ecItems</strong>: entityIdRef – multi-valued reference to other event chain entities acting as items for this event chain entity
</li>
<li>
<strong>ecStimulus</strong>: eventIdRef – reference to an event acting as the stimulus for this event chain entity (multiple values represent an event set)
</li>
<li>
<strong>ecResponse</strong>: eventIdRef – reference to an event acting as the response for this event chain entity (multiple values represent an event set)
</li>
</ul>
<h5><a id="section4.9.1.2.2"></a>PropertyValue</h5>
<p>Here, the actual properties are set for entities. Multiple property values are represented with a strictly sequential counting number (sqcnr). In case of ordered multiple values, this acts as the index of the value within the list of values.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – Foreign Key, the id of the entity for which a row in this table holds a property value</li>
<li>propertyId: integer – Foreign Key, the id of the property for which a row in this table holds a value</li>
<li>sqcnr: integer – strictly sequential counting number (starting with 0) that will be counted up for each unique entityId – propertyId pair</li>
<li>value: text – text representation of the value of the property</li>
<li>
<strong>Compound Primary Key</strong>: entityId, propertyId, sqcnr
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.2.3"></a>Event</h5>
<p>Observable event specifications directly sourced from an AMALTHEA model can be stored in this table. Since event sets are handled via multi-valued properties, this table directly corresponds the abstract EntityEvent meta-class from AMALTHEA. The description field is left out. The name, eventType, and entity columns directly match the AMALTHEA pendants. The subtype-specific references in the EntityEvents are abstractly represented by the sourceEntity in this table. The events contained in this table are referenced in event chain entities.</p>
<ul>
<li>Columns
<ul>
<li>id: integer – Primary Key</li>
<li>name: text – unique, the name of the event</li>
<li>eventTypeId: integer – Foreign Key, reference to the type of this event</li>
<li>entityId: integer – Foreign Key, reference to the entity that shall experience this event</li>
<li>sourceEntityId: integer – Foreign Key, reference to the source entity that shall emit this event</li>
</ul>
</li>
</ul>
<h4><a id="section4.9.1.3"></a>Metric Tables</h4>
<p>Derived information about entities and their instances which can be calculated (via metrics) based on an event trace may be stored in metric tables. In the above diagram these tables are colored in green.</p>
<h5><a id="section4.9.1.3.1"></a>Metric</h5>
<p>Similar to Property, this table contains the name and dimension for metrics which are referenced by the other metric tables. Commonly used metrics per entity type are defined in the Requirements section of the AMALTHEA data model [REFERENCE???].</p>
<ul>
<li>Columns
<ul>
<li>id: integer – Primary Key</li>
<li>name: text – unique, the name of the metric</li>
<li>dimension: text – the dimension of the metric (e.g. time, count, percentage, ...)</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.3.2"></a>EntityMetricValue</h5>
<p>Contains entity-specific values for given metrics.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – Foreign Key, the id of the entity for which the metric was calculated</li>
<li>metricId: integer – Foreign Key, the id of the metric that was calculated for the entity</li>
<li>value: text – textual representation of the metric's value</li>
<li>
<strong>Compound Primary Key</strong>: entityId, metricId
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.3.3"></a>EntityInstaneMetricValue</h5>
<p>Contains entity-instance-specific values for given metrics.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – the entity id of the entity instance</li>
<li>entityInstance: integer – the instance number of the entity</li>
<li>metricId: integer – Foreign Key, the id of the metric that was calculated for the entity instance</li>
<li>value: text – textual representation of the metric's value</li>
<li>
<strong>Compound Primary Key</strong>: entityId, entityInstance, metricId
</li>
<li>
<strong>Compound Foreign Key</strong>: entityId, entityInstance of EntityInstance
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.3.4"></a>EntityMetricInstanceValue</h5>
<p>Contains entity-specific values for given metrics. The sqcnr can be used to represent instances which are not differentiated by entity instances (e.g. by a constant sized time frame). Metrics like the average core load based on time slices can be stored here.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – Foreign Key, the id of the entity for which the metric instance was calculated</li>
<li>metricId: integer – Foreign Key, the id of the metric whose instance was calculated for the entity</li>
<li>sqcnr: integer – strictly sequential counting number (starting with 0) that will be counted up for each unique entityId – metricId pair</li>
<li>value: text – textual representation of the metric instance's value</li>
<li>
<strong>Compound Primary Key</strong>: entityId, metricId, sqcnr
</li>
</ul>
</li>
</ul>
<h4><a id="section4.9.1.4"></a>Optional Tables</h4>
<p>Depending on how much information shall be exchanged/contained in this data base the following tables do not have to be stored (they can be declared as TEMPORARY). They can, however, be quite usefull in calculating metrics about entities in a structured and comprehensive way. Once the metrics are calculated, there is no reference back to these optional tables. So, they do not have to remain in the data base. Since these tables represent a full event trace, omitting them can greatly reduce the size of the data base.</p>
<h5><a id="section4.9.1.4.1"></a>TraceEvent</h5>
<p>Opposite to the observable events, this table is used to store all events directly from a BTF trace (in timestamp ascending order). For multiple events happening at the same timestamp there is a strictly sequential counting number. All other columns of this table correspond to a typical event line in a BTF trace.</p>
<ul>
<li>Columns
<ul>
<li>timestamp: integer – point in time at which the event occurred</li>
<li>sqcnr: integer – strictly sequential counting number (starting with 0) that will be counted up for each unique timestamp</li>
<li>entityId: integer – the entity id of the entity instance</li>
<li>entityInstance: integer – the instance number of the entity</li>
<li>sourceEntityId: integer – the entity id of the source entity instance</li>
<li>entityInstance: integer – the instance number of the source entity</li>
<li>eventTypeId: integer – Foreign Key, the id of the event's type</li>
<li>value: text – in BTF this column is called
<em>Note</em>, for signal/label write events this may hold the written value
</li>
<li>
<strong>Compound Primary Key</strong>: timestamp, sqcnr
</li>
<li>
<strong>Compound Foreign Key</strong>: entityId, entityInstance of EntityInstance
</li>
<li>
<strong>Compound Foreign Key</strong>: sourceEntityId, sourceEntityInstance of EntityInstance
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.4.2"></a>RunnableInstanceTraceInfo</h5>
<p>Derived information about runnable events for easier metric calculation. All values are derived from TraceEvent. The event counts per runnable instance stored in this table help to determine if the runnable instance is completely captured within the trace.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – the id of the runnable instance</li>
<li>entityInstance: integer – the instance number of the runnable</li>
<li>[RunnableEventType]EventCount: integer – the count of the respective event type for the runnable instance</li>
<li>isComplete: boolean – derived from the event counts for each runnable instance, will be TRUE if the instance is completely captured in the trace, FALSE otherwise</li>
<li>
<strong>Compound Primary Key</strong>: entityId, entityInstance
</li>
<li>
<strong>Compound Foreign Key</strong>: entityId, entityInstance of EntityInstance
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.4.3"></a>ProcessInstanceTraceInfo</h5>
<p>Derived information about process (task or ISR) events for easier metric calculation. All values are derived from TraceEvent. The event counts per process instance stored in this table help to determine if the process instance is completely captured within the trace.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – the id of the processs instance</li>
<li>entityInstance: integer – the instance number of the process</li>
<li>[ProcessEventType]EventCount: integer – the count of the respective event type for the process instance</li>
<li>isComplete: boolean – derived from the event counts for each process instance, will be TRUE if the instance is completely captured in the trace, FALSE otherwise</li>
<li>
<strong>Compound Primary Key</strong>: entityId, entityInstance
</li>
<li>
<strong>Compound Foreign Key</strong>: entityId, entityInstance of EntityInstance
</li>
</ul>
</li>
</ul>
<h5><a id="section4.9.1.4.4"></a>EventChainInstanceInfo</h5>
<p>Derived information about event chain instances for easier metric calculation. All values are derived from event chain entities (and their properties) and TraceEvent. This table connects the event chain instances in EntityInstance to their corresponding stimulus and response events (via Compound Foreign Key) in TraceEvent. Since event chains can be subject to EventChainLatencyConstraints and there are only two types of instances considered (age and reaction) this table holds information about whether the event chain instance is age, reaction, or both.</p>
<ul>
<li>Columns
<ul>
<li>entityId: integer – the id of the event chain instance</li>
<li>entityInstance: integer – the instance number of the event chain</li>
<li>stimulusTimestamp: integer – the timestamp of the stimulus event of this event chain instance</li>
<li>stimulusSqcnr: integer – the sqcnr of the stimulus timestamp</li>
<li>responseTimestamp: integer – the timestamp of the response event of this event chain instance</li>
<li>responseSqcnr: integer – the sqcnr of the response timestamp</li>
<li>isAge: boolean – TRUE if this event chain instance represents the age</li>
<li>isReaction: boolean – TRUE if this event chain instance represents the reaction</li>
<li>
<strong>Compound Primary Key</strong>: entityId, entityInstance
</li>
<li>
<strong>Compound Foreign Key</strong>: entityId, entityInstance of EntityInstance
</li>
<li>
<strong>Compound Foreign Key</strong>: stimulusTimestamp, stimulusSqcnr of TraceEvent
</li>
<li>
<strong>Compound Foreign Key</strong>: responseTimestamp, responseSqcnr of TraceEvent
</li>
</ul>
</li>
</ul>
<h3><a id="section4.9.2">4.9.2 </a>Database Views</h3>
<p>In order to better comprehend the contents of the database, SQLite offers the definition of views, which can be used to display the tables in a more readable way. With the help of views, the database contents can be presented in a standard database browser without knowing the meaning or significance of the table values – this is conveyed in views. This section will describe the views, which in turn can be understood as database tables, and how they are derived from the persisted tables from above. The
<em>how</em> will also be given as SQL statements.
</p>
<h4><a id="section4.9.2.1"></a>Core Views</h4>
<p>The core tables include MetaInformation, Entity, EntityType, EntityInstance, and EventType. Since these tables only contain a small number of columns which are comprehensible on their own, there are no views defined for the core tables.</p>
<h4><a id="section4.9.2.2"></a>Auxillary Data Views</h4>
<p>The auxillary data tables contain more columns and refer to other tables to some extent. The following views are defined for ausillary tables:</p>
<h5><a id="section4.9.2.2.1"></a>vProperty</h5>
<p>This view shows the entity names and property names, with their corresponding values (multiple values are shown in one value entry, where the values are concatenated). In addition they also show the entity and property type names.</p>
<ul>
<li>Columns
<ul>
<li>entityName: text – name of the entity with the property value</li>
<li>entityType: text – name of the entity type of the entity</li>
<li>propertyName: text – name of the property</li>
<li>propertyType: text – type of the property</li>
<li>value: text – value of the property, if there are multiple values: comma-seperated values</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the view:</p>
<pre xml:space="preserve"><code>SELECT
(SELECT name FROM entity WHERE id = propertyValue.entityId) AS entityName,
(SELECT name FROM entityType WHERE id = (SELECT entityTypeId FROM entity WHERE id = propertyValue.entityId)) AS entityType,
(SELECT name FROM property WHERE id = propertyValue.propertyId) AS propertyName,
(SELECT type FROM property WHERE id = propertyValue.propertyId) AS propertyType,
(GROUP_CONCAT(CASE
WHEN propertyValue.propertyId IN (SELECT id FROM property WHERE type = 'entityIdRef') THEN
(SELECT name FROM entity WHERE id = propertyValue.value)
WHEN propertyValue.propertyId IN (SELECT id FROM property WHERE type = 'eventIdRef') THEN
(SELECT name FROM event WHERE id = propertyValue.value)
ELSE
propertyValue.value
END, ', ')) AS value
FROM propertyValue GROUP BY entityId, propertyId ORDER BY entityId, propertyId
</code></pre>
<h5><a id="section4.9.2.2.2"></a>vEvent</h5>
<p>The observable event specification refers to EventType and Entity. This view resolves the referenced ids and presents the events in an understandable way.</p>
<ul>
<li>Columns
<ul>
<li>name: text – name of the observable event</li>
<li>eventType: text – name of the type of the observalbe event</li>
<li>entityName: text – name of the entity that shall be subject to the observable event</li>
<li>entityType: text – name of the type of the entity</li>
<li>sourceEntityName: text – name of the source entity that is responsible for the observable event</li>
<li>sourceEntityType: text – name of the type of the source entity</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the Event view:</p>
<pre xml:space="preserve"><code>SELECT
name,
(SELECT name FROM eventType WHERE id = eventTypeId) AS eventType,
(SELECT name FROM entity WHERE id = entityId) AS entityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = event.entityId)
) AS entityType,
(SELECT name FROM entity WHERE id = sourceEntityId) AS sourceEntityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = event.sourceEntityId)
) AS sourceEntityType
FROM event
</code></pre>
<h5><a id="section4.9.2.2.3"></a>vEventChainEntity</h5>
<p>As a special case, event chains are also stored as entities, however, they never act as a subject or source entity in the trace event table. In order to better present and highlight them among all other entities, this view provides a comprehensive representation of all event chain entities.</p>
<ul>
<li>Columns
<ul>
<li>eventChainName: text – name from entity</li>
<li>stimulus: text – name(s) of the observable stimulus event(s)</li>
<li>response: text – name(s) of the observable response event(s)</li>
<li>items: text – names of all event chain items</li>
<li>minItemsCompleted: integer – number of parallel items that shall be completed until an instance of this event chain is considered complete</li>
<li>isParallel: boolean – TRUE if the property with the name 'minItemsCompleted' is set</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the event chain entity view:</p>
<pre xml:space="preserve"><code>SELECT
name AS eventChainName,
(SELECT GROUP_CONCAT(name, ', ') FROM event WHERE id IN (SELECT value FROM propertyValue WHERE entityId = ecEntity.id AND
propertyId = (SELECT id FROM property WHERE name = 'ecStimulus'))) AS stimulus,
(SELECT GROUP_CONCAT(name, ', ') FROM event WHERE id IN (SELECT value FROM propertyValue WHERE entityId = ecEntity.id AND
propertyId = (SELECT id FROM property WHERE name = 'ecResponse'))) AS response,
(SELECT GROUP_CONCAT(name, ', ') FROM entity WHERE id IN (SELECT value FROM propertyValue WHERE entityId = ecEntity.id AND
propertyId = (SELECT id FROM property WHERE name = 'ecItems' ))) AS items,
(SELECT value FROM propertyValue WHERE entityId = ecEntity.id AND propertyId =
(SELECT id FROM property WHERE name = 'ecMinItemsCompleted')) AS minItemsCompleted,
EXISTS(SELECT value FROM propertyValue WHERE entityId = ecEntity.id AND propertyId =
(SELECT id FROM property WHERE name = 'ecMinItemsCompleted')) AS isParallel
FROM entity AS ecEntity WHERE entityTypeId = (SELECT id FROM entityType WHERE entityType.name = 'EC')
</code></pre>
<h4><a id="section4.9.2.3"></a>Metric Views</h4>
<p>The metric views resolve the entity and metric ids into the corresponding names and displays them. The three metric views are thus very similar.</p>
<h5><a id="section4.9.2.3.1"></a>vEntityMetricValue</h5>
<p>This view presents non-instance-specific entity metrics.</p>
<ul>
<li>Columns
<ul>
<li>entityName: text – name of the entity for which this metric is stored</li>
<li>entityType: text – name of the type of the entity</li>
<li>metricName: text – name of the metric</li>
<li>value: text – from EntityMetricValue</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the entity metric value view:</p>
<pre xml:space="preserve"><code>SELECT
(SELECT name FROM entity WHERE id = entityMetricValue.entityId) AS entityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = entityMetricValue.entityId)
) AS entityType,
(SELECT name FROM metric WHERE id = entityMetricValue.metricId) AS metricName,
entityMetricValue.value
FROM entityMetricValue
ORDER BY entityId, metricId
</code></pre>
<h5><a id="section4.9.2.3.2"></a>vEntityInstanceMetricValue</h5>
<p>A representation of the entity instance-specific metrics is given with this view.</p>
<ul>
<li>Columns
<ul>
<li>entityName: text – name of the entity for which this metric is stored</li>
<li>entityType: text – name of the type of the entity</li>
<li>entityInstance: integer – from EntityInstanceMetricValue</li>
<li>metricName: text – name of the metric</li>
<li>value: text – from EntityInstanceMetricValue</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the entity instance metric value view:</p>
<pre xml:space="preserve"><code>SELECT
(SELECT name FROM entity WHERE id = entityInstanceMetricValue.entityId) AS entityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = entityInstanceMetricValue.entityId)
) AS entityType,
entityInstanceMetricValue.entityInstance,
(SELECT name FROM metric WHERE id = entityInstanceMetricValue.metricId) AS metricName,
entityInstanceMetricValue.value
FROM entityInstanceMetricValue
ORDER BY entityId, entityInstance, metricId
</code></pre>
<h5><a id="section4.9.2.3.3"></a>vEntityMetricInstanceValue</h5>
<p>This view shows entity metrics that are not grouped by entity instances but by metric instances.</p>
<ul>
<li>Columns
<ul>
<li>entityName: text – name of the entity for which this metric is stored</li>
<li>entityType: text – name of the type of the entity</li>
<li>metricName: text – name of the metric</li>
<li>sqcnr: integer – from EntityMetricInstanceValue</li>
<li>value: text – from EntityMetricInstanceValue</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the entity metric instance value view:</p>
<pre xml:space="preserve"><code>SELECT
(SELECT name FROM entity WHERE id = entityMetricInstanceValue.entityId) AS entityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = entityMetricInstanceValue.entityId)
) AS entityType,
(SELECT name FROM metric WHERE id = entityMetricInstanceValue.metricId) AS metricName,
entityMetricInstanceValue.sqcnr,
entityMetricInstanceValue.value
FROM entityMetricInstanceValue
ORDER BY entityId, metricId, sqcnr
</code></pre>
<h4><a id="section4.9.2.4"></a>Optional Views</h4>
<p>These views are derived from optional tables. So they may not be persisted in the database file.</p>
<h5><a id="section4.9.2.4.1"></a>vTraceEvent</h5>
<p>The trace event table itself is not readable like the BTF since all the references are ids. This view therefore offers a more BTF-like trace event table.</p>
<ul>
<li>Columns
<ul>
<li>timestamp: integer – from TraceEvent</li>
<li>sqcnr: integer – from TraceEvent</li>
<li>entityName: text – name of the entity that is subject to the trace event</li>
<li>entityType: text – name of the type of the entity</li>
<li>entityInstance: integer – from TraceEvent</li>
<li>sourceEntityName: text – name of the source entity that is responsible for the trace event</li>
<li>sourceEntityType: text – name of the type of the source entity</li>
<li>sourceEntityInstance: integer – from TraceEvent</li>
<li>eventType: text – name of the type of the trace event</li>
<li>value: text – from TraceEvent</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the TraceEvent view:</p>
<pre xml:space="preserve"><code>SELECT
traceEvent.timestamp,
traceEvent.sqcnr,
(SELECT name FROM entity WHERE id = traceEvent.entityId) AS entityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = traceEvent.entityId)
) AS entityType,
traceEvent.entityInstance,
(SELECT name FROM entity WHERE id = traceEvent.sourceEntityId) AS sourceEntityName,
(SELECT name FROM entityType WHERE id =
(SELECT entityTypeId FROM entity WHERE id = traceEvent.sourceEntityId)
) AS sourceEntityType,
traceEvent.sourceEntityInstance,
(SELECT name FROM eventType WHERE id = traceEvent.eventTypeId) AS eventType,
traceEvent.value
FROM traceEvent
</code></pre>
<h5><a id="section4.9.2.4.2"></a>vRunnableInstanceRuntimeTraceEvent</h5>
<p>This provides a filtered view on TraceEvent where the subject entity is a runnable.</p>
<ul>
<li>Columns
<ul>
<li>timestamp: integer – from TraceEvent</li>
<li>sqcnr: integer – from TraceEvent</li>
<li>runnableName: text – name of the runnable entity</li>
<li>entityInstance: integer – from TraceEvent</li>
<li>sourceEntityName: text – name of the source entity that is responsible for the runnable trace event</li>
<li>sourceEntityInstance: integer – from TraceEvent</li>
<li>eventType: text – name of the type of the runnable trace event</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the runnable instance TraceEvent view:</p>
<pre xml:space="preserve"><code>SELECT
timestamp,
sqcnr,
(SELECT name FROM entity WHERE id = entityId) AS runnableName,
entityInstance,
(SELECT name FROM entity WHERE id = sourceEntityId) AS sourceEntityName,
sourceEntityInstance,
(SELECT name FROM eventType WHERE id = eventTypeId) AS eventType
FROM (
SELECT timestamp, sqcnr, entityId, entityInstance, sourceEntityId, sourceEntityInstance, eventTypeId
FROM traceEvent WHERE
eventTypeId IN (SELECT id FROM eventType WHERE name IN ('start', 'resume', 'terminate', 'suspend')) AND
entityId IN (SELECT id FROM entity WHERE entityTypeId IN
(SELECT id FROM entityType WHERE name IN ('R'))
)
GROUP BY entityId, entityInstance, timestamp, sqcnr
)
</code></pre>
<h5><a id="section4.9.2.4.3"></a>vProcessInstanceRuntimeTraceEvent</h5>
<p>This provides a filtered view on TraceEvent where the subject entity is a process (Task or ISR).</p>
<ul>
<li>Columns
<ul>
<li>timestamp: integer – from TraceEvent</li>
<li>sqcnr: integer – from TraceEvent</li>
<li>processName: text – name of the process entity</li>
<li>entityInstance: integer – from TraceEvent</li>
<li>sourceEntityName: text – name of the source entity that is responsible for the process trace event</li>
<li>sourceEntityInstance: integer – from TraceEvent</li>
<li>eventType: text – name of the type of the process trace event</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the process instance TraceEvent view:</p>
<pre xml:space="preserve"><code>SELECT
timestamp,
sqcnr,
(SELECT name FROM entity WHERE id = entityId) AS processName,
entityInstance,
(SELECT name FROM entity WHERE id = sourceEntityId) AS sourceEntityName,
sourceEntityInstance,
(SELECT name FROM eventType WHERE id = eventTypeId) AS eventType
FROM (
SELECT timestamp, sqcnr, entityId, entityInstance, sourceEntityId, sourceEntityInstance, eventTypeId
FROM traceEvent WHERE
eventTypeId IN (SELECT id FROM eventType WHERE name IN ('activate', 'start', 'resume', 'run', 'terminate',
'preempt', 'poll', 'wait', 'poll_parking', 'park', 'release_parking', 'release', 'boundedmigration',
'fullmigration', 'mtalimitexceeded')) AND
entityId IN (SELECT id FROM entity WHERE entityTypeId IN
(SELECT id FROM entityType WHERE name IN ('T', 'I'))
)
GROUP BY entityId, entityInstance, timestamp, sqcnr
)
</code></pre>
<h5><a id="section4.9.2.4.4"></a>vRunnableInstanceTraceInfo/vProcessInstanceTraceInfo</h5>
<p>These two views directly represent the instance trace info tables, except that the entityId is resolved to the name of the entity.</p>
<h5><a id="section4.9.2.4.5"></a>vEventChainInstanceInfo</h5>
<p>This view maps event chain, stimulus event, and response event entities to their corresponding names, which makes the EventChainInstanceInfo table more comprehensible.</p>
<ul>
<li>Columns
<ul>
<li>eventChainName: text – name of the event chain entity</li>
<li>ecInstance: integer – entityInstance from eventChainInstanceInfo</li>
<li>stimulusTimestamp: integer – timestamp of the stimulus event for this event chain instance</li>
<li>stimulusEntityName: text – name of the entity that is subject to the stimulus event</li>
<li>stimulusEntityInstance: integer – instance of the stimulus entity</li>
<li>stimulusEvent: text – name of the type of the stimulus event</li>
<li>responseTimestamp: integer – timestamp of the response event for this event chain instance</li>
<li>responseEntityName: text – name of the entity that is subject to the response event</li>
<li>responseEntityInstance: integer – instance of the response entity</li>
<li>responseEvent: text – name of the type of the response event</li>
<li>latencyType: text – either 'age', 'reaction', or 'age/reaction'</li>
</ul>
</li>
</ul>
<p>The corresponding SQL query to generate the EventChainInstanceInfo view:</p>
<pre xml:space="preserve"><code>SELECT
(SELECT name FROM entity WHERE id = entityId) AS eventChainName,
entityInstance AS ecInstance,
stimulusTimestamp,
(SELECT name FROM entity WHERE id = (SELECT entityId FROM traceEvent WHERE timestamp = stimulusTimestamp AND
sqcnr = stimulusSqcnr)) AS stimulusEntityName,
(SELECT entityInstance FROM traceEvent WHERE timestamp = stimulusTimestamp AND sqcnr = stimulusSqcnr) AS stimulusEntityInstance,
(SELECT name FROM eventType WHERE id = (SELECT eventTypeId FROM traceEvent WHERE timestamp = stimulusTimestamp AND
sqcnr = stimulusSqcnr)) AS stimulusEvent,
responseTimestamp,
(SELECT name FROM entity WHERE id = (SELECT entityId FROM traceEvent WHERE timestamp = responseTimestamp AND
sqcnr = responseSqcnr)) AS responseEntityName,
(SELECT entityInstance FROM traceEvent WHERE timestamp = responseTimestamp AND
sqcnr = responseSqcnr) AS responseEntityInstance,
(SELECT name FROM eventType WHERE id = (SELECT eventTypeId FROM traceEvent WHERE timestamp = responseTimestamp AND
sqcnr = responseSqcnr)) AS responseEvent,
(CASE WHEN isAge AND isReaction THEN 'age/reaction' WHEN isAge THEN 'age' WHEN isReaction THEN 'reaction' END) AS latencyType
FROM eventChainInstanceInfo
</code></pre>
<h2><a id="section4.10">4.10 </a>AMALTHEA Trace Database (current version)</h2>
<p>The AMALTHEA Trace Database stores traces in a way that – especially for graphical user interfaces – information can be extracted efficiently.</p>
<h3><a id="section4.10.1">4.10.1 </a>General information</h3>
<p>The Database is stored as
<a href="http://www.sqlite.org/">SQLite Database</a> with extension
<strong>.atdb</strong>.
<br>All numbers are stored as integer values.
</p>
<h3><a id="section4.10.2">4.10.2 </a>Database structure</h3>
<p>The Database contains a mixture of statically and dynamically defined tables, which are described in more detail below:</p>
<ul>
<li>Static
<ul>
<li>MetaInformation</li>
<li>Entity</li>
<li>EntityInstance</li>
<li>EntitySource </li>
<li>EntityType</li>
<li>EventType</li>
</ul>
</li>
<li>Dynamic
<ul>
<li>EventTable</li>
</ul>
</li>
</ul>
<p>
<img src="images/atdb_erm_model.png"/>
</p>
<h4><a id="section4.10.2.1"></a>MetaInformation</h4>
<p>MetaInformation contains a simple key-value list of information about the Trace:</p>
<ul>
<li>Fields
<ul>
<li>Name: Text – Primary Key</li>
<li>Value: Text</li>
</ul>
</li>
</ul>
<p>By now, the following list of keys is defined:</p>
<ul>
<li>
<strong>db_version</strong>: version of the AMALTHEA Trace Database scheme with syntax "v#.#.#". Current version is "v0.2.0"
</li>
<li>
<strong>events_written</strong>: The amount of events stored in the database
</li>
<li>
<strong>input</strong>: path to the file, from which the information was produced
</li>
<li>
<strong>time_base</strong>: The base time in which time-values are stored
</li>
</ul>
<h4><a id="section4.10.2.2"></a>Entity</h4>
<p>Entity contains information about the Entities used in the database.</p>
<ul>
<li>Fields
<ul>
<li>Id: Number – Primary Key</li>
<li>Name: Text -
<strong>Case-Sensitive</strong> Unique
</li>
<li>EntityType: Number – 1:n Reference to EntityType-Table</li>
<li>HasEvents: Number – possible values
<ul>
<li>1: Events for that Entity were produced</li>
<li>
<em>null</em>: No Events for that Entity were produced
</li>
</ul>
</li>
<li>EventTableName: Text – The name of the table in which, the events for that entity are stored</li>
</ul>
</li>
</ul>
<h4><a id="section4.10.2.3"></a>EntityType</h4>
<p>EntityType contains information about the EntityTypes used in the database.</p>
<ul>
<li>Fields
<ul>
<li>Id: Number – Primary Key</li>
<li>Name: Text</li>
</ul>
</li>
</ul>
<p>By now, the following EntityTypes are defined:</p>
<ul>
<li>Core</li>
<li>EventChain</li>
<li>Interrupt</li>
<li>InstructionBlock</li>
<li>Process</li>
<li>Runnable</li>
<li>Scheduler</li>
<li>SemaphoreAccess</li>
<li>Semaphore</li>
<li>Signal</li>
<li>Stimulus</li>
<li>Task</li>
</ul>
<h4><a id="section4.10.2.4"></a>EventType</h4>
<ul>
<li>Fields
<ul>
<li>Id: Number – Primary Key</li>
<li>Name: Text</li>
</ul>
</li>
</ul>
<p>The list of EventTypes which may occur can be retrieved from "AMALTHEA_BTF_Specification".</p>
<h4><a id="section4.10.2.5"></a>EntitySource</h4>
<p>EntitySource contains information about which Entity has events caused by which other Entities.</p>
<ul>
<li>Fields
<ul>
<li>EntityId: Number – Primary Key; EntityId references the Entity events occurred for</li>
<li>SourceEntityId: Number – Primary Key; SourceId references the Entity, which caused the event</li>
</ul>
</li>
</ul>
<h4><a id="section4.10.2.6"></a>EntityInstance</h4>
<p>EntityInstance contains information about the time span an instance of an entity was active.</p>
<ul>
<li>Fields
<ul>
<li>Id: Number – Primary Key</li>
<li>EntityId: Number – Reference to an entity</li>
<li>EntityInstanceId: Number – Instance number for that entity</li>
<li>TimeFrom: Number – Start-Time of the instance</li>
<li>TimeTo: Number – End-Time of the instance</li>
</ul>
</li>
</ul>
<h4><a id="section4.10.2.7"></a>EventTables</h4>
<p>There is a dynamic amount of EventTables. An EventTable contains events of 1 or more entities. The information which entity is part of which EventTable is stored in Entity-Table.</p>
<ul>
<li>Fields
<ul>
<li>Id: Number – Primary Key, ascending id-number for each EventTable</li>
<li>TimeStamp: Number – Time at which the event occurred in base_unit defined at MetaInformation</li>
<li>Remainder: Number – Time modulo 1000 to get a more precise value in cases it is required</li>
<li>SQCNR: Number – A strictly ascending sequential number telling the order of event at same time stamp</li>
<li>EntityId: Number – Reference to entity, for which the event occurred</li>
<li>EntityInstanceId: Number – Instance of the entity</li>
<li>SourceEntityId: Number – Reference to entity, which caused the event </li>
<li>SourceEntityInstanceId: Number – Instance of the source entity</li>
<li>EventTypeId: Number – Reference to EventType</li>
<li>Value: String – Additional unstructured data for an event like e.g. the written value in case of a Signal Write event</li>
</ul>
</li>
</ul>
</article>
<article>
<h1><a id="section5">5 </a>Release Notes</h1>
<h2><a id="section5.1">5.1 </a>Eclipse APP4MC 0.9.9 (Jul 2020)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.8 -&gt; 0.9.9)</li>
</ul>
<p>Model changes</p>
<ul>
<li>Data types: Struct and StructEntry are taggable</li>
<li>MeasurementModel is deprecated</li>
</ul>
<p>Product</p>
<ul>
<li>Trace data and metrics: Extended definition of Amalthea Trace Database (Preview)</li>
<li>Validations: New INCHRON validations, extended documentation</li>
</ul>
<p>UI</p>
<ul>
<li>Model Explorer no longer expands model files</li>
<li>Migration dialog supports recursive operation on folders</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.9/bugs">Release 0.9.9 issues</a>
</em>
</p>
<h2><a id="section5.2">5.2 </a>Eclipse APP4MC 0.9.8 (Apr 2020)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.7 -&gt; 0.9.8)</li>
</ul>
<p>Product</p>
<ul>
<li>Eclipse target platform is updated to IDE 2019-12</li>
<li>New (extendable) visualization framework</li>
<li>Standard visualizations for runnables and deviations</li>
<li>Additional example models</li>
<li>EMF model viewers are available as update site</li>
<li>...</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.8/bugs">Release 0.9.8 issues</a>
</em>
</p>
<h2><a id="section5.3">5.3 </a>Eclipse APP4MC 0.9.7 (Jan 2020)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.6 -&gt; 0.9.7)</li>
<li>Added virtual folders in component model tree view</li>
</ul>
<p>Model changes</p>
<ul>
<li>Introduced namespaces and component structures</li>
<li>New model element to describe hierarchical interfaces</li>
<li>Model cleanup (simplified component ports)</li>
</ul>
<p>Product</p>
<ul>
<li>Restructured migration component (also available as headless jar)</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.7/bugs">Release 0.9.7 issues</a>
</em>
</p>
<h2><a id="section5.4">5.4 </a>Eclipse APP4MC 0.9.6 (Oct 2019)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.5 -&gt; 0.9.6)</li>
<li>New "no-load" nature (avoids model loading while moving/copying model files)</li>
<li>Multi-line strings are supported in the editor (for selected string attributes)</li>
</ul>
<p>Model changes</p>
<ul>
<li>Extended ModeConditions (allow the comparison of two mode labels)</li>
<li>Refined EventChain definition (to explicitly describe fork-join, alternative, etc.)</li>
<li>Counter added to RunnableCall</li>
</ul>
<p>Build infrastructure</p>
<ul>
<li>Split git repository and independent build job for model migration component</li>
<li>Changed to tycho-pomless maven builds</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.6/bugs">Release 0.9.6 issues</a>
</em>
</p>
<h2><a id="section5.5">5.5 </a>Eclipse APP4MC 0.9.5 (Jul 2019)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.4 -&gt; 0.9.5)</li>
<li>New validation framework</li>
</ul>
<p>Model changes</p>
<ul>
<li>Consolidated call graph: items of tasks and runnables are unified, call sequences are removed</li>
<li>Simplified clock definitions (used in scenarios of variable rate stimuli)</li>
<li>Limited frequency values to non negative (value &gt;= 0)</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.5/bugs">Release 0.9.5 issues</a>
</em>
</p>
<h2><a id="section5.6">5.6 </a>Eclipse APP4MC 0.9.4 (Apr 2019)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.3 -&gt; 0.9.4)</li>
<li>Optimized model search</li>
<li>New validation framework (preview)</li>
</ul>
<p>Model changes</p>
<ul>
<li>Extended modes to allow the handling of counters (integer values, comparison, increment, decrement)</li>
<li>Uniform use of execution conditions (for stimuli, runnables, mode switches)</li>
<li>Model cleanup (removed runnable deadlines, distinct naming)</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.4/bugs">Release 0.9.4 issues</a>
</em>
</p>
<h2><a id="section5.7">5.7 </a>Eclipse APP4MC 0.9.3 (Jan 2019)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.2 -&gt; 0.9.3)</li>
<li>Optimized model search</li>
</ul>
<p>Model changes</p>
<ul>
<li>Introduced "Ticks" as base concept for required computation effort</li>
<li>Simplified "Execution Needs" (no specific entries for different processing units)</li>
<li>Reworked distributions (discrete, continuous, time) without generics</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.3/bugs">Release 0.9.3 issues</a>
</em>
</p>
<h2><a id="section5.8">5.8 </a>Eclipse APP4MC 0.9.2 (Oct 2018)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.1 -&gt; 0.9.2)</li>
<li>New model search dialog</li>
<li>New model builders (with a Groovy-like builder pattern)</li>
</ul>
<p>Model changes</p>
<ul>
<li>Small extensions in the hardware model</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.9.2/bugs">Release 0.9.2 issues</a>
</em>
</p>
<h2><a id="section5.9">5.9 </a>Eclipse APP4MC 0.9.1 (Jul 2018)</h2>
<p>General</p>
<ul>
<li>New Eclipse Oxygen.3a based product (compatible with Java 8, Java 9 and Java 10)</li>
<li>License change from EPL-1.0 to EPL-2.0</li>
</ul>
<p>Model handling</p>
<ul>
<li>Model migration support (0.9.0 -&gt; 0.9.1)</li>
<li>New implementation of transient back references</li>
<li>Unified approach for fast name search and mass delete</li>
<li>Updated model utilities</li>
</ul>
<p>Model changes</p>
<ul>
<li>New concept of DataDependency (to describe potential data dependencies)</li>
<li>New possibility to specify RunnableParameters and CallArguments</li>
</ul>
<h2><a id="section5.10">5.10 </a>Eclipse APP4MC 0.9.0 (Apr 2018)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.8.3 -&gt; 0.9.0)</li>
<li>Updated model utilities</li>
</ul>
<p>Model changes</p>
<ul>
<li>
<strong>New hardware model</strong>
</li>
<li>New concept of ExecutionNeed (replaces the former RunnableInstructions)</li>
</ul>
<i>Note: This is the first implementation of the new hardware model. It will be extended in the next version and (minor) changes are expected</i>.
<h2><a id="section5.11">5.11 </a>Eclipse APP4MC 0.8.3 (Jan 2018)</h2>
<p>General</p>
<ul>
<li>New Eclipse Neon.3 based product</li>
</ul>
<p>Model handling</p>
<ul>
<li>Model migration support (0.8.2 -&gt; 0.8.3)</li>
<li>Updated model utilities</li>
</ul>
<p>Model changes</p>
<ul>
<li>New mode conditions (logical AND)</li>
<li>New timing requirement (end to start)</li>
<li>Reworked Stimuli definitions</li>
<li>New reference to port for client server and sender receiver communication</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.8.3/bugs">Release 0.8.3 issues</a>
</em>
</p>
<h2><a id="section5.12">5.12 </a>Eclipse APP4MC 0.8.2 (Oct 2017)</h2>
<p>General</p>
<ul>
<li>Model changes (extensions)</li>
<li>New graphical editors (based on Sirius)</li>
</ul>
<p>Model handling</p>
<ul>
<li>Model migration support (0.8.1 -&gt; 0.8.2)</li>
<li>New model utilities</li>
</ul>
<p>Model changes</p>
<ul>
<li>New runnable item to get the result of an asynchronous request</li>
<li>New possibility to specify the label access implementation</li>
<li>New measurement model</li>
<li>New component event</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.8.2/bugs">Release 0.8.2 issues</a>
</em>
</p>
<h2><a id="section5.13">5.13 </a>Eclipse APP4MC 0.8.1 (Jul 2017)</h2>
<p>General</p>
<ul>
<li>Model changes (extension and harmonization)</li>
<li>Improved model handling</li>
<li>New tooling: EMF Graphical Viewer</li>
</ul>
<p>Model handling</p>
<ul>
<li>Model migration support (0.8.0 -&gt; 0.8.1)</li>
<li>New support for compressed model files (zip)</li>
<li>More back references</li>
</ul>
<p>Model changes</p>
<ul>
<li>Extended Schedulers (hierarchical, reservation based)</li>
<li>Extend Semaphore definition (types)</li>
<li>Consistent naming of Triggers, Activations and Stimuli</li>
<li>New elements for data driven computation (conditions, triggers)</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.8.1/bugs">Release 0.8.1 issues</a>
</em>
</p>
<h2><a id="section5.14">5.14 </a>Eclipse APP4MC 0.8.0 (Apr 2017)</h2>
<p>General</p>
<ul>
<li>Model changes (mainly to simplify handling)</li>
<li>Improved tooling: model utilities</li>
<li>New UI components: Multicore Wizard, Task-Visualizer (draft version)</li>
</ul>
<p>Model handling</p>
<ul>
<li>Model migration support (0.7.2 -&gt; 0.8.0)</li>
</ul>
<p>Model changes</p>
<ul>
<li>Simplified model handling: Mapping Model, Modes, Time</li>
<li>New classifiers to annotate Core and Memory</li>
<li>Reworked Property Constraints</li>
<li>Extended OS Overheads</li>
</ul>
<p>
<em>For details see
<a href="https://projects.eclipse.org/projects/technology.app4mc/releases/0.8.0/bugs">Release 0.8.0 issues</a>
</em>
</p>
<h2><a id="section5.15">5.15 </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 -&gt; 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 -&gt; Mapping, Scheduler -&gt; 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">Release 0.7.2 issues</a>
</em>
</p>
<h2><a id="section5.16">5.16 </a>Eclipse APP4MC 0.7.1 (Oct 2016)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (0.7.0 -&gt; 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&amp;target_milestone=0.7.1">Bugzilla entries for 0.7.1</a>
</em>
</p>
<h2><a id="section5.17">5.17 </a>Eclipse APP4MC 0.7.0 (Jul 2016)</h2>
<p>Model handling</p>
<ul>
<li>Model migration support (itea1.1.0 -&gt; itea1.1.1 -&gt; 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>
</article>
<article>
<h1><a id="section6">6 </a>Roadmap</h1>
<p>Current topics:</p>
<ul>
<li>Model changes (e.g. for heterogeneous hardware)</li>
<li>Model validation</li>
<li>Model utilities</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">Eclipse APP4MC</a>.
</p>
</article>
<!-- - - - - - - - - - - Articles - - - - - - - - - - -->
</div>
</div>
</body>
</html>