1. Large Synoptic Survey Telescope (LSST)
  2. Observatory System Specifications
  3. LSE-30 v 5.1
  4. Latest Revision: April 10, 2015
  5. Change Record
    1. Table of Contents
  6. The LSST Observatory System Specifications
    1. Introduction and Scope
    2. Acronyms and Definitions of Terms
    3. Reference Documents
    4. Verb Usage
  7. The LSST Observatory System Specifications
    1. 1 System Composition and Constraints
      1. 1.1 Facilities
      2. 1.2 Sites
    2. 2 Common System Functions & Performance
      1. 2.1 Survey Scheduling and Management
      2. 2.2 System Control
      3. 2.3 System Monitoring & Diagnostics
      4. 2.4 System Maintenance
      5. 2.5 System Availability
      6. 2.6 System Time Reference
      7. 2.7 System Standards
    3. 3 Detailed Specifications
      1. 3.1 Science and Bulk Data
      2. 3.2 Optical System
      3. 3.3 System Throughput
      4. 3.4 Camera System
      5. 3.5 Photometric Calibration
      6. 1.1.1.1.1 Flat Fielding Allocations
    4. 1.1.1.2 Data Products fo r Photometric Calibration
      1. 3.6 System Timing and Dynamics
      2. 3.7 Education and Public Outreach

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval of the LSST Change Control Board.
1
Large Synoptic Survey Telescope (LSST)

Back to top


Observatory System Specifications
Charles F. Claver and the Systems Engineering Integrated Project Team

Back to top


LSE-30 v 5.1

Back to top


Latest Revision: April 10, 2015
This LSST document has been approved as a Content-Controlled Document. Its contents are subject to
configuration control and may not be changed, altered, or their provisions waived without prior
approval. If this document is changed or superseded, the new document will retain the Handle
designation shown above. The control is on the most recent digital document with this Handle in the
LSST digital archive and not printed versions.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
i

Back to top


Change Record
Version
Date
Description
Owner name
1
5/23/2011
Initial draft for configuration control. Review
comments and actions taken in this draft are found
in Document-­­11071.
Chuck Claver
2
5/26/2011
Updated type and clarifications per May 25, 2011
CCB meeting. Affected requirements: OSS-REQ-
0010, 0014, 0051, 0064, 0314, 0083, 0084, 0092,
0108, 0239, 0253, and 0259.
C. Claver
10/15/2012
LCR-88; changes OSS-REQ-0267 (page 95), the
system pixel noise from 10e- to 1.7e- per pixel visit.
C. Claver
10/15/2012
LCR-103; Establishes new requirements for
crosstalk amplitudes and correction OSS-REQ-0327-
0330, 0346-0349 (pg 91-94)
C. Claver
10/15/2012
LCR-86; Complete refactoring of photometric
requirements (pg 97-102, 104)
C. Claver
10/15/2012
LCR-84; Updates filling in TBDs in level 1 (pg 46-48)
and level 2 (pg50-54) data quality metrics
C. Claver
10/15/2012
LCR-113; Updates to EMI/Rfi requirements (pg 32)
C. Claver
3
2/14/2013
LCR-85; Redefinition of the seismic design criteria
(pg 3, 9-10, 33)
George Angeli
4
10/8/2013
Incorporates all changes approved via LCRs 133,
145, 146, 148, and 153 and all amendments made
to those LCRs by the CCB during the meetings held
10/2/2013 and 10/8/2013
Brian Selvy
4.1
2/12/2014
Incorporates changes approved in LCR-166
regarding changing the reference to Document-
8123 to LSE-180 in the Discussion of OSS-REQ-0194.
Incorporates all changes approved in LCR-168
regarding barometric pressues in OSS-REQ-0010.
B. Selvy
5.0
1/27/2015
Incorporates changes approved in the following
LCRs
131: Change Camera Interfaces to DM and
B. Selvy & C. Claver

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
ii
TCS to 18-bits; 141: SRD text refinement for
photometry; 176: Revised OSS Timing
Requirements; 182: Exposure time in LSR and OSS;
183: Revised Filter Definitions; 188: OSS Omnibus
Change Request; 189: Camera Crosstalk
Requirements Update; 195: Addition of optics
second surface clear aperture; 199: Add Collimated
Beam Projector to Project Baseline; 253: SRD
Spatial Variation Requirements Flowdown to LSR,
OSS & Camera
5.1
4/10/2015
Fixed several typos. Moved several misplaced
tables (Constraint Blocks in the SysML model) to
their proper locations.
B. Selvy

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
iii
Table of Contents
Change
Record
...............................................................................................................................................
i
Introduction
and
Scope
................................................................................................................................
vii
Acronyms and Definitions of Terms ............................................................................................................. vii
Reference
Documents
..................................................................................................................................
vii
Verb
Usage
...................................................................................................................................................
vii
2
System Composition and Constraints ................................................................................................... 1
2.1
Facilities
...........................................................................................................................................
1
2.1.1 The Summit Facility ................................................................................................................... 1
2.1.2 The Base Facility ........................................................................................................................ 1
2.1.3 The Archive Facility ................................................................................................................... 2
2.1.4 The Headquarters Facility ......................................................................................................... 2
2.2
Sites
..................................................................................................................................................
3
2.2.1 Chilean Summit and Base Sites ................................................................................................. 3
2.2.2 Archive Site ............................................................................................................................. 10
2.2.3 Headquarters Site ................................................................................................................... 10
3
Common System Functions & Performance ....................................................................................... 10
3.1 Survey Scheduling and Management ............................................................................................ 11
3.1.1 Survey Scheduling ................................................................................................................... 11
3.1.2 Survey Planning and Performance Monitoring ....................................................................... 12
3.2 System Control ............................................................................................................................... 12
3.2.1 Control Capabilities ................................................................................................................. 13
3.2.2 Standard Operating States ...................................................................................................... 15
3.2.3 Degraded Operational States .................................................................................................. 16
3.3 System Monitoring & Diagnostics .................................................................................................. 18
3.3.1 Image Visualization ................................................................................................................. 19
3.3.2 Data Visualization ................................................................................................................... 20

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
iv
3.3.3 Subsystem Telemetry .............................................................................................................. 20
3.3.4 Subsystem Baseline Performance ........................................................................................... 23
3.3.5 Subsystem Performance Reporting ........................................................................................ 23
3.3.6 Performance & Trend Analysis Toolkit ................................................................................... 23
3.3.7 Summit Environment Monitoring ........................................................................................... 24
3.4 System Maintenance ..................................................................................................................... 25
3.4.1 Predictive Maintenance .......................................................................................................... 25
3.4.2 Preventive Maintenance ......................................................................................................... 26
3.4.3 Maintenance Activity Support ................................................................................................ 26
3.4.4 Maintenance Reporting .......................................................................................................... 26
3.4.5 Maintenance Tracking and Analysis ....................................................................................... 26
3.5 System Availability ......................................................................................................................... 26
3.5.1 Scheduled Down Time ............................................................................................................ 27
3.5.2 Unscheduled Down Time ........................................................................................................ 27
3.6 System Time Reference ................................................................................................................. 28
3.6.1 Time Accuracy and Precision .................................................................................................. 28
3.6.2 Time Reporting Standard ........................................................................................................ 28
3.7 System Standards ........................................................................................................................... 28
3.7.1 Component Standardization Goal ........................................................................................... 28
3.7.2 Environment ........................................................................................................................... 29
3.7.3 Building Codes ......................................................................................................................... 30
3.7.4 Electrical and Controls Standards ........................................................................................... 31
3.7.5 Minimum Design Lifetime ....................................................................................................... 31
3.7.6
Safety
......................................................................................................................................
31
3.7.7
Health
......................................................................................................................................
33
3.7.8
Security
...................................................................................................................................
33
4
Detailed Specifications ........................................................................................................................ 33

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
v
4.1 Science and Bulk Data .................................................................................................................... 34
4.1.1
Scoping
....................................................................................................................................
34
4.1.2 Science Image Handling Reliability ......................................................................................... 37
4.1.3 Data Acquisition ...................................................................................................................... 38
4.1.4 Data Processing ....................................................................................................................... 38
4.1.5 Data Products .......................................................................................................................... 40
4.1.6 Data Archiving ......................................................................................................................... 50
4.1.7 Data Access ............................................................................................................................. 52
4.2 Optical System ............................................................................................................................... 54
4.2.1 Optical Design Specification .................................................................................................... 55
4.2.2 Optical Alignment and Compensation .................................................................................... 59
4.2.3 Stray and Scattered Light Control ........................................................................................... 62
4.2.4 Image Quality .......................................................................................................................... 63
4.2.5 Image Ellipticity ....................................................................................................................... 65
4.3 System Throughput ........................................................................................................................ 66
4.3.1 Filter Response ........................................................................................................................ 66
4.3.2 Optical Throughput ................................................................................................................. 80
4.3.3 10-year Integrated Throughput .............................................................................................. 84
4.4 Camera System .............................................................................................................................. 85
4.4.1 Image Delivery ........................................................................................................................ 85
4.4.2 Image Acquisition.................................................................................................................... 86
4.4.3 Imaging Control ....................................................................................................................... 91
4.5 Photometric Calibration ................................................................................................................. 91
4.5.1 Calibration of the Instrumental Transmission ........................................................................ 91
4.5.2 Calibration of the Atmospheric Transmission ........................................................................ 95
4.5.3 Calibration Data Processing .................................................................................................... 97
4.6 System Timing and Dynamics ........................................................................................................ 99

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
vi
4.6.1 Cadence and Visit Timing ........................................................................................................ 99
4.6.2 Filter Swaps & Changes ......................................................................................................... 100
4.6.3 Observatory Pointing and Tracking ....................................................................................... 102
4.7 Education and Public Outreach .................................................................................................... 104
4.7.1 EPO - National Priorities........................................................................................................ 104

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
vii

Back to top


The LSST Observatory System Specifications
Introduction and Scope
This Observatory System Specifications (OSS) document describes the functional and performance
requirements and allocations needed to fulfill the system functionality and survey performance
described by the LSST System Requirements Document (LSE-29). These specifications include those
derived from the following activities and/or modelling tools:
the reference system architecture consisting of fore (4) principle sites
summit, base, archive
and headquarters
the selection of the summit site on Cerro Pachón;
the modelling the dynamic survey performance with the LSST Operations Simulator;
the optical design optimization;
the point source SNR analysis of the system throughput
In addition to the system specifications this document also includes required codes and regulations
covering safety, construction, and other engineering standards.
Acronyms and Definitions of Terms
Glossary of Abbreviations
(
Document-11921
)
Glossary of Definitions
(
Document-14412
)
Reference Documents
LSST Science Requirements Document (LPM-17)
LSST System Requirements (LSE-29)
LSST Systems Engineering Management Plan (LSE-17)
LSST Change Control and Configuration Management Plan (LPM-19)
LSST Risk Management Plan (LPM-20)
Verb Usage
Statements of need, requirements, and constraints are written using one of three verbs that have a
specific meaning with respect to verification. All statements in this specification that convey operational,
functional, or performance needs, requirements, constraints, or goals on the LSST system will contain
one of these three verbs.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
viii
Will
A statement of fact. Will statements document something that will occur through the
course of normal design practice, project process, etc. These statements do not get formally
verified.
Should
A goal. Should statements document a stretch goal. A should statement is typically
partnered with a Shall statement. Should statements do not get formally verified.
Shall
A requirement that gets formally verified. Shall statements document critical
requirements that must be verified through inspection, demonstration, analysis, or test during
the verification phase of the project in order to ensure objectively that the as-built design meets
the requirement.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
1

Back to top


The LSST Observatory System Specifications
1 System Composition and Constraints
The LSST system will consist of facilities constructed at several sites in Chile and the United States. In this section
we enumerate the planned facilities and their functions. The data processing functions at these facilities are further
divided into "Centers" -- collections of closely related activities.
We specify the choice of the physical sites used for the system design. These choices imply specific constraints that
impact the system requirements and design. The specific sites drive system architecture and connectivity
specifications. The choice of the summit site, and the subsequent agreement with Chile, also determines particular
requirements on the system components that are provided.
The LSST summit site selection process resulted in the choice of Cerro Pachón in Chile for the location of the
observatory itself. The weather and astro-climate (seeing and cloud cover) of Cerro Pachón provide system
constraints under which the survey design requirements must be met which in turns drives certain system
specifications.
1.1 Facilities
ID: OSS-REQ-0001
Last Modified: 4/21/2011
Specification:
The LSST Observatory shall be designed using the following four facilities; Summit Facility. Base
Facility, Archive Facility, and Headquarters Facility. These are described below.
1.1.1 The Summit Facility
ID: OSS-REQ-0002
Last Modified: 4/21/2011
Specification:
The LSST shall provide a "Summit Facility" to host the following functions and their associated
maintenance activities:
1. Collection of the science data for the survey;
2. Collection of additional data required for photometric calibration; and
3. Control of the Observatory.
Discussion:
The Summit Facility includes the main telescope and its enclosure, camera service areas, mirror coating
systems, the auxiliary telescope and its enclosure, utility equipment, and all other infrastructure necessary to safely
execute all the functions above and secure all LSST assets located on the summit. Summit Facility also must provide
the space and functional equipment to safely maintain all the system assets operating on the site.
1.1.2 The Base Facility
ID: OSS-REQ-0003
Last Modified: 10/7/2013
Specification:
The LSST shall provide a "Base Facility" to host the following functions and their associated
maintenance activities:
1. The Primary Remote Observing facility to assist in the control of the Observatory;
2. Survey planning and performance monitoring;
3. Collection of newly acquired data for transfer to the LSST data archive;

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
2
4. Backup of all data - raw, engineering, and derived products;
5. Host Country Data Access Center, as defined below; and
6. Control of Data Management operations (secondary location).
Discussion:
The Base Facility may be a single structure or a series of co-located buildings that provides the
personnel offices, computer equipment, and other specialized infrastructure necessary to safely execute all the
functions above and to secure all LSST assets located at the Base.
1.1.3 The Archive Facility
ID: OSS-REQ-0004
Last Modified: 5/20/2011
Specification:
The LSST shall provide an "Archive Facility" to host the following functions:
1. Ingest and daily reprocessing of all raw science data;
2. Archiving of all data - raw, engineering, and derived products;
3. Data Release Production;
4. Calibration Product Production;
5. Moving Object Production;
6. United States Data Access Center; and
7. Data Management Operations (secondary location).
Discussion:
The Archive Facility includes the personnel offices, computer equipment, and other specialized
infrastructure necessary to safely execute all the functions of the listed Centers and to secure all LSST assets located
at the Archive.
1.1.4 The Headquarters Facility
ID: OSS-REQ-0005
Last Modified: 9/16/2010
Specification:
The LSST shall provide a "Headquarters Facility" to host the following functions:
1. Survey planning and performance monitoring;
2. Management of community science input;
3. Overall Observatory and project administration;
4. Education and Public Outreach; and
5. Data Management Operations Center
Discussion:
The function of Observatory and project administration includes the activities of a director, technical
manager, business manager, and human resources, and covers all matters of compliance and reporting, interface to
funding agencies, and management of the overall LSST Observatory and its operations world-wide.
The functions of Education and public outreach include the development of K-12 curricula, citizen science
programs, and the necessary serving of LSST data to educators and the general public through a dedicated Data
Access Center within, or in close proximity to, the Headquarters facility.
The Headquarters Facility includes the personnel offices, business equipment, and other specialized infrastructure
necessary to safely execute all the functions above and to secure all LSST assets located at the Headquarters.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
3
1.2 Sites
ID: OSS-REQ-0006
Last Modified: 9/15/2010
Specification:
The LSST Observatory system shall be designed to safely meet its technical requirements and
operational specifications with the above-defined Facilities constructed at the following physical locations ("Sites"):
1. Cerro Pachón in Chile for the Summit Facility;
2. The AURA Recinto in La Serena, Chile for the Base Facility;
3. The National Center for Supercomputing Applications (NCSA) in Urbana-Champaign, IL for the Archive
Facility; and
4. A continental U.S. site for the Headquarters Facility.
1.2.1 Chilean Summit and Base Sites
ID: OSS-REQ-0350
Last Modified: 2/5/2013
1.2.1.1 Summit Site
ID: OSS-REQ-0007
Last Modified: 10/18/2012
Specification:
The LSST observatory Summit Facility shall be located within the AURA property on Cerro Pachón
(El Peñón), Chile, and shall meet all requirements for survey performance and operations at that site. All other
functions of the Summit Facility shall be compatible with the defined weather, access, seismic and other site
conditions provided below.
1.2.1.1.1 Summit Geographic Definitions
ID: OSS-REQ-0008
Last Modified: 8/28/2010
Specifications:
When design considerations require the specification of the summit site location, the following
definitions for elevation, latitude, and longitude shall be used:
Description
Value
Unit
Name
The operational summit elevation to be used for design purposes is
summitElevation.
2650
Meters
summitElevation
The operational site latitude to be used for design purposes is
summit Latitude.
-30.2444
Degrees
summitLatitude
The operational summit longitude to be used for design purposes is
summitLongitude.
-70.7494
Degrees
summitLongitude
1.2.1.1.2 Summit Environment
ID: OSS-REQ-0009
Last Modified: 12/1/2010
Specification:
All systems operating at the Summit Facility exposed to the external environment (includes the dome
interior) shall meet all their functional and performance specifications for the Normal site conditions, shall operate
in defined degraded modes under the Marginal conditions, and withstand without damage the non-operational
Survival conditions provided below.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
4
1.2.1.1.2.1 Normal Operating Conditions
ID: OSS-REQ-0010
Last Modified: 12/1/2010
Specification:
The equipment and systems exposed to the external environment at the Summit Facilities shall meet
all of their functional, performance, and operational specifications for the normal environmental conditions specified
in the table below.
Discussion:
These conditions correspond to the ~90% to 95% values of the weather distribution.
Description
Value
Unit
Name
The mean temperature for normal operations at the summit shall be
normTempMean
.
11.5
Celsius
normTempMean
The minimum temperature for normal operations at the summit shall
be
normTempMin
.
-3.0
Celsius
normTempMin
The maximum temperature for normal operations at the summit
shall be
normTempMax
.
19.0
Celsius
normTempMax
The rate of change for design purposes shall be
normTempGrad.
0.7
C/Hour
normTempGrad
When design considerations require operational wind specifications
all summit based systems shall use the extreme operational wind
speed,
normWindMax
.
12
m/sec
normWindMax
When design considerations require humidity specifications all
summit based systems shall use the normal maximal operational
relative humidity (non-condensing)
normHumidityMax
90
Percent
normHumidityMax
When design considerations require humidity specifications all
summit based systems shall use the normal mean operational
relative humidity (non-condensing)
normHumidityMean.
40
Percent
normHumidityMean
When design considerations require barometric pressure
specifications all summit based systems shall use the mean pressure
normBaroMean
.
750
milibar
normBaroMean
The maximum barometric pressure for normal operations at the
summit shall be
normBaroMax
.
775
milibar
normBaroMax
The minimum barometric pressure for normal operations at the
summit shall be
normBaroMin
.
725
milibar
normBaroMin
1.2.1.1.2.2 Marginal Operating Conditions
ID: OSS-REQ-0011
Last Modified: 4/21/2011
Specification:
The equipment and systems exposed to the external environment at the Summit Facility shall be
operable (not necessarily meeting all performance and functional requirements) over the range of marginal
environmental conditions specified in the table below.
Discussion:
These conditions correspond to the ~99% values of the weather distribution.
Description
Value
Unit
Name
The temperature rate of change for degraded operations is
marginalTempGradient
2.0
C/Hour
marginaltempGradi
ent
The maximum temperature for degraded operations at the summit
shall be
marginalTempMax
.
30
Celsius
marginalTempMax
The minimum temperature for degraded operations at the summit
-5
Celsius
marginalTempMin

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
5
Description
Value
Unit
Name
shall be
marginalTempMin
.
The maximum free air windspeed for degraded operations at the
summit shall be
marginalWind
.
20
m/sec
marginalWind
1.2.1.1.2.3 Survival Conditions
ID: OSS-REQ-0012
Last Modified: 5/25/2011
Specification:
The exterior of the Summit Facility and all hardware permanently located on the exterior shall be
capable of surviving a constant wind speed of
survivalWindExterior.
All equipment and systems at the Summit Facility, when exposed to the external environment (e.g. when the dome is
open) shall survive the other environmental conditions specified in the table below.
Description
Value
Unit
Name
All hardware permanently located on the exterior of the Summit
Facility shall be capable of surviving a constant wind speed of
survivalWindExterior.
54
m/sec
survivalWindExteri
or
The equipment in the interior of the Summit Facility must be
capable of surviving an exterior 10-second wind gust speed of
survivalWindGust.
25
m/sec
survivalWindGust
The equipment in the interior of the Summit Facility must be
capable of surviving a constant wind speed of
survivalWind.
20
m/sec
survivalWind
All equipment at the Summit Facility must be capable of surviving a
maximum non-condensing humidity of
survivalHumidity
without
damage.
100
Percent
survivalHumidity
All equipment located at the Summit Facility must be capable of
surviving an ambient air temperature of
survivalTemperature.
-10
Celsius
survivalTemperatur
e
The survival load on the Summit Facility due to snow shall be
snowLoading
(ref. Norma Chilena NCH 431).
200
kg/m^2
snowLoading
The survival load on the Summit Facility for ice on vertical surfaces
shall be
iceLoading
(ref. Norma Chilena NCH 431)
22
kg/m^2
iceLoading
1.2.1.1.2.4 Transportation/Shipping Environment
ID: OSS-REQ-0013
Last Modified: 5/18/2011
Specification:
Components of the LSST Observatory that are transported to Chile shall survive the shipping
conditions described below.
Discussion:
The shipping environment includes the general conditions when equipment is shipped to the summit.
The equipment must remain undamaged after repeated shipments. Delivery is expected to be by plane or boat to
Chile and then by road to the summit.
There is a tunnel on the road between the town of La Serena and the summit site on Cerro Pachon called the Puclaro
Tunnel. Any equipment will have to pass through that tunnel. Its overall dimensions are given below.
Description
Value
Unit
Name
During transportation, the effective altitude can change between sea
level and 3000m.
Sea level
to 2700m
Meters
Altitude

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
6
Description
Value
Unit
Name
The ambient temperature range or transportation to the summit is
-15C to
+40C
Celsius
Temperature Range
The relative humidity range is from 10% to 100% with condensation
for transportation to the summit
10% to
100%
Percent
Relative Humidity
Range
Wind speed may reach up to 45m/s during transportation to the
summit
45
m/sec
Wind Speed
Pressure will change during transportation to the summit from
1000mbar at sea level down to 750mbar at the summit
1000 to
750
milibar
Pressure
Containers have to be designed to limit water, dust, sand and insect
access during transportation
Contamination
Dirt roads will be used during transportation to the summit with
grades up to 16%
16
Percent
Roads
During transportation to the summit, some roads have vehicle
weight restrictions.
Gross Vehicle Weight GVW = TBD
Weight/axle = TBD
TBD
kg
GVW
The container dimensions are limited by the Puclaro Dam tunnel
(see figure 7) located on the road between La Serena and the
summit.
9
Meters
Tunnel
1.2.1.1.3 Astro-Climate
ID: OSS-REQ-0015
Last Modified: 8/5/2010
Discussion:
The selection of the summit site on Cerro Pachon implies a set of constraints relating to the astro-
climate under which the survey performance requirements from the LSR must be met. These include atmospheric
seeing, usable fraction of nights and cloud cover fraction, standard dark sky brightness, and standard atmospheric
transparency.
1.2.1.1.3.1 Atmospheric Seeing
ID: OSS-REQ-0016
Last Modified: 12/1/2010
Specification
: The LSST shall meet the survey performance requirements under the constraint of the atmospheric
seeing on Cerro Pachon (El Penon) as specified in the table below.
Discussion:
The values included here are direct DIMM measurements referenced to a wavelength of 500 nm. They
do not represent the integrated delivered seeing over an 8.4m aperture or include affects from the outer scale.
Description
Value
Unit
Name
The first quartile of the seeing distribution shall be taken as
seeing1stQuartile
0.58
ArcsecFWH
M
seeing1stQuartile
The median of the seeing distribution shall be taken as
seeingMedian
0.69
ArcsecFWH
M
seeingMedian
The third quartile of the seeing distribution shall be taken as
seeing3rdQuartile
0.84
ArcsecFWH
M
seeing3rdQuartile
1.2.1.1.3.2 Cloud Coverage
ID: OSS-REQ-0017
Last Modified: 12/1/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
7
Specification:
The LSST Observatory shall meet the survey specifications under the assumed weather conditions
recorded at Cerro Tololo Observatory from 1975 to 2005 for cloud cover and fraction of photometric and usable
nights as defined in the table below.
Description
Value
Unit
Name
The historically monthly mean available time fraction that is
considered "photometric" (i.e. cloudless) shall be taken as
photTimeFrac
53
Percent
photTimeFrac
The historically monthly mean available time fraction that is
considered usable (i.e. with clouds but observable, also called
"spectroscopic") shall be taken as
usableTimeFrac
85
Percent
usableTimeFrac
1.2.1.1.3.3 Standard Atmospheric Transmission
ID: OSS-REQ-0018
Last Modified: 4/21/2011
Specification:
For the purpose of evaluating the system performance and the flow down of subsystem requirements
the standard atmospheric transmission shall be calculated from the USAF MODTRAN model using the reference
atmospheric parameters given in the table below.
Discussion:
While the reference airmass is X=1, Collection-973 contains data files for other airmass values up to
x=2.5. Document-3902 contains details on using MODTRAN to calculate the atmospheric transmission functions.
https://www.lsstcorp.org/docushare/dsweb/Get/Document-3902
https://www.lsstcorp.org/docushare/dsweb/View/Collection-973
Description
Value
Unit
Name
1976 US standard STP sea level pressure is
seaLevelPressure
.
1013
milibar
seaLevelPressure
The standard relative humidity percentage is
stpRelHumidity
.
15
Percent
stpRelHumidity
The standard typical Ozone level over northern Chile is
ozoneLevel
.
338
Dobson
ozoneLevel
Reference airmass for calculating the standard transmission function
is
stdAirmass
.
1.0
Airmass
stdAirmass
1.2.1.1.3.4 Standard Dark Sky Emission
ID: OSS-REQ-0019
Last Modified: 4/21/2011
Specification:
For the purpose of evaluating the system performance and the flow down of subsystem requirements
the assumed sky brightness in each filter shall be as defined in the
darkSkyBrightness
table below.
Discussion:
The details of the sky brightness model and assumptions used are given in Document-8857. The data
file containing the assumed sky spectrum is found in Document-8817.
The value for the y-band is for the adopted baseline y4 filter.
The intense sky emission at the extreme red end of the LSST system response means this value could change
significantly should a different y-band definition be adopted later.
https://www.lsstcorp.org/docushare/dsweb/Get/Document-8817

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
8
https://www.lsstcorp.org/docushare/dsweb/Get/Document-8857
Description
Value
Unit
Name
Integrated reference sky brightness in the u-band.
22.92
mag/SqArcs
ec
u_SkyBrightness
Integrated reference sky brightness in the g-band.
22.27
mag/SqArcs
ec
g_SkyBrightness
Integrated reference sky brightness in the r-band.
21.20
mag/SqArcs
ec
r_SkyBrightness
Integrated reference sky brightness in the i-band.
20.47
mag/SqArcs
ec
i_SkyBrightness
Integrated reference sky brightness in the z-band.
19.59
mag/SqArcs
ec
z_SkyBrightness
Integrated reference sky brightness in the y-band.
18.42
mag/SqArcs
ec
y_SkyBrightness
1.2.1.1.3.5 Usable Observing Time
ID: OSS-REQ-0020
Last Modified: 5/3/2011
Specification:
The LSST system shall be designed for the expected average number of usable observing hours at the
site,
nightDurationAvg
, the winter maximum,
nightDurationMax
, and the summer minimum,
nightDurationMin
.
Discussion:
These values have been defined with reference to Nautical (12-degree) twilight and do not include the
effects of weather.
These specifications are required for the design of the peak and average capacities of the Data Management system.
They also provide constraints for the definition of the non-observing-time budget for observing preparation,
calibration, and maintenance activities together. During the period around winter solstice the scheduled maintenance
and calibration activities will be defined such that they can be accommodated in short non-observing hours.
Description
Value
Unit
Name
The mean useable length of a night shall be taken as
nightDurationAvg.
10
Hour
nightDurationAvg
The maximum useable length of a winter night shall be taken as
nightDurationMax
.
12
Hour
nightDurationMax
The minimum useable length of a summer night shall be taken as
nightDurationMin
.
8
Hour
nightDurationMin
1.2.1.2 Base Site
ID: OSS-REQ-0021
Last Modified: 10/18/2012
Specification:
The LSST Base Facility shall be located at the AURA Recinto compound in La Serena, Chile. The
facilities at the Base Site shall be designed to be consistent with existing conditions; where local standard
construction codes are not sufficient, all equipment shall be designed to project-defined Seismic Specifications.
Discussion:
The facilities at this site will be developed through new construction or through agreements that meet
operational and functional requirements but take advantage of existing NSF and AURA infrastructure.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
9
1.2.1.3 Seismic Design Parameters
ID: OSS-REQ-0344
Last Modified: 10/9/2013
Discussion:
The LSST Summit and Base Facilities are located in Region-3, Chile; a known seismically active area.
The requirements for seismic accelerations established here determine the probability for survival, recoverable and
operable events as defined below.
As a result of the interactions of the dynamic characteristics (natural frequencies and damping) of the telescope
mount and its components with the vibration frequencies of the seismic accelerations, the maximum accelerations of
the telescope systems vary significantly according to their location on the telescope mount. Consequently, for all
systems mounted to the telescope for all event levels, the design accelerations will be determined by the application
of the appropriate seismic vibration spectrum to a finite element analysis (FEA) model of the telescope and its pier.
These accelerations will be specified at the appropriate interfaces between subsystems and/or components.
Verification of these requirement will be by analysis or prototype. The implied accelerations are normalized to
ductile materials and should be scaled to ASME standard safety factors for other material types (e.g. glass, carbon
fiber etc.). Where a range of material strengths is possible verification analysis will use the minimum strength to
determine compliance.
1.2.1.3.1 Survival Seismic Design Parameters
ID: OSS-REQ-0014
Last Modified: 2/5/2013
Specification:
All systems and/or components permanently located at the Summit or Base Facilities shall be designed to withstand
the loads resulting from an earthquake up to the levels a 300-year return period seismic event and stay intact such
that catastrophic failure is prevented and the hazards to personnel safety are either eliminated or reduced. The levels
of a 300-year return period earthquake have a 9.5% probability of being exceeded in 30 years. The ground
acceleration values corresponding to a 300-year return period earthquake are defined in the standards established in
OSS-REQ-0095.
"Catastrophic failure” shall be defined as fracture or
rupture that allows a significant element to separate and fall, or
produces the possibility of personnel injury.
Discussion:
See discussion on design accelerations in "Seismic Design Parameters" (OSS-REQ-0344).
The return of the Summit or Base Facilities and their contents to "normal" operations following a "Survival" event
will be assessed based on actual damage incurred.
1.2.1.3.2 Recoverable Seismic Design Parameters
ID: OSS-REQ-0342
Last Modified: 10/18/2012
Specification:
All systems and/or components permanently located at the Summit Facility shall be designed to operate without any
permanent damage following a seismic event equivalent to a 20% probability of return over the specified design
lifetime of the system and/or component.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
10
"Permanent damage”
shall be defined as any damage to optical elements, any yielding of primary structural
components, damage where capital repair costs are in excess of $10M (TBR) or repair times longer than 6 months
after access and damage assessment.
Discussion:
See discussion on design accelerations in "Seismic Design Parameters" (OSS-REQ-0344).
1.2.1.3.3 Operable Seismic Design Parameters
ID: OSS-REQ-0345
Last Modified: 10/18/2012
Specification:
All systems and/or components permanently located at the Summit Facility shall be designed to
operate without any significant damage following a seismic event with a return period equivalent to specified design
lifetime of the system and/or component.
"Significant damage" shall be defined as any damage that cannot be repaired within the statistical allocation of the
unscheduled down time defined in OSS-REQ-0082.
Discussion:
See discussion on design accelerations in "Seismic Design Parameters" (OSS-REQ-0344).
1.2.2 Archive Site
ID: OSS-REQ-0022
Last Modified: 9/14/2010
Specification:
The LSST Archive Facility shall be located at the National Center for Supercomputing Applications
(NCSA) in Champaign-Urbana Illinois.
Discussion:
The facilities at this site will be developed through new construction or through agreements that meet
operational and functional requirements but take advantage of existing NSF and NCSA infrastructure.
1.2.3 Headquarters Site
ID: OSS-REQ-0023
Last Modified: 12/1/2010
Specification:
The LSST Headquarters Facility shall be located in the continental United States of America. When
design considerations require the specification of the site location, Tucson Arizona shall be used.
Discussion:
The facilities at the selected site shall be developed through new construction or through agreements
that meet operational and functional requirements.
2 Common System Functions & Performance
The requirements and specification called out in this section are common and apply across the LSST System. These
requirements address the following topics:
1. Survey Scheduling and Management;
2. System Control;
3. System Monitoring and Diagnostics,
4. System Maintenance;
5. System Availability;
6. System Time References;

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
11
7. System Standards (including environmental and safety).
2.1 Survey Scheduling and Management
ID: OSS-REQ-0024
Last Modified: 4/21/2011
Specification:
The LSST shall be capable of scheduling the survey observations in an automated maner based on
several optimization parameters established to produce the Survey specifications defined in the LSST System
Requirements (LSE-29) and maximize the operational efficiency. Through the parameters defined below, the LSST
shall be capable of adjusting its observations and its scientific priorities if they should change before or during the
survey. The System shall monitor survey progress and provide the necessary tools described below to evaluate
performance.
2.1.1 Survey Scheduling
ID: OSS-REQ-0025
Last Modified: 5/18/2011
Specification:
The Observatory Control System shall schedule the survey with the functionality detailed below.
2.1.1.1 Environmental Optimization
ID: OSS-REQ-0026
Last Modified: 4/21/2011
Specification:
The survey scheduling shall be optimized against local environmental conditions to maximize the
survey's scientific return. This optimization shall include the ability to adjust filters based on seeing conditions, the
ability to avoid clouds with predefined opacity, and adjust to constraints derived from wind direction.
2.1.1.2 Multiple Science Programs
ID: OSS-REQ-0027
Last Modified: 5/18/2011
Specification:
The survey scheduling shall be capable of optimizing scientific returns from multiple science
priorities, numbering at least
nSciProp
.
Discussion:
A science proposal will be defined by that include but are not limited to
number of visits and distribution by filter;
temporal of visit distribution and/or sequence definition;
limits on astro-climate quality for observation;
constraints on the location of visit fields;
priority relative to other science proposals
Description
Value
Unit
Name
The minimum science proposal that the scheduling algorithm must
be capable of optimizing over.
6
int
nSciProp
2.1.1.3 Parallax Factor Sampling
ID: OSS-REQ-0028
Last Modified: 5/18/2011
Specification:
The scheduler shall enforce an even distribution of parallax factor over the sum of all visits in the 10-
year survey.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
12
2.1.1.4 Scheduling Assessment
ID: OSS-REQ-0029
Last Modified: 12/1/2010
Specification:
The survey scheduling shall be adjustable based on periodic assessment of performance. This shall be
done down to periods of 1 hour throughout the night and shall be based on actual accomplishments compared to
objectives and current system technical performance.
2.1.1.5 Survey History Record
ID: OSS-REQ-0030
Last Modified: 4/21/2011
Specification:
The LSST Scheduler shall maintain an independent record of all past observations and shall include
Data Quality Assessment parameters determined by evaluation of the imaging data.
2.1.1.6 Temporal Visit Distribution
ID: OSS-REQ-0031
Last Modified: 5/18/2011
Specification:
The scheduler shall be capable of enforcing 5 (TBR) defined temporal distributions of visits covering
the fast sample area (defined in the SRD).
2.1.1.7 Visit Optimization
ID: OSS-REQ-0032
Last Modified: 12/1/2010
Specification:
The survey schedule shall be optimized to maximize the number of scientifically useful visits per
night.
2.1.2 Survey Planning and Performance Monitoring
ID: OSS-REQ-0033
Last Modified: 12/1/2010
Specification:
The LSST shall provide the tools and administrative processes necessary to monitor the progress of
the ongoing survey,provide reports on the progress of the survey, respond to feedback from the science community,
and evaluate the impact of changing science priorities over the 10 year survey lifetime.
Discussion:
It is expected that the performance of this task will require the use of detailed survey simulations in
order to evaluate scheduling alternatives and optimize the future performance of the survey.
2.2 System Control
ID: OSS-REQ-0034
Last Modified: 5/18/2011
Specification:
The LSST Observatory shall be implemented with a coordinated set of control software that will
achieve the specified survey, as well as the necessary command, control and monitoring of all observatory functions
and states across the Facilities.
Discussion:
This control software includes both the Observatory Control System, which is responsible for
sequencing activities associated with data collection and initial processing, and the control software for the Data
Management system, which will be responsible for alert, data release, and calibration products productions, and
archiving and serving data to users.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
13
2.2.1 Control Capabilities
ID: OSS-REQ-0035
Last Modified: 5/26/2011
Specification
: The LSST control capabilities throughout the system shall be designed to achieve the specified
survey with an operating team consistent with the LSST Operations Plan. [document-7838] To control the system
efficiently, safely and reliably, the control system shall include both local and remote control modes as specified in
this section.
https://www.lsstcorp.org/docushare/dsweb/Get/Document-7838
2.2.1.1 Local Autonomous Administration of System Sites
ID: OSS-REQ-0036
Last Modified: 5/18/2011
Specification:
Each site in the LSST Observatory shall be capable of local autonomous control and operation. The
LSST System shall include the necessary provisions to function effectively when data connections to other sites of
the Observatory are interrupted.
Discussion:
By "Function effectively" it is understood that when data connections are lost that not system functions
will be preserved. For example, the Base Facility cannot generate alerts within 60 seconds without the data coming
from the Summit Facility and the Archive Facility cannot serve data it doesn't yet have. Further, regarding data
management "effectively" means that the equipment operates normally, processes, and serves whatever data is
available.
2.2.1.2 Remote Operation Capabilities
ID: OSS-REQ-0043
Last Modified: 5/18/2011
Specification:
All LSST major subsystems and OCS shall be remotely operable from any of the LSST Facilities or
other Project designated site (e.g. SLAC for camera troubleshooting).
Discussion:
This provides the opportunity to establish a single operations center for the various system functions.
Remote operation of the telescope requires granting of permission by an operator who is present at the site, and must
remain present during remote operation
It is expected that routine observing oversight of the observatory will be done from the Base Facility, with the
exception of actions for which safety and/or equipment protection considerations require operator presence on the
summit. These restrictions will be documented in the LSST Safety Plan.
2.2.1.2.1 Summit Facility Operator
ID: OSS-REQ-0308
Last Modified: 4/21/2011
Requirement:
A local operator shall be always available at the Summit Facility to regain local control when
conditions or safety considerations merit.
2.2.1.2.2 Network Security
ID: OSS-REQ-0309
Last Modified: 2/9/2015
Requirement:
Remote operations shall comply with all LSST Corporation cyber security policies in effect at the
time.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
14
2.2.1.3 Observatory Safety System
ID: OSS-REQ-0321
Last Modified: 5/20/2011
Specification:
Each Facility in the LSST Observatory shall implement a non-software based safety system(s) in
areas where injury or harm to personnel and or equipment can occur.
2.2.1.4 Observatory Control System Definition
ID: OSS-REQ-0037
Last Modified: 5/18/2011
Specification:
The Observatory Control System (OCS) is the primary high level supervisor and monitor for
conducting the survey that shall consist of software subsystems that interact through a connectivity backbone
layered on top of the observatory communications network.
Discussion
: The OCS commands, monitors and controls all observatory activities, to achieve a safe and efficient
observation environment.
2.2.1.4.1 Scope of Control
ID: OSS-REQ-0038
Last Modified: 4/21/2011
Specification:
The OCS shall control and monitor all activities necessary for the acquisition of the survey and
ancillary data. Additionally, the OCS shall provide high level control of the Data Management system's processing
of new data from the observatory, including the selection of its operational mode consistent with each type of
operational and maintenance data acquisition.
Discussion:
The operational mode selection above is intended to encompass the choice of normal nightly science
data acquisition, calibration data acquisition of various types, and diagnostic processes. The OCS will control the
nightly start and stop of DM processing and overall system state changes, but it is not envisioned that it will exert
fine-grained (e.g. per-exposure or per-visit) control of DM's activity.
2.2.1.4.2 Visit Sequencing
ID: OSS-REQ-0039
Last Modified: 4/21/2011
Specification:
The OCS shall include the ability to orchestrate a complete sequence of visits over any 24 hour time
period. This master sequencer shall be capable of system action flow control as well as system process
synchronization and parallelization.
Discussion:
OCS can be viewed as a sequencing engine for the execution of science, calibration, and engineering
observations. The sequence of science observations are generated by the observatory scheduler based on observatory
performance and project defined priorities. The master sequencer will include observatory configuration and target
acquisition sequences, from an OCS master process sequencer.
2.2.1.4.3 Manual Visit Specification
ID: OSS-REQ-0040
Last Modified: 12/1/2010
Specification:
The OCS shall be capable of accepting a full set of visit specifications from an external source. This
shall include individual operator defined targets and a target list that is followed in order.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
15
2.2.1.5 Subsystem Activation
ID: OSS-REQ-0041
Last Modified: 5/19/2011
Specification:
Upon activation, each subsystem connected to the OCS architecture shall be able to initialize itself
and be ready for communication with the OCS without further human intervention. This activation process shall take
less
subSysStart
to complete.
Discussion:
In the context of this requirement a subsystem refers to the three major subsystem of the LSST
Observatory, Telescope, Camera, and Data Management. It can also include other subsystems of each of the three
that are directly connected to the OCS architecture.
This does not place any requirements on the subsystem in terms of being ready to take data. For example, the
Camera cool down (which requires activation) will take considerable longer than 1 minute.
This requirement assumes a "warm restart" or activation with the appropriate computer(s) up and running.
Description
Value
Unit
Name
The maximum time for a subsystem to execute a warm restart and
regain connectivity with the OCS.
60
Seconds
subSysStart
2.2.1.6 Subsystem Initialization
ID: OSS-REQ-0307
Last Modified: 5/23/2011
Specification:
Each subsystem when powered up shall be initialized into a known safe state without human
intervention.
2.2.1.7 Subsystem Health and Welfare
ID: OSS-REQ-0042
Last Modified: 5/20/2011
Specification:
Each LSST subsystem shall be responsible for maintaining its own technical heath, safety, and status
without any other subsystem operational.
Discussion:
The Observatory shall have independent safety systems but each subsystem shall include an initial level
of autonomous safety for independent operation.
2.2.2 Standard Operating States
ID: OSS-REQ-0044
Last Modified: 4/21/2011
Specification:
The LSST observatory system shall be designed and constructed to support the following operational
states:
Fully automated observing - used for most of the survey observing;
Calibrate - used for special observing modes needed to calibration either the science data or other
technical aspects of the observatory;
Manual observing - used for specific non-scheduler driven observing to support system verification
and testing or specialized science programs;
Engineering and Maintenance

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
16
Note: The states need further definition in terms of access and safety requirements for each.
2.2.2.1 Automated Survey Observing
ID: OSS-REQ-0045
Last Modified: 4/21/2011
Specification
: The LSST system shall be capable of operating in an automated operation state to perform the survey
execution.
Discussion
: The survey operation shall proceed under the conduct of the OCS utilizing the automated scheduler and
its coordination capabilities with an operator available at the Summit Facility.
2.2.2.2 Calibration
ID: OSS-REQ-0046
Last Modified: 10/27/2010
Specification
: In calibration state the LSST system shall be capable of performing a science calibration plan.
Discussion:
The science calibration plan can include both the acquisition of specialized sky observations or
instrumental characterization data (e.g. dome flats, dark and bias images).
2.2.2.3 Engineering and Maintenance
ID: OSS-REQ-0047
Last Modified: 4/21/2011
Specification
: While in the engineering and maintenance state the LSST system shall provide the capabilities to
support the activities comprising of access to maintenance plans, capturing relevant telemetry, executing sequences
of tests, recording of associated activities, among others.
2.2.2.4 Manual Observing
ID: OSS-REQ-0048
Last Modified: 4/21/2011
Specification:
The LSST Observatory shall be capable of executing manual or simple script driven observations.
2.2.3 Degraded Operational States
ID: OSS-REQ-0049
Last Modified: 4/21/2011
Specification:
The LSST system shall support the modes of degraded operation enumerated below.
Discussion:
For each type of degradation we specify the time for which we can tolerate an outage of that particular
type. Longer outages are then assumed to cause unacceptable losses, and are then charged against the unscheduled
downtime budget. The system should therefore be engineered to minimize the occurrences of outages longer than
the specified durations.
This can lead to concrete requirements at lower levels. For instance, the fact that we are designing for two-day
outages in Summit-Base and Base-Archive connectivity now requires us to minimize the number of outages longer
than two days. This can be done, for instance, by requiring - at the subsystem level - the acquisition of redundant
network links.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
17
2.2.3.1 Summit Power Grid Loss
ID: OSS-REQ-0050
Last Modified: 10/27/2010
Specification:
The summit Facility shall be capable of normal survey operations in the event of power loss from the
grid for a minimum duration of
gridLossTime.
Description
Value
Unit
Name
The minimum time between resupply of the Summit Facility backup
power under continuous operation.
2
Days
gridLossTime
2.2.3.2 Summit-Base Connectivity Loss
ID: OSS-REQ-0051
Last Modified: 5/25/2011
Specification:
The LSST shall be able to continue with automated survey observing in the event that the data
communications between the Summit and Base sites are severed, for outages of less than
summitConnectivityLossTime
.
Discussion:
The level of data quality monitoring provided during such degraded operation may be lower than
normal, due to the lack of availability of Base resources for computing. However, at a minimum, data quality
monitoring related to the health and welfare of the subsystems (see OSS-REQ-0065) and simple analytic functions
of the "quick look" display (see OSS-REQ-0057) must be maintained.
Upon resumption of normal operations all normal science data processing, including full data quality assessment,
must be completed on acquired during the outage.
The emphasis on automated survey observing here is meant to convey that other capabilities might be lost during
such an outage, for instance the ability to reassess the progress of the survey, adjust scientific priorities, etc.
Description
Value
Unit
Name
Minimum duration of summit-base connectivity outage for which
normal survey operation can be maintained
48
Hour
summitConnectivity
LossTime
2.2.3.2.1 Summit Data Buffer
ID: OSS-REQ-0052
Last Modified: 5/20/2011
Specification:
The LSST system shall provide a limited buffer of both raw image (science and wave front sensing
images) and telemetry data to allow survey observations to proceed in the event of communications loss between the
summit and base. The buffer(s) shall have sufficient capacity to store the raw pixel and telemetry data for at least the
design outage time,
summitConnectivityLossTime
. Upon recovery from a communications interruption, it shall be
possible to drain the buffer, in parallel with continuing normal operations, in no more than
summitBufferTransferTime
.
Discussion:
Once the connectivity is restored it is expected that any data obtained during the outage will be
transferred to the Base Facility and then forwarded to the Archive Facility where it will be processed for alerts (late)
and the data base updated.
Discussion:
This requirement does not imply completing the nightly reprocessing of 3 days worth of data at the
Archive Facility within 24 hours.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
18
Description
Value
Unit
Name
The maximumallowedtime to transmit entire pixel buffer in parallel
with normal operations is
summitBufferTransferTime
.
24
Hour
summitBufferTransf
erTime
2.2.3.3 Base-Archive Connectivity Loss
ID: OSS-REQ-0053
Last Modified: 4/28/2011
Specification:
The LSST system shall be able to conduct normal science operations in the event that data
communication between the base and archive sites is lost, for outages of less than
baseConnectivityLossTime
.
Description
Value
Unit
Name
Minimum duration of base-archive connectivity outage for which
normal survey operation can be maintained
48
Hour
baseConnectivityLo
ssTime
Maximum time for recovery from a Base-Archive communications
outage of length
baseConnectivityLossTime
.
24
Hour
baseConnectivityRe
coveryTime
2.2.3.3.1 Base Data Buffer
ID: OSS-REQ-0054
Last Modified: 10/7/2013
Specification:
The LSST system shall provide a limited buffer for data (raw, processed, and engineering)
en route
from the Base to the Archive Center, to allow science operations to proceed in the event of communications loss
between the Base and Archive. The system shall have sufficient capacity to store all
en route
data for at least the
design outage time,
baseConnectivityLossTime
.
Discussion:
This requirement does not imply completing the nightly reprocessing of the buffered data at the Archive
Facility within 24 hours once it is transferred.
2.2.3.3.2 Base Updating from Archive
ID: OSS-REQ-0055
Last Modified: 10/7/2013
Specification:
Following an outage in Base-Archive connectivity not longer than
baseConnectivityLossTime
, all
data transfer from Archive to Base shall be brought current within
baseConnectivityRecoveryTime
, in parallel with
the continuation of normal operations.
2.3 System Monitoring & Diagnostics
ID: OSS-REQ-0056
Last Modified: 4/28/2011
Specification:
LSST Observatory shall monitor system and instrument performance on a regular (daily where
appropriate) basis with the goal of detecting sudden as well as gradual performance changes.
Discussion:
Data volume and rate drive the need for very summary or statistical representation of the information,
thresholds and alarms, and the ability to drill down.
During routine observing hours the system will provide real time display(s) summarizing system performance. This
includes real time display of the FPA image and basic image analysis including, but not limited to PSF
measurements, background levels, amplifier noise and other image statistics.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
19
.
During non-observing hours the primary activity shall be to review the quality control and performance parameters
specified by the established baseline performance report against the current performance summarized in automated
reports.
Sudden changes should be obvious from the near real time displays and image analysis
detecting long-term
changes will require monitoring performance as a function of time.
2.3.1 Image Visualization
ID: OSS-REQ-0057
Last Modified: 5/19/2011
Specification:
The LSST Observatory shall provide the means to display images from the FPA (including both
science and wavefront sensors) in real time commensurate with the FPA readout, as well as from archived images.
This "quick look" display shall support the following global functions:
Pan/zoom quickly and easily to arbitrary resolution
View from laptop/workstation or multi-monitor wall (albeit with performance trade-offs)
Ability to view warning/quality flags via color coding, overlays or some other mechanism
blink / compare images from at least two different exposures
2.3.1.1 Analytic Functions
ID: OSS-REQ-0058
Last Modified: 4/28/2011
Specification:
The "quick look" display tool shall support as a minimum the following analytic functions:
computation of basic statistics (mean, mode, SDEV, etc...) over an arbitrary region of pixel space
line/column plot on any scale
histogram of pixel values in an arbitrary region of pixel space
basic PSF measurements (FWHM, second moments, radial plots profile fitting, etc...)
simple arithmetic between arbitrary regions of two images
overlaying the results of queries to the Engineering & Facility Database
2.3.1.2 Display Timing Performance
ID: OSS-REQ-0059
Last Modified: 4/28/2011
Specification:
The "quick look" image display at the Summit and Base Facilities shall respond with the latency
performance indicated below.
Discussion:
these requirements only apply to "quick look" display located at the Summit and BAse Facilities when
accessing data from either the base archive or the summit data buffer.
Description
Value
Unit
Name
Users at the Summit or Base facility shall be able to view the image
data from the most recent exposure within
displayLatency
after the
shutter has closed.
10
Seconds
displayLatency
Users shall be able to cycle through predefined views of the full
image (e.g. bright or faint star optimized binned, bias map, noise
map, etc.) within
viewCycleTime
between each.
2
Seconds
viewCycleTime

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
20
2.3.1.3 Image Data Sources
ID: OSS-REQ-0060
Last Modified: 4/28/2011
Specification:
The "quick look" image display shall have access to image data from the following sources:
the real-time pixel streams (raw or cross-talk corrected)
the 2-day on Summit image buffer (from Summit and Base only)
the image archive at the Base Facility
the image archive at Archive Facility
2.3.1.4 Image Display Locations
ID: OSS-REQ-0310
Last Modified: 5/19/2011
Specification:
"Quick look" image displays shall be locatde at a minimum at the following locations:
Summit Facility Control Room
Base Facility Control Room
Archive Facility
Headquarters
Data Access Centers
2.3.2 Data Visualization
ID: OSS-REQ-0061
Last Modified: 12/1/2010
Specification:
The LSST Observatory shall provide facilities (physical and software) for the visualization of a
variety of types of data produced by the Observatory at the locations specified in OSS-REQ-0006, including:
Catalog data derived from image analysis
Calibration data and data products, including images and spectra from the ancillary telescopes and cameras
in the Observatory
Data quality metrics derived from the analysis of the Observatory's raw data
Engineering and facilities data, including monitoring and diagnostic data from the Observatory and data
processing systems
Data processing metadata
Selected reference datasets from external sources (e.g., astrometric catalogs)
These facilities shall provide for at least the following types of displays:
Statistical, including histograms, correlation plots, and basic statistical data reductions on selected data
Temporal, showing time histories of selected parameters and of statistical properties of acquired data
Spatial, displaying data overlaid on associated images
2.3.3 Subsystem Telemetry
ID: OSS-REQ-0062
Last Modified: 5/19/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
21
Specification:
All LSST subsystems shall publish telemetry using the Observatory specified protocol (LSST
Document-2233) containing time stamped structures of all command-response pairs and all technical data streams
including hardware health, and status information.
Discussion:
In the context of this requirement a subsystem refers to the three major subsystem of the LSST
Observatory, Telescope, Camera, and Data Management. It can also include other subsystems of each of the three
that are directly connected to the OCS architecture.
Hardware health and status information includes data regarding the correct functionality of all major internal
components and sub-subsystems.
The data for the science, wavefront sensing, and raw guider images are not included in this requirement.
https://www.lsstcorp.org/docushare/dsweb/Get/Document-2233
2.3.3.1 Subsystem Metadata for Science Analysis
ID: OSS-REQ-0063
Last Modified: 5/20/2011
Specification:
The subsystem telemetry shall include all required information (metadata) needed for the scientific
analysis of the survey data.
Discussion:
The specific metadata that each subsystem is required to produce will be detailed as part of the DM
interface control definitions between the Camera, Telescope & Site, and OCS. Collection-1539 contains the lists of
metadata for the EFD as it is developed.
https://www.lsstcorp.org/docushare/dsweb/View/Collection-1539
2.3.3.2 Subsystem State Notification
ID: OSS-REQ-0064
Last Modified: 5/25/2011
Specification:
Each subsystem shall report changes in its internal state consistent with the significant state changes
contained in the Observatory State Model in SysML.
Discussion:
The state change notification include at least those states defined in OSS-REQ-0047, as well as the
following additional states:
System Reset
Emergency Shutdown
Standby / Idle
Reconfiguring
2.3.3.3 Subsystem Status
ID: OSS-REQ-0065
Last Modified: 6/23/2010
Specification:
Each LSST subsystem (or a small number of major subsystem components) shall assess and report an
overall hardware health status.
Discussion:
The primary purpose of these status indicators is for the OCS to be able to orchestrate normal
operations and handle out of normal conditions.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
22
2.3.3.4 Telemetry Database
ID: OSS-REQ-0195
Last Modified: 5/18/2011
Specification
: The LSST System shall capture the telemetry data produced by every subsystem, organize it and
make it available through an Engineering Facility Data Base (EFD).
Discussion:
There will be two kinds of interfaces for querying the EFD. One is to obtain the current value of the
telemetry, a real-time status of the system. The other one is for accessing the history of the telemetry. The access of
large amount of history data may span through more than one distributed instance of the EFD, and such fact must be
transparent to the user performing the query, as well as not having an impact on real-time operations.
https://www.lsstcorp.org/docushare/dsweb/View/Collection-677
2.3.3.4.1 Control Data
ID: OSS-REQ-0196
Last Modified: 5/18/2011
Specification:
The telemetry data shall include reported values needed for the purpose of the real-time control of the
observatory.
2.3.3.4.2 Engineering Data
ID: OSS-REQ-0197
Last Modified: 5/18/2011
Specification:
The telemetry data shall include reported values needed for the purpose of the engineering activities.
2.3.3.4.3 Meta Data
ID: OSS-REQ-0198
Last Modified: 5/18/2011
Specification:
The telemetry data shall include reported values needed for the purpose of the insertion of meta data
alongside the science data.
2.3.3.4.4 Monitoring Data
ID: OSS-REQ-0199
Last Modified: 5/18/2011
Specification:
The telemetry data shall include reported values needed for the purpose of the monitoring activities.
2.3.3.4.5 Telemetry Database Sizing
ID: OSS-REQ-0311
Last Modified: 5/26/2011
Specifications:
The telemetry database shall be sized and support the bandwidths defined in the table
(EFD_OSSparameters) below.
Discussion
: The average rate
EFD_AvgRate
and the estimated data storage requirement i
EFD_DayStore
are
supported in document 7722. There is another set of data (see document 7721) consisting of non-science images that
are not permanently stored in the EFD that pushes the data rate transfer to
Blob_AvgRate
, for a combined rate of
NonScience_MaxRate
.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
23
https://www.lsstcorp.org/docushare/dsweb/Get/Document-7721
https://www.lsstcorp.org/docushare/dsweb/Get/Document-7722
Description
Value
Unit
Name
Long-term mean ingest rate to the Engineering and Facilities
Database required to be supported.
6.5
Mbit/sec
EFD_AvgRate
The minimum supported daily data volume of the engineering
facility data base.
30
GBytes
EFD_DayStore
Long-term mean ingest rate to the Engineering and Facilities
Database of non-science images required to be supported.
15.4
Mbit/sec
Blob_AvgRate
Maximum ingest rate to the Engineering and Facilities Database of
non-science images required to be supported.
21.9
Mbit/sec
NonScience_MaxR
ate
2.3.3.4.6 Initiation of Telemetry Database
ID: OSS-REQ-0312
Last Modified: 5/18/2011
Specification:
Collection and retention of telemetry data shall begin no later than the start of system integration in
the Summit Facility.
2.3.3.4.7 Telemetry Database Retention
ID: OSS-REQ-0313
Last Modified: 5/18/2011
Specification:
The data in the EFD shall be retained at least for the lifetime of the survey.
2.3.4 Subsystem Baseline Performance
ID: OSS-REQ-0066
Last Modified: 5/19/2011
Specification:
Each subsystem shall provide a baseline of the as built performance as determined during acceptance
testing and system integration & test.
Discussion:
The baseline analysis is a deliverable of the subsystem and will be part of the acceptance process. It is
expected that over time the observatory operations staff will modify and add to the analysis as knowledge of the
subsystems improves.
2.3.5 Subsystem Performance Reporting
ID: OSS-REQ-0314
Last Modified: 5/25/2011
Specification:
The LSST Observatory over the course of the 10-year survey shall monitor its performance with
respect to its established baseline and report variances exceeding established thresholds.
2.3.6 Performance & Trend Analysis Toolkit
ID: OSS-REQ-0067
Last Modified: 5/10/2011
Specification:
The LSST system shall provide a common tool kit for conducting performance analysis, including
trending, on the telemetry captured in the Engineering & Facility Database.
Discussion:
This tool kit will be part of the OCS.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
24
2.3.7 Summit Environment Monitoring
ID: OSS-REQ-0068
Last Modified: 4/28/2011
Specification:
The LSST Observatory shall monitor the local observing environment so that delivered data
performances can be assessed against the state of the environment at the time the data were obtained. The
monitoring shall include all natural elements that impact the image data quality and at a minimum shall include the
following as detailed below:
Cloud Coverage
Meteorological Parameters
Atmospheric Turbulence Structure
Integrated atmospheric seeing
Seismic activity
Discussion:
The data generated from the Summit Environmental Monitoring is part of the recorded observatory
telemetry streams (see OSS-REQ-0062).
2.3.7.1 Atmospheric Seeing
ID: OSS-REQ-0069
Last Modified: 12/1/2010
Specification:
For the purpose of monitoring the system performance and optimizing its operation the LSST
Observatory shall provide the necessary instruments to measure the atmospheric seeing independently from the main
observing system.
2.3.7.2 Atmospheric Turbulence Structure
ID: OSS-REQ-0070
Last Modified: 12/1/2010
Specification:
For the purpose of monitoring the system performance and optimizing its operation the LSST
Observatory shall provide the necessary instruments to measure the structure of the atmospheric turbulence in at
least
minTurbLayers
to an altitude of
minTurbHighAltitude
.
Description
Value
Unit
Name
The high altitude limit to which the atmospheric turbulent profile
shall be measured shall be no less than
minTurbHighAltitude.
20000
Meters
minTurbHighAltitu
de
The number of layers for which the atmospheric turbulence structure
will be measured shall be at least
minTurbLayers
.
6
int
minTurbLayers
2.3.7.3 Cloud Mapping and Monitoring
ID: OSS-REQ-0071
Last Modified: 5/19/2011
Specification:
For the purpose of monitoring the system performance and optimizing its operation the LSST
Observatory shall provide the necessary instruments to provide a 2-D map of the cloud cover covering the visible
sky centered on the Summit Site with a cadence equal to or faster than a standard visit. The could map shall as
minimum the properties listed in the table below.
Description
Value
Unit
Name
The angular resolution of the all sky cloud map shall be at least
cloudMapResolution.
1.0
Degrees
cloudMapResolutio
n

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
25
Description
Value
Unit
Name
The angular extent of the all sky cloud map centered on the zenith
point shall be at least
cloudmapCoverage
.
150
Degrees
cloudMapCoverage
2.3.7.4 Weather and Meteorological Monitoring
ID: OSS-REQ-0072
Last Modified: 12/1/2010
Specification:
The LSST Observatory on the summit shall provide local weather conditions that impact, and at a
resolution consistent with, technical and scientific performance. This shall include, at a minimum,
Temperature
Humidity
Wind Speed
Wind Direction
2.3.7.5 Seismic Monitoring
ID: OSS-REQ-0073
Last Modified: 12/1/2010
Specification:
The LSST Observatory shall provide and report real time monitoring of local summit seismic activity
and a near real-time feed back on nearby seismic events to the local operators at the summit and base facilities.
2.4 System Maintenance
ID: OSS-REQ-0074
Last Modified: 1/27/2015
Specification:
The LSST system shall be designed for maintainability of components, and a maintenance plan shall
be implemented to achieve the required survey performance during the life span.
Discussion:
The concept of the maintenance comprises both the idea to facilitate the monitor/inspection/repair activities and the
plan to perform the activities. The maintenance activities and the plan to perform them, will be derived from
documentation delivered as part of each subsystem.
Maintainability features in the designs will include: the adoption of standard components where possible; use of
software and utility systems to track and minimize the spare parts inventories; and technical training and toolsets for
maintenance activities.
Specific standards and codes are detailed below in
System Standards.
2.4.1 Predictive Maintenance
ID: OSS-REQ-0075
Last Modified: 5/19/2010
Specification:
The LSST Observatory shall implement and maintain a comprehensive system-wide predictive
maintenance program based on regular inspection and/or condition monitoring of all major sub-systems including
enclosure, telescope, adaptive optics, and instrumentation.
Discussion:
The goal is to detect and correct performance degradation and/or potential failures before these
problems cause lost science time or significantly reduce system efficiency.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
26
2.4.2 Preventive Maintenance
ID: OSS-REQ-0076
Last Modified: 4/28/2011
Specification:
The LSST Observatory shall implement and maintain a comprehensive system-wide preventive
maintenance program based on vendor recommendation.
Discussion:
This program shall cover all major technical sub-systems including enclosure, telescope, active optics,
instrumentation, and data processing hardware and software. The goal is to maintain system efficiency within
specified ranges and maximize the time between failures.
2.4.3 Maintenance Activity Support
ID: OSS-REQ-0077
Last Modified: 10/25/2010
Specification:
In support of all maintenance activity, both predictive and preventive, the LSST Observatory shall
implement the following systems:
Comprehensive problem reporting, tracking, and management system
Work order driven preventive maintenance support system (usually known as CMMS for Computerized
Maintenance Management System).
Warehouse inventory and property control
Document control center
Analysis tools for supporting predictive maintenance.
2.4.4 Maintenance Reporting
ID: OSS-REQ-0078
Last Modified: 10/25/2010
Specification:
For the purposes of monitoring technical performance, a set of automatic reports based on
engineering telemetry shall be generated on a daily basis.
Discussion
: The reports are based on device/mechanism usage, behavior of their parameters within specified limits,
and correlation with common environmental conditions.
More detailed and specific reports can be generated using the tools specified in
Maintenance Activity Support
.
2.4.5 Maintenance Tracking and Analysis
ID: OSS-REQ-0079
Last Modified: 5/19/2010
Specification:
The LSST Observatory shall maintain a permanent record of the description and time required to
recover from all maintenance events.
2.5 System Availability
ID: OSS-REQ-0080
Last Modified: 5/19/2011
Specification
: The LSST system shall have an availability for science and calibration observations, of at least
plannedAvailability
of observing nights of operation, within the specified performance limits defined under
"Normal Operating Conditions" (see OSS-REQ-0010 above) and the allowed fractional cloud cover
cloudCoverFrac
, in order to achieve the goals given by the survey.
Discussion
: An observing night is considered when weather conditions are within observable limits. Of those
observing nights a percentage is allocated for scheduled downtime and another for unscheduled downtime.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
27
Description
Value
Unit
Name
The minimum allowed fraction of available nights that can be used
when all sources of down time are summed is
plannedAvailability
.
90
Percent
plannedAvailability
An night is considered "observable" when the fractional cloud cover
is less than
cloudCoverFrac
.
62.5
Percent
cloudCoverFrac
2.5.1 Scheduled Down Time
ID: OSS-REQ-0081
Last Modified: 8/5/2010
Specification:
The LSST shall meet the survey specifications allowing for
plannedDownTime
days of scheduled
down time annually for maintenance and repair.
Description
Value
Unit
Name
Allowed down time for scheduled non-observing activities is
scheduledDownTime
.
14
Days
scheduledDownTim
e
2.5.2 Unscheduled Down Time
ID: OSS-REQ-0082
Last Modified: 5/26/2011
Specification:
The LSST shall meet the survey specifications allowing for the equivalent of
unplannedDownTime
days for un-scheduled down time annually for maintenance and/or repair.
Discussion:
The basis for allocating the unscheduled downtime uses "typical" observatory down time of 4% with
2% added to account for the single instrument of the LSST.
This down time covers only the ability to collect survey data.
Description
Value
Unit
Name
The allowed time the system can be down for unplanned events is
unplannedDownTime
.
21
Days
unplannedDownTi
me
2.5.2.1 Unscheduled Downtime Subsystem Allocations
ID: OSS-REQ-0373
Last Modified: 1/27/2015
Specification
: The Telescope & Site, Camera, and Data Management subsystems shall contribute no more than
TSUnschedDowntime, CamUnschedDowntime,
and
DMUnschedDowntime
, respectively, of observatory
unscheduled downtime annually due to failures or unplanned maintenance.
Discussion:
This requirement does not invoke the need to verify by reliability analysis. Verification is by analysis
that identifies likely hardware failures and identifies mitigations to minimize downtime caused by those failures.
Description
Value
Unit
Name
Telescope & Site subsystem unplanned downtime per year
allocation
10
Days
TSUnschedDownti
me
Camera subsystem unplanned downtime per year allocation
10
Days
CamUnschedDownt
ime

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
28
Description
Value
Unit
Name
Data Management subsystem unplanned downtime per year
allocation
1
Days
DMUnschedDownti
me
2.6 System Time Reference
ID: OSS-REQ-0086
Last Modified: 12/1/2010
Specification:
The LSST system shall provide an observatory wide standard time reference that shall be used by all
subsystems where absolute and external time reference is required
2.6.1 Time Accuracy and Precision
ID: OSS-REQ-0087
Last Modified: 8/4/2014
Specification:
Computer clocks used to produce timestamps shall be synchronized with an observatory master clock
to a precision of
timestampPrecision
and an accuracy of
timestampAccuracy
, as given in the table below. This
requirement shall apply separately to each computer clock.
Discussion:
The purpose of time synchronization is to ensure that timestamps recorded in the database are
meaningful regardless of which computer generated the timestamp. To achieve this, an observatory master clock is
distributed to all computer hosts that generate timestamps recorded in LSST telemetry. Current protocols (PTP and
NTPv4) allow system clocks to be synchronized well within the requirement. Timestamps are used to record both
internal and external events as observatory telemetry. The relationship between the timestamp and the actual
physical event, expressed as latency/jitter, depends on both the computer and the hardware (mechanical, electrical,
etc.). It is the responsibility of individual hardware design teams to determine the relevance of latency/jitter. When
cross subsystem dependencies on timestamps exist, additional requirements can be documented in ICDs. The term
"precision" is to be interpreted as a one-sigma statistical measure, and the term "accuracy" as a statistically
determined mean measurement bias.
Description
Value
Unit
Name
Computer clock timestamp accuracy
0.010
Seconds
timestampAccuracy
Computer clock timestamp precision
0.001
Seconds
timestampPrecision
2.6.2 Time Reporting Standard
ID: OSS-REQ-0089
Last Modified: 10/7/2013
Specification:
The time reporting standard shall be International Atomic Time (TAI).
Discussion:
TAI is a purely sequential time standard without leap seconds. It forms the basis of the Terrestrial
Dynamic Time standard from which most other time references can be derived.
2.7 System Standards
ID: OSS-REQ-0090
Last Modified: 9/29/2014
2.7.1 Component Standardization Goal
ID: OSS-REQ-0372
Last Modified: 9/29/2014

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
29
Goal:
The LSST should be designed to standardize site-based components when component functional,
performance, and operational requirements define overlapping solution spaces.
Discussion:
While it is desired to standardize component selection, it is realized that imposing this as a strict
requirement is not practical due to a variety of factors, including component requirements that may require selection
of unique hardware. However, standardizing components, where practical, supports many project operational goals,
including standardization of operational and maintenance procedures. Additionally, standardization reduces the
number of unique spares that must be stocked, helping reduce maintenance costs during commissioning and
operations. To support the goal of component standardization, it is recommended that the subsystems exchange
information on an ongoing basis on their component selection to enable choices to be made informed by what
components are already in use.
2.7.2 Environment
ID: OSS-REQ-0091
Last Modified: 1/27/2015
Specification:
The LSST shall be developed and operated in compliance with all applicable local environmental,
cultural, and permitting regulations for each relevant LSST site and location of work. All LSST development and
operation shall comply with the LSST Site Environmental and Cultural Plan (LPM-52) that describes in detail the
LSST Policy and Procedure for adhering to local permitting requirements and other US Federal guidelines for
extraterritorial projects. In addition to these local and international standards the LSST shall also comply with the
following environmental parameters.
2.7.2.1 Electromagnetic Compatibility
ID: OSS-REQ-0343
Last Modified: 9/26/2012
Discussion:
LSST consists of a collection of commercial and custom electronics supporting a single scientific
instrument. Some parts of the instrument deal with exceptionally small electrical signals and are, thereby,
susceptible to interference from neighboring equipment. Some parts of the instrument deal with large voltage and
current changes and are, thereby, potential sources of interference. It is essential for robust operation of the
Observatory that all electrical and electronic equipment be purchased, designed, fabricated and installed with this in
mind.
2.7.2.1.1 Electromagnetic (RF) Emissions
ID: OSS-REQ-0092
Last Modified: 10/8/2012
Specification:
The LSST Observatory shall not emit electromagnetic radiation on any frequency in accordance to
FCC part 15 Class B standards that significantly interferes with itself (as defined by meeting its performance
specifications) or the operation of any neighboring facility, not including the formal certification defined in those
standards. All off-the-shelf electronic devices that are not compliant require suitable shielding or other mitigation.
Custom designed LSST electronics shall take advantage of all reasonable good practices in design and fabrication to
minimize interference.
2.7.2.1.2 Electromagnetic (RF) Susceptibility
ID: OSS-REQ-0326
Last Modified: 10/8/2012
Specification:
The LSST Observatory shall not be susceptible to electromagnetic emissions consistent with FCC
Part 15 Class A standards and commercial sources within and external to the Summit Facility, not including the
formal certification defined in those standards. All off the shelf electronic components that are not compliant require

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
30
suitable shielding or other mitigation. Custom designed LSST electronics will include all reasonable good practices
in design and fabrication that minimize susceptibility.
Discussion:
This requirement is meant to ensure the LSST design is robust against typical radio emissions in and
around the Summit Facility (e.g. walkie talkie and cell phone transmissions).
2.7.2.2 Night Light Emission
ID: OSS-REQ-0093
Last Modified: 4/28/2011
Specification:
During normal night time operation the LSST Summit Facility shall not generate detectable light
pollution.
Discussion:
The requirement is meant to both protect the scientific integrity of the LSST survey and also minimize
the LSST's impact on neighboring observatories.
2.7.2.3 Radio Active Background
ID: OSS-REQ-0094
Last Modified: 1/27/2015
Specification:
The LSST observatory system, Telescope & Site subsystem, and Camera subsystem shall each have a
project-reviewed radioactive material test plan.
Discussion:
The observatory, T&S, and Camera must develop radioactive material test plans that define testing
approaches that are reasonable such that the subsystems and project as a whole can achieve a radiation level that is
"As Low as Reasonably Achievable" (ALARA). The test plans must specify testing of critical components and
subsystems assemblies to ensure that their contributions are well below the
level of artifacts caused by cosmic
radiation. Critical components and sub-assemblies, as well as test success criteria, will be determined by the
subsystems taking into consideration their distance between the component and sensors, shielding, component mass,
and primary material of the component. A project-reviewed radioactive material test plan means that each
subsystem's test plan must be placed under the appropriate subsystem's change control; initial baselining and any
subsequent updates must include review and input from the LSST Project Systems Engineering (PSE) office. The
LSST observatory system radioactive material test plan must be approved by the LSST Change Control Board
(CCB) and placed under formal configuration control.
2.7.3 Building Codes
ID: OSS-REQ-0095
Last Modified: 2/6/2013
Specification:
All LSST facilities shall comply with the 2006 International Building Code and the accompanying
2006 International Mechanical/Plumbing Codes for the design of the Summit Support Facility. These codes shall
also apply to the LSST Base facility in Chile and the design of all U.S.-based facilities.
In addition, all LSST Facilities in Chile shall comply with the applicable
Norma Chilena:
NCH-431: "Earthquake resistant design of buildings";
NCH-433: "Earthquake resistant design of buildings";
NCH-2369: "Seismic design of industrial structures and installations"; and
with other related regulations regarding seismic design. In cases of conflicting requirements, the most stringent code
shall govern.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
31
2.7.4 Electrical and Controls Standards
ID: OSS-REQ-0096
Last Modified: 4/28/2011
Specification:
For each system Facility the LSST shall develop and document standards for the following:
Control Panels
Electrical and Electromagnetic Compatibility
Controllers and associated software
Utility Connection
Grounding
Summit Facility - Document-TBD
Base Facility - Document-TBD
Archive Facility - Document-TBD
Headquarters - Document-TBD
Discussion:
The objective of these standards is to support efficient operations and minimize the dispersion of final
design elements across the LSST system. This requirement will be applied at the facility/site level to account for
differences in facility/site specific needs.
2.7.5 Minimum Design Lifetime
ID: OSS-REQ-0097
Last Modified: 5/25/2011
Specification:
The LSST Observatory shall be designed for a minimum lifetime of
minDesignLife.
Discussion:
The minimum design lifetime includes the time from initial assembly during construction, 2 years of
commissioning, and 10 years of survey operations.
Description
Value
Unit
Name
The minimum expected lifetime covering mid-construction through
to the end of 10 years of survey operation is
minDesignLife
.
15
Years
minDesignLife
2.7.6 Safety
ID: OSS-REQ-0098
Last Modified: 12/1/2010
Specification:
The LSST shall be designed to achieve the highest level of personnel health and safety performance
in all phases of the project lifecycle. All aspects of the design and construction shall comply with the LSST Safety
Policy, LPM-18. This policy defines the procedures for personnel and equipment safety throughout the design,
construction, and operation phases of the project addressing working conditions and procedures, as well as the
management structure and design features that impact safety throughout the LSST Project.
2.7.6.1 Safety Priorities
ID: OSS-REQ-0099
Last Modified: 12/1/2010
Specification:
The safety priority within the entire LSST shall be (in priority order):
1. The protection of personnel;
2. The protection of the technical integrity of the LSST system and other equipment associated with its
operation; and
3. The protection of scientific data.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
32
2.7.6.2 Hazard Analysis and Safety Practices
ID: OSS-REQ-0100
Last Modified: 4/28/2011
Specification:
The LSST system shall govern its hazard analysis and safety practices (see LPM-49) in an order of
precedence as follows:
1.
Design for Minimum Risk:
The primary means for mitigating risk shall be to eliminate the hazard through
design.
2.
Incorporate Safety Devices:
Protective devices shall be used as part of system design to reduce hazard
risks to an acceptable level where possible. These devices shall be subjected to periodic functional tests and
checks.
3.
Provide warning Devices:
when neither design or safety devices can effectively minimize a hazard risk,
devices shall be used to detect the hazard condition and alert personnel of its presence. These devices may
include visual or audible alarms and/or movable or permanent signs.
4.
Procedures and Training:
Only when it is impractical to substantially eliminate or reduce the hazard, or
where the condition of the hazard indicates additional emphasis, special operating procedures and training
shall be used. All such procedures shall be fully documented.
https://www.lsstcorp.org/docushare/dsweb/Get/LPM-49
2.7.6.3 Safety Plan
ID: OSS-REQ-0101
Last Modified: 12/1/2010
Specification:
Comprehensive safety plans shall be developed and implemented before construction starts at each of
the 4 LSST system sites.
2.7.6.4 Operational Safety Plan
ID: OSS-REQ-0102
Last Modified: 12/1/2010
Specification:
An operational safety plan shall be developed and implemented before the Commissioning phase
starts.
2.7.6.5 Emergency Communications
ID: OSS-REQ-0103
Last Modified: 12/1/2010
Specification:
The LSST shall be designed, and shall include, the necessary communication equipment to support
the necessary machine and personnel communication in both normal and emergency operating conditions at the
summit. Other LSST sites are not specifically addressed due to their proximity to normal municipality infrastructure
and emergency response services.
2.7.6.5.1 Earthquake Display
ID: OSS-REQ-0104
Last Modified: 5/19/2011
Specification:
The summit facility shall include a comfort display to present summit personnel with information on
seismic activity monitored per OSS-REQ-0073 down to a level of 3 on the Richter scale.
2.7.6.5.2 Summit Radio Equipment
ID: OSS-REQ-0105
Last Modified: 12/1/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
33
Specification:
LSST shall include radio communication devices to support the personnel necessary to be on the
remote summit site. This equipment shall be consistent with Summit radio infrastructure already in place.
2.7.7 Health
ID: OSS-REQ-0106
Last Modified: 8/4/2010
Specification:
The LSST shall comply with all applicable local and national environmental and occupational health
codes, regulations, and standards.
2.7.8 Security
ID: OSS-REQ-0107
Last Modified: 9/29/2014
Specification:
The LSST shall provide a secure and safe environment for personnel, equipment, and data at each of
its 4 operational sites throughout the full life cycle of the project.
2.7.8.1 Cyber Security Agency Requirements
ID: OSS-REQ-0108
Last Modified: 5/25/2011
Specification:
The LSST shall comply with funding agency requirements for cyber security appropriate to the
sensitivity of the project and the data it maintains and produces.
Discussion:
This process requires an evaluation of the threat level and of the consequences of a compromise of
security. The bulk of the project will generally be subject to security requirements for what is often called an
"open/public/unrestricted" environment. In such an environment, the cyber security architecture focuses on
maintenance of the integrity of the data and computing systems, and of system availability.
Any sensitive computing systems, such as those used to manage personnel and business data or other Personally
Identifiable Information, will be subject to more stringent requirements. The control systems for the LSST
Observatory will also require additional levels of security appropriate to SCADA (Supervisory Control and Data
Acquisition) for physical systems.
2.7.8.2 Cyber Security Planning
ID: OSS-REQ-0109
Last Modified: 10/7/2013
Specification:
The LSST project shall produce and maintain a cybersecurity plan and corresponding system
architecture.
Discussion:
The plan must comply with agency requirements (see OSS-REQ-0108). It should be based on
established best practices appropriate to the sensitivity of the project and the data it maintains and produces. Within
that context, it will reflect engineering tradeoffs based on an evaluation of the anticipated threats, capabilities of
security systems, the role of personnel in maintaining a secure environment, and the cost of proposed mitigations.
3 Detailed Specifications

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
34
3.1 Science and Bulk Data
The composite requirements below concern the acquisition, processing, and management of science data, as well as
certain other bulk data such as wavefront sensor images.
3.1.1 Scoping
ID: OSS-REQ-0188
Last Modified: 10/7/2013
Discussion:
The scoping requirements control the amount of input data and catalog entries the Data Management
system is expected to process, archive, distribute, and store, and the query and processing load design point for user
support.
The processing load and resources associated with the derived data products are constrained by these requirements,
and may be calculated from them, but do not appear here in the OSS.
Many data products are best defined with respect to content, quantity, or quality given certain reference conditions.
These conditions are also grouped under this requirement.
3.1.1.1 Raw Exposures Per Night, Maximum
ID: OSS-REQ-0189
Last Modified: 5/23/2011
Specification:
The LSST Observatory shall support the acquisition, processing, and archiving of a rate of at least
nRawExpNightMax
new science exposures per night, in isolated peaks, and an average rate of
nRawExpNightWinterAvg
for extended periods.
Discussion:
These rates are derived from the estimate of
nightDurationMax
hours of science observing on the
longest nights of the year, and from the
visitDuration
and
aveVisitInterval
parameters of the standard cadence.
The peak requirement is derived by adding two hours of twilight observing and taking a worst-case scenario of short
slews: it does not account for any time spent moving to a new field beyond the two-second readout period for the
second exposure in a visit.
This requirement does not include calibration exposures, which are considered separately.
Description
Value
Unit
Name
Minimum number of raw science exposures required to be supported
by the LSST Observatory in a single-night burst
2800
int
nRawExpNightMax
Minimum number of raw science exposures required to be supported
by the LSST Observatory over a sustained period (as during the
weeks around the winter solstice)
1960
int
nRawExpNightWint
erAvg
3.1.1.2 Raw Exposures Per Year
ID: OSS-REQ-0190
Last Modified: 10/7/2013
Specification:
The LSST Observatory shall support the acquisition, processing, and archiving of a rate of at least
nRawExpYear
new science exposures per year.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
35
Discussion:
This rate is derived from an estimate of an average of 10 hours of science observing per night, 300
nights per year that are available for observing (rounded up after taking
scheduledDownTime
and
cloudCoverFrac
into account), assuming
visitDuration
and
aveVisitInterval
parameters of the standard cadence, and adding a 10%
margin.
Description
Value
Unit
Name
Minimum number of raw science exposures required to be supported
by the LSST Observatory over the course of a single year
5.5E5
int
nRawExpYear
3.1.1.3 Galaxy Counts
ID: OSS-REQ-0191
Last Modified: 10/7/2013
Specification:
The LSST Data Management system shall be sized to handle approximately
nGalaxyYr1
identified
galaxies by the end of the processing of the first year's data. It shall be designed to scale to
nGalaxySurvey
galaxies
by the end of the planned survey.
Discussion:
These numbers are based on peer reviewed estimates collected in the LSST Science Book, Section
3.7.2, and captured in the DM Sizing Model (LSE-81). They assume survey-depth coverage of 25,000 deg
2
. Their
values depend on the expected depth of single images and the survey. The scaling with time further depends on an
assumed luminosity function.
Description
Value
Unit
Name
Minimum number of identified galaxies required to be supported by
the end of the processing of the first year's data
8.0E9
int
nGalaxyYr1
Minimum number of identified galaxies required to be supported by
the end of the processing of the data from the ten-year survey.
2.0E10
int
nGalaxySurvey
3.1.1.4 Star Counts
ID: OSS-REQ-0192
Last Modified: 10/7/2013
Specification:
The LSST Data Management system shall be sized to handle approximately
nStarYr1
identified
stars by the end of the processing of the first year's data. It shall be designed to scale to
nStarSurvey
stars by the
end of the planned survey.
Discussion:
These numbers are based on peer reviewed estimates collected in the LSST Science Book, Section 3.7,
and captured in the DM Sizing Model (LSE-81). They assume survey-depth coverage of 25,000 deg
2
. Their values
depend on the expected depth of single images and the survey. The scaling with time further depends on an assumed
luminosity function.
Description
Value
Unit
Name
Minimum number of identified stars required to be supported by the
end of the processing of the first year's data
1.3E10
int
nStarYr1
Minimum number of identified stars required to be supported by the
end of the processing of the data from the ten-year survey.
1.7E10
int
nStarSurvey
3.1.1.5 Alerts per Visit
ID: OSS-REQ-0193
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
36
Specification:
The LSST Data Management system shall be sized to accommodate an average value of at least
nAlertVisitAvg
alerts generated per standard visit while meeting all its other requirements. Performance shall
degrade gracefully beyond that limit.
Discussion:
This is derived directly from the SRD specification for
transN.
Description
Value
Unit
Name
Minimum number of alerts required to be accommodated from a
single standard visit
10000
int
nAlertVisitAvg
3.1.1.6 Calibration Exposures Per Day
ID: OSS-REQ-0194
Last Modified: 2/12/2014
Specification:
The LSST Observatory shall be capable of collecting at least
nCalibExpDay
calibration exposures
per day, while meeting all other requirements for the use of day time for maintenance and other activities and at least
nCalExpMax
over a 24 hour period.
Discussion:
These include bias frames, monochromatic flats, broadband flats, and twilight calibration exposures, as
described in the Level 2 Photometric Calibration for the LSST Survey (LSE-180). It is understood that calibration
data for guider sensors is a part of this data set. The specification for
nCalExpMax
is meant to accommodate a
cloudy night that is dedicated to calibration.
Description
Value
Unit
Name
Minimum number of calibration exposures able to be acquired per
day under normal operation shall be at least
nCalibExpDay
.
450
int
nCalibExpDay
The number of calibration exposures that can be acquired over a
single 24 hour period (e.g. on a cloudy night) shall be at least
nCalibExpMax
.
750
int
nCalibExpMax
3.1.1.7 Calibration Exposures per Year
ID: OSS-REQ-0323
Last Modified: 10/7/2013
Specification:
The LSST Observatory shall support the acquisition, processing, and archiving of a rate of at least
nRawCalYear
new Calibration exposures per year.
Description
Value
Unit
Name
The total number of calibration exposures that the observatory must
be capable of support over a 1 year period shall be at least
nCalExpYear
.
1.5E5
int
nCalExpYear
3.1.1.8 Bright, Isolated Point Source
ID: OSS-REQ-0337
Last Modified: 9/22/2012
Specification:
The terms "bright, isolated point source" and "isolated point source" are used repeatedly in the data
quality requirements. This is because many of the requirements are specified as an asymptotic value in the absence
of contributions from photon statistics or overlapping objects/confusion. For the purposes of defining test cases for
these requirements, "bright" shall be understood to mean having a magnitude in the "bright end" range as defined in

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
37
sec. 3.3 of the SRD. "Isolated point source" shall be understood to mean a point source (typically a star) having no
other detected source within a radius of
isolatedRadius
PSF FWHM.
Description
Value
Unit
Name
Radius containing no other detected sources
10
PSF FWHM
isolatedRadius
3.1.2 Science Image Handling Reliability
ID: OSS-REQ-0110
Last Modified: 5/18/2011
Discussion:
The following requirements place constraints on the losses of and damage to science data that has been
archived and that are processed during each visit.
3.1.2.1 Science Image Archiving Reliability
ID: OSS-REQ-0111
Last Modified: 9/21/2012
Specification:
No more than
sciImageLoss
% of science, wavefront, and guider images read out in the camera and
specified to be acquired by Data Management shall be permanently lost or corrupted, integrated over all stages of
data handling through archiving and availability of the image for access in the archive, or have its essential image
acquisition metadata permanently lost or disassociated with the image.
Corruption of images shall mean changes of any image pixel values, with the exception of application of a
compression algorithm. Any such compression algorithm must be shown to have no effect on any SRD requirement.
Discussion:
The "specified to be acquired" language allows for the possibility that under some operating modes,
such as diagnostics, images might be acquired by the camera and deliberately not archived.
Description
Value
Unit
Name
Maximum fraction of read-out raw images permitted to be
permanently lost or corrupted downstream, including loss due to the
loss or corruption of essential associated metadata.
1%
Percent
sciImageLoss
3.1.2.2 Science Visit Alert Generation Reliability
ID: OSS-REQ-0112
Last Modified: 9/22/2012
Specification:
No more than
sciVisitAlertFailure
% of science visits read out in the camera [and specified to be
analyzed by Data Management] shall fail to be subjected to alert generation and distribution, integrated over all
stages of data handling from data acquisition through transmission of the alerts across the project boundary.
Specification:
No more than
sciVisitAlertDelay
% of science visits read out in the camera [and specified to be
analyzed by Data Management] shall have their alert generation and distribution completed later than the SRD
specification for alert latency (
OTT1
).
Discussion:
The "specified to be analyzed" language allows for the possibility that under some operating modes,
such as diagnostics, images deliberately not be analyzed for alerts.
This requirement applies to
visits
, and not to individual alerts, because a specification that, e.g., "no more than 1% of
alerts shall fail to be generated" gets tangled with questions of the scientific performance of the actual alert
detection. This requirement is a performance specification on the DM system, taking the alert-detection algorithm as
a given.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
38
Note:
Visits with alerts delayed beyond the latency specification will not have
all
of their alerts generated late. A
substantial proportion of the alerts for those visits will still be delivered on time.
Description
Value
Unit
Name
Maximum fraction of science visits for which alerts are generated,
but delivered later than the
OTT1
latency specification
1%
Percent
sciVisitAlertDelay
Maximum fraction of visits for which alerts are not generated or
distributed
0.1%
Percent
sciVisitAlertFailure
3.1.3 Data Acquisition
ID: OSS-REQ-0113
Last Modified: 5/23/2011
[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the
hierarchy.]
Discussion:
These requirements deal primarily with the bulk science data.
3.1.3.1 Acquisition of Science Sensor data
ID: OSS-REQ-0114
Last Modified: 5/18/2011
Specification:
The LSST data management system shall acquire science images from the camera, for archiving and
for further processing.
3.1.3.2 Ancillary Image Data
ID: OSS-REQ-0315
Last Modified: 5/18/2011
Specification:
The LSST shall provide for the acquisition of other ancillary image data (e.g. data from the auxiliary
telescope) needed for the analysis of the science data.
3.1.3.3 Wavefront Sensor Data
ID: OSS-REQ-0316
Last Modified: 5/18/2011
Specification:
The LSST shall provide for the acquisition of wavefront images used determine the alignment,
surface control, and knowledge of the instrumental PSF over the FOV.
3.1.4 Data Processing
ID: OSS-REQ-0116
Last Modified: 5/18/2011
[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the
hierarchy.]
Discussion:
These requirements enumerate the general principles that govern the processing of science data.
3.1.4.1 Automated Production
ID: OSS-REQ-0117
Last Modified: 8/30/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
39
Specification:
Level 1 Data Product production shall proceed without the need for routine human intervention in the
course of a night's observing.
3.1.4.2 Consistency and Completeness
ID: OSS-REQ-0118
Last Modified: 8/30/2010
Specification:
The LSST data management system shall ensure that internal processing tasks are carried out on self-
consistent and complete inputs, and that means are provided for users to achieve this in their own processing tasks.
Discussion:
it should not be possible to inadvertently mix data, calibrations, and code from different data releases.
All available data shall be used, and no piece of input data shall be inadvertently double-counted.
3.1.4.2.1 Completeness
ID: OSS-REQ-0119
Last Modified: 8/30/2010
Specification:
Completeness means that every appropriate piece of input data from the data sets intended to be
processed, such as images or catalog entries, shall be included exactly once in the processing; i.e., that no data will
be inadvertently skipped and that no single piece of data will be used, counted, etc. more than once.
Discussion:
3.1.4.2.2 Consistency
ID: OSS-REQ-0120
Last Modified: 3/16/2010
Specification:
Consistency shall mean that all input data, such as raw images, facility data, catalogs, processed
images, metadata, calibrations, camera configuration data, etc., match each other and arise from consistent previous
stages of processing, and that all processing is carried out within a single major code release.
3.1.4.3 Open Source, Open Configuration
ID: OSS-REQ-0121
Last Modified: 8/30/2010
Specification:
All LSST-written data processing software shall be released under an open-source license. All
configuration information necessary for users to be able to apply the software to reproduce LSST's processing shall
also be made publicly available.
Discussion:
The LSST software is permitted to depend on other open-source software packages, and will establish a
configuration control mechanism for determining which are acceptable for use in the project.
Discussion:
This specification does not prohibit the LSST
production
system from using infrastructure with a
proprietary component, if that is justified by a cost-benefit analysis. The software itself must be open-source, and
must be able to be run in at least small-scale production on open platforms.
3.1.4.4 Provenance
ID: OSS-REQ-0122
Last Modified: 9/21/2012
Specification:
The LSST Data Management system shall record provenance data on all its processing activities: all
information necessary to reproduce computed data products from the associated raw data, and to understand the
processing history of any data product.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
40
This shall include at least: software version and build information, settings of all configurable parameters, history of
processing steps, identification of all calibration constants used in processing, and hardware and operating system
configurations used.
Discussion:
The intent is for provenance information to be sufficient to support the Reproducibility requirement.
3.1.4.5 Reproducibility
ID: OSS-REQ-0123
Last Modified: 11/18/2010
Specification:
The LSST data management system shall ensure that the results of processing of data are
reproducible. Any data processing task, when re-run based on the provenance data from the previous run, on the
same system, shall produce the same results (with the exception of provenance data or other execution records that
depend on the wall-clock time or on variable system loads). Tasks re-run on different systems shall produce the
same results to the extent computationally feasible.
Discussion:
"Computationally feasible" refers to the fact that floating-point operations typically can return slightly
different results on different hardware platforms. LSST code is required to use reasonable care in the
implementation of floating-point computations to avoid the unnecessary accumulation of error, but is not required to
adopt computationally costly defensive techniques to avoid differences altogether.
3.1.4.6 Software Development Standards
ID: OSS-REQ-0124
Last Modified: 8/30/2010
Specification:
The LSST project shall define a set of software development standards that shall govern all code
developed under project auspices, as well as open-source code contributed to and accepted by the project from
outside. These standards shall take account of best practices in scientific software development and shall incorporate
specifications of external programming language and operating system API standards where appropriate.
The software development standards shall be devised to meet applicable project requirements, and shall be under
project configuration control.
Discussion:
It is intended that these standards will include, for example, statements of which specific version of the
C++ and POSIX standards the project will follow.
3.1.5 Data Products
ID: OSS-REQ-0125
Last Modified: 11/23/2010
Discussion:
This composite requirement contains only the definitions for what data products are required to exist. It
does not cover
how
they are produced nor where or how they are
archived
nor what means and level of
access
are to
be provided.
3.1.5.1 Level 1 Data Products
ID: OSS-REQ-0126
Last Modified: 10/7/2013
Specification:
Level 1 data products are intended to enable time-domain science use cases requiring timely alerting
and follow-up. They are the result of processing of the stream of image data from the Camera during normal
observing.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
41
Discussion:
The baseline list of Level 1 data products is provided as the composite contents of this requirement.
3.1.5.1.1 Level 1 Data Product Availability
ID: OSS-REQ-0127
Last Modified: 10/8/2013
Specification:
With the exception of alerts and Solar System Orbits, all Level 1 Data Products shall be made public
within time
L1PublicT
of the acquisition of the data. Solar System Orbits shall be made available within
L1PublicT
of successful moving source linkage and orbit computation. Alerts shall be made available within time
OTT1
, from the conclusion of readout of the raw exposures used to generate each alert to the distribution of the alert
to community distribution mechanisms.
Discussion:
Level 1 Data Products will in general arise from either the nightly Alert Production or from the daily
processing of each night's data, and will be released to the public promptly following the completion of processing.
There is no high-level requirement in the SRD on the latency of delivery to external users of Level 1 data products
other than transient alerts, but they should be distributed in a timely way.
3.1.5.1.2 Alerts
ID: OSS-REQ-0128
Last Modified: 8/3/2010
Specification:
The Level 1 Data Products shall include the Alerts produced as part of the nightly Alert Production.
3.1.5.1.3 Exposures (Level 1)
ID: OSS-REQ-0129
Last Modified: 10/7/2013
Specification:
The Level 1 Data Products shall include the following types of Exposures:
Raw Exposures as obtained from the Camera and assembled/re-formatted for processing
Processed Exposures (trimmed, de-biased, flattened, etc. - i.e., provisionally calibrated)
Difference Exposures.
Discussion:
All exposures, other than raw exposures, may be regenerated on demand from raw data, rather than be
physically stored.
3.1.5.1.4 Catalogs (Level 1)
ID: OSS-REQ-0130
Last Modified: 10/7/2013
Specification:
The Level 1 Data Products shall include the following catalogs:
Exposure meta-data
Difference Sources (DIASources, detected by comparing visits with reference images for the same field)
Difference Objects (DIAObjects, inferred from positionally coincident DIASources)
Difference Forced Sources (DIAForcedSources, obtained by performing photometry at the predicted
location of previously detected DIAObjects)
Solar System Objects (SSObjects, detected by associating sets of DIASources consistent with motion on
Keplerian orbits around the Sun)
Discussion:
These catalogs are all also recreated from scratch during the production of each Data Release. New
Solar System Objects will be identified in daily post-processing.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
42
3.1.5.1.5 Nightly Summary Products
ID: OSS-REQ-0131
Last Modified: 8/3/2010
Specification:
The Level 1 Data Products shall include a variety of reports, generated every night, that summarize
the scientific quality of the Level 1 data (SDQA metrics), and the associated Observatory performance and
performance of the Data Management subsystem.
3.1.5.1.6 Engineering and Facility Database Archive
ID: OSS-REQ-0132
Last Modified: 8/3/2010
Specification:
The Level 1 Data Products shall include a daily update of the Archive Center copy of the
Engineering and Facilities Database (EFD), including all data from the Summit/Base copy of the EFD associated
with other released Level 1 Data Products.
3.1.5.1.7 Level 1 Data Product Quality
ID: OSS-REQ-0147
Last Modified: 10/7/2013
Discussion:
The requirements in this area specify the scientific performance required of the LSST Level 1 data
products. These are driven by the needs of the science missions in the LSST SRD.
3.1.5.1.7.1 Level 1 Catalog Precision
ID: OSS-REQ-0149
Last Modified: 10/7/2013
Specification:
Data processing shall contribute no more than a fraction
dmL1PhotoErr
to point source photometric
errors in Level 1 data products. Data processing shall contribute no more than an RMS error of
dmL1AstroErr
to
point source astrometric errors in Level 1 data products.
Discussion:
This requirement will be tested with simulation, and in commissioning using repeated observations of
one or more fields.
Description
Value
Unit
Name
Maximum contribution from DM to Level 1 point source astrometric
errors
0.1
arcsec
dmL1AstroErr
Maximum contribution from DM to Level 1 point source
photometric errors
6
mmag
dmL1PhotoErr
3.1.5.1.7.2 Level 1 Photometric Zero Point Error
ID: OSS-REQ-0152
Last Modified: 10/7/2013
Specification
: The photometric zero point determined for each CCD in the Level 1 data products shall agree with
the final zero point result from photometric calibration within
photoZeroPointOffset
.
Discussion:
This is meant to be interpreted as a requirement on the accuracy of the Level 1 photometric zero-point
determination algorithm compared to its Level 2 counterpart, and not a requirement on the weather (e.g., the
presence or structure of clouds).
Description
Value
Unit
Name

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
43
Description
Value
Unit
Name
Maximum photometric zero point offset between CCDs and final
photometriccalibration
50
mili-Mag photoZeroPointOffs
et
3.1.5.1.7.2.1 Alert Completeness and Purity
ID: OSS-REQ-0166
Last Modified: 10/7/2013
3.1.5.1.7.2.2 Difference Source Spurious Probability Metric
ID: OSS-REQ-0351
Last Modified: 10/8/2013
Specification:
The Observatory shall develop a metric to characterize the probability of each reported difference
source being spurious.
Discussion:
This spuriousness metric will be “prior free” to the extent possible. For example, while it may make use
of information from the source and image characterization (e.g., comparison of source to PSF morphology), as well
as the information on the Telescope and Camera system (e.g., ghost maps, defect maps, etc.), it will not use any
information about the astrophysical neighborhood of the source, whether it has been previously observed or not, etc.
The intent is to avoid introducing a bias against unusual sources or sources discovered in unusual environments.
The performance of this metric will be assessed by simulations, by insertion and recovery of artificial sources, and
comparisons to ground truth where known (i.e., asteroids, known variable stars, known variable quasars, etc).
3.1.5.1.7.2.3 Difference Source Sample Completeness
ID: OSS-REQ-0352
Last Modified: 10/7/2013
Specification:
For each visit, the Observatory shall estimate the detected difference source sample completeness and
purity as a function of spuriousness metric threshold cut.
Discussion:
Assuming some spuriousness threshold
T
, a sample of sources with spuriousness
s > T
will have some
purity (defined as the ratio of the number real sources with
s > T
and the number of all sources with
s > T
), and
completeness (defined as the ratio of the number of real sources with
s > T
, and the total number of real sources).
This information will aid the end users in selecting the spuriousness threshold appropriate for their particular science
case.
3.1.5.1.7.2.4 Difference Source Spuriousness Threshold - Transients
ID: OSS-REQ-0353
Last Modified: 10/8/2013
Specification:
There shall exist a spuriousness threshold
T
for which the completeness and purity of selected
difference sources are higher than
transCompletenessMin
and
transPurityMin
, respectively, at the SNR detection
threshold
transSampleSNR
. This requirement is to be interpreted as an average over the entire survey.
Discussion:
This specification captures representative completeness and purity rates supportive of time-domain
science cases. Note that these are rates determined only using the spuriousness metric cut; it is likely the end-users
will perform further classification steps to increase the purity of their samples, depending on their particular science
case.
This specification will be tested using simulations, by insertion and recovery of artificial sources, and comparisons
to ground truth where known (i.e., asteroids, known variable stars, known variable quasars, etc).

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
44
Description
Value
Unit
Name
Minimum average completeness for transient science
90
Percent
transCompleteness
Min
Minimum average purity for transient science
95
Percent
transPurityMin
SNR threshold at which the above are evaluated
6
int
transSampleSNR
3.1.5.1.7.2.5 Difference Source Spuriousness Threshold - MOPS
ID: OSS-REQ-0354
Last Modified: 10/8/2013
Specification:
There shall exist a spuriousness threshold
T
for which the completeness and purity of difference
sources are higher than
mopsCompletenessMin
and
mopsPurityMin
, respectively, at the SNR detection threshold
orbitObservationThreshold
. This requirement is intended to be interpreted as an average for any one month of
observing.
Discussion:
This specification captures representative completeness and purity rates needed to enable successful
identification and linking of observed Solar System objects. In particular, the need to have a Solar System object
repeatedly detected
orbitObservation
times in
orbitObservationInterval
days strongly prefers high completeness,
even at the expense of purity.
This specification will be tested using simulations, by insertion and recovery of artificial sources, and comparisons
to ground truth where known (i.e., asteroids, known variable stars, known variable quasars, etc).
Description
Value
Unit
Name
Minimum average completeness for Solar System object discovery
99
Percent
mopsCompleteness
Min
Minimum average purity for Solar System object discovery
50
Percent
mopsPurityMin
3.1.5.1.7.3 Level 1 Difference Source - Difference Object Association Quality
ID: OSS-REQ-0160
Last Modified: 10/7/2013
Specification:
The fraction of isolated Difference Sources not flagged as likely artifacts that are associated with an
incorrect Difference Object shall be less than
sourceMisassociation
for Difference Sources brighter than
sourceAssocThreshold
sigma in a single visit.
Discussion:
Source association algorithms that take Difference Object characteristics, such as proper motions,
positional error estimates, or shapes, may be needed to satisfy this requirement. The verification method will be by
comparison with simulated inputs.
Description
Value
Unit
Name
Significance threshold for testing of Source-Object associations
5
Sigma
sourceAssocThresh
old
Maximum fraction of significant Source detections that may be
associated with the wrong Object
0.1
Percent
sourceMisassociatio
n
3.1.5.1.7.4 Level 1 Moving Object Quality
ID: OSS-REQ-0159
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
45
Specification:
Valid identification and orbits shall be determined for at least a fraction
orbitCompleteness
of Solar
System objects which are detected
orbitObservations
times in
orbitObservationInterval
days at a level
orbitObservationThreshold
sigma or more above the single frame background.
Discussion:
Valid identification means that detections of the same Solar System objects have been correctly
associated as such. The verification method for this requirement will be comparison with simulated inputs.
Description
Value
Unit
Name
Minimum fraction of Solar System objects meeting reference
criteria for which valid orbits shall be determined
95%
Percent
orbitCompleteness
Interval over which a reference test case Solar System object must
be observed within a night
90
minutes
orbitNightlyObserv
ationInterval
Interval over which a reference test case Solar System object must
be observed
3
days
orbitObservationInt
erval
Number of detections within a single night required to define the
reference test case for Solar System objects
2
int
orbitObservations
Significance threshold required for moving object detections to be
included in the reference test case definition
5
Sigma
orbitObservationThr
eshold
3.1.5.2 Level 2 Data Products
ID: OSS-REQ-0133
Last Modified: 9/21/2012
Specification:
Level 2 Data Products shall periodically be derived from a processing pass over the complete data
set.
Discussion:
The baseline list of Level 2 data products is provided as the composite contents of this requirement.
3.1.5.2.1 Level 2 Data Product Availability
ID: OSS-REQ-0134
Last Modified: 2/9/2015
Specification:
All Level 2 Data Products shall be made public as part of a Data Release, with releases coming at
least once every time
DRT1
, and as soon as possible following the completion of data release processing as is
consistent with verifying the applicable data quality requirements.
Discussion:
Data Release processing will be initiated more frequently during the first year of the survey.
3.1.5.2.2 Uniformly calibrated and processed versions of Level 1 Data Products
ID: OSS-REQ-0135
Last Modified: 5/18/2011
Specification:
In association with the production of the Level 2 Data Products, a data release shall also include
uniformly processed and calibrated versions of all the Level 1 Data Products.
3.1.5.2.3 Co-added Exposures
ID: OSS-REQ-0136
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
46
Specification:
The Level 2 Data Products shall include the following types of co-added Exposures, covering the full
exposed area of the survey:
Template co-adds for creating Difference Exposures, per filter band
Detection co-adds for object detection, optimized for the faintest limiting magnitude; may be both multi-
band and single-band
Multi-band (RGB) co-adds for visualization and EPO
3.1.5.2.4 Catalogs (Level 2)
ID: OSS-REQ-0137
Last Modified: 10/7/2013
Specification:
The Level 2 Data Products shall include the following catalogs, created anew, uniformly, during the
production of each Data Release:
Object
Solar System Object
Source
Forced Source
In addition, the Exposure catalog shall be updated with the latest derived metadata, such as WCS and PSF.
3.1.5.2.5 Release Independence
ID: OSS-REQ-0138
Last Modified: 11/18/2010
Specification:
Each Data Release shall consist of a complete reprocessing of the entire LSST data set on a uniform
footing, and shall not require access to the data products of any previous Data Release to interpret.
Discussion:
This does not prevent some results of one Data Release from being used as a seed for an iterative
refinement of some calibration or reference catalog. It does require that any data so used, e.g., from Data Release N-
1, be incorporated by value as part of the contents of Data Release N.
3.1.5.2.6 Level 2 Data Product Quality
ID: OSS-REQ-0338
Last Modified: 10/7/2013
Discussion:
The requirements in this area specify the scientific performance required of the LSST Level 2 data
products. These are driven by the needs of the science missions in the LSST SRD.
3.1.5.2.6.1 Level 2 Catalog Accuracy
ID: OSS-REQ-0162
Last Modified: 10/7/2013
Specification:
DM processing shall result in products with photometric accuracy and precision consistent with OSS-
REQ-0275. DM processing shall contribute no more than an RMS error of
dmL2AstroErr
to point source
astrometric errors in Level 2 data products.
Discussion:
The verification method for this requirement will be comparison with simulated inputs.
Description
Value
Unit
Name
Maximum contribution from DM to Level 2 point source astrometric
errors
0.05
arcsec
dmL2AstroErr

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
47
3.1.5.2.6.2 World Coordinate System Accuracy
ID: OSS-REQ-0153
Last Modified: 9/22/2012
Specification
: WCS inaccuracies, including any refinements due to astrometric calibration, in processed images
shall contribute no more than
wcsAbsoluteError
to the PSF FWHM of template and deep detection coadds.
Description
Value
Unit
Name
Maximum contribution from WCS inaccuracy to the PSF FWHM in
template and deep detection coadds
0.1
Pixels
wcsAbsoluteError
3.1.5.2.6.3 Level 2 Source-Object Association Quality
ID: OSS-REQ-0339
Last Modified: 5/3/2012
Specification:
The Level 2 source-object association quality requirements are the same as at Level 1; see OSS-
REQ-0160.
3.1.5.2.6.4 Coaddition for Deep Detection
ID: OSS-REQ-0157
Last Modified: 10/7/2013
Specification
: False detections on the deep detection coadds caused by unremoved artifacts from moving objects,
transient objects, and other instrumental artifacts (e.g. glints) shall be no more than
falseDeepDetect
fraction of all
detections on those coadds. This specification will be tested using simulations under realistic survey conditions
encountered in Commissioning.
Discussion:
The scientific rationale for this requirement is that statistical studies of real objects (galaxies, stars) are
not overwhelmed by false detections. 0.1% is a reasonable number that achieves this. This is also a reasonable upper
limit based on experience with existing surveys.
Description
Value
Unit
Name
Fraction of all detections on deep detection coadds caused by
unremoved artifacts
0.1%
percent
falseDeepDetect
3.1.5.2.6.5 Coaddition for Templates for Subtraction
ID: OSS-REQ-0158
Last Modified: 2/9/2015
Specification
: Subtraction templates shall contribute no more than a fraction
templateNoiseLevelY1
to the noise of
the difference images in year 1 of the survey and
templateNoiseLevelY2
to the noise in subsequent years of the
survey. (The variance of the difference image shall be no more than 1 +
templateNoiseLevelY1
times the variance
of the single visit image.)
Discussion:
Note that this requirement imposes a constraint on the scheduler to obtain some minimum number of
exposures of each part of the sky in order for it to be met. The time variation in this requirement reflects the fact that
the first-year templates may not have as many epochs available as subsequent years.
Description
Value
Unit
Name
Maximum permissible fraction of the noise level in difference
images contributed by the subtraction template in Year 1
40
Percent
templateNoiseLevel
Y1

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
48
Description
Value
Unit
Name
Maximum permissible fraction of the noise level in difference
images contributed by the subtraction template in Year 2 and
following
20
Percent
templateNoiseLevel
Y2
3.1.5.2.6.6 Deep Detection and Measurement Quality
ID: OSS-REQ-0161
Last Modified: 10/7/2013
Specification:
The deep detection and measurement shall meet the implied requirements from the SRD on coadded
depth, assuming the nominal survey conditions.
For a galaxy with elliptical isophots and Sersic radial profile with radius
ellipTestRadius
and Sersic index
ellipTestSersicIndex
, the ellipse parameters shall be measured to an accuracy
ellipAccuracy1
for galaxies detected
on the coadd at a signal-to-noise
ellipTestSNR1
, and
ellipAccuracy2
for galaxies detected on the coadd at a signal-
to-noise
ellipTestSNR2
.
Discussion:
While the detection will be performed on full-depth coadds, the measurement may use techniques such
as multifit,that perform measurements using individual epoch data. The verification method for this requirement will
be comparison with simulated inputs.
Description
Value
Unit
Name
Galaxy radius definition for the ellipse parameter accuracy test
5
Arcsec
ellipTestRadius
Galaxy Sersic index definition for the ellipse parameter accuracy
test
1
float
ellipTestSersicIndex
Reference SNR #1 for ellipse parameter accuracy test
10
int
ellipTestSNR1
Reference SNR #2 for ellipse parameter accuracy test
1000
int
ellipTestSNR2
Maximum RMS error on ellipse parameters measured for a galaxy
of magnitude
ellipTestSNR1
1
Percent
ellipAccuracy1
Maximum RMS error on ellipse parameters measured for a galaxy
of magnitude
ellipTestSNR2
.01
Percent
ellipAccuracy2
3.1.5.2.6.7 Object Deblending
ID: OSS-REQ-0155
Last Modified: 10/7/2013
Specification:
The Observatory shall be capable of measuring properties of overlapping (blended) objects. Any
degradation of accuracy and precision in measurement of blended objects shall be bounded by the need to satisfy
LSR-REQ-0043 through LSR-REQ-0046.
Discussion:
This requirement will give rise to a deblender software component, or an algorithm to perform
simultaneous measurements of blended objects. While it is extremely difficult to write quantitative yet all-
encompassing and actionable requirements on the deblender, it is understood that it is primarily an enabling
component to perform measurements and statistical studies involving those measurements. Therefore, its
performance will be evaluated by assessing the efficacy of measurements that employ it, and studies that depend on
those measurements (e.g., in the context of weak lensing).
3.1.5.2.6.8 Level 2 Moving Object Quality
ID: OSS-REQ-0340
Last Modified: 5/3/2012

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
49
Specification:
The Level 2 moving object quality requirements are the same as at Level 1; see OSS-REQ-0159.
3.1.5.2.6.9 Catalog Completeness and Reliability
ID: OSS-REQ-0164
Last Modified: 5/3/2012
Specification:
The object catalog completeness and reliability shall be determined by the data management system
for a variety of astrophysical objects to be specified by the LSST Science Council.
Discussion:
Objects that will be evaluated for completeness in the catalogs will include at least stars of a range of
colors, small galaxies on both the red- and blue-sequence at a range of redshifts, and supernovae at a range of
redshifts, and will be reported as a function of magnitude.
Further, provisions will be made to determine completeness and reliability of more specialized object types through
injection of synthetic objects into the DM pipelines during the Data Release processing (ie. not part of the live data
stream).
3.1.5.3 Level 3 Data Products
ID: OSS-REQ-0139
Last Modified: 10/7/2013
Specification:
The LSST Observatory shall support Level 3 Data Products that are the result of processing based on
Level 1 and Level 2 Data Products, of a nature specified by users (by the provision of code and/or processing
configuration data).
Discussion:
This is flowed down from LSR-REQ-0041.
3.1.5.3.1 Production
ID: OSS-REQ-0140
Last Modified: 8/3/2010
Specification:
It shall be possible to create Level 3 Data Products either using external or internal (Data Access
Center) resources, provided they meet certain requirements. LSST shall provide a set of specifications and a
software toolkit to facilitate this.
Level 3 Data Products may consist of new catalogs, additional data to be federated with existing catalogs, or image
data.
3.1.5.3.2 Storage
ID: OSS-REQ-0141
Last Modified: 8/3/2010
Specification:
The LSST Data Management system shall provide for the archiving of Level 3 Data Products that
meet project-specified requirements.
3.1.5.3.3 Access
ID: OSS-REQ-0142
Last Modified: 8/3/2010
Specification:
Archived Level 3 Data Products shall be capable of being federated with and analyzed in conjunction
with Level 1, Level 2, and other Level 3 Data Products. The LSST project shall support access controls for Level 3
Data Products that allow them to be restricted to specific individuals or groups as well as released for public access.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
50
3.1.5.3.4 Resource Allocation
ID: OSS-REQ-0143
Last Modified: 8/3/2010
Specification:
The LSST project shall define a resource allocation policy and mechanism for arbitrating among the
calls on Level 3 Data Product production, archiving, and analysis resources.
3.1.5.4 Internal Data Products
ID: OSS-REQ-0144
Last Modified: 5/19/2011
[This is a composite requirement in the SysML model, signifying simply the union of the requirements below it in the
hierarchy.]
3.1.5.4.1 Science Data Quality Analysis
ID: OSS-REQ-0145
Last Modified: 10/7/2013
Specification:
The facilities and software of LSST Observatory shall be designed and built so that Data Quality
Analysis during operations is supported.
Discussion:
For example, a DQA group should be able to monitor metrics and undertake data explorations of
outliers. Automated searches and monitoring of known issues (example: known systematics) during pipeline
processing could provide alerts to the operator and DQA group.
3.1.5.4.2 WCS Reporting
ID: OSS-REQ-0146
Last Modified: 5/18/2011
Specification:
The LSST data management system shall make available to other Observatory systems a WCS
solution for each exposure. The WCS is a computational map from pixel coordinates to sky (ra, dec) coordinates,
and will have an RMS error of no more than
wcsReportingPrecision
within a time
wcsReportingLatency
of the
completion of data readout for a standard visit.
Discussion:
This is in addition to the archiving of the WCS solution as part of the metadata for each processed
exposure. The purpose of this report is for the monitoring and potential recalculation of the accuracy of the mount
model. The WCS reporting will be done with using the OCS publish/subscribe mechanism used for other
observatory telemetry reporting.
Description
Value
Unit
Name
Maximum RMS uncertainty on the comparison of observed and
reference star positions from the real-time WCS reporting
0.2
ArcsecRMS wcsReportingPrecis
ion
Maximum time for the reporting of telemetry data containing WCS
solutions from the completion of the readout of the data for a
standard visit
60
Seconds
wcsReportingLaten
cy
3.1.6 Data Archiving
ID: OSS-REQ-0167
Last Modified: 11/23/2010
Specification:
The LSST project shall create and manage an archive of all its public data products and the raw data
necessary to reproduce them. In addition, the archive shall contain all necessary engineering and calibration data for
the full understanding of the performance and operation of the Observatory.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
51
3.1.6.1 Science Sensor Raw Data
ID: OSS-REQ-0168
Last Modified: 8/27/2010
Specification:
The LSST project shall archive all raw data acquired from the science sensor array during operation
of the Observatory.
3.1.6.2 Data Products
ID: OSS-REQ-0169
Last Modified: 5/23/2011
Specification:
The LSST project shall archive each of its Level 1 and Level 2 data products, or the complete set of
inputs and provenance necessary to reproduce it, for the lifetime of the survey.
Discussion:
Some data products are archived, while others, such as calibrated exposures, are intended to be
recreated on demand.
3.1.6.3 Calibration Data
ID: OSS-REQ-0170
Last Modified: 8/27/2010
Specification:
The LSST project shall archive all raw data acquired from the calibration instrumentation and
processes.
3.1.6.4 Engineering and Facilities Data
ID: OSS-REQ-0171
Last Modified: 5/18/2011
Specification:
The LSST project shall archive all engineering and facility data required to (recreate the physical
state of the observatory).
Discussion:
This is not intended to be a live copy of the EFD, but rather a periodic transfer of a copy of the live
database operating at the Base Facility.
3.1.6.5 Provenance Archiving
ID: OSS-REQ-0172
Last Modified: 8/30/2010
Specification:
The LSST project shall archive all processing provenance associated with archived data products.
3.1.6.6 Wavefront Sensor Raw Data
ID: OSS-REQ-0173
Last Modified: 10/7/2013
Specification:
The LSST project shall archive all raw data acquired from the wavefront sensing system during
operation of the Observatory.
3.1.6.7 Data Archive Lifetime
ID: OSS-REQ-0174
Last Modified: 5/23/2011
Specification:
The LSST data archive design shall facilitate the maintenance of the archive beyond the lifetime of
the survey.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
52
Discussion:
The project recognizes that there will be great long-term interest in the availability of its data set.
Planning for long-term data curation should be guided by funding agency policies and requirements. This is an
active area of research and policy development at present, which LSST should follow as the design and construction
process continues.
This requirement does not commit the project to fund the operations costs of the archive beyond the lifetime of the
survey. The intent here is to facilitate an orderly transition.
3.1.6.8 Redundant Backup of Archive
ID: OSS-REQ-0175
Last Modified: 5/23/2011
Specification:
The LSST project shall ensure that a redundant and physically separate copy is maintained of the
1. raw science data;
2. raw calibration data;
3. the full engineering and facility data required to make use of the science and calibration raw data above;
and
4. all science data products or the data necessary to reproduce them.
Discussion:
This requirement goes beyond merely using the appropriate engineering required to meet the archive
reliability requirements. It requires a backup that can be used for disaster recovery. The intent is that this redundant
copy will be maintained at the Base Facility. It does not have to have the access performance required of the "live"
copy.
3.1.7 Data Access
ID: OSS-REQ-0176
Last Modified: 11/23/2010
Specification:
The LSST Data Management System shall provide open access to all LSST Level 1 and Level 2 Data
Products, as defined in the LSST System Requirements and herein, in accordance with LSSTC Board approved
policies. The LSST project shall make available open-source software for querying and processing the data products
and for generating Level 3 Data Products, and limited computing and storage resources for performing such analyses
and productions.
3.1.7.1 Data Access Environment
ID: OSS-REQ-0177
Last Modified: 5/18/2011
Specification:
The LSST shall provide an open-source environment for access to its public data products, including
images and catalogs.
Discussion:
It is expected that this software will be written to be compatible with common varieties of Linux, and
perhaps other widely available Unix-like operating systems.
See also the "Software Development Standards" requirement elsewhere in this document.
It is a design goal of the LSST Data Management software that it be portable within the family of Unix-like
operating systems. It is also a goal to separate, as much as possible, the parts of the code that implement substantive
image processing and astronomical algorithms from the parts with platform dependencies.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
53
3.1.7.2 Data Distribution
ID: OSS-REQ-0178
Last Modified: 8/29/2010
Specification:
The LSST project shall facilitate the distribution of its data products in bulk to other sites and
institutions willing to host it, in accordance with LSSTC Board approved policies for data release.
Discussion:
This does not require the LSST project to absorb the marginal costs of the actual distribution, e.g., the
provision of increased network bandwidth between the Archive Center and the external consumer.
3.1.7.3 Data Products Processing Infrastructure
ID: OSS-REQ-0179
Last Modified: 11/18/2010
Specification:
The Data Management System shall provide at least a fraction
userComputingFraction
of its total
capability for user-dedicated processing and user-dedicated storage, including for the generation of Level 3 data
products.
Discussion:
This allocation does not include the resources needed to support the expected load of queries against the
catalog database.
3.1.7.4 Data Products Query and Download Availability
ID: OSS-REQ-0180
Last Modified: 5/23/2011
Specification:
The data product query and download system at each Data Access Center shall be available to end
users a fraction
dpAvailabilityFraction
of the time, averaged over a year. Individual outages shall be no longer than
dpAvailabilityOutage
working days.
These include both scheduled and unscheduled downtime.
Description
Value
Unit
Name
Minimum fraction of the time that data products are available for
query and/or download, including scheduled and unscheduled
downtime.
98
Percent
dpAvailabilityFracti
on
Maximum duration of a single outage of data product access, in
working days.
3
Days
dpAvailabilityOutag
e
3.1.7.5 Data Products Query and Download Infrastructure
ID: OSS-REQ-0181
Last Modified: 8/29/2010
Specification:
The LSST project shall provide processing, storage, and network resources for general community
query and download access to LSST data products.
Discussion:
The resources to be provided will be based on a sizing model using representative queries derived from
the key science goals of LSST.
3.1.7.6 Transient Alerts
ID: OSS-REQ-0183
Last Modified: 11/17/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
54
3.1.7.6.1 Transient Alert Publication
ID: OSS-REQ-0184
Last Modified: 11/17/2010
Specification:
Transient alerts shall be published to community alert distribution networks using community-
standard protocols, to be determined during the LSST construction phase as community standards evolve.
Discussion:
The intent is to use a community standard like VOEvent, assuming that the standard as of the time of
LSST construction meets the project's requirements.
3.1.7.6.2 Transient Alert Query
ID: OSS-REQ-0185
Last Modified: 11/17/2010
Specification:
All published transient alerts, as well as all reprocessed historical alerts generated as part of a Data
Release, shall be available for query.
Discussion:
This allows users to perform statistical analyses on alerts, which are of interest both for actually
published, real-time alerts, e.g., for assessment of the quality of the real-time alert analysis, and for uniformly
reprocessed alerts in Data Releases, e.g., for optimally calibrated studies of the statistics of actual astrophysical
transients.
3.1.7.7 Access to Previous Data Releases
ID: OSS-REQ-0186
Last Modified: 10/7/2013
Specification:
The LSST project shall maintain user access to the contents of Data Releases prior to the current one.
However, this facility may be provided with substantially reduced performance and capability compared to the
access provided to the most recent Data Release.
Discussion:
Data Releases other than the two most recent ones are planned to be archived on tape (e.g., as database
table dumps) and be accessible as bulk downloads only. End-users interested in these products are expected to use
their own hardware and set up any the necessary software infrastructure (e.g., databases).
3.1.7.8 Information Security
ID: OSS-REQ-0187
Last Modified: 5/18/2011
Specification:
The LSST project shall ensure that Personally Identifiable Information (PII) and other sensitive data
relating to individuals or business relationships are protected from unauthorized disclosure, as required by law and
applicable standards.
Discussion:
Data of this nature is not expected to be part of the science data set, but could arise in the engineering
and facilities data collected as part of Observatory operations (e.g., information associated with the operations
personnel). PII may also be associated with the resource management in Data Access Centers (e.g. names, addresses,
etc. for researchers producing Level 3 data products).
3.2 Optical System
The LSST shall be design and constructed using the following specifications for:
1. Optical design Prescription
2. Optical Alignment and Compensation

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
55
3. Ghost Image Control
4. Stray and Scattered Light Control
3.2.1 Optical Design Specification
ID: OSS-REQ-0200
Last Modified: 11/23/2010
Specification:
The LSST optical system shall be a Mersene-Schmidt design consisting of a 3-mirror modified Paul-
Baker telescope and a 4-element (3 lenses + filter) refractive corrector.
Discussion:
The reference optical prescription is given below with details and performance discussed in document
LSE-11. The prescription contains parameters to define each surface, their separations, and clear apertures.
All parameters follow the sign conventions used by the Zemax raytracing software.
3.2.1.1 M1 Prescription
ID: OSS-REQ-0201
Last Modified: 7/19/2010
Specification:
The surface prescription of the primary mirror (M1) shall be defined by the table of parameters
m1Prescription:
Description
Value
Unit
Name
The primary mirror outer clear aperture radius shall be at least
m1OuterCa.
4180.0
mm
m1OuterCa
The primary mirror inner clear aperture radius shall be no more than
m1InnerCa.
2558.0
mm
m1InnerCa
The primary mirror radius of curvature shall be
m1Radius
-19835.0
mm
m1Radius
The primary mirror surface conic constant shall be
m1ConicConstant.
-1.2150
m1ConicConstant
The primary mirror surface 6th order aspheric coefficient shall be
m1_6thAsphere
1.381e-24
mm^-5
m1_6thAsphere
3.2.1.2 M2 Prescription
ID: OSS-REQ-0202
Last Modified: 7/19/2010
Specification:
The surface prescription of the secondary mirror (M2) shall be defined by the table of parameters
m2Prescription:
Description
Value
Unit
Name
The secondary mirror (m2) outer clear aperture radius shall be
m2OuterCa.
1710.0
mm
m2OuterCa
The secondary mirror (m2) inner clear aperture radius shall be
m2InnerCa
900.0
mm
m2InnerCa
The secondary mirror surface radius of curvature shall be
m2Radius.
-6788.0
mm
m2Radius
The secondary mirror surface conic constant shall be
m2Conic.
-0.2220
m2Conic
The secondary mirror surface 6th order aspheric coefficient shall be
m2_6thAsphere.
-1.274e-20
mm^-5
m2_6thAsphere
The secondary mirror surface 8th order aspheric coefficient shall be -9.680e-28
mm^-7
m2_8thAsphere

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
56
Description
Value
Unit
Name
m2_8thAsphere.
3.2.1.3 M3 Prescription
ID: OSS-REQ-0203
Last Modified: 7/19/2010
Specification:
The surface prescription of the tertiary mirror (M3) shall be defined by the table of parameters
m3Prescription:
Description
Value
Unit
Name
The tertiary mirror outer clear aperture radius shall be at least
m3OuterCa.
2508.0
mm
m3OuterCa
The tertiary mirror inner clear aperture radius shall be at least
m3InnerCa.
550.0
mm
m3InnerCa
The tertiary mirror surface radius of curvature shall be
m3Radius.
-8344.5
mm
m3Radius
The tertiary mirror surface conic constant shall be
m3Conic.
0.1550
m3Connic
The tertiary mirror surface 6th order aspheric coefficient shall be
m3_6thAsphere.
-4.500e-22
mm^-5
m3_6thAsphere
The tertiary mirror surface 8th order aspheric coefficient shall be
m3_8thAsphere.
-8.150e-30
mm^-7
m3_8thAsphere
3.2.1.4 Mirror Spacings
ID: OSS-REQ-0204
Last Modified: 7/19/2010
The prescription for the separation of the successive mirror surfaces and the next optical element in the system shall
be defined by the parameters in table
mirrorSpacings
Description
Value
Unit
Name
The distance from the vertex of M1 to the vertex of M2 shall be
m1m2Spacing
-6156.2006
mm
m1m2Spacing
The distance from the vertex of M2 to the vertex of M3 shall be
m2m3Spacing
6390.0006
mm
m2m3Spacing
The distance from the vertex of M3 to the vertex of the first surface
of L1 in the r-band shall be
m2l1Spacing
-3631.273
mm
m3l1Spacing
3.2.1.5 L1 Prescription
ID: OSS-REQ-0205
Last Modified: 7/19/2010
Specification:
The prescription of the first lens (L1) shall be defined by the table of parameters
l1Prescription:
Description
Value
Unit
Name
The first lens (L1) shall be fabricated from
l1GlassType
Fused
Silica
l1GlassType
The center thickness of the first lens (L1) shall be
l1CenThic
82.23
mm
l1CenThick
The clear aperture diameter of the first lens (L1) first surface (S1)
shall be
l1_s1OuterCa
1550
mm
l1_s1OuterCa

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
57
Description
Value
Unit
Name
The radius of the first surface (s1) of the first lens (l1) shall be
l1_s1Radius
-2824.0
mm
l1_s1Radius
The clear aperture diameter of the first lens (L1) second surface (S2)
shall be
l1_s2OuterCa
1523
mm
l1_s2OuterCa
The radius of the second surface (s2) of the first lens (l1) shall be
l1_s2Radius
-5021.00
mm
l1_s2Radius
3.2.1.6 L2 Prescription
ID: OSS-REQ-0206
Last Modified: 2/9/2015
Specification:
The prescription of the second lens (L2) shall be defined by the table of parameters
l2Prescription:
Description
Value
Unit
Name
The second lens (L2) shall be fabricated from
l2GlassType
Fused
Silica
l2GlassType
The center thickness of the second lens (L2) shall be
l2CenThic
30.00
mm
l2CenThick
The clear aperture diameter of the second lens (L2) first surface (S!)
shall be
l2_s1OuterCa
1102.0
mm
l2_s1OuterCa
The radius of the first surface (s1) of the second lens (l2) shall be
l2_s1Radius
Infinite
l2_s1Radius
The clear aperture diameter of the second lens (L2) second surface
(S2) shall be
l2_s2OuterCa
1040.0
mm
l2_s2OuterCa
The radius of the second surface (s2) of the second lens (l2) shall be
l2_s2Radius
-2529.0
mm
l2_s2Radius
The second surface (s2) conic constant on the second lens (L2) shall
be
l2_s2Conic
.
-1.5700
l2_s2Conic
The second surface 6th order aspheric coefficient on the second lens
shall be
l2_s2_6thAsphere.
1.656e-18
mm^-5
l2_s2_6thAsphere
3.2.1.7 Filter Prescription
ID: OSS-REQ-0207
Last Modified: 2/9/2015
Specification:
The prescription of the filter substrates shall be defined by the table of parameters
filterPrescription:
Description
Value
Unit
Name
The third lens (L3) shall be fabricated from
l3GlassType
Fused
Silica
filterGlassType
The clear aperture diameter of the filter substrate first surface (S1)
shall be
filterOuterCa
756.0
mm
filter_s1OuterCa
The radius of the first surface (s1) of the filter substrates shall be
filter_s1Radius
-5632.0
mm
filter_s1Radius
The thicknes of the u-band filter substrate shall be
filterThick_u
26.60
mm
filterThick_u
The thicknes of the g-band filter substrate shall be
filterThick_g
21.50
mm
filterThick_g
The thicknes of the r-band filter substrate shall be
filterThick_r
17.90
mm
filterThick_r
The thicknes of the i-band filter substrate shall be
filterThick_i
15.70
mm
filterThick_i
The thicknes of the z-band filter substrate shall be
filterThick_z
14.4
mm
filterThick_z

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
58
Description
Value
Unit
Name
The thicknes of the y-band filter substrate shall be
filterThick_y
13.60
mm
filterThick_y
The radius of the second surface (s2) of the u-band filter substrate
shall be
filter_s2Radius_u
-5530.0
mm
filter_s2Radius_u
The radius of the second surface (s2) of the g-band filter substrate
shall be
filter_s2Radius_g
-5576.0
mm
filter_s2Radius_g
The radius of the second surface (s2) of the r-band filter substrate
shall be
filter_s2Radius_r
-5606.0
mm
filter_s2Radius_r
The radius of the second surface (s2) of the i-band filter substrate
shall be
filter_s2Radius_i
-5623.0
mm
filter_s2Radius_i
The radius of the second surface (s2) of the z-band filter substrate
shall be
filter_s2Radius_z
-5632.0
mm
filter_s2Radius_z
The radius of the second surface (s2) of the y-band filter substrate
shall be
filter_s2Radius_y
-5640.0
mm
filter_s2Radius_y
The clear aperture diameter of the u-band filter substrates second
surface (S2) shall be
filter_s2OuterCa_u
737.0
mm
filter_s2OuterCa_u
The clear aperture diameter of the g-band filter substrates second
surface (S2) shall be
filter_s2OuterCa_g
741.0
mm
filter_s2OuterCa_g
The clear aperture diameter of the r-band filter substrates second
surface (S2) shall be
filter_s2OuterCa_r
745.0
mm
filter_s2OuterCa_r
The clear aperture diameter of the i-band filter substrates second
surface (S2) shall be
filter_s2OuterCa_i
746.0
mm
filter_s2OuterCa_i
The clear aperture diameter of the z-band filter substrates second
surface (S2) shall be
filter_s2OuterCa_z
747.0
mm
filter_s2OuterCa_z
The clear aperture diameter of the y-band filter substrates second
surface (S2) shall be
filter_s2OuterCa_y
748.0
mm
filter_s2OuterCa_y
3.2.1.8 L3 Prescription
ID: OSS-REQ-0208
Last Modified: 7/19/2010
Specification:
The prescription of the third lens (L3) shall be defined by the table of parameters
l3Prescription:
Description
Value
Unit
Name
The third lens (L3) shall be fabricated from
l3GlassType
Fused
Silica
l3GlassType
The center thickness of the third lens (L3) shall be
l3CenThic
60.00
mm
l3CenThick
The clear aperture diameter of the third lens (L3) first surface (S1)
shall be
l3_s1OuterCa
722.0
mm
l3_s1OuterCa
The radius of the first surface (s1) of the third lens (L3) shall be
l3_s1Radius
-3169.0
mm
l3_s1Radius
The first surface (s1) conic constant on the third lens (L3) shall be
l3_s1Conic
.
-0.9620
l3_s1Conic
The clear aperture diameter of the third lens (L3) second surface
(S2) shall be
l3_s2OuterCa
722.0
mm
l3_s2OuterCa
The radius of the second surface (s2) of the third lens (L3) shall be
l3_s2Radius
13360.0
mm
l3_s2Radius
3.2.1.9 Lens Spacings
ID: OSS-REQ-0209
Last Modified: 7/19/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
59
The prescription for the separation of the successive lenses in the system shall be defined by the parameters in table
lensSpacings
Description
Value
Unit
Name
The distance from the vertex of the second surface of L1 to the
vertex of the first surface of L2 shall be
l1_l2Spacing.
-412.642
mm
l1_l2Spacing
The distance from the vertex of the second surface of L2 to the
vertex of the first surface of the filter substrate shall be
L2_filterSpacing.
-349.58
mm
l2_filterSpacing
The distance from the vertex of the second surface of the u-band
filter substrate to the vertex of the first surface of L3 shall be
L3_filterSpacing_u.
-42.40
mm
L3_filterSpacing_u
The distance from the vertex of the second surface of the g-band
filter substrate to the vertex of the first surface of L3 shall be
L3_filterSpacing_g.
-47.50
mm
L3_filterSpacing_g
The distance from the vertex of the second surface of the r-band
filter substrate to the vertex of the first surface of L3 shall be
L3_filterSpacing_r.
-51.10
mm
L3_filterSpacing_r
The distance from the vertex of the second surface of the i-band
filter substrate to the vertex of the first surface of L3 shall be
L3_filterSpacing_i.
-53.30
mm
L3_filterSpacing_i
The distance from the vertex of the second surface of the z-band
filter substrate to the vertex of the first surface of L3 shall be
L3_filterSpacing_z.
-54.60
mm
L3_filterSpacing_z
The distance from the vertex of the second surface of the y-band
filter substrate to the vertex of the first surface of L3 shall be
L3_filterSpacing_y.
-55.40
mm
L3_filterSpacing_y
The distance from the vertex of the second surface of L3 to the focal
plane array (FPA) shall be
l3_fpaSpacing.
-28.50
mm
l3_fpaSpacing
3.2.2 Optical Alignment and Compensation
ID: OSS-REQ-0210
Last Modified: 11/23/2010
Discussion:
The LSST optical design has been analyzed for its ability to compensate for errors in alignment and
optical fabrication. There are two "one time" compensators in the lens positions that correct for fabrication errors in
radii and conic constants of the mirrors. Additionally there are 10 degrees of freedom between the secondary mirror
and the camera optics for alignment. The specifications below constrain the minimum range of adjustment for each
compensator.
3.2.2.1 Dynamic Alignment and Figure Compensation
ID: OSS-REQ-0211
Last Modified: 7/21/2010
Specification:
The LSST optical shall dynamically compensate for deflections and deformation caused by gravity
and thermal gradients.
3.2.2.1.1 Secondary (M2) Adjustment
ID: OSS-REQ-0212
Last Modified: 2/9/2015

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
60
Specification:
The rigid body position of the secondary mirror shall be adjustable in 5 degrees of freedom (decenter
x-y, piston along the optical axis, tilt x-y) over a range specified in the table below.
Description
Value
Unit
Name
The range of motion of the secondary on either side of its nominal
design position in the x-direction.
10
mm
x-decenterRangeM2
The range of motion of the secondary on either side of its nominal
design position in the y-direction.
10
mm
y-decenterRangeM2
The range of motion of the secondary on either side of its nominal
design position in the z-direction.
10
mm
z-positionRangeM2
The range of tilt of the secondary on either side of its nominal
design position about the x-axis.
0.1
Degrees
x-tiltRangeM2
The range of tilt of the secondary on either side of its nominal
design position about the y-axis.
0.1
Degrees
y-tiltRangeM2
3.2.2.1.2 Camera Adjustment
ID: OSS-REQ-0213
Last Modified: 5/16/2011
Specification:
The rigid body position of the camera optical system (3 lenses, filter and focal plane) shall adjustable
in 5 degrees of freedom over a range specified in the table below.
Description
Value
Unit
Name
The range of motion of the camera on either side of its nominal
design position in the x-direction.
10
mm
x-
decenterRangeCam
The range of motion of the camera on either side of its nominal
design position in the y-direction.
10
mm
y-
decenterRangeCam
The range of motion of the camera on either side of its nominal
design position in the z-direction.
10
mm
z-
positionRangCcam
The range of tilt of the camera on either side of its nominal design
position about the x-axis.
0.1
Degrees
x-tiltRangeCam
The range of tilt of the camera on either side of its nominal design
position about the y-axis.
0.1
Degrees
y-tiltRangeCam
3.2.2.2 One-time Static Compensation
ID: OSS-REQ-0214
Last Modified: 5/16/2011
Specification:
The LSST optical system shall provide for one time compensation for the as-built prescriptions (radii
and conic constant) on the three mirror surfaces.
3.2.2.2.1 L3+FPA to L2 Spacing
ID: OSS-REQ-0215
Last Modified: 11/18/2010
Specification:
The spacing of the FPA+L3 (+ optionally the filter) to L2 shall be adjustable one time over a range of
l3L2Comp
about its nominal design spacing.
Discussion:
Sensitivity analysis show that the filter can be optionally allowed to move with the FPA+L3 group
when making this adjustment within system performance.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
61
Description
Value
Unit
Name
The minimum adjustment range of the L3-L2 spacing about either
side of the nominal design spacing as a one-time compensator.
5
mm
l3L2Comp
3.2.2.2.2 L3-FPA Spacing
ID: OSS-REQ-0216
Last Modified: 7/21/2010
Specification:
The spacing between L3 and the FPA shall be adjustable one time within the range of
fpaL3Comp
about the nominal design spacing.
Description
Value
Unit
Name
The minimum adjustment range of the FPA+L3 spacing about either
side of the nominal design spacing as a one-time compensator.
3.5
mm
fpaL3Comp
3.2.2.3 Wavefront Sensing Functions
ID: OSS-REQ-0217
Last Modified: 8/5/2010
Specification:
The LSST optical system shall be able to determine the self induced wavefront aberrations caused by
misalignment of the secondary mirror and camera along with figure distortions on the surfaces of the 3 telescope
mirrors.
3.2.2.3.1 Wavefront Estimation Range
ID: OSS-REQ-0218
Last Modified: 7/21/2010
Specification:
Each wavefront sensor shall provide sufficient information to be able to reconstruct the equivalent of
up to the first 22 Zernike modes of wavefront error at the telescope pupil.
3.2.2.3.2 Wavefront Sensing on Sky Efficiency
ID: OSS-REQ-0219
Last Modified: 5/16/2011
Specification:
The wavefront sensors shall supply data for the estimation of the wavefront over at least
wfsSkyEfficiency
of all visits regardless of visit filter.
Discussion:
The fraction of sky coverage is based on the ability to recover the coefficients for Zernikie polynomials
(or equivalent) Z4 - Z22 using the standard Noll notation.
Description
Value
Unit
Name
The minimum fraction of visits where valid wavefront sensing data
can be obtained.
95
Percent
wfsSkyEfficiency
3.2.2.3.3 Wavefront Sensor FPA Geometry
ID: OSS-REQ-0220
Last Modified: 5/26/2011
Specification:
For the purpose of determining the optical alignment and mirror surface errors the LSST optical
system shall use 4 wavefront sensors located near the corners of the inscribed square to the 3.5 degree FOV.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
62
3.2.2.3.4 WFS Data Archiving and Buffering
ID: OSS-REQ-0221
Last Modified: 7/21/2010
Specification:
For the purposes of archiving and buffering the wavefront sensor imaging data shall be treated the
same as science image data.
3.2.3 Stray and Scattered Light Control
ID: OSS-REQ-0224
Last Modified: 11/23/2010
Specification:
All sources of stray and scattered light shall be minimized by design to the extent that it is feasible
using standard practices and surface treatments.
3.2.3.1 Ghost Image Control
ID: OSS-REQ-0222
Last Modified: 5/18/2011
Specification:
The effects of image ghosts in single visits shall not increase the errors in photometric repeatability
of non-varying sources by more than
ghostPhotErr
above the limit set by the calculated noise (photon statistics and
other measured noise sources).
Specification:
No more than
ghostGradientArea
% of image area in a single visit shall be affected by ghosts with
surface brightness gradients on 1 arcsec scale exceeding 1/3 of the sky noise.
Discussion:
These requirements limit the impact of ghosting. The first requirement effectively places an upper limit
on the precision of sky brightness determination (~1 % for design specification), which may be affected by ghosts.
The second requirement is derived from the effects of ghosting on shape systematics on the scale of faint galaxies.
Description
Value
Unit
Name
The increase in photometric error over repeated measurements
caused by the effects of image ghosts shall not exceed
ghostPhotErr
.
10.0
Percent
ghostPhotErr
The maximum scientific image area that can be affected by 1 arcsec
scale ghost gradients exceeding 1/3 of the sky noise shall be no
more than
ghostGradientArea.
1.0
Percent
ghostGradientArea
3.2.3.1.1 Lens Anti-Reflection Coating
ID: OSS-REQ-0223
Last Modified: 9/17/2010
Specification:
The reflection off the any transmissive optical surface shall be less than
lensReflection
over the
entire operating wavelength rage of the LSST system.
Discussion:
These specifications constrain the intensity of the 2-reflection ghost images.
Description
Value
Unit
Name
The maximum allowable reflection fraction from any lens surface
after AR coating.
2
Percent
lensReflection
3.2.3.2 Lunar Stray Light
ID: OSS-REQ-0225
Last Modified: 11/18/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
63
Specification:
All sources of stray light that contribute more than
strayThreshold
relative to the natural sky
background within
lunarAngle
shall be identified and treated to minimize their impact on diffuse stray light.
Description
Value
Unit
Name
The threshold above which surfaces need to be identified and treated
for minimization of stray light.
10
Percent
strayThreshold
The limiting angle from the moon with respect to the optical axis
where surface contributions to stray light need to be identified.
45
Degrees
lunarAngle
3.2.3.3 Optical Baffling
ID: OSS-REQ-0226
Last Modified: 11/18/2010
Specification:
The optical system shall be baffled such that there are no direct specular paths to the focal plane
outside the nominal field of view from celestial sources.
3.2.4 Image Quality
ID: OSS-REQ-0227
Last Modified: 5/16/2011
The delivered PSF image quality specifications flow directly from the SRD/LSR.
3.2.4.1 System Image Quality
ID: OSS-REQ-0228
Last Modified: 6/21/2014
Specification:
The delivered image quality of isolated bright unresolved point sources in images from a single visit
shall have the properties specified in the table
imageQuality
.
Discussion:
The design point specified here deviates from the SRD design specification due to the conflict between
image quality and charge spreading in thick detectors, needed to achieve the desired z-band and y-band sensitivities.
The adopted base system image quality of 0.4 arcsec FWHM is within the allowed value set by the SRD minimum
specification.
Description
Value
Unit
Name
The maximum RSS contribution from the LSST system to the
atmospheric seeing referenced at zenith or airmass (sec(zd)) = 1.
0.40
ArcsecFWH
M
SysIm_0
The maximum RSS contribution from the LSST system to the
atmospheric seeing referenced at zenith distance of 45 degrees or
airmass (sec(zd)) = 1.4.
0.49
ArcsecFWH
M
SysIm_45
The maximum RSS contribution from the LSST system to the
atmospheric seeing referenced at zenith distance of 60 degrees or
airmass (sec(zd)) = 2.0.
0.60
ArcsecFWH
M
SysIm_60
Delivered image quality increase factor allowed over
SF1
fraction of
the field of view.
1.1
float
SX
The maximum fraction of the field of view that can exceed the
delivered image size by a factor of
SX
.
10
Percent
SF1
The minimum number of pixels across the FWHM of the delivered
PSF under median atmospheric conditions (0.6 arcsec FWHM) shall
be
3
Pixels
PSFSample
The system image budget is allowed to degrade through the three
0.6
ImFunc

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
64
Description
Value
Unit
Name
reference zenith distances (zd) as sec(zd)^
ImFunc
.
The maximum radius of the PSF spatial profile for a fiducial
delivered image quality of 0.69 arcsec FWHM containing 80 percent
encircled energy shall be no more than
SR1
.
0.76
Arcsec
SR1
The maximum radius of the PSF spatial profile for a fiducial
delivered image quality of 0.69 arcsec FWHM containing 90 percent
encircled energy shall be no more than
SR2
.
1.17
Arcsec
SR2
The maximum radius of the PSF spatial profile for a fiducial
delivered image quality of 0.69 arcsec FWHM containing 95 percent
encircled energy shall be no more than
SR3
.
1.62
Arcsec
SR3
3.2.4.2 Image Quality Subsystem Allocations
ID: OSS-REQ-0229
Last Modified: 7/17/2011
Specification:
The telescope and camera subsystems shall use the RSS budget allocations defined by
imgBudgetTel
and
imgBudgetCam
in the table below.
Description
Value
Unit
Name
The portion of the system image budget allocated to the Telescope is
imgBudgetTel.
0.25
ArcsecFWH
M
imgBugetTel
The portion of the system image budget allocated to the Camera is
imgBudgetCam.
0.30
ArcsecFWH
M
imgBugetTCam
3.2.4.3 Off Zenith Image Degradation
ID: OSS-REQ-0230
Last Modified: 11/17/2010
Specification:
The system image quality is allowed to degrade as a function of Zenith Distance (angle) at the same
rate as the atmospheric turbulent seeing. The canonical dependence on zenith distance is given as sec(ZD)
0.6
.
Discussion:
The design specification for the image quality requires that, for the median atmospheric seeing, the
system contribution to the delivered image quality never exceeds 15%. This requirement should be fulfilled
irrespective of the airmass, which limits the seeing degradation due to hardware away from the zenith (e.g. due to
gravity load). Assuming that the atmospheric seeing increases with airmass, X, as X^0.6 , the design specification
for the allowed error budget due to system is 0.52 arcsec at airmass of 2 and for the median seeing conditions (0.42
arcsec for X=1.4).
3.2.4.4 Image Pixel Sampling
ID: OSS-REQ-0231
Last Modified: 5/16/2011
Specification:
The image sampling shall be pixelSize.
Description
Value
Unit
Name
The maximum physical pixel size needed to achieve critical PSF
sampling in the reference median seeing conditions.
10.0
Microns
pixelSize

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
65
3.2.5 Image Ellipticity
ID: OSS-REQ-0232
Last Modified: 5/16/2011
Discussion:
The image ellipticity performance parameters specified here flow directly from the SRD/LSR without
any further derivation. Monte Carlo analysis of the optical system using the component tolerances derived from the
image quality budget shows that these ellipticity specifications are met (see Document-1361).
Thus, the ellipticity specifications detailed here are held at the System Level and do not flow down to either the
camera or telescope subsystems.
https://www.lsstcorp.org/docushare/dsweb/Get/Document-1361
3.2.5.1 Single Image PSF Ellipticity
ID: OSS-REQ-0233
Last Modified: 5/16/2011
Specification:
The Point spread function ellipticity of bright isolated unresolved sources in images from a single r-
band or i-band visit shall have the properties specified in the table
imageEllipticity
below.
Discussion:
These specifications apply to single isolated unresolved sources as delivered to and recorded by the
LSST imaging system.
Description
Value
Unit
Name
The maximum median raw PSF ellipticity over the full field of view
in a single 15 second exposure for bright isolated non-saturated
stars.
0.04
Ellipticity
SE1
The maximum PSF raw ellipticity limit.
0.07
Ellipticity
SE2
The fraction of PSF ellipticity measurements allowed to exceed the
ellipticity outlier limit for bright isolated non-saturated stars.
5
Percent
EF1
The maximum residual ellipticity correlation amplitude over 1
arcmin scales.
2.0e-4
SE3
The maximum residual ellipticity correlation amplitude over 5
arcmin scales.
5.0e-7
SE4
The maximum median residual ellipticity amplitude outlier limit on
scales less than or equal to 1 arcmin.
4.0e-4
SE5
The maximum median residual ellipticity amplitude outlier limit on
scales between 1 and 5 arcmin.
1.0e-6
SE6
Fraction of allowed PSF measurements of isolated bright stars to
exceed the ellipticity residual correlation amplitude outlier limit.
10
Percent
EF2
3.2.5.2 10-year Ellipticity Residuals
ID: OSS-REQ-0234
Last Modified: 5/16/2011
Specification:
Over the total number of visits in the full set of survey data (or 10 year equivalent stack), the residual
ellipticity correlations of bright isolated point sources in the r-band or i-band, after correction, shall have the
properties defined in the
overallEllipticity
table below.
Description
Value
Unit
Name
Median residual PSF ellipticity correlations averaged over an
2.0e-5
TE1

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
66
Description
Value
Unit
Name
arbitrary field of view for separations less than 1 arcmin shall be no
greater than
TE1.
Median residual PSF ellipticity correlations averaged over an
arbitrary field of view for separations less than 5 arcmin shall be no
greater than
TE2.
1.0e-7
TE2
The outlier limit on the PSF ellipticity correlation residuals on 1
arcminute scales shall be no more than
TE3.
4.0e-5
TE3
The outlier limit on the PSF ellipticity correlation residuals on 5
arcminute scales shall be no more than
TE4.
2.0e-7
TE4
The fraction of PSF ellipticity correlation residuals that can exceed
the outlier limits on 1 and 5 arcminutes scales over an arbitrary field
of view shall be no more than
TF1
.
15
Percent
TF1
3.3 System Throughput
The LSST system throughput shall allow efficient collection of the science data over a wide range of wavelengths,
from near the atmospheric cutoff in the blue to the band gap of silicon in the red.
3.3.1 Filter Response
ID: OSS-REQ-0235
Last Modified: 6/21/2014
Specification:
The area weighted mean response function (as defined in Document-16295; see link below) for each
filter shall lie within their respective upper and lower trapezoidal response envelopes defined.
Discussion:
The "filter response" function of a given point on the filter substrate refers to the net wavelength
response integrated over the incident optical beam centered at that point that has been normalized to a unity mean
between the "in-band" wavelength limits as defined for each filter. The normalized response function can have
values greater than unity by no more than maxFiltRipple due to response wiggles within the in-band region.
Note:
For the purpose of estimating system throughput performance the response functions for the baseline ideal
filters contained in Collection-1777 in the LSST document archive (see collection link below) are to be used.
https://docushare.lsstcorp.org/docushare/dsweb/Services/Document-16295
https://www.lsstcorp.org/docushare/dsweb/View/Collection-1777
3.3.1.1 Filter Out of Band Constraints
ID: OSS-REQ-0237
Last Modified: 6/19/2014
Specification:
Each of the 6 defined filters must block it’s out of band transmission according to the specifications
in the table below.
Discussion:
For leakage that occurs in the wavelength region beyond 1050 the response of 100 micron thick silicon
at -100 C can be multiplied against the filter response in the total integrated leak evaluation.
Description
Value
Unit
Name
The average leakage in any 10nm segment between 300-1200nm
outside the wavelength span one FWHM from the central
wavelength shall be no more than
fLeak_10nm.
0.01
Percent
fLeak_10nm

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
67
Description
Value
Unit
Name
The integrated transmission over all wavelengths between 300-
1200nm outside the wavelength span between the first time the filter
response goes below 0.1% of the peak the total leakage shall not
exceeded
fleakTotal
relative to the total integrated transmission
between 300nm and 1200nm.
0.03
Percent
fLeakTotal
Up to
fLeakException
of the 10nm intervals 1 FWHM from the
central wavelength (between 300nm and 1200nm) may be greater
than
fLeak_10nm
but no more than
fLeakMax.
5.0
Percent
fleakException
The maximum allowed leakage.
0.1
Percent
fleakMax
3.3.1.2 Filter Response Uniformity
ID: OSS-REQ-0238
Last Modified: 6/19/2014
Specification:
The wavelength of the blue and red 50% response points of the response function over any 100mm
circle within the filter clear aperture shall not deviate by no more than
grizy_filtUniformity
and
u_filtUniformity
from that of the area weighted mean response function.
Description
Value
Unit
Name
The maximum allowed u-band filter response uniformity.
2.5%
Percent
filtUniformity_u
The maximum allowed grizy-band filter response uniformity.
1.5%
Percent
filtUniformity_grizy
3.3.1.3 In-band Ripple
ID: OSS-REQ-0239
Last Modified: 6/19/2014
Specification:
The in-band filter response function at any given point within the filter clear aperture shall have
peak-to-valley ripple of no more than +/-
maxFiltRipple
relative to the in-band mean for that location.
Discussion:
The region for measuring ripple is defined by the in-band limits provided in the specifications below.
Description
Value
Unit
Name
The maximum peak-to-valley ripple.
3
Percent
maxFiltRipple
3.3.1.4 u-band Response Envelope
ID: OSS-REQ-0240
Last Modified: 5/16/2014
Specification:
The area weighted mean u-band filter response normalized to the in-band average (as measured
between
u_inBandBlue
and
u_inBandRed
) shall lie between the upper and lower envelopes defined in the tables
below:
Description
Value
Unit
Name
The in-band blue limit for the u-band filter response normalization.
335.5
nm
u_InBandBlue
The in-band red limit for the u-band filter response normalization.
378.5
nm
u_InBandRed
Description
Value
Unit
Name

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
68
Description
Value
Unit
Name
The blue side zero response wavelength of the u-band lower
envelope.
310.5
nm
u_lowerBlue(0)
The blue side 97% response wavelength of the u-band lower
envelope.
334.75
nm
u_lowerBlue(0.97)
The red side 97% response wavelength of the u-band lower
envelope.
379.25
nm
u_lowerRed(0.97)
The red side zero response wavelength of the u-band lower
envelope.
403.5
nm
u_lowerRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the u-band upper
envelope.
305.5
nm
u_upperBlue(0)
The blue side 103% response wavelength of the u-band upper
envelope.
331.25
nm
u_upperBlue(1.03)
The red side 103% response wavelength of the u-band upper
envelope.
382.75
nm
u_upperRed(1.03)
The red side zero response wavelength of the u-band upper
envelope.
408.5
nm
u_upperRed(0)
3.3.1.4.1 u-band not-to-exceed envelope
ID: OSS-REQ-0366
Last Modified: 5/16/2014
Specification:
Over the wavelength range defined by the upper envelope - excluding the in-band range, 30% (by
wavelength) of the area weighted average u-band filter response with may lie outside the nominal upper and lower
envelope, but shall lie completely within the minimum and maximum envelopes defined below.
Discussion:
Specific instances of non-compliance to this specification will be evaluated by the project to assess
acceptability.
Description
Value
Unit
Name
The blue side zero response wavelength of the u-band minimum
envelope.
313.5
nm
u_minBlue(0)
The blue side 97% response wavelength of the u-band minimum
envelope.
334.75
nm
u_minBlue(0.97)
The red side 97% response wavelength of the u-band minimum
envelope.
379.25
nm
u_minRed(0.97)
The red side zero response wavelength of the u-band minimum
envelope.
400.5
nm
u_minRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the u-band maximum
envelope.
302.5
nm
u_maxBlue(0)
The blue side 103% response wavelength of the u-band maximum
envelope.
328.25
nm
u_maxBlue(1.03)
The red side 103% response wavelength of the u-band maximum
envelope.
385.75
nm
u_maxRed(1.03)
The red side zero response wavelength of the u-band maximum
411.5
nm
u_maxRed(0)

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
69
Description
Value
Unit
Name
envelope.
Figure 1: u-band envelope
3.3.1.5 g-band Response Envelope
ID: OSS-REQ-0241
Last Modified: 6/19/2014
Specification:
The area weighted mean g-band filter response normalized to the in-band average (as measured
between
g_inBandBlue
and
g_inBandRed
) shall lie between the upper and lower envelopes defined in the tables
below:
Description
Value
Unit
Name
The in-band blue limit for the g-band filter response normalization.
416.5
nm
g_InBAndBlue
The upper and lower u-band response envelope and the in-band limits.

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
70
Description
Value
Unit
Name
The in-band red limit for the g-band filter response normalization.
537.0
nm
g_InBandRed
Description
Value
Unit
Name
The blue side zero response wavelength of the g-band lower
envelope.
391.5
nm
g_lowerBlue(0)
The blue side 0.97% response wavelength of the g-band lower
envelope.
415.75
nm
g_lowerBlue(0.97)
The red side 0.97% response wavelength of the g-band lower
envelope.
537.75
nm
g_lowerRed(0.97)
The red side zero response wavelength of the g-band lower
envelope.
562.0
nm
g_lowerRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the g-band upper
envelope.
386.5
nm
g_upperBlue(0)
The blue side 103% response wavelength of the g-band upper
envelope.
412.25
nm
g_upperBlue(1.03)
The red side 103% response wavelength of the g-band upper
envelope.
541.25
nm
g_upperRed(1.03)
The red side zero response wavelength of the g-band upper
envelope.
567.0
nm
g_upperRed(0)
3.3.1.5.1 g-band not-to-exceed envelope
ID: OSS-REQ-0367
Last Modified: 5/16/2014
Specification:
Over the wavelength range defined by the upper envelope - excluding the in-band range, 30% (by
wavelength) of the area weighted average g-band filter response with may lie outside the nominal upper and lower
envelope, but shall lie completely within the minimum and maximum envelopes defined below.
Discussion:
Specific instances of non-compliance to this specification will be evaluated by the project to assess
acceptability.
Description
Value
Unit
Name
The blue side zero response wavelength of the g-band minimum
envelope.
394.5
nm
g_minBlue(0)
The blue side 97% response wavelength of the g-band minimum
envelope.
415.75
nm
g_minBlue(0.97)
The red side 97% response wavelength of the g-band minimum
envelope.
537.75
nm
g_minRed(0.97)
The red side zero response wavelength of the g-band minimum
envelope.
559.0
nm
g_minRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the g-band maximum
envelope.
383.5
nm
g_maxBlue(0)
The blue side 103% response wavelength of the g-band maximum
409.25
nm
g_maxBlue(1.03)

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
71
Description
Value
Unit
Name
envelope.
The red side 103% response wavelength of the g-band maximum
envelope.
544.25
nm
g_maxRed(1.03)
The red side zero response wavelength of the g-band maximum
envelope.
570.0
nm
g_maxRed(0)
Figure 2: g-band evenlope
3.3.1.6 r-band Response Envelope
ID: OSS-REQ-0242
Last Modified: 5/6/2014
Specification:
The area weighted mean r-band filter response normalized to the in-band average (as measured
between
r_inBandBlue
and
r_inBandRed
) shall lie between the upper and lower envelopes defined in the tables
below:

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
72
Description
Value
Unit
Name
The in-band blue limit for the r-band filter response normalization.
567.0
nm
r_InBandBlue
The in-band red limit for the r-band filter response normalization.
676.0
nm
r_InBandRed
Description
Value
Unit
Name
The blue side zero response wavelength of the r-band lower
envelope.
542.0
nm
r_lowerBlue(0)
The blue side 97% response wavelength of the r-band lower
envelope.
566.25
nm
r_lowerBlue(0.97)
The red side 97% response wavelength of the r-band lower
envelope.
676.75
nm
r_lowerRed(0.97)
The red side zero response wavelength of the r-band lower envelope.
701.0
nm
r_lowerRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the r-band upper
envelope.
537.0
nm
r_upperBlue(0)
The blue side 103% response wavelength of the r-band upper
envelope.
562.75
nm
r_upperBlue(1.03)
The red side 103% response wavelength of the r-band upper
envelope.
680.25
nm
r_upperRed(1.03)
The red side zero response wavelength of the r-band upper envelope.
706.0
nm
r_upperRed(0)
3.3.1.6.1 r-band not-to-exceed envelope
ID: OSS-REQ-0368
Last Modified: 5/16/2014
Specification:
Over the wavelength range defined by the upper envelope - excluding the in-band range, 30% (by
wavelength) of the area weighted average r-band filter response with may lie outside the nominal upper and lower
envelope, but shall lie completely within the minimum and maximum envelopes defined below.
Description
Value
Unit
Name
The blue side zero response wavelength of the r-band minimum
envelope.
545.0
nm
r_minBlue(0)
The blue side 97% response wavelength of the r-band minimum
envelope.
566.25
nm
r_minBlue(0.97)
The red side 97% response wavelength of the r-band minimum
envelope.
676.75
nm
r_minRed(0.97)
The red side zero response wavelength of the r-band minimum
envelope.
698.0
nm
r_minRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the r-band maximum
envelope.
534.0
nm
r_maxBlue(0)
The blue side 103% response wavelength of the r-band maximum
envelope.
559.75
nm
r_maxBlue(1.03)
The red side 103% response wavelength of the r-band maximum
683.25
nm
r_maxRed(1.03)

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
73
Description
Value
Unit
Name
envelope.
The red side zero response wavelength of the r-band maximum
envelope.
709.0
nm
r_maxRed(0)
Figure 3: r-band envelope
3.3.1.7 i-band Response Envelope
ID: OSS-REQ-0243
Last Modified: 5/6/2014
Specification:
The area weighted mean i-band filter response normalized to the in-band average (as measured
between
i_inBandBlue
and
i_inBandRed
) shall lie between the upper and lower envelopes defined in the tables
below:

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
74
Description
Value
Unit
Name
The in-band blue limit for the i-band filter response normalization.
706.0
nm
i_InBandBlue
The in-band red limit for the i-band filter response normalization.
803.0
nm
i_InBandRed
Description
Value
Unit
Name
The blue side zero response wavelength of the i-band lower
envelope.
681.0
nm
i_lowerBlue(0)
The blue side 97% response wavelength of the i-band lower
envelope.
705.25
nm
i_lowerBlue(0.97)
The red side 97% response wavelength of the i-band lower
envelope.
803.75
nm
i_lowerRed(0.97)
The red side zero response wavelength of the i-band lower envelope.
828.0
nm
i_lowerRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the i-band upper
envelope.
676.0
nm
i_upperBlue(0)
The blue side 103% response wavelength of the i-band upper
envelope.
701.75
nm
i_upperBlue(1.03)
The red side 103% response wavelength of the i-band upper
envelope.
807.25
nm
i_upperRed(1.03)
The red side zero response wavelength of the i-band upper envelope.
833.0
nm
i_upperRed(0)
3.3.1.7.1 i-band not-to-exceed envelope
ID: OSS-REQ-0369
Last Modified: 5/16/2014
Specification:
Over the wavelength range defined by the upper envelope - excluding the in-band range, 30% (by
wavelength) of the area weighted average i-band filter response with may lie outside the nominal upper and lower
envelope, but shall lie completely within the minimum and maximum envelopes defined below.
Discussion:
Specific instances of non-compliance to this specification will be evaluated by the project to assess
acceptability.
Description
Value
Unit
Name
The blue side zero response wavelength of the i-band minimum
envelope.
684.0
nm
i_minBlue(0)
The blue side 97% response wavelength of the i-band minimum
envelope.
705.25
nm
i_minBlue(0.97)
The red side 97% response wavelength of the i-band minimum
envelope.
803.75
nm
i_minRed(0.97)
The red side zero response wavelength of the i-band minimum
envelope.
825.0
nm
i_minRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the i-band maximum
envelope.
673.0
nm
i_maxBlue(0)
The blue side 103% response wavelength of the i-band maximum
698.75
nm
i_maxBlue(1.03)

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
75
Description
Value
Unit
Name
envelope.
The red side 103% response wavelength of the i-band maximum
envelope.
810.25
nm
i_maxRed(1.03)
The red side zero response wavelength of the i-band maximum
envelope.
836.0
nm
i_maxRed(0)
Figure 4: i-band evenlope
3.3.1.8 z-band Response Envelope
ID: OSS-REQ-0244
Last Modified: 5/6/2014

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
76
Specification:
The area weighted mean z-band filter response normalized to the in-band average (as measured
between z_inBandBlue and z_inBandRed) shall lie between the upper and lower envelopes defined in the tables
below:
Description
Value
Unit
Name
The in-band blue limit for the z-band filter response normalization.
833.0
nm
z_InBandBlue
The in-band red limit for the z-band filter response normalization.
908.5
nm
z_InBandRed
Description
Value
Unit
Name
The blue side zero response wavelength of the z-band lower
envelope.
808.0
nm
z_lowerBlue(0)
The blue side 97% response wavelength of the z-band lower
envelope.
832.25
nm
z_lowerBlue(0.97)
The red side 97% response wavelength of the z-band lower
envelope.
909.25
nm
z_lowerRed(0.97)
The red side zero response wavelength of the z-band lower
envelope.
933.5
nm
z_lowerRed(0)
Description
Value
Unit
Name
The blue side zero response wavelength of the z-band upper
envelope.
803.0
nm
z_upperBlue(0)
The blue side 103% response wavelength of the z-band upper
envelope.
828.75
nm
z_upperBlue(1.03)
The red side 103% response wavelength of the z-band upper
envelope.
912.75
nm
z_upperRed(1.03)
The red side zero response wavelength of the z-band upper
envelope.
938.5
nm
z_upperRed(0)
3.3.1.8.1 z-band not-to-exceed envelope
ID: OSS-REQ-0370
Last Modified: 5/16/2014
Specification:
Over the wavelength range defined by the upper envelope - excluding the in-band range, 30% (by
wavelength) of the area weighted average z-band filter response with may lie outside the nominal upper and lower
envelope, but shall lie completely within the minimum and maximum envelopes defined below.
Discussion:
Specific instances of non-compliance to this specification will be evaluated by the project to assess
acceptability.
Description
Value
Unit
Name
The blue side zero response wavelength of the z-band minimum
envelope.
811.0
nm
z_minBlue(0)
The blue side 97% response wavelength of the z-band minimum
envelope.
832.25
nm
z_minBlue(0.97)
The red side 97% response wavelength of the z-band minimum
envelope.
909.25
nm
z_minred(0.97)
The red side zero response wavelength of the z-band minimum
envelope.
930.5
nm
z_minred(0)

LSST Observatory System Specifications
LSE-30
Latest Revision 4/10/2015
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
77
Description
Value