
h2. Mapping Model

The mapping model is intended to provide tools that use hardware and software models (e.g. code generators) information about the corresponding mappings and allocations. This information contains associations between
* schedulers and executable software: A scheduler manages and distributes executable software like runnables or tasks on its managed processing units
* schedulers and processing units: A scheduler can manage one or more processing units and deploy computations on these
* data and memories: Data (such as functions, variables, heap etc) is mapped on static and volatile memories

Note the mapping model is the only sub model of Amalthea with an attribute in the root element. The _Address Mapping Type_ defines the interpretation of used addresses in the mapping model. Additional information can be found in the _MemoryMapping_ section.


h3. Overview

The Meta Model specifying the Mapping Model is shown below.

!(scale)../pictures/model_mapping_overview.svg!

h4. MappingModel

The __MappingModel__ serves as a container for each of the mapping rules, i.e. __Allocations__ (executable software and processing units which are allocated to schedulers) and __Mappings__ (labels and software which is mapped to memories).


h3. Allocations

!(scale)../pictures/model_mapping_allocation.svg!

h4. SchedulerAllocation

The __SchedulerAllocation__ describes the allocation of  a __Scheduler__ to processing units. This class consists of references to the respective __Scheduler__, which is specified within an existing OS model, and a processing units, which is specified in a hardware model. Schedulers with algorithm "Grouping" are not allocated since they take no decisions and produce no overhead.

table(minimal){padding:10px; border:1px solid black; background:#f8f8f8}.
|_. Name |_. Description |
| __scheduler__ | The scheduler (that is specified in more detail). |
| __responsibility__ | Defines the processing units the scheduler is responsible for. On these units the scheduler takes decisions. Multiple schedulers can be responsible for one processing unit because of hierarchies. Child-schedulers only take decisions, if they parent-schedulers allows them to (e.g. hypervisors with virtual machines which execute an own operating system). Tasks allocated to this scheduler execute on the intersection between affinity and the responsibility of the scheduler. If this is null the configuration is invalid. If the intersection results in multiple cores, the task can migrate. |
| __executingPU__ | Defines on which processing unit the scheduling algorithm is actually executed to consider the overhead.  |

h4. RunnableAllocation

The __RunnableAllocation__ is used to associate a __Runnable__, specified within an existing software model, with a __Scheduler__.

h4. TaskAllocation

The __TaskAllocation__ is used to associate a __Task__ with its __TaskScheduler__.

table(minimal){padding:10px; border:1px solid black; background:#f8f8f8}.
|_. Name |_. Description |
| __task__ | The task  (that is specified in more detail). |
| __scheduler__ | Specifies the unique allocation to the scheduler of the task. |
| __affinity__ | Specifies the possible processing units the task can run. If only one unit is specified, the task runs on this core. If multiple cores are specified, the task can migrate between the units. The task executes on the intersection between affinity and the responsibility of the scheduler. If this is null the configuration is invalid. If the intersection results in multiple cores, the task can migrate. |
| __schedulingParameters__ | Used to assign scheduling parameters for this specific allocation. For details see chapter "Scheduling Parameters" in OS Model. |

h4. ISRAllocation

The __ISRAllocation__ is used to associate an __ISR__ with an __InterruptConroller__. The attribute 'priority' can be used to assign a value for this specific allocation.


h3. Mappings

h4. MemoryMapping

The __MemoryMapping__ is a class, describing the mapping of parts of the software model to __Memory__. It is used to associate specializations of the __AbstractMemoryElement__ (i.e. __Label__, __Runnable__, __TaskPrototype__ and __Process__). The target memory is specified by a reference to an explicit __Memory__ within an existing hardware model. The position in memory can also be defined as address here. If the address is a absolute memory address, a offset address from the memories first address, or if the address information is not expected at all is defined by the __Memory Address Mapping Type__ enumeration in the root element of the __Mapping Model__. The  Additional attributes, e.g. to supply further information for a code generator, may be described by the containment attributeList.

h4. PhysicalSectionMapping

The _PhysicalSectionMapping_ class (can also be called as *Physical Memory Section* ) describes the following:
* mapping of various *Section* elements to a specific *Memory*
* mapping various *Label and Runnable* elements to a Physical Memory Section
* description of memory address location where the Physical Memory Section is allocated

Note for additional information (see <notextile><a href="./user_memorysection.html#user-memsection">User Guide > Concepts > Memory Sections</a></notextile>)