| |
| |
| 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| |
| |