VII. Using Cheddar within OSATE 2

VII.1 How to install Cheddar plugin within OSATE 2

• Open the OSATE Help menu.
• Select from there the Install additional OSATE components menu.
• Then a window is opened and you can check Non SEI Components section, select Cheddar and follow installation instructions.

• The first plugin, displayed with the "XML" string in the toolbar, only transforms an AADL instance model into a Cheddar ADL XML file. Once this plugin is over, it displays the location of the generated file. No Cheddar binary is required there.
• The second plugin (which runs the Cheddar cheddar.exe binary on windows) both generates the Cheddar XML file and also calls the Cheddar binary if it is available. This plugin assumes Cheddar was previously installed in a folder called Cheddar_bin inside your home Desktop folder. Cheddar_bin must contain both the executables and all the required libraries or DLL. Figure 7.1 shows a typical folder with such binaries for a windows target. This folder can be populated by simply unzipping a Cheddar binary distribution ( see there for downloading one ).
  
  
  
  Figure 7.1 Cheddar_bin folder example
  
  If the Cheddar binary is stored in a specific location, the actual Cheddar binary location has to be specified by AADL properties in the root system component of the AADL model instance. For such a purpose, the required AADL properties are Cheddar_Install_Folder and Cheddar_Working_Folder. These properties are part of the Cheddar_Parameter_Properties set. Here is an sample of this set:

   	
      -- Configure where Cheddar working folder.
      -- The property Cheddar_Working_Folder will be used by Cheddar to store any
      -- of its working files. 
      -- 
      Cheddar_Working_Folder : aadlstring applies to (system);
  
      -- Configure what is the folder where Cheddar binaries and libraries are installed
      -- 
      Cheddar_Install_Folder : aadlstring applies to (system);
  

• The last plugin (which runs the Cheddar response_time.exe binary on windows) displayed with the "RT" string in the toolbar, allows users to compute worst/best/average response time of each thread. Again the Cheddar XML model file is generated and a dedicated Cheddar program is perform response time analysis. This program is an example that shows how to design a specific Cheddar plugin providing a specific schedulability analysis picked up from the Cheddar facade, i.e. the Cheddar framework interface.

VII.2 Cheddar plugins simple example of use

1. Create and populate a new OSATE project, or open any existing AADL project.
2. From a root AADL component of the declarative AADL model, build the instance model. The declarative AADL model cannot be used for scheduling analysis. Analysis are run on the instance model only. To create an instance model from a declarative model with OSATE, in the list of components on the right side of the OSATE windows, select a top system component and open the context menu (with the right mouse button), then select the "instanciate" menu item. The instance model appears in the middle of the OSATE windows. From this instance model, we can then generate the Cheddar XML model by selecting the root component of the instance model and pushing select the root system component and with a right mouse button call the Instanciate tool of OSATE.
3. From the project explorer, select the instancied model and generate the Cheddar XML model by pushing one of the 3 Cheddar plugins toolbar buttons. In the windows above, you can see a screenshot of OSATE. The generated Cheddar XML model is saved in the location given by the dialog box opened when the transformation is over. The OSATE toolbar also shows the 3 Cheddar plugins, from to the left to the right: the first produces the Cheddar XML model, the second generates the XML Cheddar model and launches Cheddar, the third generates the Cheddar ADL model and launches the Cheddar tool to compute thread response times.
   
   
   Figure 7.2 OSATE 2 run the Cheddar plugin
   
   
   
   
4. When you launch the Cheddar tool (middle toolbar button), you can call any analysis feature that is compliant with the XML Cheddar generated model. The response time tool (right toolbar button) can either compute response time from a scheduling simulation or from a feasibility test. To parametrize how the response time will be computed, one can set AADL properties on the root system. The sequel defines and explains what are the possible values for these properties.

VII.3 Cheddar AADL properties

• Cheddar_Properties.aadl. This first set is the original Cheddar AADL properties set proposed in 2007 for AADL 2.1. Some of those properties are now part of the AADL standard. AADL models can be designed with such standardized properties or with Cheddar_Properties.aadl properties, i.e. the Cheddar plugin should behave similarly. See there for the description of these original properties .
  
  
• Cheddar_Parameters_Properties.aadl. This set provides parameters to the Cheddar plugins or to the analysis features called by the plugins. Most of the AADL properties of this set have to associated to the root system component of the AADL model instance.
  
  Parameters to configure how to run cheddar are:
  • Cheddar_Working_Folder This property specifies the folder the plugins can use to store any Cheddar working files.
  • Cheddar_Install_Folder. This property gives the path to the folder that is supposed to contain the Cheddar binaries and any components require to run them, i.e. windows DLL or linux shared libraries.
  
  
  Several parameters also exist to configure how to compute the response time of the threads. With the right Cheddar plugin, response times can be computed either by scheduling simulation or by feasibility tests. By feasibility tests, Cheddar is only able to compute worst case response time. From scheduling simulation, both worst, best and average case can be computed for the thread response time. During schduling simulation, various events can be activeted or not with AADL properties. The highest parameter is the interval of time the scheduling simulation has to be computed : in the best case, one should compute the scheduling simulation during the feasibility interval, i.e. the interval of time which captures all possible events of the analyzed moodel. Finally, for response times computed by feasibility tests, it is possible to take into account latencies due to interfences on shared resources (both software and hardware).
  
  Here is the properties available to configure such analysis:

  
      -- Allows user to select how to compute WCRT : with scheduling simulation or with
      -- feasibility tests
      -- 
      Response_Time_From_Scheduling_Simulation : aadlboolean applies to (system);
      Response_Time_From_Feasibility_Test : aadlboolean applies to (system);
  
  
      -- Set the time interval on which scheduling simulation has to be computed
      -- by Cheddar tools 
      -- 
      Scheduling_Feasibility_Interval : aadlinteger applies to (system);
  	
  
      -- Select the type of interference we apply when computing WCRT with
      -- feasibility tests
      -- Interferences can be computed on memory shared resources such as cache or 
      -- memory bank
      --
      CRPD_Interference_Type  : type enumeration (No_CRPD, ECB_Only, ECB_Union_Multiset,
  			UCB_Union_Multiset, Combined_Multiset);
      CRPD_Interference : Cheddar_Transformation_Properties::CRPD_Interference_Type  applies to (system);  
  
      Memory_Interference_Type  : type enumeration (No_Memory_Interference,
  			DRAM_Single_Arbiter, Kalray_Multi_Arbiter);
      Memory_Interference : Cheddar_Transformation_Properties::Memory_Interference_Type  applies to (system);  
  
  	
      -- Properties to customize the scheduling simulations 
      -- if True, those parameters allow scheduling simulator to take into account 
      -- Offsets, jitters, CRPD, Precendencies and resources
      -- Those parameters have the following default values :
      --    Scheduling_With_Offsets => False
      --    Scheduling_With_Jitters => True
      --    Scheduling_With_CRPD => False
      --    Scheduling_With_Precendencies => True	
      --    Scheduling_With_Resources => True
      --
      Scheduling_With_Offsets : aadlboolean applies to (system);
      Scheduling_With_Jitters : aadlboolean applies to (system);
      Scheduling_With_CRPD : aadlboolean applies to (system);
      Scheduling_With_Precendencies : aadlboolean applies to (system);	
      Scheduling_With_Resources : aadlboolean applies to (system);	
  

  
  
  
• Cheddar_Transformation_Properties.aadl. The properties defined ther are used to drive transformation of AADL models towards Cheddar XML models. There is not an unique way to produce the Cheddar model from a given AADL model instance. How each entity of the AADL instance model must be mapped to Cheddar entities depends on the analysis method users expect to apply.
  
  Most of the AADL properties of this set have to associated to the root system component of the AADL model instance.
  
  First Cheddar only handles uniform timing data, i.e. timing data which are expressed with different units. In fact, in Cheddar, there is no unit at all. In contrary, AADL models may mix various units and then it is mandatory to transform all timing data from the AADL instance model to an unique unit. By default the Cheddar plugins generates millisecond values but such behavior can be changed with the Exported_Attribute_Time_Units property.
  
  The value of the Debug_Level property can be changed to fetch debug data from the Cheddar plugin.
  
  In many cases, designers expect to run worst case analysis by designing Cheddar model composed of periodic tasks. By default the Cheddar plugin does not change the thread dispatching model of the analyzed AADL instance model. If one expect to change Poisson or Sporadic AADL threads to periodic Cheddar ADL tasks, one can set the properties Transform_Sporadic_To_Periodic or Transform_Poisson_To_Periodic.
  
  Finally, data port can be handle by differents means with Cheddar. Data port connections can be mapped either by Cheddar precedences or by time triggered" Cheddar dependency. AADL property Data_Port_To_Time_Triggered_Dependency can used to custimize such a mapping.
  
  Here is the definition of the properties available to configure the transformation from AADL to Cheddar ADL:

      -- Configure the level of debug data produce by the plug in during 
      -- transformation
      --
      Debug_Type  : type enumeration (No_Debug, Minimal, Verbose, Very_Verbose);
      Debug_Level : Cheddar_Transformation_Properties::Debug_Type applies to (system);
  	
    
      -- All attributes of a Cheddar XML file are homogenous from
      -- a units point of view.
      -- For time units, by default, OSATE 2 Cheddar plugin generates millisecond values
      -- The following property allows desginers to select a different
      -- time unit for the generated values
      --  
      Time_Units: type enumeration (MicroSecond, MilliSecond, Second);
      Exported_Attribute_Time_Units : Cheddar_Transformation_Properties::Time_Units applies to (system);
  	
    
      -- For analysis motivations, one may want to produce Cheddar periodic tasks
      -- from AADL sporadic threads ; this is typically the case when from an AADL model
      -- one expect to run a worst case analysis
      -- If true, the following properties express that for a given system, its sporadic threads must 
      -- be transformed to periodic Cheddar task, to sporadic Cheddar task otherwise.
      -- The same mechanism also exits for AADL threads with a poisson process dispatching law.
      -- By default, we do not produce periodic Cheddar tasks for those kind of AADL threads
      --
      Transform_Sporadic_To_Periodic : aadlboolean applies to (system);
      Transform_Poisson_To_Periodic : aadlboolean applies to (system);
  		
  
      -- Data port connections can be mapped either by Cheddar "precedence"
      -- dependency or by "time triggered" Cheddar dependency
      -- if Data_Port_To_Time_triggeret_Dependency is false, Cheddar precedencies are generated
      -- otherwise time triggered entities are generated
      --
      Data_Port_To_Time_Triggered_Dependency : aadlboolean applies to (system);
  
  

  
  
  
• Cheddar_Multicore_Properties.aadl. This last property set contains experimental properties to model multi/manycore architectures. The main focus of these properties is to describe the hardware resources and their potential interferences/delays they may introduce. This last property set may change and it is adviced to check up its definition in OSATE 2 before using them.