blob: 36988daca6c16ea84ac8c17fec8079dcc90c4322 [file] [log] [blame]
h3. Modeling Example 2
h4. General information
Modeling Example 2 describes a simple system consisting of 4 Tasks, which is running on a single core processor.
The following figure shows the execution footprint in a Gantt chart:
!../pictures/example_modeling/modeling_2_gantt.png!
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.
h4. Hardware Model
!../pictures/example_modeling/modeling_2_hw.png!
The hardware model of Modeling Example 2 consists as already mentioned of a single core processor.
The following gives a structural overview on the modeled elements.
There, the core, 'Core_1' , has a static processing frequency of 600 MHz each, which is specified by the corresponding quartz oscillator 'Quartz_1'.
h4. Operating System Model
!../pictures/example_modeling/modeling_2_scheduler.png!
The operating system (OS) model defines in case of Modeling Example 2 only the needed Scheduler.
Since only a single core has to be managed, a single scheduler is modeled correspondingly.
In addition to the scheduling algorithm used by the scheduler, in this case OSEK, a delay of 100 ns is set, which is the presumed time the scheduler needs for context switches.
A comprehension of the modeled properties can be found in the following table:
table(classic){text-align:center; background:#f8f8f8}.
{background:#eee}.|_.Scheduler |_.Type|_.Algorithm|_.Delay|
| *Scheduler_1* | SchedulingHwUnit | OSEK | 100 ns |
h4. Mapping Model
!../pictures/example_modeling/modeling_2_mapping.png!
The mapping model defines allocations between different model parts.
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'.
On the other hand the allocation of cores to a scheduler is set.
As a consequence, the scheduler manages the only available processing core.
A comprehension of the modeled properties can be found in the following tables:
h5. Executable Allocation
table(classic){text-align:center; background:#f8f8f8}.
{background:#eee}.|_.Scheduler|_.Process|
| Scheduler_1 | Task_1 |
| Scheduler_1 | Task_2 |
| Scheduler_1 | Task_3 |
| Scheduler_1 | Task_4 |
h5. Core Allocation
table(classic){text-align:center; background:#f8f8f8}.
{background:#eee}.|_.Scheduler|_.Core|
| Scheduler_1 | Core_1 |
h4. Software Model
h5. Tasks
!../pictures/example_modeling/modeling_2_tasks.png!
As already mentioned above, the software model of Modeling Example 2 consists exactly of four tasks, named 'Task_1' to 'Task_4'.
All tasks have assigned the same priority (10) to get a cooperative scheduling.
'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.
A comprehension of the modeled properties can be found in the following table:
table(classic){text-align:center; background:#f8f8f8}.
{background:#eee}.|_.Task|_.Priority|_.Preemption|_.MTA*|_.Deadline|_.Calls|
|/8.*Task_1*|/8.10|/8.Preemptive|/8.3|/8.25 ms|<.1.1) Runnable_1_1|
|<.1.2) Runnable_1_2|
|<.1.3) Task_2|
|<.1.4) Runnable_1_4|
|<.2.1) Runnable_1_1|
|<.2.2) Runnable_1_3|
|<.2.3) Task_3|
|<.2.4) Runnable_1_4|
|*Task_2*|10|Preemptive|3|25 ms|<.1) Runnable_2_1|
|*Task_3*|10|Preemptive|3|25 ms|<.1) Runnable_3_1|
|*Task_4*|10|Preemptive|3|25 ms|<.1) Runnable_4_1|
*MTA = Multiple Task Activation Limit
h5. Runnables
!../pictures/example_modeling/modeling_2_runnables.png!
In addition to the task, the software model also contains a definition of Runnables.
For Modeling Example 2, seven individual Runnables are defined.
The only function of those in this example is to consume processing resources.
Therefore, for each Runnable a number of instruction cycles is stated.
The number of instruction cycles is thereby either constant or defined by a statistical distribution.
A comprehension of the modeled properties can be found in the following table:
table(classic){text-align:center; background:#f8f8f8}.
{background:#eee}.|_.Runnable|_.Type|_.Instructions|
|*Runnable_1_1*|Constant|1000000|
|*Runnable_1_2*|Constant|2000000|
|*Runnable_1_3*|Constant|3000000|
|*Runnable_1_4*|Constant|4000000|
|/2.*Runnable_2_1*|/2.Uniform Distribution|1000000|
|5000000|
|/3.*Runnable_3_1*|/3.Gauss Distribution|<.mean: 1000000|
|<.sd: 50000|
|<.upper: 5000000|
|*Runnable_4_1*|Constant|4000000|
h4. Stimulation Model
!../pictures/example_modeling/modeling_2_stimuli.png!
The stimulation model defines the activations of tasks.
'Task_1' is activated periodically by 'Stimulus_Task_1'
'Stimulus_Task_2' and 'Stimulus_Task_3' represent the inter-process activations for the corresponding tasks.
'Task_4' finally is activated sporadically following a Gauss distribution.
A comprehension of the modeled properties can be found in the following table:
table(classic){text-align:center; background:#f8f8f8}.
{background:#eee}.|_.Stimulus|_.Type|_.Parameters|
|/2.*Stimulus_Task_1*|/2.Periodic|<.offset: 0 ms|
|<.recurrence: 25 ms|
|*Stimulus_Task_2*|Inter-Process| |
|*Stimulus_Task_3*|Inter-Process| |
|/3.*Stimulus_Task_4*|/3.Sporadic (Gauss)|<.mean: 30 ms|
|<.sd: 5 ms|
|<.upper: 100 ms|