| |
| |
| h3. Modeling Example 1 |
| |
| h4. General information |
| |
| Modeling Example 1 describes a simple system consisting of 4 Tasks, which is running on a dual core processor. |
| The following figure shows the execution footprint in a Gantt chart: |
| !../pictures/example_modeling/modeling_1_gantt.png! |
| 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. |
| |
| h4. Hardware Model |
| |
| !../pictures/example_modeling/modeling_1_hw.png! |
| |
| The hardware model of Modeling Example 1 consists as already mentioned of a dual core processor. |
| The following gives a structural overview on the modeled elements. |
| 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'. |
| |
| h4. Operating System Model |
| |
| !../pictures/example_modeling/modeling_1_schedulers.png! |
| |
| The operating system (OS) model defines in case of Modeling Example 1 only the needed Scheduler. |
| Since a dual core processor has to be managed, two schedulers are 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 | |
| | *Scheduler_2* | SchedulingHWUnit | OSEK | 100 ns | |
| |
| h4. Mapping Model |
| |
| !../pictures/example_modeling/modeling_1_mapping.png! |
| |
| The mapping model defines allocations between different model parts. |
| 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'. |
| 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. |
| 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_2 | Task_3 | |
| | Scheduler_2 | Task_4 | |
| |
| h5. Core Allocation |
| |
| table(classic){text-align:center; background:#f8f8f8}. |
| {background:#eee}.|_.Scheduler|_.Core| |
| | Scheduler_1 | Core_1 | |
| | Scheduler_2 | Core_2 | |
| |
| h4. Software Model |
| |
| h5. Tasks |
| |
| !../pictures/example_modeling/modeling_1_tasks.png! |
| |
| 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 has a priority assigned according its deadline, meaning the one with the shortest deadline, 'Task_1', has the highest priority, and so on. |
| Each task also calls a definitive number of Runnables in a sequential order. |
| 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| |
| |*Task_1*|4|Preemptive|1|75 ms| 1) Runnable_1_1| |
| |/2.*Task_2*|/2.3|/2.Preemptive|/2.1|/2.115 ms| 1) Runnable_2_1| |
| | 2) Runnable_2_2| |
| |/3.*Task_3*|/3.2|/3.Preemptive|/3.1|/3.300 ms| 1) Runnable_3_1| |
| | 2) Runnable_3_2| |
| | 3) Runnable_3_3| |
| |/4.*Task_4*|/4.1|/4.Preemptive|/4.1|/4.960 ms| 1) Runnable_4_1| |
| | 2) Runnable_4_2| |
| | 3) Runnable_4_3| |
| | 4) Runnable_4_4| |
| |
| *MTA = Multiple Task Activation Limit |
| |
| h5. Runnables |
| |
| !../pictures/example_modeling/modeling_1_runnables.png! |
| |
| In addition to the task, the software model also contains a definition of Runnables. |
| For Modeling Example 1, ten individual Runnables are defined. |
| The only function of those in this example is to consume processing resources. |
| Therefore, for each Runnable a constant number of instruction cycles is stated. |
| A comprehension of the modeled properties can be found in the following table: |
| |
| table(classic){text-align:center; background:#f8f8f8}. |
| {background:#eee}.|_.Runnable|_.InstructionCycles| |
| | Runnable_1_1 | 1500000 | |
| | Runnable_2_1 | 1500000 | |
| | Runnable_2_2 | 1500000 | |
| | Runnable_3_1 | 1000000 | |
| | Runnable_3_2 | 2000000 | |
| | Runnable_3_3 | 1000000 | |
| | Runnable_4_1 | 1000000 | |
| | Runnable_4_2 | 2000000 | |
| | Runnable_4_3 | 3000000 | |
| | Runnable_4_4 | 2000000 | |
| |
| h4. Stimuli Model |
| |
| !../pictures/example_modeling/modeling_1_stimuli.png! |
| |
| The stimulation model defines the activations of tasks. |
| Since the four tasks of Modeling Example 1 are activated periodically, four stimuli according their recurrence are modeled. |
| A comprehension of the modeled properties can be found in the following table: |
| |
| table(classic){text-align:center; background:#f8f8f8}. |
| {background:#eee}.|_.Stimulus|_.Type|_.Offset|_.Recurrence| |
| | Stimulus_Task_1 | Periodic | 0 ms | 180 ms | |
| | Stimulus_Task_2 | Periodic | 0 ms | 200 ms | |
| | Stimulus_Task_3 | Periodic | 0 ms | 300 ms | |
| | Stimulus_Task_4 | Periodic | 0 ms | 1 s | |
| |
| |