Future of DeviceAccess Front-End Software

In the GSI facility, a reasonable amount of DeviceAccess software is installed in the front-end layer, running nearly exclusively on VME GµP /SE controllers. Based on proprietary hardware for the SEs and software tools running out of support (CORBA, compiler for 68k processor) one has to think of a major renovation.

In principle, there are some major alternatives:

• replace the installed device hardware by devices, with their FESA-classes, which will be used in FAIR
• re-implement the front-end control in FESA
• port the existing DeviceAcces software to recent hardware, e.g. SCUs, and replace outdated components like CORBA

Alternative one looks realistic only for a small part of the installations, complete replacement would be far too costly in money and manpower. This leaves, for the majority of devices, the other two options. These two options are not strict exlusive: As an intermediate step they can be mixed:

• port parts of the DeviceAccess software which implement a complex logic, or which are voluminous, to a nowadays software environment on a recent hardware platform and embed these parts into a shell which fits to the FAIR control system.

Re-Implement in FESA

For devices which have to be supported in future too, best solution in terms of long-time support would be to re-write the frond-end control in FESA. For a first impression on the effort needed for re-writig in FESA in the attached libre office spreadshead eq-mods.ods (also see as PDF), the equipment models are listed. The columns labeled 'effort, man-month' gives an estimated effort for transfering functionality to FESA. Effort is given in man-month, calculated as net-time (if work is done exclusively, without additional activity). When it looks reasonable that the device hardware is replaced, effort is listed in the sub-column 'replace?', otherwise in the sub-column 'convert'.

Total effort is about 30 man months. Assuming, in a year a person is absent for 2 months for vacation, sickness and other reasons, this means three years of total work (without any disruption!). Of course, this is not based on a detailed analysis but should give the order of magnitude.

Port to Recent Hardware/Software

In terms of implementing equipment specific handling it would be easier to keep the existing software and port it to new platforms. However, this puts a load on the front-end software support since then two systems have to be maintained for quite a long time.

Integrate Ported Parts into a FAIR-Compatible Shell

During the long evolution of the DeviceAccess control system, many specific aspects where considered in the control systems. This imlpies assuring strict time constrains as well as handling of a wide range of equipment specific characteristics and constraints. It would be worth to keep such parts by porting to recent environments: This would save quite an amount of time to implement all such features newly. Nevertheless from higher levels of the control systems (such as applications) access to front-ends must be possible the same way as for 'normal' FESA devices.

Access to such recycled parts of the DeviceAccess control system can be provided by special gateways, or by embedding such parts into newly developed FESA-classes which provide the RDA interface. This was done already once: When the DeviceAccess (PowerPC) GµP software replaced the MOPS/NetMan (68020) GµP software, the existing device specific USRs could be integrated nearly unchanged. Especially the implemented logic could be kept unchanged, adaptation often was only done by modelling the function call interface. However, for integration iinto the FAIR control system, it has to be be checked whether the existing USRs should be re-used. Connection can also bedone, as an example, by directly accessing the DPR.