Purpose

FESA properties are the access interface to control and monitor the equipment in the accelerator. There are many ways how properties can be defined for a given piece of equipment. This page presents some recommondations and hints how to define the property outline of equipment.

In the simplest way, properties only pass commands and data directly, as is required respectively provided by the equipment. To give a simple example: In the existing GSI control system equipment is switched on and off by two different commands on the GSI field bus. ON is assigned to the field bus command code 2, and OFF is asigned to the command code 3. A hypothetical property to switch the equipment on or off may be implemented such that it requires the field bus command code (that is 2 or 3) and passes it to the equipment. However, more suitable is to model on- and off-states by values 0 for OFF and 1 for ON. The property then takes 0 or 1 as inoput data and internally transfers these data to the commands 2 or 3 to be sent on the field bus.

The example ist obvious. However, it may demonstrate how an adequate design of the proprties can ease operation of the devices when propeties present the device in a way which is intuitive for users.

Aim of Equipment Modeling

Properties should abstract the equipment's specifics. They should model the equipment's features and data in a way which reflects the functionality of the equipment. Data should be transferred to technical and physical meaning. Properties should present the handling of the equipment in a way which gives some information on how to use the equipment, or at least gives some hints to remember the handling of the equipment.

All of the given recommondations must not be taken strictly. In every case it must be analysed carefully how the general aim (present the equipment's capabilities as clear and intuitive as possible) is achieved best.

Recommondations

Few Properties with many value items versus many properties with few value items?

FESA supports combining many setting data fields in one property and selecting which ones are supplied when calling the property. In principle, all setting data can be integrated into one single property. However, the user then must take great care not to provide data to fields which are incompatible (or to use "partial setting"). On the other hand, for each data field a dedicated property could be used - this also would not support the aim of clarification.

Modeling the equipment has to balance using few Properties with many value items versus many properties with few value items. The recommondation is:

Data with related meaning and with similar functionality should be combined in one property

E. g.: Data to set up measurement parameters of a beam diagnostic device, like 'gain', 'range', 'integration time', should be combined in one property. The property may be named MeasurementSetup.

Different functionality requires separate properties

Non-related value items or different functionality should not be combined in one property, separate properties should be foreseen instead.

Examples:

.The command to start or stop a measurement in general should not be contained in the above mentioned property which sets up the measurement parameters. Handling start and stop schould be implemented in a separate property, which then handles both start and stop because these are related. The property may be named Measuring with fields Run or Stop.

To provide the state of the measuring process another property should be forseen, which may be called MeasuremenStatus, which may contain a field containing the set command (showing Run or Stop) and contains a field fo the state of the measurement process, containing values like Running, Stopped, InconsistSetting, Aborted, or others.

Property Setting

If there is a preferred way to bring the equipment in a well defined state for a supposed beam by supplying a set of data fields, a property called Setting. should be provided which contains value items to set these all these data fields.

Property Acquisition

If a device provides a set of measured data, which are generally used for routine operation, a property Acquision should be foreseen to provided theses data. The property Acquision should also contain the setting values to which the device has to be set to return the set of acquision data.

Properties should have meaningful names

The name of a property should reflect what the property does. If it is obvious that the property constitued setter and getter methods (provides data or reads data), the name may represent the meaning of the data (as with measurementSetup).

If a property constitutes not only data exchange, but also incorporates some action, the name of the property should reflect also the activity which is started by calling the property. E.g. a property name like Calibrate for a property which starts a calibration which is described by a value-item calibrationMode is preferred. Using a name like CalibrationMode for the property would not reflect that not only the mode is set but additionally the calibration is started.

Avoid separate states when inconsistent combinations are possible

Avoid properties where the combination of their data may be invalid. Assume a power supply which can be switched to different loads. Don't implement the switching by several value-items load1, load2, load3, ..., each with values on/off). What happens then when load1 as well as load2 are switched on, but at connection is possible to one load only?

Use a general load value item with the data like none, load1, load2, ... instead.

Appendix

The attached guideline from CERN ( CERN Guideline and Conventions for Properties) may give additional hints for design of the properties.