1

FESA architecture v.1.0Framework Configuration

& Data-entry Tool5th December 2003

2

Outline

1. Controlling and refining the framework2. Code generation3. Data-files and populating the shared

memory4. The configuration tool layout5. Advanced uses of the tool and wizards6. Starting the tool and demo

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

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

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

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

Per-class definitions

XSL

tem

plat

es

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

The generated libraryThe library is deployed under /user/fesa/config It is version dependant

V1 has different library to V2The library will be automatically (re)compiled

when the user ‘make’s their instrumentThe .a will be ultimately linked with the final

executables to complete the refinement of the framework

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

The config tool in action

Selected panel areaThe 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

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

Inheritance and interfacesFESARef

MySubClass

MyClass

AnInterface1 AnInterface2

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

basedOn

basedOnInterface basedOnInterface

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

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

To the demo…