1. 1 FESA architecture v.1.0 Framework Configuration & Data-entry Tool 5 th December 2003

2. 2 Outline 1.Controlling and refining the framework 2.Code generation 3.Data-files and populating the shared memory 4.The configuration tool layout 5.Advanced uses of the tool and wizards 6.Starting the tool and demo

3. 3 Terminology  Field  A description of a primitive data-type, including its name, type, min, max, default, etc…  Definition  A description of 1 or more related fields  Data partition  The realisation of a definition residing in shared memory  Data-file (data-store)  Configuration files, used to populate shared memory when a crate boots  XSL template  An XML document which when combined with the XML tree from the configuration tool, produces C,C++ or Java code

4. 4 Refining the framework  Data partitions definition  The framework automatically handles all 8 (currently) available data partitions  Every partition must exist but can be empty (except for obligatory index keys such as cycleName and deviceName)  Developer can define 0..n fields in each of the data partitions  The developer decides where the field will reside  Is the field per-cycle or global?  Should the field be visible to a single device, or to all devices?  A field’s attributes consists of

5. 5 Controlling the framework  Special framework definitions  Fields defined here don’t reside in shared memory  Nevertheless, they are applied to an XSL template to generate some part of the framework, or to create a placeholder in the framework  SOURCE – Lists private event sources your class will implement  HARDWARE – Lists hardware device types your class will use (see next Friday’s presentation)  RTTACTION – Lists the RT actions your class will implement  COMMACTION – Lists & describes ‘extra services’ your class will implement (implies definitions for filters/results composite types) Action List Filter (parameter in) Result (parameter out)

6. 6 What then?  Once the developer has tailored the framework to the instrument’s needs  Call the ‘Generate Library’ wizard  This will apply the XSL templates to the data partition definitions to generate  C header files which define structures etc  C code files that will handle the manipulation of data in shared memory  C++ wrapper files to handle shared memory (via the device class)  Java stubs that will handle client access to the data structures  The XSL templates will also be applied to the special framework definitions to produce  A device C++ class  The real-time and communications (actions) schedulers  Makefiles  … etc

7. 7 Per-class definitions XSL templates How code generation works XSLT Processor fesa_hpp_shm.xsl fesa_cpp_shm.xsl fesa_hpp_device.xsl fesa_cpp_device.xsl fesa_cpp_test.xsl fesa_c_superfunc.xsl fesa_h_superfunc.xsl fesa_makefile.xsl fesa_java_sstub.xsl fesa_js_docs.xsl REFIM1Shm.hpp REFIM1Shm.cpp REFIM1Device.hpp REFIM1Device.cpp REFIM1Test.cpp REFIM1.c REFIM1.h Makefile REFIM1.java REFIM1.js biconfig.dtd V1.xml Configuration tool Generated Files

8. 8 The generated library  The library is deployed under /user/fesa/config  It is version dependant  V1 has different library to V2  The library will be automatically (re)compiled when the user ‘make’s their instrument  The.a will be ultimately linked with the final executables to complete the refinement of the framework

9. 9 Populating the shared memory  The configuration tool makes a clear distinction between Data and Definition  Definitions are used to control and refine the framework  Data is used to configure the software once it has been deployed  Framework (FESA) data-files  Data-files which are loaded at runtime, to configure the framework  Event Dispatching  Alias Definitions  Global Device Declarations  Class’s declaration  Simulation Sequences  Partition (CLASS) data-files  Data-files that will be loaded into shared memory to populate the partitions’ fields you defined during framework refinement  If the partition is ordered by device, 1 file per-device  … otherwise one file for the entire partition (which could contain many cycles for example)

10. 10 The config tool in action Selected panel area The content of this area is controlled by the panel selection above Panel selection Allows the selection of a definition file, or a data file Wizards and general application control Application separated into 3 areas Many panels can be opened/closed

11. 11 Class ownership and user control  To allow FESA to scale, access to a class must be controlled  A class has 0 or more users and 1 or more owners  Users can access and modify data-files  Owners can access and modify data-files AND the definitions of the data partitions AND the special files that refine the framework  This means that you can allow only selected users to modify your class, while other users can modify the data-files.  Users and Owners are declared in the ‘class declaration’ when you create the class. It can be accessed later by a button in the tool.  Control is bypassed by FESA super-users!  A FESA super-user is an owner of the special FESA class  Super-users can do anything to everything!

12. 12 Inheritance and interfaces FESARefMySubClassMyClassAnInterface1AnInterface2  A class can be ‘basedOn’ another class  No limit to hierarchy, but…  A class can only be ‘basedOn’ ONE class  The class FESAREF must be at the top of the hierarchy  A class can’t redefine any part of it’s ‘basedOn’ class  Classes can have ‘basedOnInterfaces’  Same as basedOn classes but…  More than one interface can be defined  Re-declaration of array-types’ sizes is possible  As with user control, this is defined in the class declaration basedOn basedOnInterface

13. 13 Soft-keys and the wizards  In FESAREF, some fields are defined as Soft-Keys  The soft-keys in a partition, form a unique key  Eg. The partition DEVICE.USER.STORED has two soft-keys, cycleName and deviceName  When entering data, soft-keys cannot be modified  So you can’t enter or modify deviceName or cycleName for example  You can populate the data-files via the wizards however  Create a new device – device/cycleName are filled automatically depending on device’s timing domain  Update a device - cycleNames are updated to reflect the current events in device’s timing domain  Remove a device – All relevant entries in FESA files and ‘per-device’ files are removed

14. 14 Starting the tool…  Can be started from Linux  /user/fesa/tools/FESAApps  Or via web-start from windows  http://slwww/~pcrops/apps/fesatestapps.shtml

15. 15 To the demo…