The ALMA Common Software (ACS) is an application framework designed to provide a common and homogeneous software architecture and infrastructure, spanning the end to end needs of an Astronomical observatory, from the Telescope Control system to high-level data flow management. ACS offers, at the lower level, several basic services needed for object-oriented distributed computing like transparent remote object invocation, object deployment and location, distributed error, alarm handling, logging and events. On top of this it provides an application architecture based on the Component/Container paradigm that fosters sharing and reusing of software components. Although developed for the ALMA project, ACS is now used by several other projects worldwide, among which the Italian Sardinia Radio Telescope (SRT). Besides, there is an active community that shares ideas, concepts and actual software components. Major drivers for this diffusion were the choice of adopting the LGPL public license and the adoption of CORBA, a free but reliable and widely used middleware software. In this paper we present an overview of the main features of ACS, emphasizing in particular the role of INAF-OAT in this project.

Injection-involved synchronization timing system must provide synchronization triggers and clocks with the jitter values in the range of few tens of ps. A well-thought-out system-level design approach was necessary, splitting a design into several sub-modules, each addressing the specific synchronization issue. Tight synchronization between the unrelated RF signal and external trigger is based on a PLL phase-shifted over-sampling technique. Beam-monitoring instrumentation synchronization is also handled. An emphasis was put into a design, offering an installation without calibration. Utilizing state-of-the art FPGA circuits we designed a purely digital system, without analogue components (i.e. delay lines) that would require a time-consuming calibration and lead to increasing jitter for long delay ranges. Finally, regardless of its complexity the timing solution has to provide seamless integration into the accelerator facility. To leverage the performance, offered by a dedicated state-of- the-art HW, with flexibility, offered by a SW solution, we used a standard device for peripheral CS integration, based on an embedded processor running OS - a part of a microIOC family of products.

The ALMA Common Software (ACS) provides the software infrastructure used by ALMA and by several other telescope projects, thanks also to the choice of adopting the LGPL public license. ACS is a set of application frameworks providing the basic services needed for object oriented distributed computing. Among these are transparent remote object invocation, object deployment and location based on a container/component model, distributed error, alarm handling, logging and events. ACS is based on CORBA and built on top of free CORBA implementations. Free software is extensively used wherever possible. The general architecture of ACS was presented at SPIE 2002. ACS has been under development for 6 years and it is midway through its development life. Many applications have been written using ACS; the ALMA test facility, APEX and other telescopes are running systems based on ACS. This is therefore a good time to look back and see what have been until now the strong and the weak points of ACS in terms of architecture and implementation. In this perspective, it is very important to analyze the applications based on ACS, the feedback received by the users and the impact that this feedback has had on the development of ACS itself, by favoring the development of some features with respect to others. The purpose of this paper is to describe the results of this analysis and discuss what we would like to do in order to extend and improve ACS in the coming years, in particular to make application development easier and more efficient.

Atomic blocks allow programmers to delimit sections of code as 'atomic', leaving the language's implementation to enforce atomicity. Existing work has shown how to implement atomic blocks over word-based transactional memory that provides scalable multi-processor performance without requiring changes to the basic structure of objects in the heap. However, these implementations perform poorly because they interpose on all accesses to shared memory in the atomic block, redirecting updates to a thread-private log which must be searched by reads in the block and later reconciled with the heap when leaving the block.This paper takes a four-pronged approach to improving performance: (1) we introduce a new 'direct access' implementation that avoids searching thread-private logs, (2) we develop compiler optimizations to reduce the amount of logging (e.g. when a thread accesses the same data repeatedly in an atomic block), (3) we use runtime filtering to detect duplicate log entries that are missed statically, and (4) we present a series of GC-time techniques to compact the logs generated by long-running atomic blocks.Our implementation supports short-running scalable concurrent benchmarks with less than 50\% overhead over a non-thread-safe baseline. We support long atomic blocks containing millions of shared memory accesses with a 2.5-4.5x slowdown.

The word Cosylab stands for Control System Laboratory, which implies that new developments and technologies are at the centre of our efforts, as we have proven in previous conferences. In this article, we present the highlights of our new developments since the last PCaPAC conference and how they fit together as a whole. The main guideline is simplification for the user, be it the control system developer or the user of the control system. In order to achieve this, we have developed and improved such diverse components as a series of generic client applications, a native Java implementation of the EPICS channel access protocol, implemented load balancing and failover in ACS, replaced an expensive commercial tool with Visual DCT and developed a plug & play control system box with an embedded computer for integrating external devices. The presentation will conclude with successful examples of our technology transfer into other fields of computing and information technologies, such as Geographic Information Systems (GIS), which is becoming a new challenging field for Cosylab.

The control system at ANKA, the 2.5 GeV synchrotron light source in Karlsruhe, has been designed and built with CORBA distributed remote objects. The whole control system was divided in three major layers: device drivers and fieldbus, CORBA device servers and finally Java GUI libraries. In the year 2002 the layer with device servers was successfully replaced with ACS version 1.1 ( ANKA Advanced Control System, ICALEPCS’03 ). The smooth transition proved that the design of ANKA’s control system with object-oriented architecture was well chosen. The ACS is CORBA based middleware developed in cooperation with ESO. The ACS framework is build on top of CORBA which hides the complexity of the CORBA middleware and other libraries. In addition ACS provides an implementation of a coherent set of design patterns and services that makes the whole control system software uniform and maintainable. ANKA was one of the first real-life installation of ACS. Since then ACS has experienced a fast and substantial evolution, which was driven by the requirements coming from users. In the year 2005 ANKA has decided to upgrade their ACS 1.1 installation to the latest stable ACS release. With this transition ANKA will benefit from the improved performance and stability and also the integration of new hardware into ANKA control system will be easier. Since ACS version 1.1 it has been introduced a new DevIO abstract interface which simplifies writing device drivers and servers. The upgrade work is in progress.

The Experimental Physics and Industrial Control System (EPICS) (1) is a widely used particle accelerators control system. Being a product of a large scientific based collaboration, the required knowledge and experience to start working with EPICS represents a significant entry barrier. Furthermore, the traditional VME hardware is very costly for small, dedicated applications. By introducing a product which serves as a plug&play, PC- based Input Output Controller (IOC) and provides effortless integration in the control system, the microIOC together with its driver set and configuration software signals a significant step forward in making EPICS more user-friendly and accessible. microIOC, a package consisting of industrial hardware, popular control system (apart from EPICS, we can offer also variations with ACS or TINE) and Cosylab's significant software contribution, is ideal for integration of "problematic" protocol based devices (serial and GPIB) where there is important to isolate such devices from interfering with the rest of the control system. In addition, microIOC offers a wide range of communication and I/O modules and is currently installed at the Swiss Light Source and will also be used for the Australian Synchrotron Project.

The Experimental Physics and Industrial Control System (EPICS) [1] is a widely used particle accelerators control system. Being a product of a large scientific based collaboration, the required knowledge and experience to start working with EPICS represents a significant entry barrier. Furthermore, the traditional VME hardware is very costly for small, dedicated applications. By introducing a product which serves as a plug&play, PCbased Input Output Controller (IOC) and provides effortless integration in the control system, the microIOC together with its driver set and configuration software signals a significant step forward in making EPICS more user-friendly and accessible. microIOC, a package consisting of industrial hardware, popular control system (apart from EPICS, we can offer also variations with ACS or TINE) and Cosylab's significant software contribution, is ideal for integration of “problematic” protocol based devices (serial and GPIB) where there is important to isolate such devices from interfering with the rest of the control system. In addition, microIOC offers a wide range of communication and I/O modules and is currently installed at the Swiss Light Source and will also be used for the Australian Synchrotron Project.

Frequently, accelerator facilities make use of products and services offered by the industry. This paper's focus is on such outsourcing of control system hardware and soft- ware. Firstly, an attempt is made to explain the facility's motivation for seeking outside help, which is typically due to lack of resources, technology or knowledge. Then, the risks of outsourcing are enumerated. To mitigate them, the industrial partner should have not only the adequate techni- cal expertise, but also a reliable, yet agile management and quality assurance process that meets the facility's expecta- tions, schedule, budget constraints, maintenance and sup- port needs. Finally, Cosylab's business model is presented, designed to provide lasting open-source solutions that help not only a single facility, but the entire community.

The ALMA Common Software (ACS) is a set of application frameworks built on top of CORBA. It provides a common software infrastructure to all partners in the ALMA collaboration. The usage of ACS extends from high-level applications such as the Observation Preparation Tool [7] that will run on the desk of astronomers, down to the Control Software [6] domain. The purpose of ACS is twofold: from a system perspective, it provides the implementation of a coherent set of design patterns and services that will make the whole ALMA software [1] uniform and maintainable; from the perspective of an ALMA developer, it provides a friendly programming environment in which the complexity of the CORBA middleware and other libraries is hidden and coding is drastically reduced. The evolution of ACS is driven by a long term development plan, however on the 6-months release cycle the plan is adjusted based on incoming requests from ALMA subsystem development teams. ACS was presented at SPIE 2002[2]. In the two years since then, the core services provided by ACS have been extended, while the coverage of the application framework has been increased to satisfy the needs of high-level and data flow applications. ACS is available under the LGPL public license. The patterns implemented and the services provided can be of use also outside the astronomical community; several projects have already shown their interest in ACS. This paper presents the status of ACS and the progress over the last two years. Emphasis is placed on showing how requests from ACS users have driven the selection of new features.

Frequently, accelerator facilities make use of products and services offered by the industry. This paper’s focus is on such outsourcing of control system hardware and software. Firstly, an attempt is made to explain the facility’s motivation for seeking outside help, which is typically due to lack of resources, technology or knowledge. Then, the risks of outsourcing are enumerated. To mitigate them, the industrial partner should have not only the adequate technical expertise, but also a reliable, yet agile management and quality assurance process that meets the facility’s expectations, schedule, budget constraints, maintenance and support needs. Finally, Cosylab’s business model is presented, designed to provide lasting open-source solutions that help not only a single facility, but the entire community.

Large experimental facilities, like telescopes and focal plane instrumentation in the astronomical domain, are becoming more and more complex and expensive, as well as control systems for managing such instruments. The general trend, as can be learned by realizations carried out in the most recent years, clearly drives to most cost-effective solutions: widespread, stable standards in the software field, COTS (commercial off-the-shelf) components and industry standards in the hardware field. Therefore a new generation of control system products needs to be developed, in order to help the scientific community to minimize the cost and efforts required for maintenance and control of their facilities. In the spirit of the aforementioned requirements and to provide a low-cost software and hardware environment we present a working prototype of a control system, based on RTAI Linux and on ACS (Advanced Control System) framework ported to an embedded platform. The hardware has been chosen among COTS components: a PC/104+ platform equipped with a PMAC2A motion controller card and a commercial StrongARM single board controller. In this way we achieved a very powerful, inexpensive and robust real-time control system which can be used as a general purpose building block in the design of new instruments and could also be proposed as a standard in the field.

One of the important tasks of exception handling is to restore program state and invariants. Studies suggest that this is often done incorrectly. We introduce a new language construct that integrates automated memory recovery with exception handling. When an exception occurs, memory can be automatically restored to its previous state. We also provide a mechanism for applications to extend the automatic recovery mechanism with callbacks for restoring the state of external resources. We describe a logging-based implementation and evaluate its effect on performance. The implementation imposes no overhead on parts of the code that do not make use of this feature.

The ACS is a CORBA-based framework for the development of Control Systems and higher level data flow and coordination applications. It is used to develop the ALMA software and in particular the ALMA Control System. It currently runs in the ALMA Test Interferometer, in the APEX radiotelescope and in the accelerator ANKA in Karlsruhe. More about ACS status and developments can be found in the article by G. Chiozzi [1]. This paper provides an overview and description of ACS features. ACS uses several standard CORBA services such as notification service, naming service, interface repository and implementation repository. ACS hides all details of the underlying mechanisms, which use many complex features of CORBA, queuing, asynchronous communication, thread pooling, life-cycle management, etc. In addition, ACS provides a powerful XML-based configuration database, synchronous and asynchronous communication, configurable monitors and alarms that automatically reconnect after a server crash, run-time name/location resolution, archiving, error system and logging system. Any logical or physical device (e.g. power supply) in a control system is represented by a component. Component contains properties - entities that can be monitored and controlled, and characteristics which contain static data, such as name, units or description. Component management is handled by the ACS Component/Container model. In this simple model, Containers manage the lifecycle of Components with the help of a centralized Manager. The Component/Container model is language and platform independent and the Manager is capable of deploying, manage the lifecycle and locate Components in appropriate Containers written in C++, Java and Python. Containers provide Components with a very simple way to access common centralized services. Clients written in any CORBA-aware language can access these Containers and Components while the implementation of the servant side in any other of these languages would be easy. The Container also supports transparent XML serialization of complex data entities (like a complete Observing Proposal or an Observing Script) through CORBA. This capability is very important to allow a smooth data flow from high level software down to the Control System. ACS comes with all necessary generic GUI applications and tools for management, display of logs and alarms and a generic object explorer, which discovers all CORBA objects, their attributes and commands at runtime and allows the user to invoke any command. C++ is the main language for the development of core Control System DOs and for real time applications. Work is being done to port ACS to Real Time Linux. Coordination application, clients, GUIs and general higher level applications are written in Java and can run on any JVM-enabled platform. The Java-ACS subset is therefore available as a light separate package that can be installed on any platform where Java is available. In C++, ACS uses the free ORB TAO, which is based on the operating system abstraction platform ACE, ACS has been ported to Windows, Linux, Solaris and VxWorks. On the Java side, JacORB is used. Python clients are based on OmniORB. Accompanying this article, a live demo of ACS will be presented at the conference.