Complex systems engineering for the Large Synoptic Survey Telescope

The Large Synoptic Survey Telescope (LSST)^1–3 is a planned 8.4m-diameter wide-field telescope that will be located on the Cerro Pachón mountain in Chile. It will have three mirrors, a 3 gigapixel camera, and a petascale data processing and archiving system. In addition to the LSST observatory in Chile (see Figure 1), the data processing system will be located at the National Center for Super Computing Applications (University of Illinois) and the operations headquarters will be in Tucson, Arizona. The highly automated observatory therefore presents a complex hardware-software ‘system of systems.’ With the LSST, it is the aim to conduct a multi-wavelength and multi-epoch imaging survey of the southern sky (about 20,000 square degrees) over a period of 10 years. This survey will be conducted by making a series ‘field visits.’ Each visit will consist of two back-to-back 15s exposures—lasting for a total average of 39s—that will allow the entire visible sky above 30° to be observed every few nights. This fast cadence of survey observations requires that the entire LSST system be highly coordinated and automated, which involves complex interactions between the different distributed centers and systems.

Figure 1. Rendering of the Large Synoptic Survey Telescope (LSST) summit facility (center) on Cerro Pachón, along with the calibration telescope (right). The insets show the base facility (lower left) and a cutaway of the dome, showing the 8.4m telescope (lower right).

Figure 2. Organization of the LSST system architecture model, which is used to facilitate various systems engineering analyses and documentation needs.

Systems engineering is the discipline of managing technical complexity.⁴ To capture requirements, specifications, interfaces, and system behavior, separate methods and tools have traditionally been employed in systems engineering projects for astronomy applications. This approach, however, has often led to the discovery of design or behavior incompatibilities late in a project lifecycle, i.e., during integration and testing, or commissioning. Model-based systems engineering can be used instead to combine all elements of system engineering into an integrated environment. With this approach the complex interconnectivity of a system can be developed and documented.

It is the role of our LSST systems engineering team to develop and manage the project's requirements analysis. We must be able to understand the functional behavior and interactions required in the system, and accurately define and detail the interfaces. To bring the LSST to fruition in an efficient way, we are responsible for keeping the technical management of the project and the system design effort coordinated across several groups and disciplines. We have therefore developed our ‘system architecture model’ as a core principle for the LSST systems engineering effort.⁵

We implemented our system architecture model⁶ using the Systems Modeling Language (SysML),⁷ which is a graphical modeling language used to describe and express relationships of systems that consist of hardware, software, and human interactions. We used the Enterprise Architect⁸ to organize our model along three interrelated viewpoints (see Figure 2). The first viewpoint is a requirements engineering view that captures system requirements and use cases, the second is a system analysis view that is used to define the logical composition and high-level functional behavior, and the third is a system design view that captures the design elements and their interfaces. We maintain our model on a server that can be remotely accessed by our whole team.

We use the elements of the model and the linking relationships to create a database that is used for LSST documentation needs and systems engineering analyses. We have used the model to generate all of the LSST system level requirements and interface control documents (25 total), which include about 1400 requirements. We have also used the model to conduct an integrity and validation analysis. This involves querying the database to ensure each requirement has a ‘satisfy’ relationship to both a structural block and a behavioral element (activity or sequence) in either the logical or physical view, and that the behavioral element is allocated to a structural block. By maintaining this model integrity, we ensure design consistency and can achieve full traceability throughout the LSST requirements hierarchy.

We have also used our system architecture model to help develop the LSST operations plan. We used SysML ‘use cases’ to capture the operational functionality that is required across the LSST system. We developed about 300 use cases, and for each one we captured the basic course of action, its frequency, duration, and the operational personnel required. We subsequently used these use cases to develop a detailed operations staffing plan and to refine the system requirements and design.

A new system architecture model has been designed and implemented for the complex LSST system engineering effort. Our rigorous technique can be used to determine key system design, interface, and behavioral elements at all levels, and to discover significant flaws. Construction of the LSST is due to begin in July 2014, and we are extending our modeling approach to include tests, activities, and sequences for verification of the system requirements and behavior. We will use the results of this modeling to develop detailed plans for the integration and commissioning phase of the observatory.