(return back to recipe list)




  1. System to model and assumptions
  2. Typical solution
  3. Possible analysis
  4. Case study









System to model and assumptions

Critical systems such as real-time control-command can be implemented as a set of task running concurrently on a processor. We assume a uniprocessor execution platform. Task communications are not modeled in this recipe: either because we assume they are negligeable, or simply because there is no interaction.

Typical solution

A typical AADL solution for such systems is composed of thread and process components for the software part. The hardware part is modeled by a single processor component. You can download here an example of this recipe which is showed below: 
package independent_tasks
public

  thread a_task
  end a_task;  
  
  thread implementation a_task.Impl
  properties
    Dispatch_Protocol => Periodic;
  end a_task.Impl;

  process node_a
  end node_a;

  process implementation node_a.Impl
  subcomponents
    T1 : thread a_task.Impl;
    T2 : thread a_task.Impl;
  properties
    Period => 10 ms applies to T1;
    Deadline => 10 ms applies to T1;
    Compute_Execution_Time => 1 ms .. 2 ms applies to T1;
    Priority => 1 applies to T1;
    Period => 5 ms applies to T2;
    Deadline => 5 ms applies to T2;
    Compute_Execution_Time => 1 ms .. 1 ms applies to T2;
    Priority => 2 applies to T2;
  end node_a.Impl;

  processor cpu
  properties
    Scheduling_Protocol=>(POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL);
  end cpu;

  system root
  end root;

  system implementation root.Impl
  subcomponents
    process1 : process node_a.Impl;
    cpu1     : processor cpu;
  properties
    Actual_Processor_Binding => (reference (cpu1)) applies to process1;
  end root.Impl;

end independent_tasks;
The model above contains a process component called node_a.impl which models the software side and a processor component named cpu for the hardware side. The overall system is modeled by the root.Impl component, in which, the software mapping on the hardware is specified by the property assignment Actual_Processor_Binding.

The solution models two threads (called T1 and T2).
Each thread is defined as periodic, with a deadline, a priority and an execution time. Execution time of thread is defined by a time interval, with a worst case and a best case specified with the Compute_Execution_Time property. All those properties are defined inside the process component: notice the applies to to make reference to the thread at which the property value has to be assigned.

When dispatched, threads are scheduled according to the Scheduling_Protocol property assigned to the cpu component. By default, the threads are scheduling with a preemptive policy. Non-preemptive scheduling can be specified with the Preemptive_Scheduler property, again assigned to the cpu component.

Possible analysis

Thread components can be subject of analysis with this kind of model. One may want to verify if the threads will meet their deadlines, i.e. if they can complete their execution before the deadline. One may want also to compute the largest latency on the thread execution time. This latency is usually called the worst case response time. Those analysis are called a schedulability analysis. To do so, 2 methods are available for such purpose: either by scheduling simulation or by feasibility tests. Scheduling simulation consists to simulate the scheduling of the thread set and to compute several properties from the resulting scheduling. Users have to decide how much time the simulation needs to be computed to observe all the events that will be produced by the thread set: this simulation time is called the feasibility interval (Goossens 2016). From the simulation and/or with feasibility tests, one can compute: From AADLInspector, schedulability analysis can be run when the instance model is computed with either Marzhin or Cheddar. Instance model is computed by the Static Analysis, Parse and Instanciante button. With AADLInspector, schedulability with Cheddar can be run with the Timing Analysis/Simulation timelines button followed by the Simulation Tests button, or by the Timing Analysis/Theoretical Tests. For this model, the analysis with AADInspector is shown here:




From OSATE, once the instance model is computed, Cheddar can be called from one of its OSATE plugin. To compute the instance model with OSATE, in the project explorer, do a right click on the root.Impl component. A contextual menu is then displayed from which an Instanciate menu call be selected. In OSATE, an instance model is stored in a AAXL file. From this AAXL file, one can use the Cheddar plugin to generate the corresponding Cheddar XML model, and then to run schedulability. For this model, the analysis with OSATE and the Cheddar plugin is shown here:





With Ocarina, such kind of model can lead to code generation to run the application on various targets including Linux. In this case, the designer must provide the code of each thread, either as a C function or a Ada subprogram. Assuming we want that each thread simply displays a message at each periodic release, possible C functions for the example above can be: 
#include ...

void T1_spg (void)
{
  printf ("Thread T1: i am running and displays a message\n");
  fflush (stdout);
}

void T2_spg (void)
{
  printf ("Thread T2: i am running and displays a message\n");
  fflush (stdout);
}
If the C functions are stored in a file called independent_tasks.c, the AADL model must be extended as follow to specify the relationships between the C functions and the AADL threads: 
subprogram T1_spg
properties
  source_language => C;
  source_name     => "T1_spg";
  source_text     => ("independent_tasks.c");
end alarme_spg;

subprogram T2_spg
properties
  source_language => C;
  source_name     => "T2_spg";
  source_text     => ("independent_tasks.c");
end lampe_spg;

thread a_task
properties
   Dispatch_Protocol => periodic;
end a_task;

thread implementation a_task.T1
calls
 c : {
  s : subprogram T1_spg;
};
end a_task.T1;

thread implementation a_task.T2
calls
 c : {
  s : subprogram T2_spg;
};
end a_task.T2;

 process implementation Application.Impl
  subcomponents
    T1 : thread a_task.T1;
    T2 : thread a_task.T2;
  properties
    ...
Running the application built by Ocarina is another step towards the real implementation, as it allows to the AADL designer to see the result on a given target of his design. To see how to build the application and how to run it with Ocarina, see case study 1. To run it, first we must ask to Ocarina to generate the glue code between related our AADL mode, which can be made by: 
ocarina -x scenario.aadl
This command should generate a folder named node_a in which is stored the source code of the application.

The file scenario.aadl drives Ocarina during the code generation by Ocarina. Here is an example of such file: 
system root
properties
  Ocarina_Config::Timeout_Property     => 4000ms;
  Ocarina_Config::Referencial_Files    =>
    ("node_a", "node_a.ref");
  Ocarina_Config::AADL_Files           => 
    ("case_study1.aadl");
  Ocarina_Config::Generator            => polyorb_hi_c;
  Ocarina_Config::Needed_Property_Sets => 
    (value (Ocarina_Config::Data_Model),
     value (Ocarina_Config::Deployment),
     value (Ocarina_Config::Cheddar_Properties));
  Ocarina_Config::AADL_Version         => AADLv2;
end root;

system implementation root.Impl
end  root.Impl;
This AADL parameter file will ask Ocarina to produce the source code of this AADL model in a folder called node_a. polyorb_hi_c will be used as target, i.e. PolyORB is a middleware for high critical systems implemented in both C and Ada. We ask here Ocarina to generate the C code the C implementation of PolyORB.

Once generated, to compile the source code, launch the following commands: 
cd node_a
make
At compilation completion, you should find an executable named node_a in the folder node_a, executable which can be run from your shell.

AADL component properties for each tool



While AADL provides standard properties, each tool may handle specific properties and/or specific values for standard properties. This may lead to interoperability issues between AADL tools. Sometimes, different values handled by different tools make reference to the same concept/protocol/algorithm. In the sequel, we list tool specific elements about properties for the tools referenced in AACB:
  1. Scheduling_Protocol: this property specifies how the threads have to be scheduled on a given processor. Each may support different (or similar protocols).

    OSATE provides the following values for this property: 
     Static, Round_Robin_Protocol, POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL, 
 FixedTimeline, Cooperative, RMS, DMS, EDF,
 SporadicServer, SlackServer or ARINC653.


    AADLInspector supports OSATE protocols and most of the Cheddar protocols. AADLInspector supported protocols are: 
      SporadicServer, FixedTimeline,
  PARAMETRIC_PROTOCOL,
  EARLIEST_DEADLINE_FIRST_PROTOCOL,
  LEAST_LAXITY_FIRST_PROTOCOL,
  RATE_MONOTONIC_PROTOCOL,
  DEADLINE_MONOTONIC_PROTOCOL,
  ROUND_ROBIN_PROTOCOL,
  TIME_SHARING_BASED_ON_WAIT_TIME_PROTOCOL,
  POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL,
  D_OVER_PROTOCOL,
  MAXIMUM_URGENCY_FIRST_BASED_ON_LAXITY_PROTOCOL,
  MAXIMUM_URGENCY_FIRST_BASED_ON_DEADLINE_PROTOCOL,
  TIME_SHARING_BASED_ON_CPU_USAGE_PROTOCOL,
  HIERARCHICAL_CYCLIC_PROTOCOL,
  HIERARCHICAL_ROUND_ROBIN_PROTOCOL,
  HIERARCHICAL_FIXED_PRIORITY_PROTOCOL,
  HIERARCHICAL_PARAMETRIC_PROTOCOL, 
  HIERARCHICAL_OFFLINE_PROTOCOL, 
  STATIC, 
  RR, RM, RMS, DM, HPF, EDF, LLF, ARINC653, CYCLIC, OFFLINE.


    Scheduling protocols supported by Cheddar are:
Notice that tools may have different litterals refering to the same algorithm. For example:
  • Dispatch_Protocol : models how the threads are dispatched.

    Most of the tools provide the same values for this property. Bellow is the mapping of each tool values. Notice that for the Cheddar column, the values in this table are related to the Cheddar analysis model (i.e. Cheddar ADL). Note also that for Timed, Hybrid or Interrupt AADL values may be translated in Cheddar either to Periodic_Type when a worst case scenario analysis must be run, or Sporadic_Type if the Cheddar simulator is used with thread dispatching time that are randomly generated during simulation.



    AADLInspector OSATE2 Cheddar ADL
    Periodic Periodic Periodic_Type
    Sporadic Sporadic Sporadic_Type
    Aperiodic Aperiodic Aperiodic_Type
    Timed Timed Periodic_Type or Sporadic_Type
    Hybrid Hybrid Periodic_Type or Sporadic_Type
    Background Background Aperiodic_Type
    Interrupt ? Sporadic_Type



  • Tools specific property set: Any of the tool has property sets that are specific it and which may extend the elements presented above. As an example, Cheddar provides 4 specific property sets to model multiprocessor architectures for instance. For many reasons (i.e. legacy), tool specific property sets may introduce concepts that may be present in the last AADL standard. In this case, it is preferable to used standard properties to increase succesfull interoperability between AADL tools.

    For specific property sets of OSATE2 or AADLInspector, please check those tools.

    Case study



    Case study 1: fixed priority example



    We investigate a set of threads defined by the following parameters: We also assume that the task deadlines are equal to their periods. We use a preemptive fixed priority scheduling with Rate Monotonic priority assignment.
    1. Propose an AADL model with one processor running all those threads.
    2. Investigate the behavior of this model with OSATE/Cheddar or AADLInspector:
      • With the processor utilization factor test. Do the threads meet their deadlines?
      • Draw the scheduling sequence of this thread set during the first 30 units of times with a preemptive scheduler. Redraw the scheduling with a non-preemptive scheduler. What can you see?
    3. Assuming we change task parameters as follow: the period of thread 1 is now 30 ms, the worst case execution time of thread 1 is 6 ms and worst case execution time of thread 2 is 3 ms. This new thread set is said to be "harmonic". A harmonic set of periodic threads is one in which the period of each thread is an exact multiple of every thread that has a shorter period.
    4. Investigate the behavior of this new model with OSATE/Cheddar or AADLInspector:
      • Apply the processor utilization factor test again. Do the threads meet their deadlines?
      • Draw the scheduling sequence of this new thread set during the first 30 units of times. What can you see now?
      • Compute worst case response time of each thread with the Joseph and Pandia method. You should find worst case response times that are consistent with the response times in the scheduling you drew in the previous question of this exercise.
    5. With Ocarina, write an AADL model allowing to run the application on Linux for example. The subprograms of each thread must simply display the thread name at each periodic release.


    Possible solution/AADL model for this case study available here:

    A possible AADL model to investigate schedulability with AADLInspector or OSATE is given below: 
    package case_study1
public

  thread a_task
  properties
    Dispatch_Protocol => Periodic;
  end a_task;  
  
  thread T1 extends a_task
  end T1;
  thread implementation T1.Impl
  end T1.Impl;

  thread T2 extends a_task
  end T2;
  thread implementation T2.Impl
  end T2.Impl;
  
  thread T3 extends a_task
  end T3;
  thread implementation T3.Impl
  end T3.Impl;
  
  process Application
  end Application;

  process implementation Application.Impl
  subcomponents
    T1 : thread T1.Impl;
    T2 : thread T2.Impl;
    T3 : thread T3.Impl;
  properties
    Period => 29 ms applies to T1;
    Deadline => 29 ms applies to T1;
    Compute_Execution_Time => 1 ms .. 7 ms applies to T1;
    Priority => 1 applies to T1;
    
    Period => 5 ms applies to T2;
    Deadline => 5 ms applies to T2;
    Compute_Execution_Time => 1 ms .. 1 ms applies to T2;
    Priority => 3 applies to T2;
    
    Period => 10 ms applies to T3;
    Deadline => 10 ms applies to T3;
    Compute_Execution_Time => 1 ms .. 2 ms applies to T3;
    Priority => 2 applies to T3;
    
  end Application.Impl;

  processor cpu
  properties
    Scheduling_Protocol=>(RMS);
  end cpu;

  system root
  end root;

  system implementation root.Impl
  subcomponents
    process1 : process application.Impl;
    cpu1     : processor cpu;
  properties
    Actual_Processor_Binding => (reference (cpu1)) applies to process1;
  end root.Impl;

end case_study1;


    For the Ocarina model, we must extend the previous model by 1) with a AADL subprogram component for each thread 2) with an AADL file driving the code generation by Ocarina 3) with the C or Ada code of the thread subprograms.

    The AADL model must be changed by updating the thread implementation that now needs to reference the subprogram component constituting the thread main entry point: 
      subprogram T1_spg
  properties
    source_language => (C);
    source_name     => "T1_spg";
    source_text     => ("case_study1.c");
  end T1_spg;
  
  thread T1 extends a_task
  end T1;
  thread implementation T1.Impl
  calls
   c : {
     s : subprogram T1_spg;
   };
  end T1.Impl;


    We specify there that T1 must run the C function T1_spg. This C function is also store in the case_study1.c file, which stores the C functions of all thread of this AADL model: 
    #include ...

void T1_spg (void)
{
  printf ("[%d] Thread T1 is released\n", milliseconds_since_epoch());
  fflush (stdout);
}

void T2_spg (void)
{
  printf ("[%d] Thread T2 is released\n", milliseconds_since_epoch());
  fflush (stdout);
}

void T3_spg (void)
{
  printf ("[%d] Thread T3 is released\n", milliseconds_since_epoch());
  fflush (stdout);
}


    Case study 2: EDF example



    We investigate a set of threads defined by the following parameters: We also assume that the thread deadlines are equal to their periods. We use a preemptive Earliest Deadline First scheduler.
    1. Propose an AADL model with one processor running all those threads.
    2. Investigate the behavior of this model with OSATE/Cheddar or AADLInspector:
      • Apply the processor utilization factor test. Do the threads meet their deadlines?
      • Compute the feasibility interval of this threads set. How many idle units of time should we have during this feasibility interval?
      • Draw the scheduling sequence of this thread set during the feasibility interval. Is the number of idle units of time consistent with your answer of question 2?
      • Now assume a non-preemptive Earliest Deadline First scheduler. Re-draw the scheduling sequence of this task set during the feasibility interval and compare this scheduling with the scheduling sequence of question 3. Compare the behaviors of the preemptive and non-preemptive schedulers for this task set.
      • Now assume that some aperiodic threads are released: threads TA1 and TA2. TA1 has a worst case execution time of 1 ms, is released at time 7 and has to meet an absolute deadline at time 9. TA2 has a worst case execution time of 3 ms, is released at time 12 and has to meet a an absolute deadline at time 21. We assume that deadline of aperiodic threads defined above are the dynamic priorities that the EDF must handle to schedule the thread set. Draw the scheduling sequence of this new thread set for the first 30 ms. Can we meet all the deadlines under the preemptive EDF scheduler?


    Possible solution/AADL model for this case study available here: 
    package case_study2

public

  thread a_task
  end a_task;  
  
  thread implementation a_task.Impl
  properties
    Dispatch_Protocol => Periodic;
  end a_task.Impl;

  process Application
  end Application;

  process implementation Application.Impl
  subcomponents
    T1 : thread a_task.Impl;
    T2 : thread a_task.Impl;
    T3 : thread a_task.Impl;
  properties
    Period => 12 ms applies to T1;
    Deadline => 12 ms applies to T1;
    Compute_Execution_Time => 1 ms .. 5 ms applies to T1;
    
    Period => 6 ms applies to T2;
    Deadline => 6 ms applies to T2;
    Compute_Execution_Time => 1 ms .. 6 ms applies to T2;
    
    Period => 24 ms applies to T3;
    Deadline => 24 ms applies to T3;
    Compute_Execution_Time => 1 ms .. 5 ms applies to T3;
    
  end Application.Impl;

  processor cpu
  properties
    Scheduling_Protocol=>(EDF);
  end cpu;

  system root
  end root;

  system implementation root.Impl
  subcomponents
    process1 : process application.Impl;
    cpu1     : processor cpu;
  properties
    Actual_Processor_Binding => (reference (cpu1)) applies to process1;
  end root.Impl;
	
end case_study2;


    Case study 3: POSIX schedulding example



    In this example, you will practice with POSIX 1003 scheduling policies. We assume a Linux operating system that implements the POSIX 1003 standard with a scheduling model with 100 priority levels (from 0 to 99 with 99 being the highest priority). Priority level 0 is devoted to time sharing tasks. All tasks that have a 0 priority level are scheduled according to the SCHED_OTHER policy. The Linux SCHED_OTHER policy schedules tasks according to how long they waited for the processor. In priority level 0, the task to be run is the one that has waited for the longest duration to get the processor among all tasks of priority queue 0. Tasks which have a priority level between 1 and 99 are scheduled either with SCHED_FIFO or SCHED_RR. Of course, the tasks in priority queues 1 through 99 are dispatched before any tasks in the lower priority queue 0. We assume a quantum of one unit of time for the SCHED_RR policy. The scheduling is preemptive.

    Given the following threads characteristics:



    Threads Worst case execution time Release time Priority Policy
    other1 8 ms 0 0 SCHED_OTHER
    rr1 5 ms 2 3 SCHED_RR
    rr2 5 ms 2 3 SCHED_RR
    fifo1 3 ms 3 4 SCHED_FIFO
    fifo2 3 ms 3 3 SCHED_FIFO
    fifo3 3 ms 2 4 SCHED_FIFO



    With AADLInspector or OSATE/Cheddar, propose an AADL model and draw the scheduling sequence for this thread set from time 0 ms to time 25 ms.

    Possible solution/AADL model for this case study available here: 
    package case_study3

public
  with Cheddar_Properties;
  
  thread a_task
  end a_task;  
  
  thread implementation a_task.Periodic_Impl
  properties
    Dispatch_Protocol => Periodic;
  end a_task.Periodic_Impl;

  thread implementation a_task.Aperiodic_Impl
  properties
    Dispatch_Protocol => Aperiodic;
  end a_task.Aperiodic_Impl;
  
  process Application
  end Application;

  process implementation Application.Impl
  subcomponents
    other1 : thread a_task.Aperiodic_Impl;
    rr1    : thread a_task.Aperiodic_Impl;
    rr2    : thread a_task.Aperiodic_Impl;
    fifo1  : thread a_task.Aperiodic_Impl;
    fifo2  : thread a_task.Aperiodic_Impl;
    fifo3  : thread a_task.Aperiodic_Impl;    
  properties
    Compute_Execution_Time => 1 ms .. 8 ms applies to other1;
    Priority => 0 applies to other1;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_OTHERS applies to other1;
    Dispatch_Offset => 0 ms applies to other1;
    
    Compute_Execution_Time => 1 ms .. 5 ms applies to rr1;
    Priority => 3 applies to rr1;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_RR applies to rr1;
    Dispatch_Offset => 2 ms applies to rr1;
    
    Compute_Execution_Time => 1 ms .. 5 ms applies to rr2;
    Priority => 3 applies to rr2;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_RR applies to rr2;
    Dispatch_Offset => 2 ms applies to rr2;

    Compute_Execution_Time => 1 ms .. 3 ms applies to fifo1;
    Priority => 4 applies to fifo1;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_FIFO applies to fifo1;
    Dispatch_Offset => 3 ms applies to fifo1;

    Compute_Execution_Time => 1 ms .. 3 ms applies to fifo2;
    Priority => 3 applies to fifo2;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_FIFO applies to fifo2;
    Dispatch_Offset => 3 ms applies to fifo2;

    Compute_Execution_Time => 1 ms .. 3 ms applies to fifo3;
    Priority => 4 applies to fifo3;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_FIFO applies to fifo3;
    Dispatch_Offset => 2 ms applies to fifo3;
        
  end Application.Impl;

  processor cpu
  properties
    Scheduling_Protocol=>(POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL);
  end cpu;

  system root
  end root;

  system implementation root.Impl
  subcomponents
    process1 : process application.Impl;
    cpu1     : processor cpu;
  properties
    Actual_Processor_Binding => (reference (cpu1)) applies to process1;
  end root.Impl;
	
end case_study3;


    Case study 4: POSIX schedulding with periodic threads



    In this exercise you will practice with POSIX 1003 scheduling policies. We assume a system composed of two periodic theads with the folling properties: We also assume that the threads deadlines are equal to their periods.

    The operating system is a POSIX 1003.1b operating system with 32 priority levels (priority levels ranging from 0 to 31). Priority level 31 is the highest priority level. This operating system provides POSIX 1003.1b SCHED_FIFO, SCHED_RR and SCHED_OTHER policies. In the case of the SCHED_RR, the quantum is about one unit of time. SCHED_OTHER implements a time sharing scheduling. The scheduling is preemptive.
    1. With AADLInspector or OSATE/Cheddar, propose an AADL model for such thread set. We assume a Rate Monotonic priority assignment.
    2. Check the schedulability.
    3. Besides T1 and T2, the processor owns a set of aperiodic threads defined as follows:



      Threads Worst case execution time Release time Priority Policy
      other1 5 ms 5 ms 0 SCHED_OTHER
      rr1 3 ms 3 ms 7 SCHED_RR
      rr2 3 ms 4 ms 7 SCHED_RR
      fifo1 4 ms 5 ms 20 SCHED_FIFO
      fifo2 2 ms 4 ms 5 SCHED_FIFO



    4. Assign a priority level to threads T1 and T2 which allows these periodic threads to meet their deadlines and which is compliant to the operating system properties (related to POSIX 1003.1b scheduling model). Explain your choice.
    5. Draw the scheduling of all processes (both periodic and aperiodic tasks) from time 0 to time 30.


    Possible solution/AADL model for this case study available here: 
    package case_study4

public
  with Cheddar_Properties;
  
  thread a_task
  end a_task;  
  
  thread implementation a_task.Periodic_Impl
  properties
    Dispatch_Protocol => Periodic;
  end a_task.Periodic_Impl;

  thread implementation a_task.Aperiodic_Impl
  properties
    Dispatch_Protocol => Aperiodic;
  end a_task.Aperiodic_Impl;
  
  process Application
  end Application;

  process implementation Application.Impl
  subcomponents
    T1     : thread a_task.Periodic_Impl;
    T2     : thread a_task.Periodic_Impl;
    other1 : thread a_task.Aperiodic_Impl;
    rr1    : thread a_task.Aperiodic_Impl;
    rr2    : thread a_task.Aperiodic_Impl;
    fifo1  : thread a_task.Aperiodic_Impl;
    fifo2  : thread a_task.Aperiodic_Impl;
  properties
    Compute_Execution_Time => 1 ms .. 5 ms applies to T1;
    Priority => 99 applies to T1;
    Period => 12 ms applies to T1;
    Deadline => 12 ms applies to T1;
    
    Compute_Execution_Time => 1 ms .. 2 ms applies to T2;
    Period => 6 ms applies to T2;
    Priority => 100 applies to T2;
    Deadline => 6 ms applies to T2;
    
    Compute_Execution_Time => 1 ms .. 5 ms applies to other1;
    Priority => 0 applies to other1;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_OTHERS applies to other1;
    Dispatch_Offset => 5 ms applies to other1;
    
    Compute_Execution_Time => 1 ms .. 3 ms applies to rr1;
    Priority => 7 applies to rr1;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_RR applies to rr1;
    Dispatch_Offset => 3 ms applies to rr1;
    
    Compute_Execution_Time => 1 ms .. 3 ms applies to rr2;
    Priority => 7 applies to rr2;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_RR applies to rr2;
    Dispatch_Offset => 4 ms applies to rr2;

    Compute_Execution_Time => 1 ms .. 4 ms applies to fifo1;
    Priority => 20 applies to fifo1;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_FIFO applies to fifo1;
    Dispatch_Offset => 5 ms applies to fifo1;

    Compute_Execution_Time => 1 ms .. 2 ms applies to fifo2;
    Priority => 5 applies to fifo2;
    Cheddar_Properties::POSIX_Scheduling_Policy => SCHED_FIFO applies to fifo2;
    Dispatch_Offset => 4 ms applies to fifo2;
        
  end Application.Impl;

  processor cpu
  properties
    Scheduling_Protocol=>(POSIX_1003_HIGHEST_PRIORITY_FIRST_PROTOCOL);
  end cpu;

  system root
  end root;

  system implementation root.Impl
  subcomponents
    process1 : process application.Impl;
    cpu1     : processor cpu;
  properties
    Actual_Processor_Binding => (reference (cpu1)) applies to process1;
  end root.Impl;

end case_study4;









    (return back to recipe list)