Google Git
Sign in
eclipse / app4mc / org.eclipse.app4mc.web / c22fe9c3362bf1f5cc0eaab556a28e05c6c6a995 / . / websites / www.eclipse.org-app4mc-hugo / site / static / help / latest / index.html
blob: 42bafbef7b3eed8b34dcb5c1666329927d83352e [file] [log] [blame]
<!DOCTYPE html>
<!--
! Copyright (c) 2017-2022 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 2.2.0 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">Handling of multiple files (folder scope)</a></label></li>
<li><label class="leaf"><a href="#section2.1.4">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 with Scheduling Parameters</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 with Scheduling Parameters</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">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>
<li><input type="checkbox" id="toc2.3.13" /><label for="toc2.3.13"><a href="#section2.3.13">BTF Example (MultipleTaskActivationLimit 3)</a></label>
<ul>
<li><label class="leaf"><a href="#section2.3.13.1">State after timestamp 0</a></label></li>
<li><label class="leaf"><a href="#section2.3.13.2">State after timestamp 100</a></label></li>
<li><label class="leaf"><a href="#section2.3.13.3">State after timestamp 20000</a></label></li>
<li><label class="leaf"><a href="#section2.3.13.4">State after timestamp 40000</a></label></li>
<li><label class="leaf"><a href="#section2.3.13.5">State after timestamp 42000</a></label></li>
<li><label class="leaf"><a href="#section2.3.13.6">State after timestamp 42100</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">BTF -> AMALTHEA Trace Database (ATDB) Import Example</a></label></li>
<li><label class="leaf"><a href="#section2.4.2">AMALTHEA Specification Parts to ATDB Import Example</a></label></li>
<li><label class="leaf"><a href="#section2.4.3">ATDB to AMALTHEA Model Transformation</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>
</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>
<li><label class="leaf"><a href="#section2.6.2.5">Mapping</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">APP4MC.sim Validations</a></label></li>
<li><label class="leaf"><a href="#section2.7.2.3">Timing Architects Validations</a></label></li>
<li><label class="leaf"><a href="#section2.7.2.4">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>
</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>
<li><label class="leaf"><a href="#section3.2.10">Conditions</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><input type="checkbox" id="toc3.7" /><label for="toc3.7"><a href="#section3.7">Event Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.7.1">Entity Events</a></label></li>
<li><label class="leaf"><a href="#section3.7.2">Trigger Events</a></label></li>
<li><label class="leaf"><a href="#section3.7.3">Process Events</a></label></li>
<li><label class="leaf"><a href="#section3.7.4">Details</a></label></li>
</ul>
</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><input type="checkbox" id="toc3.10" /><label for="toc3.10"><a href="#section3.10">OS Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.10.1">Operating System</a></label></li>
<li><input type="checkbox" id="toc3.10.2" /><label for="toc3.10.2"><a href="#section3.10.2">Scheduler, Scheduler Definitions, and their Parameters</a></label>
<ul>
<li><label class="leaf"><a href="#section3.10.2.1">Scheduler Definition</a></label></li>
<li><label class="leaf"><a href="#section3.10.2.2">Scheduling Parameter Definition and Scheduling Parameter</a></label></li>
<li><input type="checkbox" id="toc3.10.2.3" /><label for="toc3.10.2.3"><a href="#section3.10.2.3">Standard Scheduler Definitions</a></label>
<ul>
<li><label class="leaf"><a href="#section3.10.2.3.1">Further information</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.10.2.4">Scheduler Association</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.10.3" /><label for="toc3.10.3"><a href="#section3.10.3">Os Overhead</a></label>
<ul>
<li><label class="leaf"><a href="#section3.10.3.1">ISR Overhead</a></label></li>
<li><label class="leaf"><a href="#section3.10.3.2">API Overhead</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.10.4">OS Data Consistency</a></label></li>
<li><label class="leaf"><a href="#section3.10.5">Semaphore</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.11" /><label for="toc3.11"><a href="#section3.11">PropertyConstraints Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.11.1">Structure</a></label></li>
<li><input type="checkbox" id="toc3.11.2" /><label for="toc3.11.2"><a href="#section3.11.2">CoreAllocationConstraint</a></label>
<ul>
<li><label class="leaf"><a href="#section3.11.2.1">RunnableAllocationConstraint</a></label></li>
<li><label class="leaf"><a href="#section3.11.2.2">ProcessAllocationConstraint</a></label></li>
<li><label class="leaf"><a href="#section3.11.2.3">ProcessPrototypeAllocationConstraint</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.11.3" /><label for="toc3.11.3"><a href="#section3.11.3">MemoryMappingConstraint</a></label>
<ul>
<li><label class="leaf"><a href="#section3.11.3.1">AbstractElementMappingConstraint</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.11.4">Classifications</a></label></li>
<li><label class="leaf"><a href="#section3.11.5">Example</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.12" /><label for="toc3.12"><a href="#section3.12">Stimuli Model</a></label>
<ul>
<li><input type="checkbox" id="toc3.12.1" /><label for="toc3.12.1"><a href="#section3.12.1">Stimuli</a></label>
<ul>
<li><label class="leaf"><a href="#section3.12.1.1">Single</a></label></li>
<li><label class="leaf"><a href="#section3.12.1.2">Arrival Curves</a></label></li>
<li><label class="leaf"><a href="#section3.12.1.3">Common properties of fixed periodic stimuli</a></label></li>
<li><label class="leaf"><a href="#section3.12.1.4">Periodic </a></label></li>
<li><label class="leaf"><a href="#section3.12.1.5">PeriodicSynthetic</a></label></li>
<li><label class="leaf"><a href="#section3.12.1.6">PeriodicBurst</a></label></li>
<li><label class="leaf"><a href="#section3.12.1.7">RelativePeriodic </a></label></li>
<li><label class="leaf"><a href="#section3.12.1.8">VariableRateStimulus</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.12.2" /><label for="toc3.12.2"><a href="#section3.12.2">Clocks</a></label>
<ul>
<li><label class="leaf"><a href="#section3.12.2.1">ClockFunction</a></label></li>
<li><label class="leaf"><a href="#section3.12.2.2">ClockStepList</a></label></li>
<li><label class="leaf"><a href="#section3.12.2.3">Example</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.12.3">Mode Value List and Execution Condition</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.13" /><label for="toc3.13"><a href="#section3.13">Software Model</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.1">Memory Information</a></label></li>
<li><label class="leaf"><a href="#section3.13.2">Labels</a></label></li>
<li><label class="leaf"><a href="#section3.13.3">Channels</a></label></li>
<li><input type="checkbox" id="toc3.13.4" /><label for="toc3.13.4"><a href="#section3.13.4">Data Types</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.4.1">General Information</a></label></li>
<li><label class="leaf"><a href="#section3.13.4.2">Sample</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.13.5">Activations</a></label></li>
<li><label class="leaf"><a href="#section3.13.6">Tasks / ISR</a></label></li>
<li><label class="leaf"><a href="#section3.13.7">Runnables and Services</a></label></li>
<li><label class="leaf"><a href="#section3.13.8">Runnables</a></label></li>
<li><label class="leaf"><a href="#section3.13.9">Activity Graph</a></label></li>
<li><input type="checkbox" id="toc3.13.10" /><label for="toc3.13.10"><a href="#section3.13.10">Activity Graph Items</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.10.1">Groups</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.2">While Loop</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.3">Switch</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.4">Probability Switch</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.5">Ticks</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.6">Execution Need</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.7">Calls and AUTOSAR communication</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.8">Label Access</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.9">Channel Access</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.10">Semaphore Access</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.11">Mode Label Access</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.12">Custom Event Trigger</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.13">Enforced Migration</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.14">Inter Process Trigger</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.15">Schedule Point</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.16">Terminate Process</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.17">Wait/Clear/Set Event</a></label></li>
<li><label class="leaf"><a href="#section3.13.10.18">Statistical Values</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.13.11">Modes</a></label></li>
<li><input type="checkbox" id="toc3.13.12" /><label for="toc3.13.12"><a href="#section3.13.12">Mode Labels</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.12.1">Mode Changes</a></label></li>
<li><label class="leaf"><a href="#section3.13.12.2">Mode Conditions</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc3.13.13" /><label for="toc3.13.13"><a href="#section3.13.13">Local Mode Labels</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.13.1">Local Mode Label Assignment</a></label></li>
<li><label class="leaf"><a href="#section3.13.13.2">Local Mode Conditions</a></label></li>
<li><label class="leaf"><a href="#section3.13.13.3">Local mode label examples</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section3.13.14">Process Prototypes</a></label></li>
<li><label class="leaf"><a href="#section3.13.15">Process Chains</a></label></li>
<li><label class="leaf"><a href="#section3.13.16">Custom Entities</a></label></li>
<li><label class="leaf"><a href="#section3.13.17">Section</a></label></li>
<li><input type="checkbox" id="toc3.13.18" /><label for="toc3.13.18"><a href="#section3.13.18">Data Dependencies and Runnable Parameters</a></label>
<ul>
<li><label class="leaf"><a href="#section3.13.18.1">Overview</a></label></li>
<li><label class="leaf"><a href="#section3.13.18.2">Elements with data dependency</a></label></li>
<li><label class="leaf"><a href="#section3.13.18.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 2.0.0 to APP4MC 2.1.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.2">Version APP4MC 1.2.0 to APP4MC 2.0.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.3">Version APP4MC 1.1.0 to APP4MC 1.2.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.4">Version APP4MC 1.0.0 to APP4MC 1.1.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.5">Version APP4MC 0.9.9 to APP4MC 1.0.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.6">Version APP4MC 0.9.8 to APP4MC 0.9.9</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.7">Version APP4MC 0.9.7 to APP4MC 0.9.8</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.8">Version APP4MC 0.9.6 to APP4MC 0.9.7</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.9">Version APP4MC 0.9.5 to APP4MC 0.9.6</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.10">Version APP4MC 0.9.4 to APP4MC 0.9.5</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.11">Version APP4MC 0.9.3 to APP4MC 0.9.4</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.12">Version APP4MC 0.9.2 to APP4MC 0.9.3</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.13">Version APP4MC 0.9.1 to APP4MC 0.9.2</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.14">Version APP4MC 0.9.0 to APP4MC 0.9.1</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.15">Version APP4MC 0.8.3 to APP4MC 0.9.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.16">Version APP4MC 0.8.2 to APP4MC 0.8.3</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.17">Version APP4MC 0.8.1 to APP4MC 0.8.2</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.18">Version APP4MC 0.8.0 to APP4MC 0.8.1</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.19">Version APP4MC 0.7.2 to APP4MC 0.8.0</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.20">Version APP4MC 0.7.1 to APP4MC 0.7.2</a></label></li>
<li><label class="leaf"><a href="#section4.5.4.21">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</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>
</ul>
</li>
<li><input type="checkbox" id="toc5" /><label for="toc5"><a href="#section5">Platform Extensions</a></label>
<ul>
<li><input type="checkbox" id="toc5.1" /><label for="toc5.1"><a href="#section5.1">Overview</a></label>
<ul>
<li><label class="leaf"><a href="#section5.1.1">Available Extensions</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc5.2" /><label for="toc5.2"><a href="#section5.2">EMF Model Viewers</a></label>
<ul>
<li><label class="leaf"><a href="#section5.2.1">Meta Model Explorer</a></label></li>
<li><label class="leaf"><a href="#section5.2.2">Graphical Viewer</a></label></li>
<li><label class="leaf"><a href="#section5.2.3">Installation via P2 update site</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc5.3" /><label for="toc5.3"><a href="#section5.3">Additional Examples</a></label>
<ul>
<li><label class="leaf"><a href="#section5.3.1">IDE Extensions</a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc5.4" /><label for="toc5.4"><a href="#section5.4">Model Transformation</a></label>
<ul>
<li><label class="leaf"><a href="#section5.4.1">Transformation Framework</a></label></li>
<li><label class="leaf"><a href="#section5.4.2">Generation of synthetic loads</a></label></li>
<li><label class="leaf"><a href="#section5.4.3">Generation of SystemC code for simulation</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section5.5">SystemC Timing Simulation </a></label></li>
</ul>
</li>
<li><input type="checkbox" id="toc6" /><label for="toc6"><a href="#section6">Release Notes</a></label>
<ul>
<li><label class="leaf"><a href="#section6.1">Eclipse APP4MC 2.2.0 (Jul 2022)</a></label></li>
<li><label class="leaf"><a href="#section6.2">Eclipse APP4MC 2.1.0 (Apr 2022)</a></label></li>
<li><label class="leaf"><a href="#section6.3">Eclipse APP4MC 2.0.0 (Nov 2021)</a></label></li>
<li><label class="leaf"><a href="#section6.4">Eclipse APP4MC 1.2.0 (Jul 2021)</a></label></li>
<li><label class="leaf"><a href="#section6.5">Eclipse APP4MC 1.1.0 (Apr 2021)</a></label></li>
<li><label class="leaf"><a href="#section6.6">Eclipse APP4MC 1.0.0 (Nov 2020)</a></label></li>
<li><label class="leaf"><a href="#section6.7">Eclipse APP4MC 0.9.9 (Jul 2020)</a></label></li>
<li><label class="leaf"><a href="#section6.8">Eclipse APP4MC 0.9.8 (Apr 2020)</a></label></li>
<li><label class="leaf"><a href="#section6.9">Eclipse APP4MC 0.9.7 (Jan 2020)</a></label></li>
<li><label class="leaf"><a href="#section6.10">Eclipse APP4MC 0.9.6 (Oct 2019)</a></label></li>
<li><label class="leaf"><a href="#section6.11">Eclipse APP4MC 0.9.5 (Jul 2019)</a></label></li>
<li><label class="leaf"><a href="#section6.12">Eclipse APP4MC 0.9.4 (Apr 2019)</a></label></li>
<li><label class="leaf"><a href="#section6.13">Eclipse APP4MC 0.9.3 (Jan 2019)</a></label></li>
<li><label class="leaf"><a href="#section6.14">Eclipse APP4MC 0.9.2 (Oct 2018)</a></label></li>
<li><label class="leaf"><a href="#section6.15">Eclipse APP4MC 0.9.1 (Jul 2018)</a></label></li>
<li><label class="leaf"><a href="#section6.16">Eclipse APP4MC 0.9.0 (Apr 2018)</a></label></li>
<li><label class="leaf"><a href="#section6.17">Eclipse APP4MC 0.8.3 (Jan 2018)</a></label></li>
<li><label class="leaf"><a href="#section6.18">Eclipse APP4MC 0.8.2 (Oct 2017)</a></label></li>
<li><label class="leaf"><a href="#section6.19">Eclipse APP4MC 0.8.1 (Jul 2017)</a></label></li>
<li><label class="leaf"><a href="#section6.20">Eclipse APP4MC 0.8.0 (Apr 2017)</a></label></li>
<li><label class="leaf"><a href="#section6.21">Eclipse APP4MC 0.7.2 (Jan 2017)</a></label></li>
<li><label class="leaf"><a href="#section6.22">Eclipse APP4MC 0.7.1 (Oct 2016)</a></label></li>
<li><label class="leaf"><a href="#section6.23">Eclipse APP4MC 0.7.0 (Jul 2016)</a></label></li>
</ul>
</li>
<li><label class="leaf"><a href="#section7">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>Project 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 the entire model that contains 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>The AMALTHEA Editor has additional commands available in the editor toolbar.</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 search for 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 result are shown in the Eclipse search result view.</p>
<p>
<img class="gray" src="images/user_guide_editor_search_input.png"/>
</p>
<p>A double click on a result selects the element in the editor 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>Handling of multiple files (folder scope)</h3>
<p>Amalthea model</p>
<ul>
<li>Amalthea files have the extension ".amxmi".</li>
<li>Amalthea models support references to other model files in the same folder.</li>
</ul>
<p>When the
<strong>first</strong> Amalthea file in a folder is opened in the Amalthea editor
</p>
<ul>
<li>all valid model files are loaded</li>
<li>a common editing environment is established</li>
<li>files and folder are decorated with markers
<ul>
<li>loaded model files are decorated with a green dot</li>
<li>model files that contain older versions are extended with the version</li>
<li>the folder is marked as "is in use" and decorated with a construction barrier</li>
</ul>
</li>
</ul>
<p>
<img src="images/user_guide_folder_scope.png"/>
</p>
<p>When the
<strong>last</strong> Amalthea editor of a folder is closed
</p>
<ul>
<li>the common editing environment is released</li>
<li>markers are removed</li>
</ul>
<p>
<strong>Warning:</strong>
<br>Do not modify the contents of a folder while editors are open.
<br>If you want to add or remove model files then first close all editors.
</p>
<h3><a id="section2.1.4">2.1.4 </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 this specific task – scheduler combination. Therefore the parameters are specified in the TaskAllocation object.</p>
<p>
<img src="images/user-scheduling-task-allocation.svg"/>
</p>
<h4><a id="section2.2.6.3"></a>Scheduler hierarchies</h4>
<p>Schedulers can be arranged in a hierarchy via SchedulerAssociations. If set, the parent scheduler takes the initial decision and delegates to a child-scheduler. If the child-scheduler is a reservation based server, it can only delegate scheduling decisions to its child scheduler. If it is not a server, it can take scheduling decisions.
<br>The scheduling parameters for the parent scheduler are specified in the SchedulerAssociation, just as it would have for task allocations.
<br>If a reservation based server has only one child (this can either be a process or a child scheduler), the scheduling parameters specified in this single child allocation will also be passed to the parent scheduler. The example below shows this for the EDF scheduler on the right hand side.
</p>
<p>
<img src="images/user-scheduling-hierarchy.svg"/>
</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 scheduler definition used by the scheduler, in this case OSEK, a delay of 100 ticks is set, which represents the presumed time the scheduler needs for context switches.
</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">Constant</td>
<td colspan="1" rowspan="1">OSEK</td>
<td colspan="1" rowspan="1">100 ticks</td>
</tr>
<tr>
<td colspan="1" rowspan="1">
<strong>Scheduler_2</strong>
</td>
<td colspan="1" rowspan="1">Constant</td>
<td colspan="1" rowspan="1">OSEK</td>
<td colspan="1" rowspan="1">100 ticks</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. In case of Example 1, 'Task_1' and 'Task_2' are managed by 'Scheduler_1', while the other tasks are managed by 'Scheduler_2'. Scheduler specific parameters are set here, too. For the OSEK scheduler these are 'priority' and 'taskGroup'. Each task has a priority assigned according its deadline, meaning the one with the shortest deadline, 'Task_1', has the highest priority, and so on.
<br>On the other hand the allocation of cores to a scheduler is set. For Modeling Example 1 two local schedulers were modeled. 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 with Scheduling Parameters</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>
<th colspan="1" rowspan="1">priority</th>
<th colspan="1" rowspan="1">taskGroup</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_1</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">4</td>
<td colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_1</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">3</td>
<td colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_2</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">2</td>
<td colspan="1" rowspan="1">3</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_2</td>
<td colspan="1" rowspan="1">Task_4</td>
<td colspan="1" rowspan="1">1</td>
<td colspan="1" rowspan="1">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'. Each task is preemptive and 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">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">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">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">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">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 scheduler definition used by the scheduler, in this case OSEK, a delay of 100 ticks is set, which represents the presumed time the scheduler needs for context switches.
</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">Constant</td>
<td colspan="1" rowspan="1">OSEK</td>
<td colspan="1" rowspan="1">100 ticks</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. Since there is only one scheduler available in the system, all four tasks are mapped to 'Scheduler_1'. Scheduler specific parameters are set here, too. For the OSEK scheduler these are 'priority' and 'taskGroup'. All tasks have assigned the same priority (10) to get a cooperative scheduling.
<br>On the other hand the allocation of cores to a scheduler is set. 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 with Scheduling Parameters</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>
<th colspan="1" rowspan="1">priority</th>
<th colspan="1" rowspan="1">taskGroup</th>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_1</td>
<td colspan="1" rowspan="1">Task_1</td>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">1</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_1</td>
<td colspan="1" rowspan="1">Task_2</td>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">2</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_1</td>
<td colspan="1" rowspan="1">Task_3</td>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">3</td>
</tr>
<tr>
<td colspan="1" rowspan="1">Scheduler_1</td>
<td colspan="1" rowspan="1">Task_4</td>
<td colspan="1" rowspan="1">10</td>
<td colspan="1" rowspan="1">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'. 'Task_2' to'Task_4' call a definitive number of Runnables in a sequential order. 'Task_1' instead contains a call graph that models two different possible execution sequences. 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. 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">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">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">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">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">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>