Skip to content
GitLab
Commit 9d5ad6d7 authored by Simon Barner's avatar Simon Barner
Browse files

Document task architecture 

Issue-Ref: 3834
Issue-Url: https://af3-developer.fortiss.org/issues/3834

Signed-off-by: Simon Barner's avatarSimon Barner <barner@fortiss.org>
parent 67acc479
Hide whitespace changes
Inline Side-by-side
org.fortiss.af3.rcp.help/html/ta/.ratings
View file @ 9d5ad6d7
allocations.html 91f2636b00d59253f7007864d4e0ebdd0b713dad RED
beagle_java_deployment.html 8ba70c9b06c3313f3d732bcdb43e8cc15fe193a1 RED
code_generation.html 8d3b9847eed8693bbc0c23a0dc5f8be2f118714b RED
manual_deployment.html 91f2636b00d59253f7007864d4e0ebdd0b713dad RED
platform_architecture.html 89df3aa2fa49faad25aaa52264d89393ce6bd18f RED
platform_architecture_generic.html cb91689226e3ed5168b11ba2d008601dc2661637 RED
platform_architecture_hierarchical.html 3c410b1c8ee284b2080d03eb5d022cdee531257a RED
task_architecture.html fbce88173c788b20b1a7d97195f935f685c1d7e6 RED
technical_viewpoint.html c528f8f14632305a2977029fff75f8c364d6ab5a RED
org.fortiss.af3.rcp.help/html/ta/task_architecture.html 0 → 100644
View file @ 9d5ad6d7
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Defining a Task Architecture</title>
</head>
<body>
<h2><u><font color="#336699">Defining a Task Architecture</font></u></h2>
<p>
In AutoFOCUS3, a <a href="../component_architecture.html"><i>Component Architecture</i></a> is
used to define a system's logical architecture and its behavior in an implementation independent way
in the logical viewpoint. The <i>Task Architecture</i> is part of the technical viewpoint and
allows to specify the entities to which the components of a logical architecture are
mapped during the deployment to an execution platform.
</p>
<p>To create an empty <i>Task Architecture</i>, at least one <i>Component Architecture</i> must
exist in the project. Then, open the context menu of the project and select <i>Task Architecture</i>.</p>
<img src="./pictures/Task.Architecture.Add.png">
<p>
To model the constituent <i>Task</i>s of a task architecture, drag them from the <i>Model Elements</i>
library to the task architecture. The interface of tasks is defined using either of the following ports:
</p>
<ul>
<li><i>TaskQueuingInputPort</i>: Task input port with queuing semantics. The maximum number of messages can be defined in the <a href="../model_element_attributes.html"><i>Annotations</i> view</a>.</li>
<li><i>TaskQueuingInputPort</i>: Task output port with queuing semantics. The maximum number of messages can be defined in the <a href="../model_element_attributes.html"><i>Annotations</i> view</a>.</li></li>
<li><i>TaskSamplingInputPort</i>: Task input port with sampling semantics. The sampling rate is specified by setting the port's period in a <i>Timing Specification</i>.</li>
<li><i>TaskSamplingOutputPort</i>: Task output port with sampling semantics. The sampling rate is specified by setting the port's period in a <i>Timing Specification</i>.</li>
</ul>
In order to model the data flow between tasks, task ports can be connected using <i>Signals</i> by
means of a left-drag while the ALT key is pressed. The following constraints apply:
<ul>
<li>Directed communication from task output ports to task input ports.</i>
<li>Only ports with the same semantics (sampling, queuing) can be connected.</i>
<li>Every task input port may be connected to at most one incoming signal.</i>
</ul>
<p>In order to define a mapping of one or more logical <i>Components</i> to a <i>Task</i> (n:1),
a <i>Components-to-Tasks</i> <a href="allocations.html">allocation</a> must be added. It also
allows to define the mapping of logical ports to task ports.</p>
<img src="./pictures/Allocations.Ta2Ca.Add.png">
<p>
AutoFOCUS3 provides an automatic transformation from a <i>Component Architecture</i> to a
<i>Task Architecture</i> that associates every <i>Component</i> to exactly one <i>Task</i>.
The transformation also generates the corresponding 1:1 <i>Components-to-Tasks</i> allocation.
</p>
<img src="./pictures/Task.Architecture.Generate.png">
<p>In order to define the platform-specific attributes of tasks, a <a href="platform_architecture.html">
hardware platform architecture</a> and a corresponding <i>Task-to-Hardware</i> <a href="allocations.html">allocation</a>
must be present that (it may be empty). First, the <i>Task-to-Hardware</i> has to be selected</p>
and the task architecture editor has to be restarted.</p>
<img src="./pictures/Task.Architecture.Attributes.png">
<p>Then, the following attributes can be defined in the corresponding tabs of the editor.</p>
<ul>
<li><i>Task Timing</i>: It is not only possible to define a generic platform-independent
WCET (worst-case execution), but also a specific WCET for each potential target execution unit to which a task can be allocated.</li>
<li><i>Task Memory Mapping</i>: Definition of tasks RAM and flash requirements (both generic and for each RAM/ROM resource
contained in the referenced architecture.</li>
<li><i>Task Message Buffer Mapping</i>: Definition of buffer sizes for task output ports. It is possible
(but not mandatory) to define to which RAM resource a particular buffer is mapped.</li>
</ul>
</body>
</html>
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment