I'm working in the LUCIFER project since 2002. From the very beginning of the project, I was significantly involved in the control software development. To develop one of the first instrument control softwares that is entirely based on Java and to use a multi-tier distributed architecture are the most important decisions I made. In addition to the definition and design of the service architecture, I implemented many of the frameworks and services, too. Together with a small team of post-docs and students, we are currently preparing the software to allow efficient binocular observations with both instruments. This requires several changes to software parts, which have been developed by former members of the software team as a temporary solution for LUCIFER 1.

Instrument:

LBT NIR Spectroscopic Utility with Camera and Integral Field Unit for Extragalactic Research (LUCIFER) is a pair of NIR spectrographs and imagers with multiple observation modes. One of the first presentations of the LUCIFER project was given 1999. In (2008/2009), 10 years later, the first instrument was installed at the telescope and ready for scientific use. Both instruments comprise the NIR equipment of the LBT, covering the wavelengths between 0.85μm and 2.5μm. Depending on the instrument setup selected, NIR imaging can be done by using the 2,048x2,048-pixel Rockwell HAWAII-2 detector. The field of view of LUCIFER is 4'x4' in seeing- and 30"x30" in diffraction-limited observation mode. Combined with the three internal camera optics LUCIFER offers a spatial resolutions of 0.25", 0.12", and 0.015" per detector element. Other instrument setups allow long-slit and MOS with resolutions of 5,000 to 10,000 in seeing limited and 40,000 in diffraction limited mode, respectively. These multiple observation modes make LUCIFER the so called Swiss army knife of the LBT. In order to reduce the thermal interference of the instrument, the LUCIFER mechanics and optics are placed in a cryostat. As other infrared instruments this cryostat is evacuated and cooled down to temperatures of 60-70K. Because of this cooling in the majority of cases NIR instruments are more costly and complicated than optical ones. The LUCIFER cryostat is 1.6m high and has a diameter of 1.6m and is one of the largest cryostats used in astronomical applications.

Both LUCIFER instruments are built by a collaboration of five German institutes. The LSW(Heidelberg) is the head institute of this consortium and responsible for project management and coordination of the different partners. The mechanical and optical instrument design as well as the system integration and testing was done by the LSW. This design process of the LUCIFER hardware was supported by the FHTG in Mannheim. The robot mechanism that exchanges user-defined masks in the LUCIFER instrument was designed and built by the MPE in Garching. This most critical part allows multi-object spectroscopy. Another partner in Heidelberg, the MPIA, contributed the instrument control electronics, the detector and the cryo-design. The AIRUB is responsible for developing the LUCIFER instrument control software. As head of the software group in Bochum, I'm responsible for this control software.

Control Software:

Due to the cutting edge design of the LUCIFER instrument the control software is unique and is developed as a prototype. In the LUCIFER project a simple and flexible development process was chosen. The software architecture of the LUCIFER Control Software Package (LCSP) was designed to be as simple as possible and at the same time very flexible. There are many arguments for lightweight software architectures and against heavyweight enterprise solutions, especially when working in a small team.

Multi-tier client-server and service-oriented architectures (SOAs) are examples of extremely effective design patterns. Even though SOAs get out of style, individual services provide an easy way to separate tasks, to increase abstraction and reusability, to allow autonomous execution and to encapsule complex algorithms as well as data structures. A typical example of SOA are modern UNIX-like operation systems that gain stability with independently start-/stoppable daemons.

A multi-tier architecture allows to hide complexity within a tier as well as to provide simple and powerful functions to services of a higher tier. This proven concept was applied in the development of the high level service architecture. A distributed system was chosen to increase scalability and interoperability of the software. The individual services are grouped into four tiers, the System Tier, the Control Tier, the Instrument Tier and the Operation Tier. See image on the right.

The System Tier contains all frameworks to run and control a distributed system, to allow central configuration management, persistent storage of data in a database and message generation in order to track the state of the system. Beside the basic services for messages and configuration management, frameworks to implement internationalisation and resource bundling as well as tools to improve source documentation and message database-mining are included in the System Tier.

In the Control Tier the hardware-software interaction is reflected. Therefore an RS232 communication framework is used in each of the hardware controlling services. These services are grouped in environment supervising services and into services that communicate with the motion control electronics. As a central logging mechanism this tier contains a service that tracks the instrument state. All hardware interacting services notify this logging service. The detector readout software GEIRS by Clemens Storz and an ICE interface to the telescope by Jos'e Borelli are also part of this tier.

The next tier is the Instrument Tier. This tier is responsible for hiding the complexity of the motion logics needed to set up the opto-mechanical components of the instrument. Therefore this tier is based on the usage of the hardware communication provided by the Control Tier. As a central part of this tier the sequence execution framework provides easy composing and execution of complex motion sequences. This tier is fundamental to an efficient usage of the LUCIFER instrument.

As the topmost tier the Operation Tier contains all services needed to operate the instrument. This includes the coordination of the services of the Instrument Tier and the supervision of the instrument environment as well as the interaction with the external software packages of the readout and telescope control software. The GUI used to grant engineering access as well as an observations scripting mechanism are another part of this tier.

When developing software the time to test the software is often insufficient. Especially when developing a control software that interacts with external hardware a discrepancy in available and required test time can be discovered. The tests of the communication with the electronics and the software interaction with movable elements demand the presence of a correctly working hardware. Tests cannot start until hardware development is finished. Nonetheless in many projects everyone expects a fully functional control software at the moment of hardware completion. The physical tests of the hardware and the likewise tests of the software-hardware interaction are often regarded contrarily. Of course software can be created in parallel to the hardware but the tests of the integrated system are still mandatory and the required time needs to be covered by the project schedules. To get out of this time dilemma in the LUCIFER project and to reduce the needed post-integration test time a virtual instrument was built. See image and video on the right.