1. Large Synoptic Survey Telescope (LSST)
  2. Observatory System Specifications
  3. LSE-30
  4. Latest Revision: June 5, 2017
  5. Change Record
    1. Table of Contents
  6. The LSST Observatory System Specifications
    1. Introduction and Scope
    2. Acronyms and Definitions of Terms
    3. Supporting 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. 3.6 System Timing and Dynamics
      7. 3.7 Education and Public Outreach

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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

Back to top


Latest Revision: June 5, 2017
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 6/5/2017
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.
?
LCR-103; Establishes new requirements for
crosstalk amplitudes and correction OSS-REQ-
0327-0330, 0346-0349 (pg 91-94)
?
LCR-86; Complete refactoring of photometric
requirements (pg 97-102, 104)
?
LCR-84; Updates filling in TBDs in level 1 (pg
46-48) and level 2 (pg50-54) data quality
metrics
?
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 pressures in OSS-REQ-0010.
B. Selvy

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
ii
5.0
1/27/2015
Incorporates changes approved in the following
LCRs
131: Change Camera Interfaces to DM and
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
B. Selvy & C. Claver
5.1
4/10/2015
Fixed several typos. Moved several misplaced
tables (Constraint Blocks in the SysML model) to
their proper locations.
B. Selvy
6
2/1/2016
Incorporates LCRs 378 (Consistent use of the LSST
image quality metric), 480 (Define LSST Beam for
Lens BBAR Coating and Filters), and 490 (Updated
Filter Ripple Specification).
B. Selvy
7
8/4/2016
Implementation of
LCR-359: corrects the flow down from m5 limiting
magnitude to system hardware integrals and
makes subsystem allocations for throughput.
LCR-581: removal of OSS-REQ-0070 and
modification to OSS-REQ-0068 deleting
"Atmospheric Turbulence Structure"
LCR-582: add non-sidereal tracking to section
3.6.3.7
LCR-584: add two requirements under section 2.1
Survey Scheduling and Management regarding to
provide flow down logic for advanced publication
of the expected scheduler
LCR-646: OSS-REQ-0209 and OSS-REQ-0207
changed to reflect move of the filter first surface
apex in the z-direction away from the focal plane
by 3 mm
C. Claver, Patrick
Ingraham, S. Thomas,
Pat Hascall (LCRs), B.
Selvy (SysML), Robert
McKercher
(DocuShare)
9/1/2016
Removed two requirements that should have
Kathryn Wesson

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
iii
been removed as part of release 7.
8
1/4/2017
Implemented LCR-745 and LCR-746 by adding
requirements for Avoidance Regions and Targets
of Opportunity to complete flow down of
requirements to the Scheduler Specification.
Francisco Delgado
(LCRs), K. Wesson
(SysML), R.
McKercher
(DocuShare)
2/10/2017
Added Missing Beam Projector Coordinate
Relationships Requirement that should have been
included in the LCR-581 implementation (release
7).
K. Wesson
9
6/5/2017
Implemented LCR-687. Added new publish visit
type requirement. Updated wording on REQ
0288.
G. Angeli (LCR), K.
Wesson (SysML), R.
McKercher
(DocuShare)

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
iv
Table of Contents
Change Record ............................................................................................................................................... i
Introduction and Scope................................................................................................................................. v
Acronyms and Definitions of Terms.............................................................................................................. v
Supporting Documents ................................................................................................................................. v
Verb Usage.................................................................................................................................................... v
1
System Composition and Constraints .............................................................................................. 1
1.1
Facilities
............................................................................................................................. 1
1.2
Sites
.................................................................................................................................. 3
2
Common System Functions & Performance.................................................................................. 11
2.1
Survey Scheduling and Management
................................................................................ 11
2.2
System Control
................................................................................................................. 14
2.3
System Monitoring & Diagnostics
..................................................................................... 21
2.4
System Maintenance
........................................................................................................ 28
2.5
System Availability
........................................................................................................... 30
2.6
System Time Reference
.................................................................................................... 31
2.7
System Standards
............................................................................................................. 32
3
Detailed Specifications................................................................................................................... 38
3.1
Science and Bulk Data
...................................................................................................... 38
3.2
Optical System
................................................................................................................. 62
3.3
System Throughput
.......................................................................................................... 75
3.4
Camera System
................................................................................................................ 94
3.5
Photometric Calibration
................................................................................................. 101
3.6
System Timing and Dynamics
.......................................................................................... 110
3.7
Education and Public Outreach
....................................................................................... 117

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

Back to top


The LSST Observatory System Specifications
Introduction and Scope
This Observatory System Specifications 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 modeling tools:
?
the reference system architecture consisting of four (4) principle sites - summit, base, archive and
headquarters
?
the selection of the summit site on Cerro Pachón;
?
the modeling 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
Supporting Documents
1. LSST Science Requirements Document (LPM-17)
2. LSST System Requirements (LSE-29)
3. LSST Systems Engineering Management Plan (LSE-17)
4. LSST Change Control and Configuration Management Plan (LPM-19)
5. 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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
vi
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 to ensure objectively that the as-built design meets the requirement.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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;

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
2
2.
Survey planning and performance monitoring;
3.
Collection of newly acquired data for transfer to the LSST data archive;
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 6/5/2017
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.
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
Summit Environment
ID: OSS-REQ-0009
Last Modified: 12/1/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
4
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.
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 maximum barometric pressure for normal operations at
the summit shall be
normBaroMax
.
775
milibar
normBaroMax
When design considerations require barometric pressure
specifications all summit based systems shall use the mean
pressure
normBaroMean
.
750
milibar
normBaroMean
The minimum barometric pressure for normal operations at
the summit shall be
normBaroMin
.
725
milibar
normBaroMin
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
The rate of change for design purposes shall be
normTempGrad.
0.7
C/Hour
normTempGrad
The maximum temperature for normal operations at the
summit shall be
normTempMax
.
19.0
Celsius
normTempMax
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
When design considerations require operational wind
specifications all summit based systems shall use the extreme
operational wind speed,
normWindMax
.
12
m/sec
normWindMax
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
5
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
marginaltempGradie
nt
The maximum temperature for degraded operations at the
summit is
marginalTempMax
.
30
Celsius
marginalTempMax
The minimum temperature for degraded operations at the
summit is
marginalTempMin
.
-5
Celsius
marginalTempMin
The maximum free air windspeed for degraded operations at
the summit is
marginalWind
.
20
m/sec
marginalWind
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 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
survivalTemperature
The equipment in the interior of the Summit Facility must be
capable of surviving a constant wind speed of
survivalWind.
20
m/sec
survivalWind
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
Description
Value
Unit
Name
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
The survival load on the Summit Facility due to snow shall be
snowLoading
(ref. Norma Chilena NCH 431).
200
kg/m^2
snowLoading
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
survivalWindExterior
Transportation/Shipping Environment
ID: OSS-REQ-0013
Last Modified: 5/18/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
6
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
Containers have to be designed to limit water, dust, sand and
insect access during transportation
Contamination
During transportation to the summit, some roads have vehicle
weight restrictions.
Gross Vehicle Weight GVW = TBD
Weight/axle = TBD
TBD
kg
GVW
Pressure will change during transportation to the summit from
1000mbar at sea level down to 750mbar at the summit
1000 to
750
milibar
Pressure
The relative humidity range is from 10% to 100% with
condensation for transportation to the summit
10% to
100%
Percent
Relative Humidity
Range
Dirt roads will be used during transportation to the summit
with grades up to 16%
16
Percent
Roads
The ambient temperature range or transportation to the
summit is
-15C to
+40C
Celsius
Temperature Range
The container dimensions are limited by the Puclaro Dam
tunnel located on the road between La Serena and the
summit.
9
Meters
Tunnel
Wind speed may reach up to 45m/s during transportation to
the summit
45
m/sec
Wind Speed
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.
Standard Dark Sky Emission
ID
: OSS-REQ-0019
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
7
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.
Usable Observing Time
ID
: OSS-REQ-0020
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.
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
ArcsecFW
HM
seeing1stQuartile
The third quartile of the seeing distribution shall be taken as
seeing3rdQuartile
0.84
ArcsecFW
HM
seeing3rdQuartile
The median of the seeing distribution shall be taken as
seeingMedian
0.69
ArcsecFW
HM
seeingMedian
Cloud Coverage
ID: OSS-REQ-0017
Last Modified: 12/1/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
8
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
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
The standard typical Ozone level over northern Chile is
ozoneLevel
.
338
Dobson
ozoneLevel
1976 US standard STP sea level pressure is
seaLevelPressure
.
1013
milibar
seaLevelPressure
Reference airmass for calculating the standard transmission
function is
stdAirmass
.
1.0
Airmass
stdAirmass
The standard relative humidity percentage is
stpRelHumidity
.
15
Percent
stpRelHumidity
ID: OSS-REQ-0019
Last Modified: 4/21/2011
https://www.lsstcorp.org/docushare/dsweb/Get/Document-8817
https://www.lsstcorp.org/docushare/dsweb/Get/Document-8857
Description
Value
Unit
Name
Integrated reference sky brightness in the g-band.
22.27
mag/SqArc
sec
g_SkyBrightness
Integrated reference sky brightness in the i-band.
20.47
mag/SqArc
sec
i_SkyBrightness
Integrated reference sky brightness in the r-band.
21.20
mag/SqArc
sec
r_SkyBrightness

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
9
Description
Value
Unit
Name
Integrated reference sky brightness in the u-band.
22.92
mag/SqArc
sec
u_SkyBrightness
Integrated reference sky brightness in the y-band.
18.42
mag/SqArc
sec
y_SkyBrightness
Integrated reference sky brightness in the z-band.
19.59
mag/SqArc
sec
z_SkyBrightness
ID: OSS-REQ-0020
Last Modified: 5/3/2011
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
10
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.
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
ure that allows
be adefined
significant element
as
to separate
fracture or r
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.
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.
"Permanentshall
damage”
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).
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
11
"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;
7.
System Standards (including environmental and safety).
2.1
Survey Scheduling and Management
ID: OSS-REQ-0024
Last Modified: 3/11/2015
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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 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 Publish Visit Type
ID: OSS-REQ-0385
Last Modified: 5/26/2017
Specification:
The scheduler shall provide notice whether the Standard Visit or Alternate Standard Visit
will be used for a given night.
Discussion:
The purpose for this notification is to allow configuration of the single frame processing for
alert detection to use a different cosmic ray rejection algorithm.
2.1.1.2 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.3 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.4 Parallax Factor Sampling
ID: OSS-REQ-0028
Last Modified: 5/18/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
13
Specification:
The scheduler shall enforce an even distribution of parallax factor over the sum of all visits
in the 10-year survey.
2.1.1.5 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.6 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.7 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.8 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.
1.1.1.1.1
Scheduling Targets of Opportunity
ID
: OSS-REQ-0381
Specification:
The scheduler shall be capable of accepting targets of opportunity, either planned or
unplanned, with constraints reflecting scientific priority and time urgency.
1.1.1.1.2
Avoidance Regions
ID
: OSS-REQ-0382
Specification:
The Scheduler shall accept a list of avoidance regions, including coordinate boundaries,

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
14
time window, and other inputs as appropriate. Avoidance regions may be updated continuously based
on various internal and/or external conditions and/or constraints.
2.1.2 Advanced Publishing of Scheduler Sequence
ID: OSS-REQ-0378
Last Modified: 8/3/2016
Specification
: The scheduling of the observing sequence lasting at least 2 hours shall be published in
advance of each observing visit.
2.1.2.1 Scheduling Sequence Likelihood
ID: OSS-REQ-0379
Last Modified: 8/3/2016
Specification:
Under photometric (e.g. cloudless) conditions the likelihood that the observing sequence
as published is realized shall be at least
schedSeqLikelihood
.
Description
Value
Unit
Name
The minimum likelihood that the advanced publication of the
schedule sequencing is realized based when observing
conditions are photometric.
90
Percent
schedSeqLikelihood
2.1.3 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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
15
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.
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.
Summit Facility Operator

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
16
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.
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.
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.
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.
Visit Sequencing
ID: OSS-REQ-0039
Last Modified: 4/21/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
17
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.
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.
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
18
Specification:
Each LSST subsystem shall be responsible for maintaining its own technical health,
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
Note: The states need further definition in terms of access and safety requirements for each.
2.2.2.1 Manual Observing
ID
: OSS-REQ-0048
Specification:
The LSST Observatory shall be capable of executing manual or simple script driven
observations.
2.2.2.2 Engineering and Maintenance
ID
: OSS-REQ-0047
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.3 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.4 Calibration

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
19
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).
ID: OSS-REQ-0047
Last Modified: 4/21/2011
ID: OSS-REQ-0048
Last Modified: 4/21/2011
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.
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
.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
20
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
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.
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
.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
21
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
Base Updating from Archive
ID
: OSS-REQ-0055
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.
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.
ID: OSS-REQ-0055
Last Modified: 10/7/2013
2.3
System Monitoring & Diagnostics
ID: OSS-REQ-0056
Last Modified: 8/3/2016
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.
.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
22
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 Image Display Locations
ID
: OSS-REQ-0310
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.1.2 Image Data Sources
ID
: OSS-REQ-0060
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.3 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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
23
?
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.4 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
ID: OSS-REQ-0060
Last Modified: 4/28/2011
ID: OSS-REQ-0310
Last Modified: 5/19/2011
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
24
?
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
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 State Notification
ID
: OSS-REQ-0064
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.2 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 produced 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
ID: OSS-REQ-0064
Last Modified: 5/25/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
25
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.
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
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.
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
26
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.
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
.
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 of non-science images required to be supported.
15.4
Mbit/sec
Blob_AvgRate
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
Maximum ingest rate to the Engineering and Facilities
Database of non-science images required to be supported.
21.9
Mbit/sec
NonScience_MaxRa
te
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.
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
27
Specification:
Each subsystem shall be provided 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.
2.3.7 Summit Environment Monitoring
ID: OSS-REQ-0068
Last Modified: 8/3/2016
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
?
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
28
2.3.7.2 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 cloud map shall as minimum the properties listed in the table below.
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
The angular resolution of the all sky cloud map shall be at
least
cloudMapResolution.
1.0
Degrees
cloudMapResolution
2.3.7.3 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.4 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 feedback 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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
29
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
30
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.
Description
Value
Unit
Name
An night is considered "observable" when the fractional cloud
cover is less than
cloudCoverFrac
.
62.5
Percent
cloudCoverFrac
The minimum allowed fraction of available nights that can be
used when all sources of down time are summed is
plannedAvailability
.
90
Percent
plannedAvailability
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
31
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
unplannedDownTim
e
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
Camera subsystem unplanned downtime per year allocation
10
Days
CamUnschedDownti
me
Data Management subsystem unplanned downtime per year
allocation
1
Days
DMUnschedDownti
me
Telescope & Site subsystem unplanned downtime per year
allocation
10
Days
TSUnschedDowntim
e
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
32
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
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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:
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.
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.
Electromagnetic (RF) Susceptibility
ID: OSS-REQ-0326
Last Modified: 3/11/2015
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 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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
34
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 deisgn 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.
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
35
?
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 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
36
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.
Summit Radio Equipment
ID
: OSS-REQ-0105

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
37
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.
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.
ID: OSS-REQ-0105
Last Modified: 12/1/2010
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 Planning
ID
: OSS-REQ-0109
Specification:
The LSST project shall produce and maintain a cyber security 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.
2.7.8.2 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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
38
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.
ID: OSS-REQ-0109
Last Modified: 10/7/2013
3
Detailed Specifications
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
39
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.
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 data from the
ten-year survey.
2.0E10
int
nGalaxySurvey
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
3.1.1.4 Star Counts
ID: OSS-REQ-0192
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
40
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 data from the ten-year
survey.
1.7E10
int
nStarSurvey
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
3.1.1.5 Alerts per Visit
ID: OSS-REQ-0193
Last Modified: 10/7/2013
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
41
Description
Value
Unit
Name
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 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 Visit Alert Generation Reliability
ID
: OSS-REQ-0112
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
42
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.
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.
3.1.2.2 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
ID: OSS-REQ-0112
Last Modified: 9/22/2012
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
43
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 Wavefront Sensor Data
ID
: OSS-REQ-0316
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.3.2 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.3 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.
ID: OSS-REQ-0316
Last Modified: 5/18/2011
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 Reproducibility
ID
: OSS-REQ-0123
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
44
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.2 Software Development Standards
ID
: OSS-REQ-0124
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.4.3 Provenance
ID
: OSS-REQ-0122
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.
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.4 Automated Production
ID: OSS-REQ-0117
Last Modified: 8/30/2010
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.5 Consistency and Completeness

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
45
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.
Consistency
ID
: OSS-REQ-0120
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.
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:
ID: OSS-REQ-0120
Last Modified: 3/16/2010
3.1.4.6 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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
46
ID: OSS-REQ-0122
Last Modified: 9/21/2012
ID: OSS-REQ-0123
Last Modified: 11/18/2010
ID: OSS-REQ-0124
Last Modified: 8/30/2010
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.
Discussion:
The baseline list of Level 1 data products is provided as the composite contents of this
requirement.
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.
Alerts
ID: OSS-REQ-0128
Last Modified: 8/3/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
47
Specification:
The Level 1 Data Products shall include the Alerts produced as part of the nightly Alert
Production.
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.
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.
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
48
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.
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
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
Maximum photometric zero point offset between CCDs and
final photometriccalibration
50
mili-Mag
photoZeroPointOffs
et
Alert Completeness and Purity
ID: OSS-REQ-0166
Last Modified: 10/7/2013
Difference Source Spurious Probability Metric
ID: OSS-REQ-0351
Last Modified: 10/8/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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 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 t
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).
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.
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.).
Description
Value
Unit
Name
Minimum average completeness for transient science
90
Percent
transCompleteness
Min
Minimum average purity for transient science
95
Percent
transPurityMin

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
50
Description
Value
Unit
Name
SNR threshold at which the above are evaluated
6
int
transSampleSNR
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
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
Level 1 Moving Object Quality
ID: OSS-REQ-0159
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
51
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
orbitNightlyObservat
ionInterval
Interval over which a reference test case Solar System object
must be observed
3
days
orbitObservationInte
rval
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.
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.
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.
Co-added Exposures

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
52
ID: OSS-REQ-0136
Last Modified: 10/7/2013
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
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.
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.
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.
Level 2 Catalog Accuracy
ID: OSS-REQ-0162
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
53
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
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
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.
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
Coaddition for Templates for Subtraction
ID: OSS-REQ-0158
Last Modified: 2/9/2015

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
54
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
Maximum permissible fraction of the noise level in difference
images contributed by the subtraction template in Year 2 and
following
20
Percent
templateNoiseLevel
Y2
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
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
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
Object Deblending
ID: OSS-REQ-0155
Last Modified: 10/7/2013

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
55
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).
Level 2 Moving Object Quality
ID: OSS-REQ-0340
Last Modified: 5/3/2012
Specification:
The Level 2 moving object quality requirements are the same as at Level 1; see OSS-
REQ-0159.
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.
Production
ID: OSS-REQ-0140
Last Modified: 8/3/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
56
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.
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.
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.
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.]
WCS Reporting
ID
: OSS-REQ-0146
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
57
accuracy of the mount model. The WCS reporting will be done with using the OCS publish/subscribe
mechanism used for other observatory telemetry reporting.
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.
ID: OSS-REQ-0146
Last Modified: 5/18/2011
Description
Value
Unit
Name
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
wcsReportingLatenc
y
Maximum RMS uncertainty on the comparison of observed
and reference star positions from the real-time WCS reporting
0.2
ArcsecRM
S
wcsReportingPrecisi
on
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
58
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
59
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.
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
60
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
dpAvailabilityFractio
n
Maximum duration of a single outage of data product access,
in working days.
3
Days
dpAvailabilityOutage
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 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
61
Transient Alert Query
ID
: OSS-REQ-0185
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.
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.
ID: OSS-REQ-0185
Last Modified: 11/17/2010
3.1.7.7 Information Security
ID
: OSS-REQ-0187
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.1.7.8 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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
62
products are expected to use their own hardware and set up any the necessary software infrastructure
(e.g., databases).
ID: OSS-REQ-0187
Last Modified: 5/18/2011
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
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 surface 6th order aspheric coefficient shall
be
m1_6thAsphere
1.381e-24
mm^-5
m1_6thAsphere
The primary mirror surface conic constant shall be
m1ConicConstant.
-1.2150
m1ConicConstant
The primary mirror inner clear aperture radius shall be no
more than
m1InnerCa.
2558.0
mm
m1InnerCa
The primary mirror outer clear aperture radius shall be at least
m1OuterCa.
4180.0
mm
m1OuterCa
The primary mirror radius of curvature shall be
m1Radius
-19835.0
mm
m1Radius
3.2.1.2 M2 Prescription
ID: OSS-REQ-0202
Last Modified: 7/19/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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:
The surface prescription of the secondary mirror (M2) shall be defined by the table of
parameters
m2Prescription:
Description
Value
Unit
Name
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
m2_8thAsphere.
-9.680e-
28
mm^-7
m2_8thAsphere
The secondary mirror surface conic constant shall be
m2Conic.
-0.2220
m2Conic
The secondary mirror (m2) inner clear aperture radius shall be
m2InnerCa
900.0
mm
m2InnerCa
The secondary mirror (m2) outer clear aperture radius shall be
m2OuterCa.
1710.0
mm
m2OuterCa
The secondary mirror surface radius of curvature shall be
m2Radius.
-6788.0
mm
m2Radius
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 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
The tertiary mirror surface conic constant shall be
m3Conic.
0.1550
m3Connic
The tertiary mirror inner clear aperture radius shall be at least
m3InnerCa.
550.0
mm
m3InnerCa
The tertiary mirror outer clear aperture radius shall be at least
m3OuterCa.
2508.0
mm
m3OuterCa
The tertiary mirror surface radius of curvature shall be
m3Radius.
-8344.5
mm
m3Radius
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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
The distance from the vertex of M1 to the vertex of M2 shall
be
m1m2Spacing
-
6156.200
6
mm
m1m2Spacing
The distance from the vertex of M2 to the vertex of M3 shall
be
m2m3Spacing
6390.000
6
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 clear aperture diameter of the first lens (L1) first surface
(S1) shall be
l1_s1OuterCa
1550
mm
l1_s1OuterCa
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
The center thickness of the first lens (L1) shall be
l1CenThic
82.23
mm
l1CenThick
The first lens (L1) shall be fabricated from
l1GlassType
Fused
Silica
l1GlassType
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 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 second surface 6th order aspheric coefficient on the
second lens shall be
l2_s2_6thAsphere.
1.656e-18
mm^-5
l2_s2_6thAsphere
The second surface (s2) conic constant on the second lens
(L2) shall be
l2_s2Conic
.
-1.5700
l2_s2Conic
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
65
Description
Value
Unit
Name
The center thickness of the second lens (L2) shall be
l2CenThic
30.00
mm
l2CenThick
The second lens (L2) shall be fabricated from
l2GlassType
Fused
Silica
l2GlassType
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 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 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 i-band filter substrates
second surface (S2) shall be
filter_s2OuterCa_i
746.0
mm
filter_s2OuterCa_i
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 u-band filter substrates
second surface (S2) shall be
filter_s2OuterCa_u
737.0
mm
filter_s2OuterCa_u
The clear aperture diameter of the y-band filter substrates
second surface (S2) shall be
filter_s2OuterCa_y
748.0
mm
filter_s2OuterCa_y
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 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 i-band filter
substrate shall be
filter_s2Radius_i
-5623.0
mm
filter_s2Radius_i
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 u-band filter
substrate shall be
filter_s2Radius_u
-5530.0
mm
filter_s2Radius_u
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 radius of the second surface (s2) of the z-band filter
substrate shall be
filter_s2Radius_z
-5632.0
mm
filter_s2Radius_z
The third lens (L3) shall be fabricated from
l3GlassType
Fused
Silica
filterGlassType
The thicknes of the g-band filter substrate shall be
filterThick_g
21.50
mm
filterThick_g
The thicknes of the i-band filter substrate shall be
filterThick_i
15.70
mm
filterThick_i
The thicknes of the r-band filter substrate shall be
filterThick_r
17.90
mm
filterThick_r

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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
The thicknes of the u-band filter substrate shall be
filterThick_u
26.60
mm
filterThick_u
The thicknes of the y-band filter substrate shall be
filterThick_y
13.60
mm
filterThick_y
The thicknes of the z-band filter substrate shall be
filterThick_z
14.4
mm
filterThick_z
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 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) 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 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
The center thickness of the third lens (L3) shall be
l3CenThic
60.00
mm
l3CenThick
The third lens (L3) shall be fabricated from
l3GlassType
Fused
Silica
l3GlassType
3.2.1.9 Lens Spacings
ID: OSS-REQ-0209
Last Modified: 7/19/2010
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.
-346.58
mm
l2_filterSpacing
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.
-50.50
mm
L3_filterSpacing_g
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.
-56.30
mm
L3_filterSpacing_i

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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 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.
-54.10
mm
L3_filterSpacing_r
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.
-45.40
mm
L3_filterSpacing_u
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.
-58.40
mm
L3_filterSpacing_y
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.
-57.60
mm
L3_filterSpacing_z
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 Wavefront Sensing Functions
ID
: OSS-REQ-0217
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.
Wavefront Estimation Range
ID
: OSS-REQ-0218
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.
Wavefront Sensing on Sky Efficiency
ID
: OSS-REQ-0219
Specification:
The wavefront sensors shall supply data for the estimation of the wavefront over at least
wfsSkyEfficiency
of all visits regardless of visit filter.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
68
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.
Wavefront Sensor FPA Geometry
ID
: OSS-REQ-0220
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.
WFS Data Archiving and Buffering
ID
: OSS-REQ-0221
Specification:
For the purposes of archiving and buffering the wavefront sensor imaging data shall be
treated the same as science image data.
3.2.2.2 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.
Secondary (M2) Adjustment
ID: OSS-REQ-0212
Last Modified: 2/9/2015
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 tilt of the secondary on either side of its nominal
design position about the x-axis.
0.1
Degrees
x-tiltRangeM2
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 tilt of the secondary on either side of its nominal
design position about the y-axis.
0.1
Degrees
y-tiltRangeM2
The range of motion of the secondary on either side of its
nominal design position in the z-direction.
10
mm
z-positionRangeM2
Camera Adjustment
ID: OSS-REQ-0213
Last Modified: 5/16/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
69
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 tilt of the camera on either side of its nominal
design position about the x-axis.
0.1
Degrees
x-tiltRangeCam
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 tilt of the camera on either side of its nominal
design position about the y-axis.
0.1
Degrees
y-tiltRangeCam
The range of motion of the camera on either side of its
nominal design position in the z-direction.
10
mm
z-
positionRangCcam
3.2.2.3 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.
L3-FPA Spacing
ID
: OSS-REQ-0216
Specification:
The spacing between L3 and the FPA shall be adjustable one time within the range of
fpaL3Comp
about the nominal design spacing.
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.
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
ID: OSS-REQ-0216
Last Modified: 7/21/2010

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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 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
ID: OSS-REQ-0217
Last Modified: 8/5/2010
ID: OSS-REQ-0218
Last Modified: 7/21/2010
ID: OSS-REQ-0219
Last Modified: 5/16/2011
Description
Value
Unit
Name
The minimum fraction of visits where valid wavefront sensing
data can be obtained.
95
Percent
wfsSkyEfficiency
ID: OSS-REQ-0220
Last Modified: 5/26/2011
ID: OSS-REQ-0221
Last Modified: 7/21/2010
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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
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
The increase in photometric error over repeated
measurements caused by the effects of image ghosts shall
not exceed
ghostPhotErr
.
10.0
Percent
ghostPhotErr
Lens Anti-Reflection Coating
ID: OSS-REQ-0223
Last Modified: 1/8/2016
Specification:
The reflection at any location in the pupil for any field angle in the 3.5 degree field of view
on any transmissive optical surface (not including filters), shall be less than
lensReflection
at all
wavelengths between 300-1100nm using the r-band beam angles of incidence defined in LSE-11.
Discussion:
These specifications constrain the intensity of the 2-reflection ghost images.
The r-band beam defined in LSE-11 has been designated the nominal beam for use in evaluating the lens
reflections. That definition includes the beam angles at both surfaces of each lens.
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
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 limiting angle from the moon with respect to the optical
axis where surface contributions to stray light need to be
identified.
45
Degrees
lunarAngle
The threshold above which surfaces need to be identified and
treated for minimization of stray light.
10
Percent
strayThreshold
3.2.3.3 Optical Baffing
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

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
72
ID: OSS-REQ-0227
Last Modified: 1/28/2016
Specification:
LSST image quality (size) is measured by delivered seeing expressed by using the
equivalent Gaussian width (FWHM). The LSST SRD defines the FWHM (effective FWHM) through an
equivalent, axially symmetric Gaussian shape, resulting in the same effective number of pixels (neff). This
definition of FWHM shall be observed in all performance estimates and compliance evaluations for LSST,
at all levels of performance allocation (error budgeting).
Discussion:
The numerically and conceptually efficient way of estimating the effects of optical
aberrations on the effective FWHM is by using the Normalized Point Source Sensitivity (PSSN) as
described in Document-17242.
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 system image budget is allowed to degrade through the
three reference zenith distances (zd) as sec(zd)^
ImFunc
.
0.6
ImFunc
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 maximum fraction of the field of view that can exceed the
delivered image size by a factor of
SX
.
10
Percent
SF1
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
Delivered image quality increase factor allowed over
SF1
fraction of the field of view.
1.1
float
SX
The maximum RSS contribution from the LSST system to the
atmospheric seeing referenced at zenith or airmass (sec(zd))
= 1.
0.40
ArcsecFW
HM
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
ArcsecFW
HM
SysIm_45

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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
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
ArcsecFW
HM
SysIm_60
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
Camera is
imgBudgetCam.
0.30
ArcsecFW
HM
imgBugetTCam
The portion of the system image budget allocated to the
Telescope is
imgBudgetTel.
0.25
ArcsecFW
HM
imgBugetTel
3.2.4.3 Off Zenith Image Degradation
ID: OSS-REQ-0230
Last Modified: 3/11/2015
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
3.2.5 Image Ellipticity
ID: OSS-REQ-0232
Last Modified: 5/16/2011

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
74
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 fraction of PSF ellipticity measurements allowed to
exceed the ellipticity outlier limit for bright isolated non-
saturated stars.
5
Percent
EF1
Fraction of allowed PSF measurements of isolated bright stars
to exceed the ellipticity residual correlation amplitude outlier
limit.
10
Percent
EF2
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 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
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
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
Median residual PSF ellipticity correlations averaged over an
arbitrary field of view for separations less than 1 arcmin shall
be no greater than
TE1.
2.0e-5
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: 2/16/2016
Specification:
Evaluation of the filter response shall use the area weighted mean response function as
defined in Document-16295 using the r-band beam defined in LSE-11.
Discussion:
The following definitions apply to the filter response requirements below
1.
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.
2.
The area weighted mean response function (as defined in Document-16295) is used combine the
filter response functions for points on the filter substrate into an average response.
3.
The r-band beam footprints defined in LSE-11 have been designated the nominal beam footprints
for use in evaluating filter performance. That footprint definition includes the annulus and beam angles at
both surfaces of each filter. The r-band filter annulus is typically within a few percent of the filter annulus
for the other bands, The u-band second surface is 7% smaller. The incident angle of the beam varies
linearly from the outer edge of the annulus to the inner edge of the annulus.
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
specifications in the table below.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
76
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
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
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
3.3.1.2 Filter Response Uniformity
ID: OSS-REQ-0238
Last Modified: 1/28/2016
Specification:
The wavelength of the blue and red 50% response points of the response function at any
given point 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 grizy-band filter response uniformity.
1.5%
Percent
filtUniformity_grizy
The maximum allowed u-band filter response uniformity.
2.5%
Percent
filtUniformity_u
3.3.1.3 In-band Ripple
ID: OSS-REQ-0239
Last Modified: 1/28/2016
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. The in-band limits are allowed to be shifted by the measured shift allowed by OSS-REQ-0238.
Description
Value
Unit
Name
Allowed filter ripple
3
Percent
maxFiltRipple
3.3.1.4 u-band Response Envelope
ID: OSS-REQ-0240
Last Modified: 5/16/2014

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
77
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
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 zero response wavelength of the u-band lower
envelope.
403.5
nm
u_lowerRed(0)
The red side 97% response wavelength of the u-band lower
envelope.
379.25
nm
u_lowerRed(0.97)
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 zero response wavelength of the u-band upper
envelope.
408.5
nm
u_upperRed(0)
The red side 103% response wavelength of the u-band upper
envelope.
382.75
nm
u_upperRed(1.03)
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)

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
78
Description
Value
Unit
Name
The red side zero response wavelength of the u-band
minimum envelope.
400.5
nm
u_minRed(0)
The red side 97% response wavelength of the u-band
minimum envelope.
379.25
nm
u_minRed(0.97)
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 zero response wavelength of the u-band
maximum envelope.
411.5
nm
u_maxRed(0)
The red side 103% response wavelength of the u-band
maximum envelope.
385.75
nm
u_maxRed(1.03)
Figure 1: u-band envelope

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
79
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 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 zero response wavelength of the g-band lower
envelope.
562.0
nm
g_lowerRed(0)
The red side 0.97% response wavelength of the g-band lower
envelope.
537.75
nm
g_lowerRed(0.97)
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 zero response wavelength of the g-band upper
envelope.
567.0
nm
g_upperRed(0)
The red side 103% response wavelength of the g-band upper
envelope.
541.25
nm
g_upperRed(1.03)
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
80
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 zero response wavelength of the g-band
minimum envelope.
559.0
nm
g_minRed(0)
The red side 97% response wavelength of the g-band
minimum envelope.
537.75
nm
g_minRed(0.97)
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 envelope.
409.25
nm
g_maxBlue(1.03)
The red side zero response wavelength of the g-band
maximum envelope.
570.0
nm
g_maxRed(0)
The red side 103% response wavelength of the g-band
maximum envelope.
544.25
nm
g_maxRed(1.03)
Figure 2: g-band envelope

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
81
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:
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 zero response wavelength of the r-band lower
envelope.
701.0
nm
r_lowerRed(0)
The red side 97% response wavelength of the r-band lower
envelope.
676.75
nm
r_lowerRed(0.97)
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 zero response wavelength of the r-band upper
envelope.
706.0
nm
r_upperRed(0)
The red side 103% response wavelength of the r-band upper
envelope.
680.25
nm
r_upperRed(1.03)
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
82
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 zero response wavelength of the r-band
minimum envelope.
698.0
nm
r_minRed(0)
The red side 97% response wavelength of the r-band
minimum envelope.
676.75
nm
r_minRed(0.97)
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 zero response wavelength of the r-band
maximum envelope.
709.0
nm
r_maxRed(0)
The red side 103% response wavelength of the r-band
maximum envelope.
683.25
nm
r_maxRed(1.03)
Figure 3: r-band envelope
3.3.1.7 i-band Response Envelope

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
83
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:
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 zero response wavelength of the i-band lower
envelope.
828.0
nm
i_lowerRed(0)
The red side 97% response wavelength of the i-band lower
envelope.
803.75
nm
i_lowerRed(0.97)
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 zero response wavelength of the i-band upper
envelope.
833.0
nm
i_upperRed(0)
The red side 103% response wavelength of the i-band upper
envelope.
807.25
nm
i_upperRed(1.03)
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)

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
84
Description
Value
Unit
Name
The blue side 97% response wavelength of the i-band
minimum envelope.
705.25
nm
i_minBlue(0.97)
The red side zero response wavelength of the i-band
minimum envelope.
825.0
nm
i_minRed(0)
The red side 97% response wavelength of the i-band
minimum envelope.
803.75
nm
i_minRed(0.97)
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 envelope.
698.75
nm
i_maxBlue(1.03)
The red side zero response wavelength of the i-band
maximum envelope.
836.0
nm
i_maxRed(0)
The red side 103% response wavelength of the i-band
maximum envelope.
810.25
nm
i_maxRed(1.03)

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
85
Figure 4: i-band envelope
3.3.1.8 z-band Response Envelope
ID: OSS-REQ-0244
Last Modified: 5/6/2014
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 zero response wavelength of the z-band lower
envelope.
933.5
nm
z_lowerRed(0)
The red side 97% response wavelength of the z-band lower
envelope.
909.25
nm
z_lowerRed(0.97)
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 zero response wavelength of the z-band upper
envelope.
938.5
nm
z_upperRed(0)
The red side 103% response wavelength of the z-band upper
envelope.
912.75
nm
z_upperRed(1.03)
z-band not-to-exceed envelope
ID: OSS-REQ-0370
Last Modified: 4/10/2015
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.

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
86
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 zero response wavelength of the z-band
minimum envelope.
930.5
nm
z_minred(0)
The red side 97% response wavelength of the z-band
minimum envelope.
909.25
nm
z_minred(0.97)
Description
Value
Unit
Name
The blue side zero response wavelength of the z-band
maximum envelope.
800.0
nm
z_maxBlue(0)
The blue side 103% response wavelength of the z-band
maximum envelope.
825.75
nm
z_maxBlue(1.03)
The red side zero response wavelength of the z-band
maximum envelope.
941.5
nm
z_maxRed(0)
The red side 103% response wavelength of the z-band
maximum envelope.
915.75
nm
z_maxRed(1.03)

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
87
Figure 5: z-band envelope
3.3.1.9 y-band Response Envelope
ID: OSS-REQ-0245
Last Modified: 5/16/2014
Specification:
The area weighted mean y-band filter response normalized to the in-band average (as
measured between y_inBandBlue and y_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 y-band filter response
normalization.
938.5
nm
y_InBandBlue
The in-band red limit for the y-band filter response
normalization.
1069.25
nm
y_InBandRed

LSST Observatory System Specifications
LSE-30
Latest Revision 6/5/2017
The contents of this document are subject to configuration control and may not be changed, altered, or their provisions
waived without prior approval.
88
Description
Value
Unit
Name
The blue side zero response wavelength of the y-band lower
envelope.
913.5
nm
y_lowerBlue(0)
The blue side 97% response wavelength of the y-band lower
envelope.
937.75
nm
y_lowerBlue(0.97)
The red side zero response wavelength of the y-band lower
envelope.
1070.0
nm
y_lowerRed(0)
The red side 97% response wavelength of the y-band lower
envelope.
1070.0
nm
y_lowerRed(0.97)
Description
Value
Unit
Name
The blue side zero response wavelength of the y-band upper
envelope.
908.5
nm
y_upperBlue(0)
The blue side 103% response wavelength of the y-band upper
envelope.
934.25
nm
y_upperBlue(1.03)
The red side zero response wavelength of the y-band upper
envelope.
1201.0
nm
y_upperRed(0)
The red side 103% response wavelength of the y-band upper
envelope.
1201.0
nm
y_upperRed(1.03)
y-band not-to-exceed envelope
ID: OSS-REQ-0371
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 y-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 y-band
minimum envelope.
916.5
nm
y_minBlue(0)
The blue side 97% response wavelength of the y-band
minimum envelope.
937.75
nm
y_minBlue(0.97)
The red side zero response wavelength of the y-band
minimum envelope.
1070.0
nm
y_minRed(0)
The red side 97% response wavelength of the y-band
minimum envelope.
1070.0
nm
y_minRed(0.97)