There is currently no document on the Cheddar's framework but this directory provides somes examples of programs that you can use in order to directly call the framework without the machine-man interface. To call the framework, you must use the framework interface. The framework interface is implemented in the call_framework.ads package. The call_framework.ads package implements the facade design pattern : it means that all the services provided by the framework is available from this package. You may others analysis features of Cheddar, but if they are not in the facade, it means that they are not robust enough to be used.

The following programs use the call_framework.ads interface :

• build_schedule_from_xml.adb : this program computes a scheduling from an XML Cheddar architecture model and saves the result into a second file. This is an example which shows how to use cheddar through the command line. The XML file name of the system to analyze must be given with the "-i" switch. The XML file name of the scheduling to save must be given with the "-o" switch. This program also takes one argument : the period on which the scheduling must be computed. The resulting scheduling is in fact the event table produced by the scheduling engine.
  
• comprehensive_call.adb : this program is an example of a call to the framework. This call includes the analysis of a scheduling. The result is formatted as a simple ASCII text.
  
• xml_basics.adb : this program shows you how to call Cheddar and to save the analysis results computed by feasibility test in an file.
  
• schedule_hardcoded_model.adb : this program shows you how to use the Cheddar framework API to design an architecture model. Some examples of architecture models are given in the package architecture_models.adb. The schedule_hardcoded_model.adb package called a sub-program of architecture_models.adb to build a architecture model and then, compute scheduling sequences for the builded architecture model.
  
• parse_and_display_schedule.adb : this program shows how to read and parse an XML file containing a schedule computed by Cheddar. This schedule is in fact, the event table produced by the scheduling engine. The "-s" switch must be used to provide the anayzed system (eg. its XML file name). The "-e" switch must be used to provide the event table (eg. its XML file name).
  
• read_sys.adb : this program shows how to load a XML Cheddar architecture model into the framework and how to print it on the screen.
  
• write_sys.adb : this program gives an example on how to save an architecture model in a XML Cheddar file.
  
• produce_arinc_pst.adb : this program reads a architecture model, computes the scheduling and export the corresponding ARINC 653 PST.
  
• xml_comprehensive_call.adb : this program implements the same calls to the framework than comprehensive_call.adb but the result produced by this program is generated with XML tags (in order to be displayed by an Internet browser). However, this feature is not fully implemented : some XML tags are missing today.
  
• Select_feasibility_test_simpl_from_xml : is an example of feasibility test selection prototype. It enable to apply the design pattern recognition method to architecture models.
  This program can either take an architecture model in xml format as an entry, and also provide 8 architecture examples to illustrate how it works.
  Those 8 example are:
  (1) compliant_ttc: an architecture compliant to the Time_Triggered_Communication Design pattern;
  (2)uncompliant_ttc: an architecture close but uncompliant to the Time_Triggered_Communication Design pattern;
  (3)compliant_rav: an architecture compliant to the Ravenscar Design pattern;
  (4)uncompliant_rav: an architecture close but uncompliant to the Ravenscar Design pattern;
  (5)compliant_unpl: an architecture compliant to the Time_Triggered_Communication Design pattern;
  (6)uncompliant_unpl: an architecture close but uncompliant to the Unplugged Design pattern;
  (7)uncompliant_env: an architecture with a multi core processor environment
  (8)uncompliant_buff: an architecture close but uncompliant to the Time_Triggered_Communication Design pattern (there is an extra buffer).
  
  The result and the xml representation of the architecture are displayed if the verbose mode is asked (-v). The result is stored in a text file whom name is given by the user.
  
  Here is an example of command line to launch the program:
  
  ./select_feasibility_test_simple_from_xml -v -a 1 -o result1.txt
  
  Just change the architecture number to try the different cases. As any cheddar tool, the list of possible arguments can be displayed by the '-u' argument.

In this folder, there are also some XML examples that show various features of Cheddar :

• arinc653_cyclic_hierarchical.xmlv3 : this is an example of hierarchical scheduling of several address space/partition. Each address space est run for a duration corresponding to its scheduler quantum and the set of addresss spaces are activated in a fixed order.
  
• arinc653_offline_hierarchical.xmlv3 : same scheduling as above excepts that address spaces are now activated according to a offline scheduling provided by a Cheddar event table (table supposed to be either previously computed or edited by hand).
  
• arinc653_fixed_priority_hierarchical.xmlv3 : To be implemented. Should provide a fixed priority scheduling of the address spaces. Address space execution time should be expressed by their capacity.
  
• event_table_of_arinc653_cyclic_hierarchical.xml : this is an example of event table produced from an ADL model (an architecture model which models an ARINC 653 systems).
  
• arinc653_partition_activation_table.xml : this file is an example of ARINC 653 partition off line scheduling (which is actually a Cheddar event table). This file is read by Cheddar to produce a task scheduling wwith an HIERARCHICAL_OFFLINE_SCHEDULER
  
• arinc653_tsp.xml : this file is an example of ARINC 652 TSP produced by Cheddar from a ADL model. This is actually a Cheddar evant table but formatted as ARINC 653 expects it.