Gemini North Observatory successfully began nighttime remote operations from the Hilo Base Facility control room in November 2015. The implementation of the Gemini North Base Facility Operations (BFO) products was a great learning experience for many of our employees, including the author of this paper, the BFO Systems Engineer.
In this paper we focus on the tailored Systems Engineering processes used for the project, the various software tools used in project support, and finally discuss the lessons learned from the Gemini North implementation. This experience and the lessons learned will be used both to aid our implementation of the Gemini South BFO in 2016, and in future technical projects at Gemini Observatory.
Gemini’s Base Facilities Operations (BFO) Project provided the capabilities to perform routine nighttime operations without anyone on the summit. The expected benefits were to achieve money savings and to become an enabler of the future development of remote operations.
The project was executed using a tailored version of Prince2 project management methodology.
It was schedule driven and managing it demanded flexibility and creativity to produce what was needed, taking into consideration all the constraints present at the time: Time available to implement BFO at Gemini North (GN), two years.
The project had to be done in a matrix resources environment.
There were only three resources assigned exclusively to BFO.
The implementation of new capabilities had to be done without disrupting operations.
And we needed to succeed, introducing the new operational model that implied Telescope and instrumentation Operators (Science Operations Specialists - SOS) relying on technology to assess summit conditions.
To meet schedule we created a large number of concurrent smaller projects called Work Packages (WP).
To be reassured that we would successfully implement BFO, we initially spent a good portion of time and effort, collecting and learning about user’s needs. This was done through close interaction with SOSs, Observers, Engineers and Technicians.
Once we had a clear understanding of the requirements, we took the approach of implementing the "bare minimum" necessary technology that would meet them and that would be maintainable in the long term.
Another key element was the introduction of the "gradual descent" concept. In this, we increasingly provided tools to the SOSs and Observers to prevent them from going outside the control room during nighttime operations, giving them the opportunity of familiarizing themselves with the new tools over a time span of several months. Also, by using these tools at an early stage, Engineers and Technicians had more time for debugging, problem fixing and systems usage and servicing training as well.
The aim of the Gemini Observatory’s Base Facilities Project is to provide the capabilities to perform routine night time operations with both telescopes and their instruments from their respective base facilities without anyone present at the summit. Tightening budget constraints prompted this project as both a means to save money and an opportunity to move toward increasing remote operations in the future.
We successfully moved Gemini North nighttime operation to our base facility in Hawaii in Nov., 2015. This is the first 8mclass telescope to completely move night time operations to base facility. We are currently working on implementing BFO to Gemini South.
Key challenges for this project include: (1) This is a schedule driven project. We have to implement the new capabilities by the end of 2015 for Gemini North and end of 2016 for Gemini South. (2) The resources are limited and shared with operations which has the higher priority than our project. (3) Managing parallel work within the project. (4) Testing, commissioning and introducing new tools to operational systems without adding significant disruptions to nightly operations. (5) Staff buying to the new operational model. (6) The staff involved in the project are spread on two locations separated by 10,000km, seven time zones away from each other. To overcome these challenges, we applied two principles: "Bare Minimum" and "Gradual Descent". As a result, we successfully completed the project ahead of schedule at Gemini North Telescope. I will discuss how we managed the cultural and human aspects of the project through these concepts. The other management aspects will be presented by Gustavo Arriagada , the Project Manager of this project. For technical details, please see presentations from Andrew Serio  and Martin Cordova .
The Gemini Planet Imager (GPI) is a facility extreme-AO high-contrast instrument – optimized solely for study of faint companions – on the Gemini telescope. It combines a high-order MEMS AO system (1493 active actuators), an apodized pupil Lyot coronagraph, a high-accuracy IR post-coronagraph wavefront sensor, and a near-infrared integral field spectrograph. GPI incorporates several other novel features such as ultra-high quality optics, a spatially-filtered wavefront sensor, and new calibration techniques. GPI had first light in November 2013. This paper presnets results of first-light and performance verification and optimization and shows early science results including extrasolar planet spectra and polarimetric detection of the HR4696A disk. GPI is now achieving contrasts approaching 10-6 at 0.5” in 30 minute exposures.
The Gemini Planet Imager is a next-generation instrument for the direct detection and characterization of young warm exoplanets, designed to be an order of magnitude more sensitive than existing facilities. It combines a 1700-actuator adaptive optics system, an apodized-pupil Lyot coronagraph, a precision interferometric infrared wavefront sensor, and a integral field spectrograph. All hardware and software subsystems are now complete and undergoing integration and test at UC Santa Cruz. We will present test results on each subsystem and the results of end-to-end testing. In laboratory testing, GPI has achieved a raw contrast (without post-processing) of 10-6 5σ at 0.4”, and with multiwavelength speckle suppression, 2x10-7 at the same separation.
Gemini Observatory is using a new approach with instrument software that takes advantage of the strengths of our
instrument builders and at the same time better supports our own operational needs. A lightweight software library in
conjunction with modern agile software development methodologies is being used to ameliorate the problems
encountered with the development of the first and second-generation Gemini instruments.
Over the last two years, Gemini and the team constructing the software for the Gemini Planet Imager (GPI) have been
using an agile development process to implement the Gemini Instrument Application Interface (GIAPI) and the highlevel
control software for the GPI instrument. The GPI is being tested and exercised with the GIAPI, and this has
allowed us to perform early end-to-end testing of the instrument software. Early in 2009 for the first time in our
development history, we were able to move instrument mechanisms with Gemini software during early instrument
construction. As a result of this approach, we discovered and fixed software interface issues between Gemini and GPI.
Resolving these problems at this stage is simpler and less expensive than when the full instrument is completed.
GPI is currently approaching its integration and testing phase, which will occur in 2010. We expect that utilizing this
new approach will yield a more robust software implementation resulting in smoother instrument integration, testing,
and commissioning phases. In this paper we describe the key points of our approach and results of applying the new
instrument API approach together with agile development methodologies. The paper concludes with lessons learned and
suggestions for adapting agile approaches in other astronomy development projects.
Gemini Observatory is now developing its next generation of astronomical instruments, the Aspen instruments. These
new instruments are sophisticated and costly requiring large distributed, collaborative teams. Instrument software
groups often include experienced team members with existing mature code. Gemini has taken its experience from the
previous generation of instruments and current hardware and software technology to create an approach for developing
instrument software that takes advantage of the strengths of our instrument builders and our own operations needs. This
paper describes this new software approach that couples a lightweight infrastructure and software library with aspects of
modern agile software development. The Gemini Planet Imager instrument project, which is currently approaching its
critical design review, is used to demonstrate aspects of this approach. New facilities under development will face
similar issues in the future, and the approach presented here can be applied to other projects.
The key to a successful observing experience at Gemini is a well-prepared science program. The astronomer uses a
software application called the Gemini Observing Tool (OT) to fill in the specifics of instrument and telescope
configuration during the Phase 2 process. This task involves knowing several details about the Gemini instruments as
well as particularities of the telescope and the best way to observe with them. Unfortunately, reviewing these programs
can be tedious and error prone. Failure to catch a simple misconfiguration could lead to suboptimal science results or
even lost time at the telescope.
As part of an effort to make it easier for investigators to define the details of their programs and for the National Gemini
Offices and Gemini contact scientists to check and validate them, we have included an automatic program-checking
engine in the OT. The "Phase 2 Checker" continually examines the science program configuration as edits are made,
finds significant problems, and reports them to the user along with suggested corrections.
Since its introduction in the 2007B semester release of the Observing Tool, this feature has been very well received by
the community. This paper describes the software (infrastructure and user interface) that supports the Phase 2 Checker,
results of validating new and existing science programs, and future improvements we are currently considering.