Present GSI control system uses an in-house developed CORBA based middleware called IFC. For FAIR project that will be built on the GSI site, a new control system is foreseen. New devices that are being integrated into the control system will be developed in CERN's Front End Software Architecture (FESA). In this article, an IFC to FESA gateway will be presented. The gateway provides an intermediate layer that is able to talk to FESA device servers on one side and provide their functionality to existing IFC clients. The gateway will allow coexistence of FESA front-end implementations and existing GSI device servers and clients, providing a smooth transition path to the future FAIR front-end environment. New GSI and FAIR devices that will be implemented in FESA will have to match GSI standards for nomenclature and device modelling. Exact match of new devices is not possible due to different hardware and software architecture of the new system, therefore a gateway solution is required. The gateway can translate the complete device model, including conversion from FESA to IFC data types. INTRODUCTION The Facility for Antiproton and Ion Research (FAIR) will be built on the GSI site. The present GSI UNILAC and SIS18 accelerator ring will be used as a injector for new accelerator installation. FAIR facility will be operated in a multiplexed mode, meaning that multiple experiments will be supplied with several different ion types simultaneously in a similar way as in the old GSI accelerator. The existing control system at GSI is well adapted for the present needs, but due to technological requirements a new control system will be used for FAIR. For front end part of the control system CERN's FESA was chosen [1]. For the transition period, when new devices are implemented in FESA but old GSI installation and many clients in control room will still use IFC, an intermediate layer of software will be required which will act as a glue between new FESA device servers and old IFC clients and device servers as shown on figure 1. Figure 1: Coexistence of IFC clients and device servers and FESA device servers.

Every beamline is different, which makes it impossible to buy a control system off the shelf. Nevertheless well tested and customizable building blocks can be prepared, which are then put together according to customer requirements. Delivering a fully operational control system is not just software development, but also gathering specifications, writing documentation, testing the hardware and trimming the software on site. Based on the delivery of a number of working beamline control systems, this paper will prove that we have optimized all stages and can guarantee that the purchased control system will be delivered on time, will work according to specifications and will be properly documented. The customers can also count on support.

ACS (Advanced Control System) is a componentoriented infrastructure for distributed control systems. Components representing controlled devices or control logic can be deployed across host computers throughout the network. A central entity called the Manager is responsible for determining on which host a given component will reside. This centralized approach to deployment allows dynamic reconfiguration of the system, e.g., due to changes in requirements or as an automated response to failures within the system. In this article, the dependability and availability of an ACS based system is discussed, and future developments in the context of the European Union’s 6th Framework project Dependable Distributed Systems (DeDiSys) are outlined.

Cosylab has created Abeans, a Java™ API for easy development and deployment of Control System applications. Abeans is a result of a continuous five-year development process. It consists of visual and non-visual libraries that support retrieval of remote data, offer various graphical visualization components and provide commonly used application services. In collaboration with DESY, a data acquisition module was implemented to use the TINE control system, accessing its device servers, properties, their characteristics, history data and the TINE archive servers. Many new graphical components, such as charting components and tables, have been included and adapted for use in rapid application development tools. Some general-purpose applications, as well as prototypes of specific accelerator control applications were developed. The main benefits of Abeans at DESY are its portability, which allows running the same applications in all the different operating systems that are used at DESY, and the flexible deployment of the applications enabled by the Java™ Web Start technology. The system has been recently upgraded to allow remote access to the DESY control system using Web Services technology.

The entire CORBA communication layer at the syn- chrotron light source ANKA was efficiently upgraded to the next generation device servers, based on Advanced Control System (ACS). The old system, which was running since 2000, required an upgrade to a new version of com- mercial CORBA libraries. Instead of purchasing a costly li- cense, a decision was made to upgrade to open source TAO CORBA and ACS. The design of ACS is the next step in the evolution of the idea, which lays behind the old ANKA CS, a vision of a control system with distributed CORBA ob- jects for remotely controllable physical devices. The ACS, developed in cooperation with ESO, extended the old de- vice servers with improved management and debugging ca- pabilities and greatly improved the long time stability of servers on Windows NT machines. Adjustment to the new server interface was smooth and without major changes at the fieldbus and client side of the CS. This was possible due to modular object-oriented architecture at all control sys- tem layers and good design of interfaces for devices. The code of complex Java clients stayed practically the same, we only had to change the communication plug of Abeans, our core Java libraries. This has significantly reduced the upgrade time because all end-user Java applications re- mained visually and functionally unchanged. This is also of great value to the operators because no additional train- ing was required. Interfaces to LonWorks device drivers, which are based on functionality of devices, also remained unchanged. In a system with a large number of various de- vices we were able to keep the whole LonWorks fieldbus intact, we even used the same configuration database with the same set of installed drivers. The smoothness of the upgrade confirms that our developments were focused into the right direction. Now even those users are 100% satis- fied with the control system, who always had something to complain about.

Abeans is the next generation of Cosylab's Java based client framework for building control system applications. It has been ported, plugged to such different CS as those of DESY (TINE), SNS (EPICS) and GSI. At the moment we are working on the installations for ALMA project by ESO and for Data Acquisition group at JLab. Abeans consists of two parts, Abeans for control and CosyBeans. Abeans for control provide application services and the mechanisms that allow simple implementation of data flow between the local application and the remote control system. This task is realized in two layers. Firstly, Abeans define a model that is a layer of Java Beans components that represents controlled objects. Secondly, Abeans define a plug which is a driver layer, specific to a given model and an underlying communication system. In addition, Abeans provide several useful services: logging, exception handling, configuration and data resource loaders, authentication, and policy management. CosyBeans provide clear and consistent visualization of dynamic data with standardized presentation of alarms, monitors and connection status. In this article we present the basic concepts of Abeans and latest developments, such as the BACI model, developed for ESO, the possibility to write CosyBeans GUI components as JADE agents for JLab and AbeansDirectory, an Abeans service that is an implementation of JNDI DirContext. We continue by outlining some use cases where we show how these technical solutions help solve concrete problems the application programmer is facing in the real life. We will look at a generic application Object Explorer that is able to display and modify any value that is accessible by a given control system. This means that the same application can be used to explore TINE, EPICS or ACS CORBA based system. Second example will be a specialized panel that displays and controls values of a remote physical device. We will show that by using Abeans, the application developer just needs to take care of the user interface – by means of CosyBeans graphical displayers, he can construct a fully functional application in a visual editor without writing a single line of code, the lifecycle of remote entities and the installation of services is performed by the Abeans. As a third example, we will show how to make use of the Abeans when developing a complex application for machine physics that interacts with a large number of physical devices and depends heavily on the services provided by the framework.