> **LANDSAT DATA CONTINUITY**
>
> **MISSION**
>
> **OPERATIONAL LAND IMAGER**
>
> **CONTRACT DATA REQUIREMENTS LIST (CDRL)**
>
> **October 31, 2006**

![](media/image1.png)

**LDCM PROJECT**

**DOCUMENT CHANGE RECORD**

Sheet: 1 of 1

+------------+----------------------------------------------+---------+
| REV        | DESCRIPTION OF CHANGE                        | DATE    |
|            |                                              |         |
| LEVEL      |                                              | A       |
|            |                                              | PPROVED |
+------------+----------------------------------------------+---------+
|            |                                              |         |
+------------+----------------------------------------------+---------+

  ------------------------------------------------------------------------------------------
  **Section**   **Type**   **Description**                    **Resolution   **Responsible
                                                              Due By**       Party**
  ------------- ---------- ---------------------------------- -------------- ---------------
                                                                             

                                                                             

                                                                             

                                                                             

                                                                             

                                                                             
  ------------------------------------------------------------------------------------------

**Table of TBDs / TBRs / TBSs**

The term "To Be Determined" (TBD) applied to a missing requirement means
that the contractor shall determine the missing requirement in
coordination with the Government. The term "To Be Supplied" (TBS) means
that the Government will supply the missing information in the course of
this contract. The term "To Be Reviewed" (TBR) means that the
requirement is subject to review for appropriateness by the contractor
or the Government, with approval by the Government. The Government may
change TBR requirements in the course of this contract.

**TABLE OF CONTENTS**

[Page]{.underline}

1.0 INTRODUCTION [1-1](#introduction)

2.0 DEFINITION OF DUE DATES/MATURITY, DEFINITION OF CATEGORIES, AND
MAILING DISTRIBUTION INSTRUCTIONS
[2-1](#definition-of-due-datesmaturity-definition-of-categories-and-mailing-distribution-instructions)

2.1 DUE DATES/MATURITY - Related Definitions
[2-1](#due-datesmaturity---related-definitions)

2.2 QUANTITY - Related Definitions
[2-2](#quantity---related-definitions)

2.3 MEDIA - Related Definitions [2-2](#media---related-definitions)

2.4 CATEGORY - Related Definitions
[2-3](#category---related-definitions)

3.0 LDCM CONTRACT DATA requirementS LIST
[3-1](#ldcm-contract-data-requirements-list)

4.0 DATA ITEM DESCRIPTIONS [4-1](#descriptions-of-required-data)

**LIST of TABLES**

[Table]{.underline} [Page]{.underline}

**Table 3‑1 Contract Data Requirements List (CDRL)
[3-2](#__RefHeading___Toc10535819)**

**Table 3-2 LDCM Thermal Math Models
Deliverables................................\......\...3-21**

# INTRODUCTION

This Contract Data Requirements List (CDRL) document defines the
requirements for deliverable documentation to be provided by the
Operational Land Imager (OLI) Contractor. Section 2.0 includes
definitions and instructions for mailing and/or distribution. Table 3-1
presents the CDRL item by item, with due dates, quantity, and media
format. Section 4.0 provides the Description of Required Data (DRD) a
description of each item, which provides the use for the deliverable and
the required preparation information. Except where specifically
indicated to the contrary, the formats and drawing standards used shall
be those normally used by the OLI Contractor and by its subcontractors.

# DEFINITION OF DUE DATES/MATURITY, DEFINITION OF CATEGORIES, AND MAILING DISTRIBUTION INSTRUCTIONS 

## DUE DATES/MATURITY - Related Definitions

The following definitions apply to the \"DUE DATE, MATURITY\" column in
Table 4-1. Unless otherwise specified, deadlines are in working days.

(a) DUE DATE:

```{=html}
<!-- -->
```
(1) [PDR, ICDR, PER, etc]{.underline}: Mission Preliminary Design
    Review, Instrument Preliminary Design Review, Pre-Environmental
    Review, Pre-Ship Review, etc (all design reviews). Electronic
    distribution to be delivered to the Government 5 working days prior
    to review, unless otherwise stated.

(2) [As Generated, Update As Required (UAR)]{.underline}: After each
    initial edition, revision, addition, etc. Items that are critical to
    schedule, performance, or interface shall be transmitted to GSFC by
    facsimile or express mail within 48 hours of generation. Where
    available, an electronic version shall also be provided.

(3) [Monthly]{.underline}: Submitted on monthly basis

(4) [T]{.underline}: Launch Date

(5) [DACA]{.underline}: (Calendar) Days After Contract Award

(6) [E]{.underline}: Electronic copies are due at the same time as hard
    copies unless otherwise specified.

```{=html}
<!-- -->
```
(b) MATURITY:

```{=html}
<!-- -->
```
(1) [Initial]{.underline}: The first submission of an item, which will
    be revised and resubmitted at a later date.

(2) .[Preliminary]{.underline}: An early submission of an item. To be
    completed as is practicable at the time of preparation. Preliminary
    submittals are written with the best available current information
    and are resubmitted when further information becomes available.

(3) [Final]{.underline}: The complete, thorough submission of an item
    for approval, review, or information that, to the best of the
    contractor's knowledge and intention, will not require further
    revision or updates. However, this does not preclude updating if
    later found to be necessary. Any updates shall require the same
    \"approval/review\" process as was required for the original
    submissions.

(4) [Current]{.underline}: The delivery is written with the best
    up-to-date information available at the time.

(5) [Update]{.underline}: The delivery is revised with the best
    up-to-date information available at the time.

Other entries in the \"DUE DATE, MATURITY\" column are self-explanatory.

## 2.2 QUANTITY - Related Definitions {#quantity---related-definitions .unnumbered}

The quantities to be delivered shall be per the CDRL listing in column
\"Quantity (QTY)\" in Table 3-1 of this document. If separate quantities
are not specified for separate submission due date/maturity items, then
the listed quantity applies to all submissions.

## MEDIA - Related Definitions

The following definition applies to the "MEDIA" column in Table 3-1.

H -- Hardcopy(s) of this documentation shall be delivered to the
Contracting Officer at GSFC Code 427.

E - Data items shall be delivered in electronic format to a GSFC Landsat
specified web portal unless otherwise noted in Table 3-1. Quantities
refer to hardcopies, not electronic copies. The Contracting Officer
shall be notified of electronic submission of the deliverable in
writing. Electronic deliverables shall be delivered in the following
formats unless otherwise approved by the government:

> Text Documents: PDF (searchable) or MSWord
>
> Presentations: PDF (searchable) or PowerPoint
>
> Spreadsheets: Microsoft Excel
>
> Database: Delimited ASCII files accompanied with database schema
> document defining tables and entries.
>
> Schedules: PDF and MS Project
>
> Schematics and Drawings: Design Web Format (DWF) and PDF
>
> Photographs: JPEG or current industry standard.
>
> Video: Any readily available open standard (e.g., AVI, MPEG)

R -- For Reviews, hardcopies will be made available at the review site
for government representatives. (Generally, this will be in addition to
electronic copies being made available prior to the review.) The
quantity specifies the number of hardcopies to be available at the
review.

If separate distribution instructions are not specified for separate
submission due date/maturity items, then the listed distribution applies
to all submissions.

## CATEGORY - Related Definitions 

The following definitions apply to \"Submission Category (CAT)\" column
in Table 3-1. If separate approval instructions are not specified for
separate submission due date/maturity items, then the listed approval
instruction applies to all submissions.

> A Approval: CDRL items in this category require approval by the GSFC
> Contracting Officer's Technical Representative (COTR) or Contracting
> Officer prior to use by the contractor. Receipt by the Government
> shall occur within the time specified in the \"Due Date\" column of
> Table 3-1 of this document. Requirements for re-submission shall be as
> specified by the Contracting Officer. For most cases the contractor
> will be required to resubmit the document within 14 calendar days of
> receiving comments from the Government. If the contractor has not
> received response from GSFC within 30 calendar days of delivery of a
> CDRL item, the contractor may proceed as if the document has been
> approved.
>
> R Review. Documents in this category require delivery to the
> Government prior to use and within the time period specified in the
> \"Due Date\" column of Table 3-1 of this document. They are subject to
> evaluation by the Government or its designated representatives to
> determine Contractor effectiveness in meeting contract objectives.
> Upon submission, the Contractor may proceed with associated work while
> the Government reviews the submission.
>
> I Information. Data in this category shall be delivered to the
> Government within the time period specified in the "Due Date" column
> of Table 3-1 for the purpose of determining current program status,
> progress, and future planning requirements.

# LDCM CONTRACT DATA requirementS LIST

Table 3-1 comprises the LDCM Contract Data Requirements List.

The Table contents are listed in the following order:

Program Management (PM)

Reviews (RE)

Flight Software (SW)

Integration and Test (IT)

Calibration/Validation (CV)

System Engineering (SE)

Systems Assurance (SA)

On-Orbit Operations (OO)

[]{#__RefHeading___Toc10535819 .anchor}Table 3‑1 Contract Data
Requirements List (CDRL)

+-----+-----------------------+--------------------+----+------+----+
| *   | **MANAGEMENT**        | **DUE DATE,        | *  | *    | *  |
| *No |                       | MATURITY**         | *Q | *MED | *C |
| .** |                       |                    | TY | IA** | AT |
|     |                       |                    | ** |      | ** |
+=====+=======================+====================+====+======+====+
| P   | Monthly Project       | Monthly (nominally | 20 | E, R | I  |
| M-1 | Status Reviews (MPSR) | the last Wednesday |    |      |    |
|     |                       | of each month)     |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Integrated Master     | \- Preliminary     | 3  | H, E | I  |
| M-2 | Schedule (IMS)        | with Proposal      |    |      |    |
|     |                       |                    | 3  | H, E | I  |
|     |                       | \- Initial 45 DACA |    |      |    |
|     |                       |                    | 3  | H, E | I  |
|     |                       | \- Baselined 60    |    |      |    |
|     |                       | DACA               | 3  | H, E | I  |
|     |                       |                    |    |      |    |
|     |                       | \- Update Monthly, |    |      |    |
|     |                       | delivered 7 days   |    |      |    |
|     |                       | prior to MPSR      |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | CADRE Data            | \- 60 DACA,        | 2  | H, E | R  |
| M-3 |                       | Preliminary        |    |      |    |
|     |                       |                    | 2  | H, E | R  |
|     |                       | \- IPDR-30 days,   |    |      |    |
|     |                       | Update             | 2  | H, E | R  |
|     |                       |                    |    |      |    |
|     |                       | \- CDR+15 days,    | 2  | H, E | R  |
|     |                       | Update             |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | \- Post-Launch,    |    |      |    |
|     |                       | Final              |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Final Report          | Delivered          | 2  | H, E | I  |
| M-4 |                       | incrementally at:  |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | ICDR               |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | IPER               |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | IPSR               |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | Acceptance + 30    |    |      |    |
|     |                       | days               |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Engineering Peer      | \- with Proposal,  | 2  | H, E | I  |
| M-5 | Review Plan           | Preliminary        |    |      |    |
|     |                       |                    | 2  | H, E | A  |
|     |                       | \- 60 DACA, Final  |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Earned Value System   | \- Preliminary     | 1  | E    | I  |
| M-6 | Management Plan       | submission after   |    |      |    |
|     |                       | notification of    | 1  | E    | R  |
|     |                       | selection, but     |    |      |    |
|     |                       | prior to contract  | 1  | E    | R  |
|     |                       | award              |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | \- Initial         |    |      |    |
|     |                       | submission 60 DACA |    |      |    |
|     |                       |                    |    |      |    |
|     |                       | \- Updated if EVM  |    |      |    |
|     |                       | System             |    |      |    |
|     |                       | Architecture       |    |      |    |
|     |                       | changes            |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Financial Reports     | 533M: Monthly      | 4  | H, E | R  |
| M-7 |                       | (within 15         |    |      |    |
|     |                       | calendar days of   |    |      |    |
|     |                       | end of previous    |    |      |    |
|     |                       | month) 533Q:       |    |      |    |
|     |                       | Quarterly          |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Cost Performance      | \- Formats 1-5     | 1  | H, E | I  |
| M-8 | Reports               | Monthly (no later  |    |      |    |
|     |                       | than 18 calendar   |    |      |    |
|     |                       | days after         |    |      |    |
|     |                       | accounting         |    |      |    |
|     |                       | calendar month end |    |      |    |
|     |                       | date)              |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| P   | Engineering           | With Proposal,     | \- | E    | I  |
| M-9 | Development Unit Plan | Preliminary        |    |      |    |
|     |                       |                    | 2  | H, E | A  |
|     |                       | ISRR, Update       |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| PM  | Hardware and Software | 45 DACA, Final     | 2  | H, E | R  |
| -10 | Configuration         |                    |    |      |    |
|     | Management Plan       |                    |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| PM  | Project Management    | 30 DACA, Final     | 2  | H, E | R  |
| -11 | Plan                  |                    |    |      |    |
+-----+-----------------------+--------------------+----+------+----+
| PM  | Risk Management Plan  | 45 DACA, Final     | 2  | H, E | R  |
| -12 |                       |                    |    |      |    |
+-----+-----------------------+--------------------+----+------+----+

+-----+----------------------------+-----------------+----+------+----+
| *   | **REVIEWS**                | **DUE DATE,     | *  | *    | *  |
| *No |                            | MATURITY**      | *Q | *MED | *C |
| .** |                            |                 | TY | IA** | AT |
|     |                            |                 | ** |      | ** |
+=====+============================+=================+====+======+====+
| R   | Instrument System          | Electronic copy | \- | E    | I  |
| E-1 | Requirements Review Data   | in Project      |    |      |    |
|     | Package                    | library:        | \- | E    | I  |
|     |                            |                 |    |      |    |
|     |                            | 1 day prior to  | 50 | H    | I  |
|     |                            | dry run         |    | ,R,E |    |
|     |                            |                 |    |      |    |
|     |                            | 5 days prior to |    |      |    |
|     |                            | review. Hard    |    |      |    |
|     |                            | copies at       |    |      |    |
|     |                            | review.         |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Instrument Preliminary     | Electronic copy | \- | E    | I  |
| E-2 | Design Review Data Package | in Project      |    |      |    |
|     |                            | library:        | \- | E    | I  |
|     |                            |                 |    |      |    |
|     |                            | 1 day prior to  | 50 | H    | I  |
|     |                            | dry run         |    | ,R,E |    |
|     |                            |                 |    |      |    |
|     |                            | 5 days prior to |    |      |    |
|     |                            | review. Hard    |    |      |    |
|     |                            | copies at       |    |      |    |
|     |                            | review.         |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Instrument Critical Design | Electronic copy | \- | E    | I  |
| E-3 | Review Package             | in Project      |    |      |    |
|     |                            | library:        | \- | E    | I  |
|     |                            |                 |    |      |    |
|     |                            | 1 day prior to  | 50 | H    | I  |
|     |                            | dry run         |    | ,R,E |    |
|     |                            |                 |    |      |    |
|     |                            | 5 days prior to |    |      |    |
|     |                            | review. Hard    |    |      |    |
|     |                            | copies at       |    |      |    |
|     |                            | review.         |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Instrument                 | Electronic copy | \- | E    | I  |
| E-4 | Pre-Environmental Review   | in Project      |    |      |    |
|     | Data Package               | library:        | \- | E    | I  |
|     |                            |                 |    |      |    |
|     |                            | 1 day prior to  | 50 | H    | I  |
|     |                            | dry run         |    | ,R,E |    |
|     |                            |                 |    |      |    |
|     |                            | 5 days prior to |    |      |    |
|     |                            | review. Hard    |    |      |    |
|     |                            | copies at       |    |      |    |
|     |                            | review.         |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Instrument Pre-Ship Review | Electronic copy | \- | E    | I  |
| E-5 | Data Package               | in Project      |    |      |    |
|     |                            | library:        | \- | E    | I  |
|     |                            |                 |    |      |    |
|     |                            | 1 day prior to  | 50 | H    | I  |
|     |                            | dry run         |    | ,R,E |    |
|     |                            |                 |    |      |    |
|     |                            | 5 days prior to |    |      |    |
|     |                            | review. Hard    |    |      |    |
|     |                            | copies at       |    |      |    |
|     |                            | review.         |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Inputs to Mission Level    | Electronic copy | \- | E    | I  |
| E-6 | Reviews                    | 10 days prior   |    |      |    |
|     |                            | to review.      |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Engineering Peer Review    | Hard copies at  | 20 | H    | I  |
| E-7 | Data Packages              | review.         |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Integrated Baseline Review | \- IBR Data     | 2  | H, E | I  |
| E-8 | Package                    | Package 120     |    |      |    |
|     |                            | DACA            | 10 | E, R | A  |
|     |                            |                 |    |      |    |
|     |                            | \- IBR Review   |    |      |    |
|     |                            | 180 DACA        |    |      |    |
|     |                            |                 |    |      |    |
|     |                            | \- Update if    |    |      |    |
|     |                            | Re-baseline     |    |      |    |
|     |                            | occurs          |    |      |    |
+-----+----------------------------+-----------------+----+------+----+
| R   | Inputs to On-Orbit         | Electronic copy | \- | E    | I  |
| E-9 | Acceptance Review          | 10 days prior   |    |      |    |
|     |                            | to review.      |    |      |    |
+-----+----------------------------+-----------------+----+------+----+

+-----+---------------------------+-----------------+----+------+----+
| *   | **INTEGRATION AND TEST**  | **DUE DATE,     | *  | *    | *  |
| *No |                           | MATURITY**      | *Q | *MED | *C |
| .** |                           |                 | TY | IA** | AT |
|     |                           |                 | ** |      | ** |
+=====+===========================+=================+====+======+====+
| S   | Software Requirements     | Software        | 2  | H, E | R  |
| W-1 | Specification             | Requirement     |    |      |    |
|     |                           | Review,         | 2  | H, E | R  |
|     |                           | Preliminary     |    |      |    |
|     |                           |                 | 2  | H, E | R  |
|     |                           | Software        |    |      |    |
|     |                           | Post-IPDR,      | 2  | H, E | R  |
|     |                           | Baseline        |    |      |    |
|     |                           |                 | 2  | H, E | R  |
|     |                           | Software        |    |      |    |
|     |                           | Post-ICDR,      |    |      |    |
|     |                           | Update          |    |      |    |
|     |                           |                 |    |      |    |
|     |                           | SWAR, Update    |    |      |    |
|     |                           |                 |    |      |    |
|     |                           | Software Final  |    |      |    |
|     |                           | Transition,     |    |      |    |
|     |                           | Update          |    |      |    |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Design Document  | ICDR,           | 3  | H, E | I  |
| W-2 |                           | preliminary     |    |      |    |
|     |                           |                 | 3  | H, E | I  |
|     |                           | IPSR, Final     |    |      |    |
|     |                           |                 | \- | H, E | I  |
|     |                           | Update as       |    |      |    |
|     |                           | Required        |    |      |    |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Users Guide      | At IPSR,        | 3  | H, E | I  |
| W-3 |                           | preliminary     |    |      |    |
|     |                           |                 | 3  | H, E | I  |
|     |                           | Update as       |    |      |    |
|     |                           | Required        | \- | H, E | I  |
|     |                           |                 |    |      |    |
|     |                           | Final: End of   |    |      |    |
|     |                           | contract        |    |      |    |
|     |                           | (\~L+5yrs)      |    |      |    |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Test Readiness   | At review,      | 10 | R    | I  |
| W-4 | Review (SWTRR) Data       | Final           |    |      |    |
|     | Package                   |                 |    |      |    |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Acceptance       | Reports 15      | 10 | R    | I  |
| W-5 | Review (SWAR) Data        | calendar days   |    |      |    |
|     | Package & Test Reports    | after each      |    |      |    |
|     |                           | test;           |    |      |    |
|     |                           |                 |    |      |    |
|     |                           | Data Package at |    |      |    |
|     |                           | review          |    |      |    |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Test Plan        | IPDR            | 2  | H, E | R  |
| W-6 |                           |                 |    |      |    |
|     |                           |                 | 2  | H, E | R  |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Delivery Package | Software: at    | \- | E    | R  |
| W-7 | and Updates               | Commissioning   |    |      |    |
|     |                           |                 | \- | E    | R  |
|     |                           | Prior to end of |    |      |    |
|     |                           | contract (\~    | \- | E    | R  |
|     |                           | L+5 yrs)        |    |      |    |
|     |                           |                 |    |      |    |
|     |                           | Updates: as     |    |      |    |
|     |                           | performed       |    |      |    |
+-----+---------------------------+-----------------+----+------+----+
| S   | Software Management and   | 90 DACA         | \- | E    | I  |
| W-8 | Development Plan          |                 |    |      |    |
+-----+---------------------------+-----------------+----+------+----+

+----+----------------------------+-----------------+----+------+----+
| *  | **INTEGRATION AND TEST**   | **DUE DATE,     | *  | *    | *  |
| *N |                            | MATURITY**      | *Q | *MED | *C |
| o. |                            |                 | TY | IA** | AT |
| ** |                            |                 | ** |      | ** |
+====+============================+=================+====+======+====+
| IT | Instrument Integration and | IPDR,           | 2  | H, E | R  |
| -1 | Test Plan                  | Preliminary     |    |      |    |
|    |                            |                 | 2  | H, E | R  |
|    |                            | ICDR, Final     |    |      |    |
+----+----------------------------+-----------------+----+------+----+
| IT | Test Reports               | 10 days after   | 2  | H, E | R  |
| -2 |                            | test completion |    |      |    |
+----+----------------------------+-----------------+----+------+----+
| IT | Detailed Test Plans        | 14 Days prior   | 2  | H, E | R  |
| -3 |                            | to test, Final  |    |      |    |
|    |                            |                 | 2  | H, E | R  |
|    |                            | Launch          |    |      |    |
|    |                            | site-specific   |    |      |    |
|    |                            | Test Plans:     |    |      |    |
|    |                            |                 |    |      |    |
|    |                            | Draft: 60       |    |      |    |
|    |                            | calendar days   |    |      |    |
|    |                            | prior to SC     |    |      |    |
|    |                            | PSR.            |    |      |    |
|    |                            |                 |    |      |    |
|    |                            | Final: SC PSR   |    |      |    |
+----+----------------------------+-----------------+----+------+----+
| IT | Packaging, Handling,       | IPDR,           | 2  | H, E | R  |
| -4 | Storage, and               | Preliminary     |    |      |    |
|    | Transportation (PHS&T)     |                 | 2  | H, E | R  |
|    | Plan and Procedures        | 21 days prior   |    |      |    |
|    |                            | to ICDR, Final  |    |      |    |
+----+----------------------------+-----------------+----+------+----+
| IT | As-Run Test Procedures     | At the          | \- | E    | I  |
| -5 |                            | conclusion of   |    |      |    |
|    |                            | each test       |    |      |    |
+----+----------------------------+-----------------+----+------+----+
| IT | Environmental Verification | 10 days prior   | 2  | H, E | A  |
| -6 | Plan and Environmental     | to IPDR,        |    |      |    |
|    | Test Matrix                |                 |    |      |    |
|    |                            | 10 days prior   |    |      |    |
|    |                            | to ICDR,        |    |      |    |
|    |                            |                 |    |      |    |
|    |                            | 15 days prior   |    |      |    |
|    |                            | to IPER,        |    |      |    |
|    |                            |                 |    |      |    |
|    |                            | Updates As      |    |      |    |
|    |                            | Required        |    |      |    |
+----+----------------------------+-----------------+----+------+----+

+----+-------------------------+---------------------+----+------+----+
| *  | **C                     | **DUE DATE,         | *  | *    | *  |
| *N | ALIBRATION/VALIDATION** | MATURITY**          | *Q | *MED | *C |
| o. |                         |                     | TY | IA** | AT |
| ** |                         |                     | ** |      | ** |
+----+-------------------------+---------------------+----+------+----+
| CV | Calibration/Validation  | With Proposal,      | 3  | H, E | I  |
| -1 | Plan                    | Draft               |    |      |    |
|    |                         |                     | 3  | H, E | A  |
|    |                         | IPDR, Update        |    |      |    |
|    |                         |                     | 3  | H, E | A  |
|    |                         | ICDR Final          |    |      |    |
|    |                         |                     | 3  | H, E | A  |
|    |                         | Updates as required |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Calibration/Validation  | 60 days prior to    | 3  | H, E | R  |
| -2 | Procedures              | use, Draft          |    |      |    |
|    |                         |                     | 3  | H, E | R  |
|    |                         | 10 days prior to    |    |      |    |
|    |                         | use, Final          | 3  | H, E | R  |
|    |                         |                     |    |      |    |
|    |                         | L-90 days, on-orbit |    |      |    |
|    |                         | procedures          |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Calibration/Validation  | Electronic Data 3   | \- | E    | I  |
| -3 | Reports and Summaries   | days post-test      |    |      |    |
|    |                         |                     | 3  | H, E | R  |
|    |                         | Test Report -- 10   |    |      |    |
|    |                         | days post-test      | 3  | H, E | R  |
|    |                         |                     |    |      |    |
|    |                         | Analyses -- At      | 3  | H, E | R  |
|    |                         | completion + 10     |    |      |    |
|    |                         | days, NLT IPSR.     | 3  | H, E | R  |
|    |                         |                     |    |      |    |
|    |                         | Pre-Ship Summary:   |    |      |    |
|    |                         | IPSR                |    |      |    |
|    |                         |                     |    |      |    |
|    |                         | Post-Launch         |    |      |    |
|    |                         | Summary: IOC + 3    |    |      |    |
|    |                         | months              |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Radiometric Math Model  | 15 days prior to    | 3  | H, E | R  |
| -4 |                         | ICDR, Final         |    |      |    |
|    |                         |                     |    |      |    |
|    |                         | Update as required  |    |      |    |
|    |                         | with measured data  |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Optical Analytical      | IPDR, Preliminary   | 3  | H, E | I  |
| -5 | Model                   |                     |    |      |    |
|    |                         | 15 days prior to    | 3  | H, E | I  |
|    |                         | ICDR, Final         |    |      |    |
|    |                         |                     | 3  | H, E | I  |
|    |                         | Update as Required  |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Calibration Algorithms  | IPSR                | 3  | H,E  | A  |
| -6 | and Parameters          |                     |    |      |    |
|    |                         | Update at IOC       |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Data Processing         | ICDR, Preliminary   | 3  | H, E | A  |
| -7 | Algorithms              |                     |    |      |    |
|    |                         | IPSR, Final         | 3  | H, E | A  |
|    |                         |                     |    |      |    |
|    |                         | IOC, Update as      | 3  | H, E | A  |
|    |                         | Required            |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Relative Spectral       | Component           | 1  | H, E | I  |
| -8 | Response (RSR)          | Measurements: As    |    |      |    |
|    | Component Measurements  | generated           | 3  | H, E | I  |
|    | and System RSR Analysis |                     |    |      |    |
|    |                         | System RSR          |    |      |    |
|    |                         | Analysis: 30 days   |    |      |    |
|    |                         | prior to Instrument |    |      |    |
|    |                         | PER                 |    |      |    |
+----+-------------------------+---------------------+----+------+----+
| CV | Instrument Data Sets    | As Generated IAW    | \- | E    | I  |
| -9 |                         | the SCTR            |    |      |    |
+----+-------------------------+---------------------+----+------+----+

+----+------------------------+---------------------+-----+-----+-----+
| *  | **SYSTEMS              | **DUE DATE,         | *   | **M | *   |
| *N | ENGINEERING**          | MATURITY**          | *QT | EDI | *CA |
| o. |                        |                     | Y** | A** | T** |
| ** |                        |                     |     |     |     |
+====+========================+=====================+=====+=====+=====+
| SE | Engineering Change     | Class I, As         | 2   | H,  | A   |
| -1 | Requests, Deviations,  | Generated           |     | E   |     |
|    | and Waivers            |                     | \-  |     | I   |
|    |                        | Class II, As        |     | E   |     |
|    |                        | Generated           |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Contractor-Generated   | As Requested        | 2   | Or  | I   |
| -2 | Internal Technical     |                     |     | igi |     |
|    | Information            |                     |     | nal |     |
|    |                        |                     |     | for |     |
|    |                        |                     |     | mat |     |
|    |                        |                     |     | (H  |     |
|    |                        |                     |     | or  |     |
|    |                        |                     |     | E)  |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Trend Analysis and     | ICDR, Initial       | 2   | H,  | R   |
| -3 | Operations Log         |                     |     | E   |     |
|    |                        | IPER, Final         | 2   |     | R   |
|    | (List)                 |                     |     | H,  |     |
|    |                        | Monthly             | 2   | E   | I   |
|    | > (Reports)            |                     |     |     |     |
|    | >                      | IPSR                | 2   | H,  | I   |
|    | > (Log)                |                     |     | E   |     |
|    |                        | PSR                 | 2   |     | I   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
|    |                        |                     |     |     |     |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Thermal Math Models    | **See Table 3-2**   | \-  | E   | R   |
| -4 |                        |                     |     |     |     |
|    |                        | All Deliveries      | 3   | H,  | R   |
|    |                        |                     |     | E   |     |
|    |                        | > Math Models       |     |     |     |
|    |                        | >                   |     |     |     |
|    |                        | > User's Guide      |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Engineering Drawings   | Electronic copy     | \-  | D   | I   |
| -5 |                        | available at 5 days |     | eli |     |
|    |                        | prior to ICDR       | \-  | ver | I   |
|    |                        |                     |     | in  |     |
|    |                        | Electronic copy     | 2   | pl  | I   |
|    |                        | available at 5 days |     | ace |     |
|    |                        | prior to IPSR (as   |     |     |     |
|    |                        | built)              |     | E   |     |
|    |                        |                     |     |     |     |
|    |                        | Hardcopies and      |     | H,  |     |
|    |                        | Electronic Final    |     | E   |     |
|    |                        | set at L-30 days    |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | System Performance     | 10 days prior to    | 5   | H,  | A   |
| -6 | Verification Plan and  | IPDR, Preliminary   |     | E   |     |
|    | Matrix                 |                     |     |     |     |
|    |                        | 10 days prior to    |     |     |     |
|    |                        | ICDR, Final         |     |     |     |
|    |                        |                     |     |     |     |
|    |                        | 15 days prior to    |     |     |     |
|    |                        | IPER, Update        |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Verification Reports   | Within 30 days      | 2   | H,  | R   |
| -7 |                        | after each          |     | E   |     |
|    |                        | verification, Final |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Configuration Item     | IPDR, Preliminary   | 2   | H,  | I   |
| -8 | Identification List    |                     |     | E   |     |
|    | and Computer Software  | ICDR, Final         | 2   |     | I   |
|    | Configuration Items    |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| SE | Instrument Design      | ISRR, Preliminary   | 2   | H,  | I   |
| -9 | Specification          |                     |     | E   |     |
|    |                        | 30 days prior to    | 2   |     | I   |
|    |                        | IPDR, Final         |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Focal Plane Array      | Items 1-6, Prior to | 2   | H,  | R   |
| E- | Documentation          | start of FPA        |     | E   |     |
| 10 |                        | manufacture         | 2   |     | I   |
|    |                        |                     |     | H,  |     |
|    |                        | Item 7, As          | 2   | E   | I   |
|    |                        | generated           |     |     |     |
|    |                        |                     |     | H,  |     |
|    |                        | Item 8, As          |     | E   |     |
|    |                        | generated, but NLT  |     |     |     |
|    |                        | IPDR +10 days       |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Interface   | TBD                 | 2   | H,  | A   |
| E- | Information            |                     |     | E   |     |
| 11 |                        |                     |     |     | I   |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Specification Tree     | ISRR, Final         | 2   | H,  | I   |
| E- |                        |                     |     | E   |     |
| 12 |                        |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Inputs to the OLI to   | Preliminary, 60     | 2   | H,  | I   |
| E- | Spacecraft Interface   | days prior to IPDR  |     | E   |     |
| 13 | Control Document       |                     | 2   |     | I   |
|    |                        | Update, 60 days     |     | H,  |     |
|    |                        | prior to ICDR       | 2   | E   | A   |
|    |                        |                     |     |     |     |
|    |                        | Final, 60 days      |     | H,  |     |
|    |                        | prior IPSR          |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Concept of  | Preliminary at ISRR | 2   | H,  | R   |
| E- | Operations Document    |                     |     | E   |     |
| 14 |                        | Final at IPDR       | 2   |     | R   |
|    |                        |                     |     | H,E |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | OLI to TIRS Interface  | TBD                 | 2   | H,  | A   |
| E- | Control Document       |                     |     | E   |     |
| 15 |                        |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Structural and Dynamic | Plan: ISRR -- one   | 3   | H,  | R   |
| E- | Models and Model       | calendar week       |     | E   |     |
| 16 | Verification Plan      |                     | \-  |     | R   |
|    |                        | Models and          |     | E   |     |
|    |                        | Matrices:           | \-  |     | R   |
|    |                        |                     |     | E   |     |
|    |                        | IPDR                | \-  |     | A   |
|    |                        |                     |     | E   |     |
|    |                        | ICDR                |     |     |     |
|    |                        |                     |     |     |     |
|    |                        | PSR -- one month,   |     |     |     |
|    |                        | correlated model    |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Analyses Reports       | Initial, IPDR       | 3   | H,  | R   |
| E- |                        |                     |     | E   |     |
| 17 | INCLUDES Thermal       | Update, ICDR        | 3   |     | R   |
|    | Analysis, Structural   |                     |     | H,  |     |
|    | and Mechanical         | Updates summarized  | 3   | E   | R   |
|    | Analysis, Stress       | twice per year      |     |     |     |
|    | Analysis, Jitter       | thereafter          |     | H,  |     |
|    | Analysis, Radiometric  |                     |     | E   |     |
|    | Analysis               |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Electrical Systems     | ISRR, Preliminary   | 2   | H,  | R   |
| E- | Requirements Document  |                     |     | E   |     |
| 18 |                        | IPDR, Final         | 2   |     | R   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Spare Parts Plan and   | IPDR                | 2   | H,  | A   |
| E- | List                   |                     |     | E   |     |
| 19 |                        |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Acceptance Data        | OLI: At OAR         | 2   | H,  | A   |
| E- | Package                |                     |     | E   |     |
| 20 |                        | Instrument          | 2   |     | A   |
|    |                        | Simulator: after    |     | H,  |     |
|    |                        | acceptance test at  | 2   | E   | A   |
|    |                        | MOC.                |     |     |     |
|    |                        |                     |     | H,  |     |
|    |                        | Instrument          |     | E   |     |
|    |                        | Interface           |     |     |     |
|    |                        | Simulator: after    |     |     |     |
|    |                        | successful checkout |     |     |     |
|    |                        | at delivery         |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Simulator   | ISSR                | 2   | H,  | R   |
| E- | Specification          |                     |     | E   |     |
| 21 |                        | Update as Required  | 2   |     | R   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Simulator   | IPER                | 2   | H,  | R   |
| E- | Users Guide            |                     |     | E   |     |
| 22 |                        | Update as Required  | 2   |     | R   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Simulator   | > Initial: ICDR     | 2   | H,  | A   |
| E- | Interface Verification | >                   |     | E   |     |
| 23 | Report                 | > Final: IPER       | 2   |     | A   |
|    |                        |                     |     | H,  |     |
|    |                        | Both: Update as     | 2   | E   | A   |
|    |                        | Required            |     |     |     |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Simulator   | Test -- 20 days     | 2   | H,  | R   |
| E- | Test Plan              |                     |     | E   |     |
| 24 |                        |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Simulator   | Test + 10 days      | 2   | H,  | R   |
| E- | Software Test Reports  |                     |     | E   |     |
| 25 |                        |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Interface   | ISRR                | 2   | H,  | R   |
| E- | Simulator              |                     |     | E   |     |
| 26 | Specification          | Update as Required  | 2   |     | R   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Interface   | IPER                | 2   | H,  | R   |
| E- | Simulator Users Guide  |                     |     | E   |     |
| 27 |                        | Update as Required  | 2   |     | R   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Interface   | > Initial: ICDR     | 2   | H,  | A   |
| E- | Simulator Interface    | >                   |     | E   |     |
| 28 | Verification Report    | > Final: IPER       | 2   |     | A   |
|    |                        |                     |     | H,  |     |
|    |                        | Both: Update as     | 2   | E   | A   |
|    |                        | Required            |     |     |     |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Interface   | Initial: IPDR       | 2   | H,  | A   |
| E- | Simulator Interface    |                     |     | E   |     |
| 29 | Verification Plan      | Final: ICDR         | 2   |     | A   |
|    |                        |                     |     | H,  |     |
|    |                        |                     |     | E   |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | Instrument Interface   | Test + 10days       | 2   | H,  | R   |
| E- | Simulator Software     |                     |     | E   |     |
| 30 | Test Reports           |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+
| S  | OLI Performance Margin | TBD                 | 2   | H,  | A   |
| E- | Analyses               |                     |     | E   |     |
| 31 |                        |                     |     |     |     |
+----+------------------------+---------------------+-----+-----+-----+

+-----+---------------------------+-----------------+----+------+---+
| *   | **SYSTEMS ASSURANCE**     | **DUE DATE,     | *  | *    | * |
| *No |                           | MATURITY**      | *Q | *MED | * |
| .** |                           |                 | TY | IA** | C |
|     |                           |                 | ** |      | A |
|     |                           |                 |    |      | T |
|     |                           |                 |    |      | * |
|     |                           |                 |    |      | * |
+=====+===========================+=================+====+======+===+
| S   | Quality Manual/Systems    | PDR, Initial    | 2  | H, E | A |
| A-1 | Assurance Plan            |                 |    |      |   |
|     |                           | CDR-45 days,    | 2  | H, E | A |
|     |                           | Final           |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | Problem Failure Reports   | Within 24       | 2  | H, E | I |
| A-2 | (PFRs)                    | hours,          |    |      |   |
|     |                           | Notification    | 2  | H, E | R |
|     |                           |                 |    |      |   |
|     |                           | At closure      |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | System Safety Program     | MDR             | 2  | H, E | A |
| A-3 | Plan                      |                 |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | Preliminary Hazard        | IPDR+30 days    | 2  | H, E | R |
| A-4 | Analysis                  | (Instrument)    |    |      |   |
|     |                           |                 | 2  | H, E | R |
|     |                           | PDR+30 days     |    |      |   |
|     |                           | (spacecraft)    |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | Operations Hazard         | 45 days prior   | 2  | H, E | R |
| A-5 | Analysis                  | to use, Prelim  |    |      |   |
|     |                           |                 | 2  | H, E | R |
|     |                           | 15 days prior   |    |      |   |
|     |                           | to use, Final   |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | Safety Requirements       | With each SAR   | 2  | H, E | I |
| A-6 | Compliance Checklist      | and MSPSP       |    |      |   |
|     |                           | submittal       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | Reliability Program Plan  | +------------+  | 2  | H, E | A |
| A-7 | []{.mark}                 | | 90 DACA,   |  |    |      |   |
|     |                           | | P          |  | 2  | H, E | A |
|     |                           | | reliminary |  |    |      |   |
|     |                           | |            |  |    |      |   |
|     |                           | | PDR-30     |  |    |      |   |
|     |                           | | days,      |  |    |      |   |
|     |                           | | Final      |  |    |      |   |
|     |                           | +------------+  |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| S   | Safety Assessment Report  | IPDR+30 days    | 2  | H, E | I |
| A-8 |                           |                 |    |      |   |
|     |                           | ICDR-30 days    | 2  | H, E | I |
|     |                           |                 |    |      |   |
|     |                           | IPSR-30 days    | 2  | H, E | I |
+-----+---------------------------+-----------------+----+------+---+
| S   | Verification Tracking Log | With each MSPSP | 2  | H, E | R |
| A-9 |                           | submittal       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Ground Operations         | PDR-60 days,    | 2  | H, E | I |
| -10 | Procedures                | Initial         |    |      |   |
|     |                           |                 | 2  | H, E | I |
|     |                           | PSR-60 days,    |    |      |   |
|     |                           | Final           |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Safety Variances          | As identified   | 2  | H, E | A |
| -11 |                           |                 |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Orbital Debris Assessment | MDR, Initial    | 2  | H, E | R |
| -12 |                           |                 |    |      |   |
|     |                           | PDR-20 days,    | 2  | H, E | R |
|     |                           | Update          |    |      |   |
|     |                           |                 | 2  | H, E | A |
|     |                           | CDR-45 days,    |    |      |   |
|     |                           | Final           |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Probabilistic Risk        | PDR -- 30 days, | 2  | H, E | R |
| -13 | Assessment Inputs         | Preliminary     |    |      |   |
|     |                           |                 | 2  | H, E | A |
|     |                           | CDR + 30 days,  |    |      |   |
|     |                           | Final           | 2  | H, E | A |
|     |                           |                 |    |      |   |
|     |                           | Updates, As     |    |      |   |
|     |                           | Generated       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Failure Modes, Effects    | PDR -- 30 days, | 2  | H, E | R |
| -14 | Analysis                  | Preliminary     |    |      |   |
|     |                           |                 | 2  | H, E | R |
|     |                           | CDR - 30 days,  |    |      |   |
|     |                           | Final           | 2  | H, E | R |
|     |                           |                 |    |      |   |
|     |                           | Updates, As     |    |      |   |
|     |                           | Generated       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Critical Items Control    | PDR -- 30 days, | 2  | H, E | R |
| -15 | Plan and Critical Items   | Preliminary     |    |      |   |
|     | List                      |                 | 2  | H, E | R |
|     |                           | CDR - 30 days,  |    |      |   |
|     |                           | Final           | 2  | H, E | R |
|     |                           |                 |    |      |   |
|     |                           | Updates, As     |    |      |   |
|     |                           | Generated       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Fault Tree Analysis       | PDR -- 30 days, | 2  | H, E | R |
| -16 |                           | Preliminary     |    |      |   |
|     |                           |                 | 2  | H, E | R |
|     |                           | CDR - 30 days,  |    |      |   |
|     |                           | Final           | 2  | H, E | R |
|     |                           |                 |    |      |   |
|     |                           | Updates, As     |    |      |   |
|     |                           | Generated       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Contamination Control     | PDR -- 30 days, | 2  | H, E | R |
| -17 | Plan                      | Initial         |    |      |   |
|     |                           |                 | 2  | H, E | A |
|     |                           | CDR -- 30 days, |    |      |   |
|     |                           | Final           |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Parts Control Plan        | PDR, Initial    | 2  | H, E | A |
| -18 |                           |                 |    |      |   |
|     |                           | CDR-45 days,    | 2  | H, E | A |
|     |                           | Final           |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Parts Identification      | PDR -- 30 days: | 2  | H, E | R |
| -19 | List/ADPL/ABPL            | PIL             |    |      |   |
|     |                           |                 | 2  | H, E | R |
|     |                           | CDR -- 30 days: |    |      |   |
|     |                           | ADPL            | 2  | H, E | R |
|     |                           |                 |    |      |   |
|     |                           | PSR -- 60 days: |    |      |   |
|     |                           | ABPL            |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Materials and Processes   | PDR             | 2  | H, E | R |
| -20 | Control Plan              |                 |    |      |   |
|     |                           | CDR -- 30 days  | 2  | H, E | A |
+-----+---------------------------+-----------------+----+------+---+
| SA  | As-Designed/As-Built      | PDR -- 30 days, | 2  | H, E | R |
| -21 | Materials and Processes   | Initial         |    |      |   |
|     | List                      |                 | 2  | H, E | A |
|     |                           | CDR -- 30 days, |    |      |   |
|     |                           | Final As        | 2  | H, E | A |
|     |                           | Designed        |    |      |   |
|     |                           |                 |    |      |   |
|     |                           | Updates as      |    |      |   |
|     |                           | required        |    |      |   |
|     |                           |                 |    |      |   |
|     |                           | As Built, Final |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Parts Stress Analysis     | CDR -- 45 days, | 2  | H, E | A |
| -22 |                           | Final           |    |      |   |
|     |                           |                 | 2  | H, E | A |
|     |                           | Updates as      |    |      |   |
|     |                           | required        |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Worst Case Analysis       | Pre-CDR Peer    | 2  | H, E | A |
| -23 |                           | Reviews -- 30   |    |      |   |
|     |                           | days            | 2  | H, E | A |
|     |                           |                 |    |      |   |
|     |                           | Updates as      |    |      |   |
|     |                           | required        |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Limited Life Items Plan   | PDR -- 30 days, | 2  | H, E | R |
| -24 | and List                  | Preliminary     |    |      |   |
|     |                           |                 | 2  | H, E | A |
|     |                           | CDR -- 30 days, |    |      |   |
|     |                           | Final           | 2  | H, E | A |
|     |                           |                 |    |      |   |
|     |                           | Updates as      |    |      |   |
|     |                           | generated       |    |      |   |
+-----+---------------------------+-----------------+----+------+---+
| SA  | Pre-Mishap Plan           | PDR + 6 months  | 2  | H, E | A |
| -25 |                           |                 |    |      |   |
|     |                           | Updates as      | 2  | H, E | A |
|     |                           | required        |    |      |   |
+-----+---------------------------+-----------------+----+------+---+

+-----+----------------------------+------------------+----+------+----+
| *   | **ON ORBIT**               | **DUE DATE,      | *  | *    | *  |
| *No |                            | MATURITY**       | *Q | *MED | *C |
| .** |                            |                  | TY | IA** | AT |
|     |                            |                  | ** |      | ** |
+=====+============================+==================+====+======+====+
| O   | OLI On-Orbit Commissioning | 90 calendar days | 5  | H, E | A  |
| O-1 | Plan                       | prior to IPSR    |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | Instrument Users Manual    | Initial at IPDR  | 3  | H, E | R  |
| O-2 |                            |                  |    |      |    |
|     |                            | Updated at ICDR  | 3  | H, E | R  |
|     |                            |                  |    |      |    |
|     |                            | Final at IPSR    | 10 | H, E | R  |
+-----+----------------------------+------------------+----+------+----+
| O   | On-Orbit Test Reports      | 10 Days after    | 3  | H, E | R  |
| O-3 |                            | each test        |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | On-orbit Anomaly           | Preliminary at   | 2  | H, E | R  |
| O-4 | Resolution Support Plan    | MOR              |    |      |    |
|     |                            |                  |    |      |    |
|     |                            | Final at FOR     |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | OLI Launch Commit Criteria | L-16 weeks       | 2  | H, E | R  |
| O-5 |                            |                  |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | Telemetry and Command      | Volume 1: 5 Days | 5  | H, E | R  |
| O-6 | Handbook                   | prior to CDR,    |    |      |    |
|     |                            | Update as        | 5  | H, E | R  |
|     |                            | required         |    |      |    |
|     |                            |                  |    |      |    |
|     |                            | Volume 2: Draft  |    |      |    |
|     |                            | at start of I&T, |    |      |    |
|     |                            | Final at PSR,    |    |      |    |
|     |                            | Update as        |    |      |    |
|     |                            | required         |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | OLI Launch and Early Orbit | L-16 weeks       | 2  | H, E | R  |
| O-7 | Procedures                 |                  |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | OLI On-Orbit Operations    | Draft 2 weeks    | 3  | H, E | A  |
| O-8 | and Contingency Procedures | prior to formal  |    |      |    |
|     |                            | test of          | 3  | H, E | A  |
|     |                            | procedure        |    |      |    |
|     |                            |                  |    |      |    |
|     |                            | Final at formal  |    |      |    |
|     |                            | test of          |    |      |    |
|     |                            | procedure        |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| O   | OLI Training Materials     | Draft 8 weeks    | 3  | H, E | R  |
| O-9 |                            | prior to         |    |      |    |
|     |                            | training session | 3  | H, E | R  |
|     |                            |                  |    |      |    |
|     |                            | Final 4 weeks    |    |      |    |
|     |                            | prior to         |    |      |    |
|     |                            | training         |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| OO  | OLI Constraints,           | MOR, Preliminary | 3  | H, E | I  |
| -10 | Restrictions, and Warnings |                  |    |      |    |
|     | Document                   | ORR, Update      | 3  | H, E | I  |
|     |                            |                  |    |      |    |
|     |                            | OAR, Final       | 3  | H, E | I  |
+-----+----------------------------+------------------+----+------+----+
| OO  | OLI Telemetry and Command  | IPER, Initial    | \- | E    | R  |
| -11 | Database                   |                  |    |      |    |
|     |                            | IPSR, Final      | \- | E    | R  |
|     |                            |                  |    |      |    |
|     |                            | Updates as       | \- | E    | R  |
|     |                            | Required         |    |      |    |
+-----+----------------------------+------------------+----+------+----+
| OO  | OLI On-Orbit Test and      | Draft 2 weeks    | 3  | H, E | A  |
| -12 | Calibration/Validation     | prior to formal  |    |      |    |
|     | Procedures                 | test of          | 3  | H, E | A  |
|     |                            | procedure        |    |      |    |
|     |                            |                  |    |      |    |
|     |                            | Final at formal  |    |      |    |
|     |                            | test of          |    |      |    |
|     |                            | procedure        |    |      |    |
+-----+----------------------------+------------------+----+------+----+

Table 3-2: OLI Thermal Math Model Deliverables

  --------------------- -------------- -------------- -------------- --------------
  **Hardware**          **Model**      **Version**    **Event**      **+/- Days
                                                                     from Event**

  Instrument            I-DTMM         1              I-PDR          -30

  Instrument            I-DTMM         2              I-CDR          -30

  Instrument^(1)^       I-DTMM         3              I-S/T tests    -5

  Instrument            I-DTMM         4              I-TB/TV        -30

  Instrument            I-DTMM         Final          I-TB/TV        30

  Instrument            I-DTMM         TV Report      I-TB/TV        60

                                                                     

  Instrument            I-RTMM         1              I-CDR          0

  Instrument            I-RTMM         2              I-TB/TV        -15

  Instrument            I-RTMM         Final          I-TB/TV        45

  Instrument^(2)^       I-RTMM         Final+         O-TB/TV        45

                                                                     

                                                                     

  Notes: (interim model                                              
  updates by mutual                                                  
  agreement between                                                  
  CDRL's )                                                           

  1\. O-DTMM used for                                                
  analysis of the                                                    
  structural/thermal,                                                
  EM, etc. test set-up,                                              
  if conducted                                                       

  2\. O-DTMM with Final                                              
  I-RTMM                                                             

  Abbreviations:                                                     

  3.      I =                                                        
  Instrument                                                         

  4.      O =                                                        
  Observatory                                                        
  (integrated                                                        
  bus+instr.)                                                        

  5.      T = Test                                                   
  (thermal equipment                                                 
  needed for ambient                                                 
  and TV/TB testing)                                                 

  6.      S/T tests =                                                
  Structural/thermal                                                 
  physical model                                                     
  testing, if conducted                                              

  7.      TB/TV =                                                    
  Thermal                                                            
  Balance/Thermal                                                    
  Vacuum                                                             

  8.      TMM = Thermal                                              
  Math Model                                                         
  (Temperature and                                                   
  Geometry)                                                          

  9.      RTMM =                                                     
  Reduced TMM                                                        

  10.    DTMM =                                                      
  Detailed TMM                                                       

                                                                     

  Usage Examples:                                                    

  a.      I-PDR =                                                    
  Instrument PDR                                                     

  b.      I-TB/TV =                                                  
  Instrument TB/TV                                                   

  c.      I-TB/TV = TV                                               
  chamber shroud, IR                                                 
  panels, etc.                                                       
  --------------------- -------------- -------------- -------------- --------------

# DESCRIPTIONS of required data

**MANAGEMENT DRDs**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-1 Monthly PROJECT STATUS REVIEWS

3\. [Reference:]{.underline}

SOW 1.2.3.2

4\. [Use:]{.underline}

To evaluate contract status. These reports will be used to provide an
opportunity for face-to-face discussions between the contractor and the
Government regarding project status, plans and issues.

5\. [Preparation Information:]{.underline}

Scope: The MPSR shall include all aspects of the contract effort.

The Monthly Project Status Review (MPSR) will be presented at a
face-to-face meeting with the Government. These meetings will occur at
the contractor's facility, unless modified by mutual consent.

The Monthly Project Status Review shall include the following:

A.  Report of Key Technical Parameters; including mass and power
    budgets, peak and average power budgets, pointing knowledge and
    control error budgets, and their current best estimated, calculated,
    and/or measured values for all parameters. The list of reported Key
    Technical Parameters shall be agreed upon with the Government and
    may be revised by the Government as the situation dictates. The
    values to be presented shall be at least to the major component
    level of the subsystems, e.g. Mechanisms, Power supplies, heaters,
    cabling, etc. The accuracy of the values and units shall be
    identified. Margins and contingency based on maturity shall be
    identified.

> A.1 Reported mass properties shall include mass, center of gravity,
> moments of inertia, products of inertia, principal axis misalignment,
> and physical dimensions. The report shall be based upon calculated
> values and shall be updated as calculations are revised and actual
> measured data becomes available. Following environmental testing and
> prior to the instrument shipment, a complete mass properties summary
> of the final instrument mass properties as measured shall be reported.
> The report shall also include the appropriate mass contingency for the
> current stage of hardware development, along with the allocated mass
> allowables.

B.  Technical status for system and subsystem design and development
    activities, including subcontract technical performance.

C.  A comparison of planned versus actual accomplishments for the period
    of time since the prior report.

D.  Summary of Integrated Master Schedule Status, including a brief
    description of the current status of each subsystem or subassembly
    along with descriptions of any existing or potential problems areas.
    The critical path and near critical paths shall be explained along
    with possible work-arounds being considered to maintain the
    schedule. The third MPSR shall include a schedule baseline review.
    The basis of the review shall be the Integrated Master Schedule.

E.  A detailed 12-month "rolling-wave" schedule (3 months of actual,
    plus 9 months of forecast)

F.  Problems encountered during the reporting period, and anticipated
    approaches for resolution (including, as appropriate, technical
    issues, manpower and staffing, supplier and subcontractor issues,
    etc.)

G.  Status of open issues and problems from prior reporting periods

H.  Focal Plane Array Status; covering the FPA activities for the
    previous month, including: schedule and technical status of FPA
    development, manufacturing status, qualification and test status,
    issues and concerns

I.  Status of action items

J.  Significant plans and activities for the following month

K.  Identification of long-lead purchases/acquisitions made prior to PDR
    and prior to CDR of the system (spacecraft, instrument, or ground
    system) in which the long lead item is a part of.

L.  Class I and Class II proposed and approved Configuration Control
    Board Changes

M.  Risk Status for top 10 risks

N.  Milestone events depicting critical items of project status for the
    succeeding month.

O.  Metrics summarizing all milestones depicting planned versus actual
    accomplishments, e.g., 30 of 1000 milestones are behind plan.

> P. CDRL Status Report that includes the following information for each
> document delivered in accordance with the CDRL or overdue from
> previous reporting periods:
>
> a\. Document Number.
>
> b\. Document Title.
>
> c\. Scheduled Due Date.
>
> d\. Actual Submittal Date.
>
> e\. Current Status
>
> f\. a list of documents planned for delivery during the next reporting
> period, listed by document number, title, and scheduled submittal
> date.

Q. Business issues, including personnel changes

The contractor shall provide paper copies of the agenda, viewgraphs and
other presentation material for all Government attendees at the time of
the review. The contractor shall place MPSR material on the
Government-access electronic database by the day of the MPSR.
Presentation material may be in contractor format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-2 Integrated master schedule (IMS)

3\. [Reference:]{.underline}

-   SOW 1.2.3.2

-   SOW 1.9

-   SOW 1.2.3.2

-   NPR 7120.5C, Program/Project Management Processes and Requirement

4\. [Use:]{.underline}

Schedules are used to plan, monitor, communicate status, and control all
activities, including pertinent resources and facilities, necessary to
accomplish assigned tasks in compliance with the LDCM Statement of Work.

5\. [Preparation Information:]{.underline}

The IMS shall be developed using the Critical Path Method-based
scheduling technique.  It will consist of the schedule baseline and the
current schedule updated each reporting period. The Master Schedule
shall be developed top-down to identify and incorporate program
milestones that are meaningful in terms of the technical scope,
schedule, risk and cost aspects of the contract.

It shall provide schedules such that actual progress can be related to
the plan and contain forecasts of expected future progress.

A monthly schedule analysis narrative shall be provided with the Master
Schedule describing the overall schedule position of the LDCM project
based on schedule float/slack analysis for each major
subsystem/assembly/subassembly and compare current month completion
date/float for that element with that of the prior month. The primary
critical path shall be explained along with possible work-around and/or
schedule risk mitigation plans being considered to maintain the
schedule. Causes for 5 days or more per month schedule improvement or
degradation to the spacecraft bus readiness for instrument integration,
the instrument readiness for integration to the bus, or the observatory
delivery to the launch site shall be explained.

Intermediate and Detailed level schedules shall be maintained as
separate entities or integrated with the Master Schedule in a single
module, without loss of detail. The basic principle is that all lower
level schedules must support the Master Schedule requirements and
provide for program interdependencies as necessary. The instrument
schedule shall be detailed to at least the instrument sub-assembly level
and shall detail progress against the plan.

Subcontract and critical procurement schedule requirements shall be
fully integrated into the overall contractor project schedule. It is
important to plan and track all critical schedule requirements that
constrain the successful conclusion of procurement actions.

The scheduling system shall establish relationships between technical
achievement and progress statusing at all levels of scheduling.

The IMS baseline must be maintained through a revision control process
which documents internal contractor-generated changes and external scope
changes authorized by the government.  These will be documented in the
schedule change log.

The detailed Preparation Information instructions below shall apply to
the instrument-level schedule as well as the Space Segment schedule.
Instrument Level 1, 2, and 3 schedules shall be prepared, updated, and
delivered with the same frequency as the Space Segment schedules.

The Integrated Master Schedule shall include:

A.  Activities detailed by task with early start and finish, and late
    start and finish dates

B.  With the exception of the project start and finish milestones, for
    any activity or milestone without a predecessor or successor
    activity a reason must be provided in the monthly narrative report.

C.  Clearly identified schedule reserve.

D.  Clearly identified Need dates for GFE.

E.  Documentation and explanation in the monthly schedule analysis
    narrative report of the use of activity or milestone constraints
    other than As Soon As Possible (e.g. contract requirement date).

F.  Activities associated with major items, components, or definable
    subassembly, such as printed wiring assembly (PWA).

G.  Fabrication schedules detailed to the subassembly level, and to the
    PWA level, and showing substantive milestones.

H.  An assembly/test flow diagram that shows sequences of fabrication,
    assembly, integration and test for components, subsystems, and
    system and includes quality assurance test points and associated
    inspection level requirements.

I.  The contractor shall provide the Government with a series of
    integrated network schedules and bar charts as described below:

    a.  Master Schedule -- The level-1 Master Schedule shall include
        programmatic milestones/events for the overall program from
        design, manufacturing, integration and test through launch
        including data on major procurements. The schedule shall be in a
        format suitable for viewgraph presentations that summarize the
        schedule data and status contained in the integrated logic
        network. This chart will be delivered directly from the
        integrated logic network and will include major program
        milestones such as Preliminary Design Reviews (PDR), Critical
        Design Reviews (CDR), Pre-Ship Review (PSR), Peer Reviews, etc.
        The Instrument Level 1 Schedule shall include major instrument
        program milestones such as Instrument Preliminary Design Reviews
        (IPDR), Instrument Critical Design Reviews (ICDR), Instrument
        Pre-Ship Review (IPSR), Instrument Peer Reviews, etc.

    b.  Intermediate Schedule -- A level-2 Intermediate Schedule by WBS
        shall be submitted. For each task/activity, the baseline start
        and completion dates; the current expected/planned start and
        completion dates, the number of work days required to accomplish
        the task, and the amount of float/slack in work days for each
        task, a unique activity identification number for each task, and
        a task description shall be included. Control milestones will be
        included on the Intermediate Schedule.

    c.  Detailed Schedule -- A Level-3 Detail Schedule at the lowest
        level of the working schedules shall be submitted. The WBS ID,
        Task Description, Start/Finish dates, and Percent Complete shall
        be identified

    d.  Integrated Logic Networks -- These networks shall be established
        for each subsystem or subassembly to the electronic board level.
        The contractor shall provide an electronic version of the
        detailed integrated logic network. The critical path shall be
        derived from the intermediate level logic network schedules.

    e.  Control Milestone Trend Report -- A control milestone trend
        chart shall be submitted. This report shall consist of the
        baseline control milestones that have been agreed upon by the
        contractor and government. The report will also contain a list
        of the control milestones expected to complete during the
        reporting period, their baseline completion dates, and their
        current status. A draft control milestone list shall be
        submitted to the government for review and concurrence. These
        milestones have to be derived from the IMS baseline, actual
        completion status and current forecast.

    f.  End Item Float Report -- A monthly report shall be submitted for
        each deliverables subsystem or subassembly comparing the current
        month total float/slack to the total float/slack of the previous
        month and explain any changes.

    g.  Schedule log book -- The contractor shall maintain a log book
        identifying all schedule changes (task additions, deletions,
        duration adjustments, changes to logic, including rationale,
        etc.) to the schedule baseline documentation and shall provide
        this data to the Government upon request.

> These schedules shall be presented by a flow type network diagram, and
> by Gantt schedule milestone charts using Microsoft Project.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-3 CADRE data

3\. [Reference:]{.underline}

SOW 1.9

4\. [Use:]{.underline}

To provide the project technical data required for the Project
Non-Advocate Review (NAR) process.

5\. [Preparation Information:]{.underline}

CADRe Part B (technical data in spreadsheet form) is required.

The spreadsheet format of the CADRe inputs is available at
<http://www.ceh.nasa.gov/downloadfiles/xls/cadrepartb10apr2005ver2.xls>

The required data for submission of this Data Item are all non-cost
technical data required for the LDCM Project to complete the full CADRe.

**\<Update for full CADRE submission\>**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-4 Final Report

3\. [Reference:]{.underline}

Contract Clause C.3

SOW 1.1

4\. [Use:]{.underline}

To provide a summary of the performance of the contract.

5\. [Preparation Information:]{.underline}

The final report shall be written in increments so that the summary from
each phase of development can be more accurately captured. The final
report due at Acceptance + 30 days shall include all previously
delivered reports plus updates from the period between PSR and
Acceptance.

Refer to contract clause 1852.235-73 (Section C.3 of the contract) for
additional instructions regarding the final report.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-5 engineering Peer review plan

3\. [Reference:]{.underline}

SOW 1.2.2

4\. [Use:]{.underline}

Early in project/product formulation, the Contractor shall identify
subsystems, components, software and crosscutting functional elements to
be subject to the Engineering Peer Review (EPR) process. The Peer Review
Plan is used to identify the methodology and scope of the contractor's
peer review process.

5\. [Preparation Information:]{.underline}

The Engineering Peer Review Plan shall:

a\. Describe the methodology used to determine the scope of the EPR
process, including rationale for specific components or subsystems that
will not be peer reviewed.

b\. Describe the peer review process, including personnel, nominal
agenda, and Request for Action (RFA) generation, tracking, and closure
process.

c\. Identify the concepts, designs, plans, processes, subsystems,
components, software, etc. that will be Peer Reviewed.

d\. Identify a schedule or associated milestones for the EPRs.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-6 Earned Value MANAGEMENT System (evms) Plan

3\. [Reference:]{.underline}

-   Statement of Work; Para. 1.9

-   NPR 7120.5D, Program/Project Management Processes and Requirement

-   NFS 1852.234-1 Notice of Earned Value Management System

-   NFS 1852.234-2 Earned Value Management System

*[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}*

4\. [Description/Use:]{.underline}

The EVMS plan and documentation shall provide a description of the
contractor's implementation of an earned value management system that
demonstrates the use and understanding of the contract's overall
financial and project management system at all levels of management. It
shall also ensure that the system provides for the results of all
analyses based on EVM to be linked to the contractor's Risk Management
System (as applicable). Any cost and/or schedule risk being managed by
the contractor's Project Manager shall correlate the results of the EVM
analysis process to track, manage, and mitigate risk.

The contractor's plan shall include methods, policies, and procedures
utilized to meet the requirements of NPR 7120.5D, and to demonstrate the
ability to implement those processes for managing cost and schedule,
management oversight, and variance analysis and estimates at completion
at the prime and subcontract levels.

This plan shall have flow down requirements to all major subcontracts
that meet the criteria as defined in NPR 7120.5D to ensure that
subcontract management processes focus on those aspects unique to
managing subcontracts. The flow down of requirements shall also ensure
that subcontract costs and schedule are integrated, and that assignment
of earned value measurement methods, collection and reporting of actual
costs for subcontractor work scope, variance analysis, and development
of estimates to complete are in accordance with the standards.

Revision to this may be required at the Government's request if a change
in the EVM system architecture occurs or in the event of a major
contract modification.

The use of electronic media is preferred unless disclosure of this
information would compromise information security.

5\. [Preparation Information:]{.underline}

The plan shall describe the development, approvals, software utilization
for EV reporting, responsibilities, and management thresholds in
compliance and consistent with the American National Standards
Institute/Electronic Industries Association (ANSI/EIA) 748-A.

A fully validated EVM system is required as per NPR 7120.5D. The
Contractor shall supply an EVM system certification and EVM System
Description as part of this plan. The certification and system
description may be provided under separate cover, if desired.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-7 FINANCIAL REPORTS

3\. [Reference:]{.underline}

-   SOW Paragraph 1.9

-   NPD 9501.2D, NASA Contractor Financial Management Reporting

-   G.1, Financial Management Reporting (GSFC 52.52.242-90) (Feb 2000)

-   G.8, NASA Contractor Financial Management Reporting(1852.242-73)(Jul
    2000)

-   NPR 7120.5D, Program/Project Management Processes and Requirements

4\. [Use:]{.underline}

The 533 M, shall provide monthly contractual expenditure data for cost
incurred and estimated cost to complete, and is necessary for the
financial control and reporting required on this contract. The 533 Q,
shall provide Quarterly contractual expenditures, cost incurred and
estimated cost to complete, and shall provide financial control and
reporting at the internal contract and subcontract level.

5\. [Preparation Information:]{.underline}

-   The Monthly and Quarterly Financial Report shall be prepared in
    accordance with the G.1, Financial Management Reporting (GSFC
    52.52.242-90)(Feb 2000) and G.8, NASA Contractor Financial
    Management Reporting (1852.242-73)(Jul 2000) clauses.

Financial reports shall be provided down to WBS level 4. A lower level
of reporting may be required for elements that are classed as technical,
schedule, cost and risk areas.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-8 Cost Performance Reports

3\. [Reference:]{.underline}

-   SOW 1.9

-   NPR 7120.5D, Program/Project Management Processes and Requirement

-   NFS 1852.234-1 Notice of Earned Value Management System

-   NFS 1852.234-2 Earned Value Management System

4\. [Use:]{.underline}

To provide information for (1) integrating cost and schedule performance
data with technical performance measures, (2) assessing the magnitude
and impact of actual and potential problem areas causing significant
cost and schedule variances, and (3) providing valid, timely project
status information to higher management.

5\. [Preparation Information:]{.underline}

The CPR shall include data pertaining to all authorized contract work,
including both priced and unpriced effort that has been authorized at a
not-to-exceed amount in accordance with the Contracting Officer\'s
direction. The CPR shall separate direct and indirect costs and identify
elements of cost for all direct reporting. The CPR shall include Formats
1-5, down to a WBS Level -4. A lower level of reporting may be required
for elements that are classified as technical, schedule, or cost risk
areas. Format-3 shall include detailed baseline change log that reflect
changes to UB, MR and baseline maintenance activities.

**[[FORMAT]{.underline}]{.smallcaps}**: EVSR formats shall be completed
according to the instructions outlined in DI-MGMT-81466 and the
following forms: Format 1 (DD Form 2734/1); Format 2 (DD Form 2734/2);
Format 3 (DD Form 2734/3); Format 4 (DD Form 2734/4); and Format 5 (DD
Form 2734/5). Images of the EVSR forms are located at
<http://ceh.nasa.gov/webhelpfiles/earnedvaluecostperfrptp27a.htm> .

Contractor format shall be substituted for EVSR formats whenever they
contain all the required data elements at the specified reporting levels
in a form suitable for NASA management use. The EVSR shall be submitted
electronically and followed up with a signed paper copy. The American
National Standards Institute (ANSI) X12/XML standards (transaction sets
839 for cost and 806 for schedule), or the United National Electronic
Data Interchange for Administration, Commerce and Transport (EDIFACT)
equivalent, shall be used for Electronic Data Interchange. This
information is located at <http://www.unece.org/trade/untdid/>.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-9 Engineering Development Unit Plan

3\. [Reference:]{.underline}

SOW 4.1.2

4\. [Use:]{.underline}

To provide plans for and justification of the functionality and purpose
of the proposed instrument Engineering Development Unit (EDU).

5\. [Preparation Information:]{.underline}

The EDU Plan shall provide a general philosophy or approach to
mitigating risk on the instrument development through the use of EDUs.
The Plan shall provide justification for the proposed EDU approach. The
EDU Plan shall provide a list of all assemblies, subassemblies, or
components of the instrument which are planned to have an engineering
development unit. The functionality and purpose of each EDU will be
discussed. The EDU Plan will identify how the EDU implementation fits
into the instrument development schedule.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-10 Hardware and software Configuration Management Plan

3\. [Reference:]{.underline}

-   SOW 1.10

-   SOW 4.2.1.2.3

-   MAR 13

4\. [Use:]{.underline}

Defines the contractor's configuration management system (including
policies and procedures) that will be implemented for the instrument
flight hardware.

5\. [Preparation Information:]{.underline}

The contractor's hardware/software configuration management plan shall
be prepared in accordance with the contractor's standards. This plan
shall describe in detail all flight hardware configuration management
processes, methods, and procedures the contractor intends to use on the
OLI instrument. This plan shall describe how hardware and software
configuration management is accomplished and how consistency between
product definition, the product's configuration, and the configuration
management records is achieved and maintained throughout the applicable
phases of the product's life cycle by the contractor.

The configuration management plan shall describe the contractor's
approach, methodology, and application of configuration management
principles and practices and shall include the following:

1\. General product definition and scope

2\. Description of configuration management activities and procedures
for each of the following configuration management functions:

> a\. Configuration planning and management
>
> b\. Configuration identification
>
> c\. Configuration Change management
>
> d\. Configuration status accounting
>
> e\. Configuration verification and audit

f\. Configuration management of digital data

g\. Configuration management of software

3\. Organization, roles, responsibilities and resources

4\. Definition of terms

5\. Programmatic and organizational interfaces

6\. Subcontract flow down of configuration management

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:\
]{.underline}

PM-11 PROJECT MANAGEMENT PLAN

3\. [Reference:]{.underline}

SOW 1.1

4\. [Use:]{.underline}

Describes how the project is organized and managed by the contractor. It
provides the management structure, its system of operation, responsible
lines of communications, and key personnel assignments. The organization
chart identifies the contractor\'s project organization with names,
functions, lines of authority, coordination, etc

5\. [Preparation Information:]{.underline}

This plan shall address the overall organization, management approach,
and structure of the contractor's project plus its interrelationships
with the parent company and the subcontractors.

Describe how and where the project will operate during all phases of the
contract.

This plan shall identify and describe interfaces with the Government.

This plan shall include graphical displays such as flow diagrams, WBS,
logic networks, etc., to reduce verbal descriptive material.

This plan shall provide an organizational chart(s) and sufficient
supplemental narrative to describe fully the following:

\(a\) Organization proposed for carrying out the project showing
interrelationships of technical management, business management, and
subcontract management, from lower level through intermediate management
to top-level management with detailed explanation of:

> 1\. The authority of the Project Manager relative to other ongoing
> projects and applicable support organizations within the company
> structure. Discuss the Project Manager's control over essential
> resources and functions necessary to accomplish the work.
>
> 2\. How and by whom interdepartmental work will be monitored and the
> authority of the Project Manager over interdepartmental work.
>
> 3\. Process to be followed by the Project Manager in obtaining
> decisions beyond his/her authority and in resolving priority conflicts
> for resources and functions not under the Project Manager's direct
> control such as personnel, finances, and facilities.
>
> 4\. The project team members with names and functions.

\(b\) Implementation approach for the project. Describe in general how
the requirements of the Statement of Work (SOW) will be achieved.
Identify potential problems related to this work, and your approach to
problem avoidance and/or solution. Identify how your risk management
system and processes are integrated into the daily management, decision
making, and strategic direction of the project. Address the degree to
which your proposed personnel and overall management procedures are
proven through similar experience. Describe such things as make/buy
strategies, acquisition plans, sparing philosophy, project dependencies,
facility requirements, internal review strategies and plans, significant
work elements on critical paths, long-lead items, and significant
milestones down to at least the lowest level of the WBS.

\(c\) Contractual procedures proposed for the project to effect
administrative and engineering changes, describing any differences from
existing procedures.

\(d\) Management techniques to be employed to minimize: 1) project costs
and schedule overruns, and 2) risks of violating interface requirements
and agreements. Describe associated controls to be exercised over
subcontractors and suppliers. Describe how issues will be surfaced in a
timely manner and at the proper levels. Identify initial proposed Key
Technical Parameters the project will use to monitor and report on (see
CDRL PM-1) interface compliance and resource status.

\(e\) The proposed Safety and Mission Assurance organizational
structure, including staffing plans, reporting channels, authority and
responsibilities, and management visibility. Discuss whether the
technical, test, manufacturing and system safety/quality assurance/
reliability/ configuration management personnel required for this
project (as indicated in your proposed labor hours) are presently on
your payroll and immediately available for this work. State the number
and disciplines/skills of persons who would have to be hired, and plans
to obtain them.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:\
]{.underline}

PM-12 RISK MANAGEMENT PLAN

3\. [Reference:]{.underline}

SOW 1.7

GPR 7120.4, Risk Management

NPR 8000.4 Risk Management Procedural Requirements w/Change 1 (4/13/04)
***e***

4\. [Use:]{.underline}

The Risk Management Plan is the basis for identifying and managing all
performance, reliability, schedule, and safety risks on the contractor's
project.

5\. [Preparation Information:]{.underline}

The risk management plan shall clearly describe:

-   Overview of the risk management process

-   Organizational responsibilities

-   Risk identification approach

-   Risk mitigation planning

-   Interface of risk management to schedule

-   Risk tracking/documentation

-   Risk management list reporting

**REVIEW DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-1 Instrument System Requirements Review (ISRR) Data package

3\. [Reference:]{.underline}

SOW 1.2.1.1

GSFC-STD-1001

4\. [Use:]{.underline}

To evaluate the requirements, requirements flow-down, and the
operational concepts and to validate the realism of the functional and
performance requirements and their congruence with the system
configuration selected to conduct the mission.

5\. [Preparation Information:]{.underline}

The ISRR shall contain the flow-down of requirements from the OLI
Requirements Document to the Instrument.

The ISRR Data Package shall contain all relevant instrument information
required to satisfy paragraph 4.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The ISRR Data Package shall discuss contractor system level
requirements, rationale, and flow-down plans to lower level
requirements.

The ISRR Data Package shall show the allocation and traceability of
requirements to major subsystems.

The ISRR Data Package shall address any identified Single Point
Failures.

The ISRR Data Package shall address the identification and functionality
of the Instrument EDU components.

The ISRR Data Package shall show how the current concept meets all
government specified requirements including interface requirements.

The ISRR Data Package shall discuss the preliminary operations concept
of the instrument.

The ISRR package shall contain a matrix of the status of compliance with
GSFC-STD-1000. The ISRR shall address compliance with GSFC-STD-1000.

Results of Review---As a result of successful completion of the ISRR,
the system and its operation are well enough understood to warrant
design and acquisition of the end items. Approved specifications for the
system, its segments, and preliminary specifications for the design of
appropriate functional elements may be released.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-2 Instrument Preliminary Design Review (IPDR) Data Package

3\. [Reference:]{.underline}

SOW 1.2.1.1

GSFC-STD-1001

4\. [Use:]{.underline}

To demonstrate the Flight Equipment and GSE design meet the documented
requirements.

5\. [Preparation Information:]{.underline}

The IPDR Data Package shall address all relevant instrument information
required to satisfy paragraph 5.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The IPDR package shall contain a matrix of the status of instrument
compliance with GSFC-STD-1000. The IPDR shall address instrument
compliance with GSFC-STD-1000.

The Instrument PDR data package shall contain information to cover the
Instrument data processing algorithm design.

The IPDR data package shall address the instrument compliance with the
OLI Requirements Document.

The IPDR data package shall include responses to action items from
previous reviews, including subsystem PDRs/Engineering Peer Reviews.

The IPDR data package shall include changes since the last review.

The IPDR data package shall address performance requirements and their
flow-down to the card or equivalent level.

The IPDR data package shall address instrument performance budgets.

The IPDR data package shall address error budget determination.

The IPDR data package shall address mass, power, data rate, coding and
format, commands, EMI/EMC.

The IPDR data package shall contain a detailed report of Key Technical
Parameters down to a level below the one reported in the MPSR.

The IPDR data package shall address interface requirements, including
the following information:

a\. Preliminary analysis that will allow the Contractor to ensure that
the \"swept\" or deployed volume is verified, accounting for all
distortions and misalignments.

b\. Preliminary estimates of gimbaled masses, inertia's, and to permit
sizing the spacecraft control components to meet pointing and stability
requirements.

c\. Preliminary analysis of disturbances of the sum of any periodic
disturbance torques, in order to produce the corresponding magnitude
spectrum.

The IPDR data package shall address mechanical/structural design,
analyses, and life tests.

The IPDR data package shall address electrical, thermal, optical,
radiometric, and calibration design and analyses.

The IPDR data package shall address software requirements, design, and
development environment.

The IPDR data package shall address Ground Support Equipment design and
work flow, and describe how each item will be fabricated, tested and
certified when needed.

The IPDR data package shall address design verification, test flow and
calibration/test plans.

The IPDR data package shall address the instrument operations concept.

The IPDR data package shall address parts selection, and qualification.

The IPDR data package shall address preliminary Failure Modes and
Effects Analysis (FMEA); Fault Tree Analysis; and reliability analysis
and results.

The IPDR data package shall address redundancy and redundancy
management.

The IPDR data package shall address single point failures.

The IPDR Data Package shall address the list of long lead items, and of
items that may become obsolete prior to completion of all flight
instruments, identify those items that must be procured prior to ICDR
(including a list of those that were ordered prior to IPDR and ISRR),
and provide a plan for procuring these items and all parts.

The IPDR data package shall address contamination requirements and
control plan

The IPDR data package shall delineate the status of each document
required at PDR as to its acceptability for use as is.

The IPDR Data Package shall present all instrument risks and address
their mitigation.

The IPDR Data Package shall provide the status of all sub-contracts and
discuss the preliminary design status of critical assemblies and
sub-assemblies.

The IPDR Data Package shall present a summary of all breadboard and
brassboard testing and present the available test results.

The IPDR Data Package shall present the development status of
sub-assembly engineering units, and available test data.

The IPDR Data Package shall present the planned and/or expected level of
functionality of the components of the Engineering Development Unit.

The IPDR Data Package shall address the producability of the design
solution.

The IPDR Data Package shall address mission assurance to be imposed
including parts and materials usage as well and workmanship standards
imposed.

The IPDR Data Package shall address software assurance process.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-3 Instrument Critical Design Review (ICDR) Data Package

3\. [Reference:]{.underline}

SOW 1.2.1.1

GSFC-STD-1001

[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

4\. [Use:]{.underline}

To present the Instrument Flight Equipment and GSE design and operation,
and to demonstrate that all related manufacturing documentation,
processes and fixtures are in place before hardware manufacture begins,
and to demonstrate that the design meets all performance requirements.

[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

5\. [Preparation Information:]{.underline}

The ICDR Data Package shall contain all relevant instrument information
required to satisfy paragraph 6.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The ICDR package shall contain a matrix of the status of instrument
compliance with GSFC-STD-1000. The CDR shall address instrument
compliance with GSFC-STD-1000.

The ICDR data package shall include responses to action items from
previous reviews, including subsystem CDRs/Peer Reviews.

The ICDR data package shall include changes since the last review.

The ICDR data package shall address instrument compliance with the OLI
Requirements Document.

The ICDR Data Package shall address the procurement status of long lead
items and Electrical, Electronic, and Electromechanical (EEE) parts.

The ICDR Data Package shall address manufacturing flow, and the status
of manufacturing and assembly drawings, bill of materials, etc.

The ICDR Data Package shall address manufacturing procedures.

The ICDR Data Package shall address mission assurance product
checkpoints and evaluation criteria.

The ICDR Data Package shall address standard applicable in-house
processes.

The ICDR Data Package shall address special/unique tooling/fixturing.

The ICDR Data Package shall address facilities required for
manufacturing.

The ICDR Data Package shall address personnel resources (time phased).

The ICDR Data Package shall address the delivery schedules for flight
hardware and GSE.

The ICDR data package shall address detailed analysis from FMEA, fault
tree analysis, and reliability analysis.

The ICDR Data Package shall address worst case analyses of:

(a) Electrical circuits

(b) Scanning drive system

(c) Lubrication and lubrication loss

(d) Tolerance and tolerance sensitivity analysis (including thermal and
    mechanical considerations)

The ICDR Data Package shall address stress analyses using NASTRAN with
hand verification

The Instrument CDR Data Package shall address thermal analysis of:

(a) Detectors/Focal Plane Array

(b) Telescope

(c) Electronics

(d) In-flight calibrators

(e) Structure

(f) Thermal control system

The ICDR Data Package shall address weight and power.

The ICDR data package shall contain a detailed report of Key Technical
Parameters down to a level below the one reported in the MPSR.

The ICDR Data Package shall address test plans (including all
environmental tests)

The ICDR Data Package shall address manufacturing considerations

The ICDR Data Package shall address maintainability considerations,
including storage.

The ICDR Data Package shall address materials and processes lists

The ICDR Data Package shall provide a summary of deviations/waivers

The ICDR Data Package shall address contamination control and monitoring
considerations

The ICDR Data Package shall address spares program

The ICDR Data Package shall address system safety hazards analyses

(a) Hazards identification matrix

(b) Single point failure summaries

(c) Risk assessment rationale

The ICDR Data Package shall delineate the status of each incomplete
deliverable document, due at ICDR, as to its acceptability for use as
is.

The ICDR package shall address the operations concept.

The ICDR Data Package shall present any additional test results from
breadboard and brassboard testing

The ICDR Data Package shall present the test data from sub-assembly
engineering development units and the status of EDU development and
testing results, if any.

The ICDR Data Package shall address the development status of all GSE,
including test and calibration procedures, and the software/firmware
design and operation and interface aspects as evaluated since the IPDR

The ICDR Data Package shall address the status of all program risks and
their mitigation

The ICDR Data Package shall address the status of all sub-contract
design activity and schedule for delivery of EDU and flight hardware, as
appropriate, and demonstrate that designs are complete and have been
adequately reviewed.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-4 Instrument Pre-Environmental Review (IPER) Data Package

3\. [Reference:]{.underline}

SOW 1.2.1.1

GSFC-STD-1001

4\. [Use:]{.underline}

To present the description and results of the Instrument
Pre-Environmental Test program, and demonstrates readiness for
environmental testing.

5\. [Preparation Information:]{.underline}

The IPER Data Package shall contain all relevant instrument information
required to satisfy paragraph 8.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The IPER Data Package shall include status of action items generated at
prior reviews

The IPER Data Package shall include analyses and reports required at the
review.

The IPER Data Package shall contain the results of any analyses updated
or revised since the ICDR.

The IPER Data Package shall include test and integration program
descriptions and results

The IPER Data Package shall include failure report summaries including
status of action and rationale for closure

The IPER Data Package shall include as-built documentation summary

The IPER Data Package shall include results of the functional and
interface tests

The IPER Data Package shall include descriptions of any malfunctions and
corrective actions

[]{.mark}

The IPER Data Package shall include comparison of measured performance
with requirements and discussion of the effect of any variance and
waivers

The IPER Data Package shall include mission operation constraints

The IPER Data Package shall include contamination avoidance requirements

The IPER Data Package shall include safety requirements

The IPER Data Package shall include list of spares for flight equipment
and GSE

The IPER Data Package shall include review of flight hardware handling
procedures

The IPER Data Package shall include spacecraft interface concerns,
problems and solutions, including:

a\. Analysis and test data that demonstrates that the \"swept\" or
deployed volume is verified, accounting for all distortions and
misalignments.

b\. In electronic format, time/magnitude plots of their disturbances,
for decomposition, of the sum of the instrument-induced periodic
disturbance torques, in order to produce the corresponding magnitude
spectrum.

The IPER Data Package shall include orbital operations plans and status
of documentation and databases.

The IPER Data Package shall include end-item data packages (submit a
summary of the content prior to review and have package available for
inspection at review)

> 1\. As-built configuration list
>
> 2\. Hardware parts lists
>
> 3\. Hardware materials and processes lists
>
> 4\. Test Log Book (including total operating time and cycle records)
>
> 5\. Open item lists (including reasons for being open)
>
> 6\. Safety compliance data package
>
> 7\. Limited life items listings and status
>
> 8\. Critical parameters trend data
>
> 9\. Final comprehensive performance test results
>
> 10\. Failure report summaries including status of action and rationale
> for closure

The Instrument IPER Data Package shall discuss the compatibility of
instrument with spacecraft flight support equipment, ground support
equipment and operational ground equipment

The IPER Data Package shall address the availability and readiness of
facilities and GSE required for environmental testing

The IPER Data Package shall address the status of all program risks and
their mitigation plans.

The IPER Data Package shall address the readiness of environmental test
plans and procedures

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-5 Instrument Pre-Ship Review (IPSR) Data Package

3\. [Reference:]{.underline}

SOW 1.2.1.1

SOW 2.5

GSFC-STD-1001

4\. [Use:]{.underline}

To evaluate instrument performance during qualification or acceptance
testing, and evaluate readiness to ship.

5\. [Preparation Information:]{.underline}

This data package shall address, as a minimum:

The IPSR Data Package shall contain all relevant instrument information
required to satisfy paragraph 10.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The IPSR Data Package shall address responses to action items generated
at prior reviews

The IPSR Data Package shall address the solutions to all problems
encountered during the environmental test and validation program and the
solution rationale.

The IPSR Data Package shall address any rework/replacement of hardware,
regression testing, and test plan changes.

The IPSR Data Package shall address compliance with the test
verification matrix

The IPSR Data Package shall address measured test margins versus
requirements.

The IPSR Data Package shall address qualification/acceptance temperature
margins

The IPSR Data Package shall address any data that has been trended to
identify compliance with specification, indicating a change or drift to
the trend.

The IPSR Data Package shall summarize and analyze the monthly trend
reports (CDRL SE-3) of trended instrument data, focusing on trends that
have changed or drifted anomalously (see SOW paragraph 2.5).

The IPSR Data Package shall address total failure-free operating time of
the item

The IPSR Data Package shall address the number of cycles during testing
of parts with finite lifespans

The IPSR Data Package shall address the results of the final audit of
any remaining drawing changes.

The IPSR Data Package shall address "could-not-duplicate failures" along
with assessment of the problem and the residual risk that may be
inherent in the item

The IPSR Data Package shall address project assessment of any residual
risk

The IPSR Data Package shall provide an update from CDR on shipping
containers, monitoring/transportation/control plans

The IPSR Data Package shall address ground support equipment status

The IPSR Data Package shall address post shipment plans

The IPSR Data Package shall address spacecraft integration plan.

The IPSR shall address the plans for storage of the instrument, if
required.

The IPSR Data Package shall include documentation verifying that the
instrument meets contamination budgets and requirements specified in the
Contamination Control Plan.

The IPSR Data Package shall include alignment data relative to the
Instrument Boresight and the mounting surface datum(s) associated with
the instrument.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-6 Inputs to Mission Level reviews

3\. [Reference:]{.underline}

SOW 1.2.1.3

GSFC-STD-1001

4\. [Use:]{.underline}

To evaluate the requirements, requirements flow-down, and the
operational concepts and to validate the realism of the functional and
performance requirements and their congruence with the system
configuration selected to conduct the mission.

5\. [Preparation Information:]{.underline}

[Mission Definition Review (MDR) Inputs]{.underline}

Inputs to the MDR Data Package shall contain all instrument information
required to satisfy paragraph 3.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The MDR Data Package shall discuss contractor system level requirements,
rationale, and flow-down plans to lower level requirements.

The MDR Data Package shall show the allocation and traceability of
requirements to major subsystems.

The MDR Data Package shall address any identified Single Point Failures.

The MDR Data Package shall cover requirements for data processing
algorithms,

The MDR Data Package shall show how the current concept meets all
government specified requirements including interface requirements.

The MDR Data Package shall discuss the preliminary operations concept of
the instrument.

Results of Review---As a result of successful completion of the MDR, the
system and its operation are well enough understood to warrant design
and acquisition of the end items. Approved specifications for the
system, its segments, and preliminary specifications for the design of
appropriate functional elements may be released.

Inputs to the Mission-Level Reviews:

The Inputs to the mission-level reviews (PDR, CDR, PER, PSR), shall be a
subset of the corresponding Instrument level reviews, with appropriate
updates. The Inputs to the System Integration Review (SIR) shall be a
subset of the instrument PSR, with appropriate updates.

[CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-7 Engineering Peer Review Data Packages

3\. [Reference:]{.underline}

SOW 1.2.2

SOW 3.2.9.3.2

4\. [Use:]{.underline}

Engineering Peer Reviews (EPRs) focus on the design and implementation
details at levels that system-level reviews cannot address. They provide
a resource for Design Teams to identify potential engineering design and
implementation flaws, and increase the probability of success. Applying
the EPR process early and throughout the product life cycle affords the
maximum advantage in terms of resource efficiency as well as design
confirmation and ultimate mission success.  Peer review documentation
represents knowledge that may prove invaluable later.

5\. [Preparation Information:]{.underline}

Engineering Peer Review documentation shall be in contractor format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

Re-8 INTEGRATED Baseline Review (ibr) Package

3\. [Reference:]{.underline}

-   Statement of Work; Para. 1.9

-   NPR 7120.5D, Program/Project Management Processes and Requirement

-   NFS 1852.234-1 Notice of Earned Value Management System

-   NFS 1852.234-2 Earned Value Management System

4\. [Use:]{.underline}

An IBR is a formal review conducted by the government Project Manager
and technical staff, jointly with their contractor counterparts,
following contract award to verify the technical content of the
performance measurement baseline (PMB) and the accuracy of the related
resources (budgets) and schedules. (Source: 4-2.b. Definition @
<http://www.acq.osd.mil/pm/> currentpolicy/jig/evmig7.htm).

5\. [Preparation Information:]{.underline}

The IBR shall:

\(1\) Ensure the technical content of work packages and cost accounts is
consistent with the contract scope of work;

\(2\) ensure that there is a logical sequence of effort planned
consistent with the contract schedule;

\(3\) assess the validity of allocated cost account and IPT budgets,
both in terms of total resources and time-phasing;

\(4\) conduct a technical assessment of the earned value methods that
will be used to measure progress to assure that objective and meaningful
performance data will be provided;

\(5\) establish a forum through which the government Project Manager and
the project technical staff gain a sense of ownership of the
cost/schedule management process; ...to ensure that baseline integrity
is maintained throughout the life of the contract.

(Source: 4-2.c. Objectives @
<http://www.acq.osd.mil/pm/currentpolicy/jig/evmig7.htm_>

An IBR Data Package shall be submitted in accordance with the IBR
objectives stated above.

The Contractor Data Package shall contain the following:

-   Program /Business Management and Control Account Notebooks that
    incorporates the data products requested by the Project Office (hard
    copy and electronic copy)

-   A baselined electronic version of the Integrated Master Schedule

-   The Contractor Earned Value Process Documentation (hardcopy and
    electronic)

-   Two months of EV Performance data

The Contractor shall be responsible for ensuring that its
sub-contractors comply with the IBR requirements that have EVMS
requirements.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-9 Inputs to on-orbit Acceptance Review

3\. [Reference:]{.underline}

SOW 1.2.1.4

4\. [Use:]{.underline}

To demonstrate that the instrument is ready for Government acceptance.

5\. [Preparation Information:]{.underline}

The On-Orbit Acceptance Review shall provide the following information:

1.  Data review (in the form of data plots/tables) of the results of
    operational performance identified during Launch and Early Orbit
    (LOR) and Instrument checkout.

2.  Results of application of all contractor-developed image algorithms
    to the image data.

3.  Results of on-orbit calibration.

4.  Data review (in the form of data plots/tables) of thermal signatures
    for key components (controls, power, thermal)

5.  Data review (in the form of data plots/tables) for all anomalies and
    unexpected behavior encountered by the contractor during LOR and
    Instrument checkout, including:

    a.  Data showing the anomalous or unexpected behavior

    b.  Descriptions of any workarounds and/or fixes

    c.  Data illustrating response to the workarounds and/or fixes

6.  Current status of all anomalies and database problems encountered by
    the contractor during LOR and commissioning

7.  Measured on-orbit performance of the OLI versus the requirements of
    the OLI Requirements Document.

**SOFTWARE DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-1 Software Requirements Specification

3\. [Reference:]{.underline}

SOW 4.2.1.2

4\. [Use:]{.underline}

The Software Requirements Specification specifies in detail each
Software Element's requirements for a particular computer Software
Configuration Item (CSCI), including functional and performance
requirements, interface requirements, testing requirements, security and
safety requirements

5\. [Related Documents:]{.underline}

NASA-Software documentation Standard (NASA STD-2100-91), Data Item
Description NASA-DID-P200

6\. [Preparation Information:]{.underline}

The Software Requirements Specification shall be prepared IAW the full
contents of NASA-Software documentation Standard (NASA STD-2100-91),
Data Item Description NASA-DID-P200. Alternatively, the contractor may,
with agreement from the government, use an alternative industry standard
SRS approach such as MIL-STD-498 or IEEE standards.

In addition to the content required by NASA-DID-P200, include a
bidirectional traceability matrix that maps each software requirement to
a system or sub-system (high level) requirement from which it is
derived. Additionally, the test method used to verify each requirement
shall be identified.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-2 Software Design Document

3\. [Reference:]{.underline}

SOW 4.2.1.2.2

4\. [Use:]{.underline}

Describes the software design and operation for use by software
maintenance team.

The Software Design Document describes in detail the architecture,
structure, and organization of a particular Computer Software
Configuration Item (CSCI), decomposing the top-level CSCI into Computer
Software Components (CSC) and lower levels of units as appropriate. The
SDD describes each unit of software in terms of its interfaces
(input/output), data architectures, and processing (e.g. logic,
algorithms).

5\. Preparation Information:

[]{.mark}

Provide a system level design overview that contains:

(a) Design Methodology

(b) Design Overview

(c) Design Studies

(d) Design Issues

(e) Hardware Interface

Provide a system design description that contains, at a minimum

(a) Subsystem Description for each subsystem

(b) Software Description for each software component

(c) Software Interface Control Description for both software-to-software
    and software-to-hardware interfaces

Describe the system operations design, including:

(a) Operations Scenarios

(b) User-System Interface

(c) Operations Environment and Facilities

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-3 Software USERS GUIDE

3\. [Reference:]{.underline}

SOW 4.2.1.2.2

4\. [Use:]{.underline}

The Software Users Guide shall contain the information required to use
the software, including detailed procedures and functionalities

5\. [Preparation Information:]{.underline}

A.  TBD

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-4 Software Test Readiness Review (SWTRR) Data Package

3\. [Reference:]{.underline}

SOW 4.2.1.3.2

4\. [Use:]{.underline}

Presents the description and results for the S/W and System
Integration/Test program.

5\. [Preparation Information:]{.underline}

The SWTRR shall show that the contractor has adequately prepared for
formal software acceptance testing to include, at a minimum, the
check-out of test procedures, test cases, and requirements traceability.

This design review package shall address, as a minimum:

B.  All documentation as called for in the Software Development and
    Management Plan

C.  Test and Integration program descriptions and results

D.  Software test results

E.  Failure report summaries including status of action and rationale
    for closure

F.  As-built documentation summary

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-5 Software Acceptance Review (SWAR) Data Package

3\. [Reference:]{.underline}

SOW 4.2.1.3.2

4\. [Use:]{.underline}

For review of all test data and designs for compliance against
specification requirements, variances, mission operations requirements,
etc.

5\. [Preparation Information:]{.underline}

This data package shall address, as a minimum:

A.  Results of the functional and interface tests

B.  Malfunctions and corrective actions

C.  Reliability predictions

D.  Comparison of measured performance with requirements and discussion
    of the effect of any variance and waivers

E.  Mission operation constraints

F.  Safety requirements

G.  Maintenance and operation manuals

H.  Interface concerns, problems and solutions

I.  Compatibility of instrument with spacecraft flight support
    equipment, ground support equipment and operational ground equipment

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-6 Software Test Plan

3\. [Reference:]{.underline}

SOW 4.2.1.2.1

4\. [Use:]{.underline}

Provide overall view of the software acceptance test program detailing
test philosophy objectives and rationale for all software testing and
hardware/software integration activities planned for the program.

5\. [Preparation Information:]{.underline}

This shall incorporate the requirements of the MAR.

This shall include, as a minimum:

A.  Tests to be accomplished to demonstrate that the software meets
    requirements; the Draft STP shall contain a bidirectional
    traceability matrix that maps all requirements in the Software
    Requirements Specification to their corresponding test cases,
    analyses, inspections, etc. The Final STP traceability matrix shall
    include the additional mapping of test cases to test
    procedures/scripts.

B.  Test environment, simulators and tools needed

C.  Required test data

D.  Expected results

E.  Test schedules

F.  Special operating conditions (if required)

G.  Any required support from other organizations

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-7 Software Delivery Package and Updates

3\. [Reference:]{.underline}

SOW 4.2.1.5

4\. [Use:]{.underline}

Required at the end of the contract period, the software delivery
package contains a letter describing what is being delivered, the actual
software, accompanying documentation and the operations transition plan.

5\. [Related Documents:]{.underline}

6\. [Preparation Information:]{.underline}

A software delivery package is required at the end of the contract
period. The software delivery package shall include the following
information with appropriate approvals:

A.  Software Delivery Letter, one page in length, which defines briefly
    what is being delivered, contains in its attachments the details of
    the delivery, and identifies a point of contact for resolution of
    questions/misunderstandings/problems involving the delivery.
    Attachments which support the delivery letter are described in
    items (a) through (k) below:

    a.  Description of Delivery Contents -- Identify the delivery in
        terms of subsystem, release number(s), configuration ID(s),
        media type(s) (tapes, diskettes, other) and number of copies.

    b.  Build Instructions - Provide instructions to be used in building
        the delivered software, including the version number of system
        or vendor-supplied software required to build the system. The
        supplier should provide evidence that these instructions have
        been executed prior to delivery and that the software has been
        built successfully using them (As Built Configuration).

    c.  Special Operating Instructions -- Indicate any special
        instructions that test or operations personnel need to know in
        using the software. These may include, for example, the use of
        special simulators, changes to operational procedures, the
        addition of new files, file format changes, operating
        constraints/limitations, workaround resolutions to documented
        problems, operational software version numbers, and associated
        database version numbers.

    d.  List of Resolved Anomaly Reports and Change Requests.

    e.  List of Unresolved Anomaly Reports and Change Requests.

    f.  Copy of Resolved Anomaly Reports and Change Requests.

    g.  Copy of Unresolved Anomaly Reports and Change Requests.

    h.  Matrix of requirements addressed by this release (may be done by
        reference to mapping of requirements identified in requirements
        specification document).

    i.  Release History Summary Matrix.

    j.  Inventory of the Delivered Media -- Produce the inventory from
        the media themselves,

    k.  List of Release Documentation, e.g. users guide procedures.

```{=html}
<!-- -->
```
B.  Software Delivery Media

> The second of the three items of the delivery package is the delivered
> software, including the source code and executable code. Provide this
> software on the media in accordance with the contract schedule. The
> media can be magnetic disk, magnetic tape, optical media, paper
> listings, etc. Number of copies of the media is in accordance with the
> contract schedule.

C.  Accompanying Documentation

> The third and final item included in the software package is the
> documentation that describes the delivered software. Provide copies of
> the following:

(a) Users Guide.

(b) Software Description

(c) Requirement(s) Documentation or draft change pages.

(d) Design Documentation or draft change pages.

(e) Data Definitions

(f) Test Plans, Procedures and Results as appropriate.

D. An operations transition plan is required prior to the final software
release for Government acceptance. It plans for the transition of all
deliverable software and supporting databases from the development team
to the operations and the software maintenance teams. The plan shall
include delivery and transition of software, documents, and users guides
to its operational state on deliverable simulators or test beds such as
the Software Development and Validation Facility and Flight Software
Validation and Maintenance Facility.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SW-8 Software Management and DEvelopment plan

3\. [Reference:]{.underline}

SOW 4.4.2

NPR 7150.2

4\. [Use:]{.underline}

Defines contractor activities required to develop and manage all
software

5\. [Preparation Information:]{.underline}

The Software Management and Development Plan shall describe processes
and activities used in the development and testing of the various types
of software being acquired, acknowledging the fact that not all software
has the same criticality level or process requirements (reference the
classification requirements in SOW sections 4.4.1.1.3 and 4.4.1.1.4.

Topics to be included in the Software Development and Management Plan
are:

A.  Purpose and Description;

B.  Resources, Budgets, Schedules, and Organization; A description of
    how the software personnel structure is integrated into the overall
    LDCM development organization.

C.  Acquisition Activities;

D.  Development methodologies and Activities;

E.  Sustaining Engineering and Operations Activities;

F.  Software Assurance Plan

G.  System safety;

H.  Software Risk Management plan;

I.  Delivery and Operational Transition

J.  V&V and IV&V;

K.  COTS, GOTS, and MOTS software.

L.  Subcontractor management and monitoring

M.  The plan and approach for training personnel (Contractor staff,
    external maintainers, Flight Operation Team) in the use of all
    delivered software and supporting facilities

Additionally, the Contractor shall evaluate all flight software using
software metrics. The metrics collected, trended, and presented monthly.
Metrics shall include at a minimum:

A.  Number of flight software requirements and their change status

B.  Design/Code complexity index at CSU, CSC, and CSCI levels

C.  Source code production rate estimates versus actuals

D.  Number of Software Change Requests/Problem Reports and their status

E.  Resource margins for Utilization of memory, CPU, I/O Bandwidth and
    Bus traffic

F.  Effort data (staffing profile) estimates versus actuals

Include an alphabetized list of definitions for abbreviations and
acronyms used in this document. Include an alphabetized list of
definitions for special terms used in the document, i.e., terms used in
a sense that differs from or is more specific than the common usage for
such terms.

Material that is too detailed or sensitive to be placed in the main body
of text may be placed in an appendix or included as a reference. Include
the appropriate reference in the main body of the text. Appendices may
be bound separately, but are considered to be part of the document and
shall be placed under configuration control as such.

**INTEGRATION AND TEST DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

IT-1 Instrument Integration and Test Plan

3\. [Reference:]{.underline}

SOW 4.2.10

4\. [Use:]{.underline}

To provide information on the integration and testing of the instrument.
An overview of the entire I&T flow and its relation to performance
verification.

5\. [Preparation Information:]{.underline}

The contractor shall provide an Instrument Integration and Test Plan
which describes the series of activities required to integrate the
various instrument components into the final flight configuration. It
also includes the activities required to test this configuration to
verify its readiness for integration onto the Observatory.

At a minimum, the plan shall contain the following information:

Deliverables to Instrument Integration and Test

Flow of instrument Integration and Test sequence, including
identification of calibration tests and characterizations. Identify
instrument level requirements to be verified at each stage, cross
referenced to the SPVP. Identify dependencies within the I&T sequence.

Description of each instrument activity or test including the general
test configuration

Description of instrument procedures required to support the activity or
test

Description of simulated data/ simulator requirements

> Description of instrument special handling requirements to support the
> activity or test
>
> Description of instrument ground support equipment requirements to
> support the activity or test
>
> Description of instrument safety requirements to support the activity
> or test
>
> Description of instrument personnel required to support the activity
> or test
>
> Requirement to take photographs during the integration process for
> reference
>
> Description of the process to be used for handling anomalies as they
> occur during I&T
>
> Requirement of log books to be maintained throughout the I&T process

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

IT-2 Test reports

3\. [Reference:]{.underline}

SOW 4.2.10

4\. [Use:]{.underline}

Report the results of all tests identified in the Test Plans, including
test procedures used, test results, and configuration status of all
items under test.

5\. [Preparation Information:]{.underline}

The Contractor shall provide test reports that summarize the results of
verification tests on the instrument. The following shall be included in
test reports:

a\. Test identification and hardware configuration-- for specific test

b\. Facility description

c\. Reference - applicable test plan, test procedures, and test
requirements, test log including the dates of the testing, photographs
of test setup, any malfunction reports written during the test

d\. Test results, to include:

1.  Identification of test results which confirmed the expected results
    as specified in the test plan / procedures or for which variations
    between actual and expected results were within specified tolerance.
    For the latter case, actual test results shall be shown.

2.  Identification of test results which differ from expected results
    beyond expected or acceptable limits

3.  Identification of any planned test objective or requirement for
    which actual results were not obtained. Reasons for not meeting the
    objective/requirement shall be stated.

4.  Identification of any false or aberrant results noted during the
    test or subsequent analyses. Note that any such behavior that can
    prevent the instrument from accomplishing its mission objectives can
    be a basis for rejection.

d\. Recommendations for subsequent actions shall be stated, based on the
test results, to include:

1.  Redesign of a particular component to enable the instrument to meet
    a specific requirement which was not fulfilled

2.  Revision of a system / subsystem specification in cases where the
    test results disclose ambiguity or conflicting requirements

3.  The performance of additional where results were not acceptable to
    fulfill objectives.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

IT-3 Detailed Test Plans

3\. [Reference:]{.underline}

SOW 4.2.10

4\. [Use:]{.underline}

To provide information on how the Instrument will be tested and how its
performance will be verified.

5\. [Preparation Information:]{.underline}

The contractor shall provide detailed test plans to be used during
Instrument Level Testing. Test Plans shall be written at a level above
the test procedures and shall provide information sufficient to
understand the purpose and methodology of all tests, and to provide the
required environmental and configuration controls necessary for
successful completion of the test. These plans shall be prepared for
each test activity defined in the Performance Verification Plan and
shall cover all Instrument test operations, interfaces, and Instrument
performance requirements (i.e., electrical, structural and mechanical,
EMC), and shall cover specialized tests such as mechanical function and
deployments, environmental exposure tests (i.e., vacuum, vibration),
Instrument calibration, GSE calibration and checkout, and pre-launch
end-to-end tests. If tests are conducted in conjunction as part of a
"group" test, for example, Limited Performance Test (LPT) or
Comprehensive Performance Test (CPT), one test plan may encompass this
group. At a minimum, the plans shall contain the following information:

a\. Test Objectives

b\. Test Methods

c\. Applicable Documents and Software

d\. Required Instrument configuration, including any differences from
flight configuration

e\. Test Equipment Configuration, including layout and interconnection
of test equipment and articles including the grounding scheme. Location
and identification of all measuring points on appropriate schematics and
diagrams

f\. Test Equipment and Facility Identification

g\. Test Instrumentation

h\. Safety Provisions and Cautions, including Identification of
hazardous and potentially hazardous situations and operations and abort
conditions

i\. Environmental and/or other conditions to be maintained, including
contamination controls

j\. Responsibilities and chain-of-command for test performance

k\. Expected results in telemetry and associated caution and warning
levels.

l.  Data Recording Requirements

m.  Data Recording Forms and Tables

n.  Accept/Reject Criteria

o.  Note any test phases and profiles

p.  List the requirements for the test procedure and test report
    development

q.  Description of any necessary functional operations required during
    the test (ie. a CPT performed at hot and cold during thermal vacuum
    testing)

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

IT-4 Packaging, Handling, Storage, and Transportation (PHS&T) Plan and
Procedures

3\. [Reference:]{.underline}

SOW 4.4

MAR

4\. [Use:]{.underline}

Provide the instructions and procedures for safe and effective
packaging, handling, storage, and transporting of flight hardware,
spares, and associated GSE throughout the contract.

5\. [Preparation Information:]{.underline}

This documentation shall discuss the plan and all of the step-by-step
procedures for the packaging, handling, storage, and transporting of the
instrument, spares, and GSE. This plan shall be prepared in accordance
with the MAR.

The documentation shall include:

For Transporting:

A.  Nomenclature of all supportive equipment

B.  Calibration and load-tested data

C.  Identification of special environmental conditions, such as
    cleanliness, temperature, humidity, etc., and the controls to be
    implemented to maintain those conditions

D.  Format for recording QA stamp, deviations and approval columns

E.  Requirements for special personnel, tools, equipment, special
    handling fixture and containers, including:

    a.  Specific procedures for use of instrument protective covers.

F.  Method of transportation and carrier

G.  Cargo manifest including aircraft layout diagrams, if applicable

H.  Ground and/or air shipment cargo loading and unloading procedures.

I.  Staging area plans and diagrams.

J.  Trip planning schedule of events, required support, route,
    contingency plans, permits.

K.  Procedures to comply with local, state and federal safety
    requirements

L.  Procedures for maintaining contact with the transported item.

For Storage:

The contractor shall provide a detailed plan for ground storage of the
OLI instrument in case it is required at the direction of the
Government. The plan shall describe the following:

a\. Preparation for storage.

b\. Ground storage facilities.

c\. Environmental control.

d\. Monitoring of critical functions during storage.

e\. GSE and testing requirements during storage.

f\. Impact of prolonged storage on instrument operational lifetime
including expendables.

g\. Removal from storage, including retesting requirements.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

IT-5 As-Run Test Procedures

3\. [Reference:]{.underline}

SOW 4.2.10

4\. [Use:]{.underline}

As an archive of test procedures used during system development to aid
in on-orbit anomaly resolution.

5\. [Preparation Information:]{.underline}

As-Run Test Procedures shall be all as-run, red-lined, contractor-format
test procedures used during instrument development, integration, and
test at instrument and at observatory levels.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

IT-6 ENvIRONMENTAL VERIFICATION PLAN AND ENVIRONMENTAL TEST MATRIX

3\. [Reference:]{.underline}

SOW 4.2.10

4\. [Use:]{.underline}

This DRD consists of the Environmental Verification Plan (EVP) and the
Environmental Test Matrix. The EVP documents the contractor\'s approach
for environmental qualification and acceptance tests. The Environmental
Test Matrix summarize the tests performed. This DRD also satisfies the
environmental verification requirements of the launch services provider.

5\. [Preparation Information:]{.underline}

The Environmental Verification Plan shall provide the general test
philosophy and an overview of the systems-level environmental testing to
be performed to demonstrate that the hardware and software comply with
the LDCM Environmental Verification Requirements Document .

The environmental verification plan shall include test objectives, test
specimen configuration, and general test methods. It should not include
detailed test procedures.

The environmental verification plan shall provide the overall approach
to accomplishing the environmental verification program. For each test,
it shall include the level of assembly, the configuration of the item,
objectives, facilities, instrumentation, safety considerations,
contamination control, test phases and profiles, necessary functional
operations, personnel responsibilities, and requirement for procedures
and reports. It shall also define a rationale for retest determination
that does not invalidate previous verification activities. When
appropriate, the interaction of the test and any related analysis
activity shall be described.

Limitations in the environmental verification program which preclude the
verification by test of any system requirement shall be documented.
Examples of limitations in the ability to demonstrate requirements
include:

-   Inability to deploy hardware in a 1-g environment.

-   Facility limitations which do not allow testing at system level of
    assembly.

-   Inability to perform certain tests because of contamination control
    requirements.

-   Inability to perform powered-on testing because of voltage breakdown
    concerns.

-   Alternative tests and analyses shall be evaluated and implemented as
    appropriate, and an assessment of program risk shall be included in
    the System Performance Verification Plan.

As an adjunct to the environmental verification plan, an environmental
test matrix shall be prepared that summarizes all tests that will be
performed on each component and each subsystem. The purpose is to
provide a ready reference to the contents of the test program in order
to prevent the deletion of a portion thereof without an alternative
means of accomplishing the objectives; it has the additional purpose of
ensuring that all flight hardware has been subjected to environmental
exposures that are sufficient to demonstrate acceptable workmanship. In
addition, the matrix shall provide traceability of the qualification
heritage of hardware. All flight hardware, spares and prototypes (when
appropriate) shall be included in the matrix. Details of each test shall
be provided (e.g., number of thermal cycles, temperature extremes,
vibration levels). It shall also relate the design environments to the
test environments and to the anticipated mission environments. The
matrix shall be prepared in conjunction with the initial environmental
verification plan and shall be updated as changes occur.

A complementary matrix shall be included showing the tests that have
been performed on each component or subsystem (or applicable level of
assembly). This should include tests performed on prototypes or
engineering units used in the qualification program, and should indicate
test results (pass/fail or malfunctions).

**CALIBRATION/VALIDATION DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-1 Calibration/Validation Plan

3\. [Reference:]{.underline}

SOW 2.3

SOW 4.2.10.3

4\. [Use:]{.underline}

Controlling document for definition of calibration methods and
equipment.

5\. [Preparation Information:]{.underline}

The Contractor shall provide a Calibration/Validation Plan that
describes the approach for calibrating, characterizing, and validating
the spectral, spatial, radiometric, and geometric performance of the
OLI, thereby ensuring that the OLI will satisfy the OLI Requirements
Document. The Calibration and Validation Plan shall address all
requirements and tests identified in the Special Calibration Test
Requirements Document.

The Calibration/Validation Plan shall incorporate the following
information at a minimum:

A.  A description of planned tests and analyses including:

    a.  what is being tested or analyzed and how it relates to
        instrument performance

    b.  the expected test or analysis results

    c.  integration level for test or analysis model, i.e. part,
        subassembly, assembly, instrument,

    d.  environmental conditions for test, e.g. ambient, thermal-vacuum,
        on-orbit

    e.  sampling methods and their statistical validity

    f.  operational phase of testing, i.e. pre-launch, or commissioning

    g.  theoretical basis for the test or analysis, i.e., how the test
        is performed, how the data are reduced and the method rationale
        supported by fundamental physics principles and equations)

    h.  the resolution, precision and accuracy of the results and
        relation to the expected results

    i.  test configuration, i.e., equipment, test equipment calibration,
        and test setup

    j.  description of test or analysis results usage, i.e. processing
        algorithms that use test or analysis results or calibration
        parameters generated by the test or analysis

B.  A test and analysis schedule and flow chart

C.  How test/analysis results are made available

D.  Government access and participation in pre-launch testing including
    a Government-owned transfer radiometer/Earth Observing System (EOS)
    radiometric scale realization activities and any government diffuser
    BRDF characterization activities

E.  Description of COTS and custom analysis tools

F.  A description of the On-Orbit Calibration capabilities of the OLI,
    including their design, characterization techniques, and operational
    implementation. This shall include a description of any necessary
    calibration data that must be collected during normal operations.

G.  Reference Standards and their calibration traceability

H.  Support data requirements, e.g. GCP, DEM, reference images

Given known issues with diffuser materials on other NASA missions being
contaminated in manufacturing or in pre-launch testing, the Contractor
shall ensure the OLI Calibration/Validation Plan also addresses the
following items:

> \(1\) All diffuser materials shall be initially vacuum baked out (with
> measurement of released contaminants).
>
> \(2\) The BRDF of the diffuser materials shall be measured after the
> bake out.
>
> \(3\) The flight diffuser and several witness samples shall be kept in
> a clean, sealed or purged environment for the duration of instrument
> testing.
>
> \(4\) Selected non-flight witness samples shall be exposed to lifetime
> ultraviolet exposure. The Contractor shall establish criteria for
> acceptable and unacceptable diffuser degradation due to ultraviolet
> exposure, and reject any diffuser material lots that do not meet these
> criteria. If the lot is rejected, steps 1-4 shall be performed with a
> new material lot.
>
> \(5\) During I&T, a test (non-flight) diffuser and several witness
> samples shall be used for all instrument and observatory I&T
> activities.
>
> \(6\) After I&T the test diffuser witness samples shall be ultraviolet
> damage tested and reflectance characterized.
>
> \(7\) After I&T, one flight diffuser witness sample shall be
> ultraviolet damage tested, one shall be vacuum baked and ultraviolet
> damage tested, and both shall be reflectance characterized.
>
> \(8\) Flight diffuser shall be vacuum baked (if necessary, based on
> the previous test) and integrated to the instrument as close to launch
> as possible.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-2 Calibration/Validation Procedures

3\. [Reference:]{.underline}

SOW 4.2.10.3

4\. [Use:]{.underline}

To verify that the planned procedures meet the goals of the
Calibration/Validation Plan.

5\. [Preparation Information:]{.underline}

1\. For each test in the Calibration/Validation Plan, the
Calibration/Validation procedure for each test shall include:

a\. Test Objectives

b\. Test Methods

c\. Assumptions

d\. Applicable Documents and Software

e\. Associated algorithms

f\. Required Instrument Configuration, including any differences between
pre-flight and flight configurations

g\. Mechanical and Electrical Test Equipment Configuration, including
layout and interconnection of test equipment and articles including the
grounding scheme. Location and identification of all measuring points on
appropriate schematics and diagrams

h\. Test Equipment Identification

i\. Test Instrumentation

j\. Calibration reference requirements

k\. Safety Provisions and Cautions, including Identification of
hazardous and potentially hazardous situations and operations and abort
conditions

l\. Environmental and/or other conditions to be maintained, including
contamination controls

m\. Personnel responsibilities and chain-of-command for test performance

n\. Expected results in telemetry and associated caution and warning
levels.

o\. Program Quality Requirements

p\. Stimuli sources and associated and associated levels

q\. Test durations

r\. Test configurations

s\. Sequence of events

t\. Trending of performance characteristics during verification testing

u\. Step-by-step instructions

v\. Data Recording/Output Format Requirements

w\. Data Recording Forms and Tables

x\. Analysis techniques

y\. Expected results

z\. Pass/Fail Criteria

aa. Test Termination Procedure

2\. For each Analysis in the Calibration/Validation Plan, the procedure
for each Analysis shall include:

> a\. Analysis Objectives, i.e. short description of the item or items
> being validated by this analysis.
>
> b\. Analysis Methods including the analysis level of depth (i.e. 1^st^
> order, 2^nd^ order, etc...)

c\. Assumptions

d\. Applicable Documents and Software

e\. Associated algorithms and software tools.

f\. Required analysis mode/model configuration(s).

> g\. List of input data that will be used and related tests ID that
> were used to

acquire the data.

> h\. List of external reference sources of input data and/or model used
> in analysis (e.g. DEM,
>
> SOLAR spectral radiance model)
>
> i\. List of fixed analysis parameters and set points

j\. List of adjustable analysis parameters and set points that may vary
between runs.

k\. Equipment requirements

l\. Program Quality Requirements

m\. Sequence of events

n\. Step-by-step description of the data analysis procedure/algorithm

o\. Description of any statistical sampling method being used

p\. Data Recording/Output Format Requirements

q\. Data Recording Forms and Tables

r\. Expected results

s\. Pass/Fail Criteria

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-3 Calibration/Validation Reports and Summaries

3\. [Reference:]{.underline}

SOW 4.2.10.3

4\. [Use:]{.underline}

To provide results of individual calibration/validation tests and
analyses for Government review. To provide summaries at a higher level
to serve as instrument calibration references for current and future
users of the LDCM data set.

5\. [Preparation Information:]{.underline}

The Contractor shall provide a Calibration/Validation Report for each
calibration or validation test or analysis. All supporting data shall be
provided in electronic format, where applicable.

The Calibration/Validation Reports shall include at a minimum:

A.  Identification of article or component tested or being validated
    with date of test or related analysis and the relevant Test/Analysis
    ID and run number

B.  Performance trends during and between each planned test

C.  List of uncertainty levels for each input data in analysis or test
    measurements

D.  If a given test or analysis have more than one configuration state
    the test or analysis configuration selected.

E.  Problems or failures with tests, procedures, or analyses

F.  Anomalies and deviations from plans or procedures and their
    resolution/status

G.  Test or analysis results, including:

    a.  any calibration parameters to be used for on-orbit processing

    b.  comparison of results with expectations and requirements

    c.  interpretation of the results

The Calibration/Validation Summary Report shall be delivered in two
phases. The Pre-Ship report shall describe the pre-ship calibration
process and results. The Post-Launch Report shall describe the
calibration process and results from the commissioning phase. Each shall
document the state of the instrument calibration relative to the OLI
Requirements Document. The reports shall include details of any
anomalies affecting the data, descriptions of the instrument calibration
and characterization tests, references to previous test reports and
analyses, and long term trending results. The Post-Launch Report shall
include any changes made to the calibration parameters and algorithms
during the Commissioning period and the justification for these
changes.  

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-4 Radiometric Math Model

3\. [Reference:]{.underline}

SOW 4.1.1.2

4\. [Use:]{.underline}

For evaluating the end-to-end radiometric performance of the instrument,
allocation of error budget, etc.

5\. [Preparation Information:]{.underline}

A.  The Radiometric Math Model shall be used to: evaluate the end-to-end
    radiometric performance of the Instrument (Photons to Calibrated
    at-Instrument-radiance); conduct sensitivity analyses; determine
    absolute and relative calibration accuracies; identify error
    contributors which can be eliminated or mitigated during the design
    phase; identify impact of error budget trades; assess instrument
    performance in terms of Signal to Noise Ratio (SNR), Noise
    Equivalent Radiance (NE∆L), stability in orbit, etc.

B.  The model shall incorporate actual test and calibration data; the
    model shall be updated and refined during the course of the
    Instrument development program until it simulates instrument
    performance within the accuracy required by the specifications.
    Detector performance predictions/margins shall be modeled at the
    detector/FPA level and compared against detector performance during
    detector/FPA development.

C.  The model shall include on-board and preflight ground laboratory
    calibration algorithms and a data book that contains all pertinent
    estimated measured data required by the calibration algorithms. The
    estimated data shall be replaced with measured data when it is
    available. The on-board calibration algorithms are used along with
    ground calibration data to demonstrate that the absolute and
    relative radiometric accuracies are being met. The calibration data
    shall also be provided in a mutually agreed upon electronic format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-5 Optical Analytical Model

3\. [Reference:]{.underline}

SOW 4.1.1.4

4\. [Use:]{.underline}

For evaluating the end-to-end geometric and spatial performance of the
instrument, allocation of error budgets, and to provide a framework for
thermal and mechanical sensitivity analyses.

5\. [Preparation Information:]{.underline}

1)  Component Models

    a.  Focal Plane Model

> Describe the size, shape, and placement of the detectors on the focal
> plane, including how the detectors are grouped by band and, if
> applicable, Instrument chip assembly. Describe how detector focal
> plane location can be determined as a function of detector number,
> chip number, and band number. Show how the detector layout and
> sampling combine to provide complete coverage of the ground target
> area. Present a model of detector spatial response (ground sampling
> footprint) that includes the effects of detector size, shape, detector
> spatial responsivity, and integration time.

b.  Optical Model

> Describe the key parameters of the optical system such as Cardinal
> Points, FOV, and 5^th^ order aberrations modeling, in a static nominal
> setting. Define the optical axes of the system and present a
> geometrical model of the optics that shows how locations in the
> instrument focal plane are mapped to directions relative to the
> optical axes. Present a model of the spatial response of the optical
> system (i.e., MTF). Provide a tolerance analysis that quantifies the
> effects of physical shifts of any static or dynamic components in the
> optical system, and physical differences in fabricated components from
> design requirements (i.e. radius of curve, index, coating quality,
> centeration, polished surface finish) on the geometrical and spatial
> models.

c.  Mechanism Models

> Geometrically characterize and model any dynamically moving part/s in
> the optical system such as a scanning/pointing mechanism, and/or a yaw
> steering table/mirror showing how any telemetry characterizing the
> operation of each mechanism is used to determine its effect upon the
> imaging geometry. Include an analysis of the effects of mechanical
> jitter documented in the Jitter Analysis Report (SE-17) on the
> instrument line of sight including a description of any methods used
> to compensate for jitter using vibration Instruments and ground
> processing.

2)  Dynamic Models

    a.  Thermal Sensitivity Model

> Use the results of the structural thermal optical program (STOP)
> analysis to derive the expected variations in the component models
> with temperature.

b.  Vibration Sensitivity Model

> Analyze the sensitivity of the component models to vibration and use
> the results of the instrument structural model to predict the expected
> variations in the component models in the operational vibration
> environment.

3)  Performance Models

    a.  Spatial Performance

> Combine the component and dynamic models to construct an integrated
> model of end-to-end spatial response that can be used to analyze and
> predict instrument edge response performance. Include the effects of
> jitter and orbital and seasonal thermal variations in the results of
> the model.

b.  Geometric Performance

> Combine the component and dynamic models to construct an integrated
> instrument geometrical line of sight model that can be used to analyze
> and predict line of sight knowledge and stability performance. Include
> the effects of jitter and orbital and seasonal thermal variations in
> the results of the model.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-6 Calibration Algorithms and Parameters

3\. [Reference:]{.underline}

SOW 4.1.1.1

SOW 4.1.1.3

4\. [Use:]{.underline}

Algorithms for determination of instrument calibration from pre-launch
and on-board calibration devices and pre-launch calibration parameters
are required for image processing

5\. [Preparation Information:]{.underline}

Required algorithms:

A.  For processing of solar diffuser data to absolute calibration
    coefficients

B.  For determination of each detectors dark response during earth image
    acquisition based on the dark pixels and dark data acquired before
    and after the earth acquisition.

C.  For determination of detector response based on the internal lamp
    system

D.  For determination of radiometric stability through launch using the
    transfer to orbit on-board calibration devices

E.  For usage of any other calibration devices

F.  For computing a line of sight relative to the instrument optical
    axes for each detector on the focal plane.

G.  For transforming detector lines of sight relative to the instrument
    optical axes to lines of sight relative to an absolute
    Earth-referenced coordinate system, using data from spacecraft
    attitude sensors, and/or jitter sensors, as required.

H.  For algorithm for characterization of the instrument response
    linearity on-orbit with the related on-board calibration device(s).

This algorithm delivery set shall consist of

a\. An overview of each algorithm including the objective or purpose of
the algorithm

a.  A description of each algorithm inputs and outputs

b.  A mathematical description of each algorithm

c.  The algorithm executable source code and identification of the
    Operating System that the source code was built on.

d.  A description of the methods used to validate each algorithm and the
    validation results

e.  A list of the instrument data components used by each algorithm

Required Calibration parameters:

A.  Pre-launch detector by detector absolute gains that meet the
    detector to detector uniformity and absolute accuracy requirements

B.  Pre-launch detector-by-detector dark responses (biases)

C.  Coefficients characterizing detector gain and bias sensitivity to
    temperature

D.  List of dead, inoperable and out-of-spec detectors (Detector
    Operability Status list)

E.  Line of sight angles and/or apparent (i.e., including the effects of
    optical distortion) detector locations relative to the optical axes
    for each detector on the focal plane.

F.  Orientation/alignment matrix relating Observatory attitude and/or
    jitter sensors to the optical axes.

G.  Scaling coefficients that convert jitter sensor (if applicable)
    counts to angular displacement.

H.  Transfer functions describing the sensitivity of the jitter sensors
    (if applicable) to vibration as a function of frequency.

I.  Scaling coefficients and/or alignment matrices that describe the
    orientation of the instrument optical axes relative to the
    instrument mounting surface.

J.  Coefficients for calibrating the output of any attitude and/or
    jitter sensors (e.g., temperature sensitivity correction
    coefficients).

K.  Any additional calibration parameters required to run the formulated
    radiometry calibration algorithms not captured in this original
    list.

Delivery of Calibration parameters shall include a description of the
parameter being delivered and any information necessary to interpret the
delivery.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-7 DATA processing Algorithms

3\. [Reference:]{.underline}

SOW 4.1.1.8

4\. [Use:]{.underline}

The Data Processing algorithms will be used to estimate and correct
systematic errors in the LDCM data and to correct residual errors in the
LDCM data so that the resulting corrected LDCM data meet the imagery
requirements of OLI Requirements Document.

5\. [Preparation Information:]{.underline}

A separate delivery shall be provided for each of the algorithms
described in the OLI Requirements Document. The algorithms to be
provided are:

1\. Radiometric correction Algorithms:

a\. Detector Bias Determination

b\. Conversion to Radiance

c\. Conversion to Reflectance

d\. Inoperable Detector Replacement

2\. Geometric Correction Algorithms:

a\. Ancillary Data Preprocessing

b\. Line-of-Sight (LOS) Model Creation

c\. Line-of-Sight Projection

d\. Line-of-Sight Model Correction

3\. Image Resampling Algorithm

Algorithm restrictions provided in the OLI Requirements Document shall
be adhered to.

Each delivery shall consist of

a\. An overview of the algorithm including the objective or purpose of
the algorithm

> b\. The rationale for the algorithms and the specifications it
> supports
>
> c\. A description of any external ancillary data (i.e. from the
> spacecraft) used by the algorithm
>
> d\. A description of the algorithm outputs
>
> e\. A mathematical description of the algorithm
>
> f\. The algorithm executable source code and identification of the
> Operating System that the source code was built on.

f.  An error analysis showing the expected accuracy of the algorithm
    results

g.  A description of the methods used to validate the algorithm and the
    validation results

h.  A list of the instrument data components used by the algorithm

i.  A list of the calibration parameters used by the algorithm

k\. A list of references

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-8 relative spectral response (RSR) component measurements and system
RSR analysis

3\. [Reference:]{.underline}

SOW 4.2.10.3

4\. [Use:]{.underline}

To provide the measurements of relative spectral response of Instrument
components and the estimated system RSR.

5\. [Preparation Information:]{.underline}

The Contractor shall provide the relative spectral response (RSR)
measurements used to estimate Instrument relative spectral response. The
provided component RSR measurements shall include:

a\. the telescope optical elements

b\. all spectral filters

c\. a sample of detectors in each band

d\. any other optical elements that contribute to the Instrument RSR

The provided component data shall include:

a\. The description of method used to obtain data including any sampling
scheme used in obtaining the calibration data (the method description
should include a statement about the traceability of the data to a
standard reference or standard laboratory calibration results)

b\. The calibration data of the instrument(s) used to measure the RSR or
a statement of the status of the calibration of the instrument(s) used
to measure the RSR.

c\. The wavelength sampling used to obtain the data.

d\. The environmental conditions such as temperature/humidity, the
optical/geometrical set up such as the incidence angle, and f/# (the
ratio of focal length to entrance pupil diameter) at which the RSR of
spectral filter data, and any other related transmissive elements in the
system optical path, at which the data was measured and how the data was
adjusted (if applicable) to account for operational temperatures,
incident angle, and f/#.

e\. A description of any other adjustments to the data.

f\. An estimate of the accuracy of the measured data, including added
RSR variations due to the method used for collecting the response data;
for example, short circuit currents vs. DN obtained directly from FPA
electronics.

The system RSR estimate shall include:

a\. The methodology used to convolve the component measurements to
estimate the system RSR.

b\. A spreadsheet of the estimated RSR of each spectral band which
contains the convolution of the component-level RSRs and any adjustments
made to the data.

c\. An accuracy estimate of the RSR in each band and the basis of the
estimate, which shall include a discussion of the entire range of
expected on-orbit operations conditions including the variation the in
total power levels illuminating the detectors.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

CV-9 Instrument data sets

3\. [Reference:]{.underline}

SOW 4.2.10

SCTR

4\. [Use:]{.underline} To provide Instrument data sets for use in LDCM
Ground Segment testing and for independent review.

5\. [Preparation Information:]{.underline}

During Instrument-level and observatory-level prelaunch testing, those
test data sets identified in the Special Calibration Test Requirements
document as requiring sensor data set delivery per this CDRL shall be
generated and recorded for use by the Government.

For instrument-level test output these data sets shall consist of:

a.  Unprocessed detector sample data with associated time indexing
    information.

b.  Instrument ancillary data that would be included in the LDCM mission
    data stream and associated time indexing information.

c.  Instrument housekeeping information that would be included in the
    observatory telemetry stream and associated time indexing
    information.

These data sets shall be provided as computer compatible, word-aligned
CCSDS CADUs in the space segment to government assets transmission
format documented in SE-NN (TBD), if practicable. Alternatively, these
data may be provided in a contractor-defined computer compatible format
if accompanied by corresponding documentation comparable to SE-NN.

These data sets shall be provided on standard commercially available
digital media.

For observatory-level test output these data sets shall consist of:

a.  Unprocessed detector sample data with associated time indexing
    information.

b.  Instrument ancillary data that would be included in the LDCM mission
    data stream and associated time indexing information.

c.  Observatory ancillary data that would be included in the LDCM
    mission data stream and associated time indexing information.
    Ancillary data fields that are not available or are not meaningful
    in the prelaunch environment (e.g., ephemeris) may be simulated.

d.  Instrument housekeeping information that would be included in the
    observatory telemetry stream and associated time indexing
    information.

e.  Observatory housekeeping information that would be included in the
    observatory telemetry stream and associated time indexing
    information.

These data sets shall be provided as computer compatible, word-aligned
CCSDS CADUs in the space segment to government assets transmission
format documented in SE-NN (TBD).

These data sets shall be provided on standard commercially available
digital media.

**SYSTEMS ENGINEERING DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-1 ENGINEERING CHANGE REQUESTS, DEVIATIONS, and WAIVERS

3\. [Reference:]{.underline}

SOW 1.10

MAR

4\. [Use:]{.underline}

To facilitate the orderly processing of change requests to appropriate
level of approval authority for disposition.

5\. [Preparation Information:]{.underline}

Consistent with the Contractor's Configuration Management Plan (CMP),
the contractor shall prepare and submit Class I Configuration Change
Request (CCR). In addition to the change description, the CCR shall
contain sufficient information in the form of attachments, drawings,
test results, etc., to allow the Government to evaluate the total impact
of the proposed change. The Government Contracting Officer may direct
the contractor to prepare CCRs under the "Changes" clause of the
contract. The contractor shall also submit Class II changes for
Government review.

For the purposes of this DRD, a Class I CCR is a change that:

a\. Affects any Government Contract specification or interface
requirement.

b\. Affects schedules of end item deliverables to the Government.

c\. Impacts Government Furnished Equipment.

d\. Affects configuration to the extent that changes would be required
to prior deliverables in order to maintain specified performance.

e\. Causes a Single Point Failure.

A change may be classified Class II when it does not fall within the
definition of a Class I change as given above. Examples of Class II
changes are:

a\. A change in documentation only (for example, correction of errors,
addition or clarifying notes or views).

b\. A minor change in hardware (for example, substitution with an
approved alternative material) which does not affect any item listed
under Class I changes.

c\. Drawing changes that do not affect a baseline, interface, etc.

Class II changes normally do not require Government CCB approval unless
they are written against Government CM-controlled documents.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-2 Contractor - Generated Internal Technical INFORMATION

3\. [Reference:]{.underline}

-   SOW 1.5

4\. [Use:]{.underline}

To document technical information and decisions related to the OLI
program.

5\. [Preparation Information:]{.underline}

These memoranda shall be in contractor format, preferably electronic.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-3 Trend Analysis and Operations Log

3\. [Reference:]{.underline}

SOW 2.5

4\. [Use:]{.underline}

Provides a list and a means of tracking critical engineering and
performance parameters for the OLI. Provides a log of OLI operating
hours. Starting at component acceptance testing and continuing during
the system integration and test phases through the on-orbit
commissioning phase, trend parameters are to be monitored for trends
leading toward degradation of performance or reliability of the OLI.

NOTE: Make a separate list of trend parameters for I&T and on-orbit
(lifetime)

5\. [Preparation Information:]{.underline}

[Trend List:]{.underline}

The list of parameters to be trended shall be subdivided by assembly or
subassembly. A brief rationale for including the parameter shall be
included. The list shall be coordinated with the Government prior to
implementation.

[Trend Reports:]{.underline}

The trend data shall be graphed with clearly marked axes. The scale of
the graphs shall be set such that trends can be clearly identified. The
scale of each graph shall be tailored for each parameter for the best
clarity. The scale of the graphs shall be readjusted with the range of
the data in order to continue identification of trends.

[Operations Log:]{.underline}

A log shall be maintained of the accumulated operating time of the OLI.
The log shall include the following information, as a minimum:

A.  Identification of hardware item

B.  Serial number

C.  Total operating time since assembly as a unit

D.  Total operating time since last failure

E.  Total additional operating time projected for the unit prior to
    launch

F.  Identification of key parameters being monitored

G.  Upper/lower spec tolerance limit for each parameter being monitored

H.  Observed value (in sequence) for the reporting interval

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-4 Thermal Math ModelS

3\. [Reference:]{.underline}

SOW 4.1.1.7

4\. [Use:]{.underline}

To design and evaluate the thermal performance of the instrument, define
the thermal control system requirements (heater power, thermometry,
etc.) and to define the thermal loads at the instrument/spacecraft
interface.

5\. [Preparation Information:]{.underline}

The model shall be composed of at least 250 nodes. The Thermal Math
Model shall have sufficient detail of all subsystems and critical
interfaces to accurately predict absolute interfaces. These models shall
be verified and refined after comparison with thermal test data.

The Contractor shall also develop reduced thermal models in accordance
with (TBD).

SINDA+TSS compatible or Thermal Desktop-compatible reduced node versions
of the full instrument thermal math model, appropriately documented, are
required for analytical integration with the spacecraft. A user's guide
shall be provided for delivered math models. The thermal model table of
delivery shall be included in the user's guide.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-5 engineering drawings

3\. [Reference:]{.underline}

SOW 1.10

4\. [Use:]{.underline}

To provide layouts and engineering drawings to serve as the basis for
technical discussions, evaluations, operations and maintenance. To
partially satisfy the Observatory drawings requirements of the launch
services provider.

5\. [Preparation Information:]{.underline}

The contractor shall submit all engineering drawings used to procure,
manufacture, assemble, integrate, test and control interfaces. Included
in this engineering drawing package shall be all reference type drawings
such as layouts, schematics, diagrams, mechanical drawings, electrical
schematics, logic diagrams, and block diagrams. The logic diagrams shall
cover the system, subsystem and component electronics and shall identify
the signal inputs and outputs, internal signal flow, and the next level
external connections.

Sketch type drawings shall not be used. Interface control drawings and
applicable Instrument layouts shall include the stowed, extended, and
critical intermediate positions of the moving mechanical assemblies and
deployables with respect to fields of view and surrounding structure,
components or other hardware. All drawing changes and change notices are
included under this requirement.

This delivery includes wiring diagrams. These wiring diagrams shall
cover the system, subsystem, component electronics. It shall identify
each wire by its classification:

-   Ground

-   Signal

-   Power

-   Wire type

-   Connector

The diagrams shall trace each wire's runs identifying all path
connections (by connector/pin number). Wire designators shall be clearly
delineated for legibility.

An indentured drawing list (including drawings from subcontractors)
shall be provided to the Government. An explanation of company
procedures for locating drawings in this package shall be provided with
this list.

All engineering drawings shall be delivered in the contractor's
designated format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-6 System Performance Verification Plan and Matrix

3\. [Reference:]{.underline}

SOW 2.3

4\. [Use:]{.underline}

Provides the overall approach for accomplishing the verification
program. Defines the specific tests, analyses, calibrations, alignments,
hardware models, etc. that will demonstrate that the flight hardware
complies with the mission requirements.

5\. [Preparation Information:]{.underline}

The System Performance Verification Plan (SPVP) shall:

A. Provide an overview of the entire OLI verification program,

B. Flow performance requirements to all levels of assembly and describe
the verification method for these tests.

The SPVP describes the approach (test, analysis, etc.) that will be
utilized to verify each OLI Requirements Document and each Instrument to
Spacecraft Interface Requirements Document requirement. If verification
relies on measurements, tests, or analyses at lower (or other) levels of
assembly, this dependence shall be described.

This Plan shall include level of assembly, configuration of item,
objectives, test phases, appropriate functional operations, and
requirements for procedures and reports. Each analysis activity shall
include objectives, a description of the mathematical model, assumptions
on which the model will be based, required output, criteria for
assessing the acceptability of the results, interaction with related
test activity, and requirements for reports.

On-orbit verification tests shall be cross-referenced to the On-Orbit
Commissioning Plan.

The Final SPVP due 15 days prior to IPER shall incorporate all review
comments.

[System Performance Verification Matrix]{.underline}

The System Performance Verification Matrix (SPVM) shall summarize the
flow-down of system specification, Mission Assurance, and
calibration/validation requirements verification. The SPVM shall
stipulate how each requirement will be verified, and summarizes current
status of compliance/non-compliance with requirements. The SPVM shall
list a summary description of each requirement, and a summary of the
measured/analyzed/demonstrated performance of the system against each
requirement. It shall show each OLI Requirements Document, MAR, and
Calibration/Validation Plan requirement reference source (to the
specific paragraph or line item), the method of compliance, applicable
procedure references, report reference numbers, etc. for each
requirement set from the OLI Requirements Document, MAR, and Special
Calibration Test Requirements Document. It shall show the flow-down of
requirements verification through the sub-system (box/board) level.

The SPVM shall trace requirements backwards to the next level above,
i.e., a level 4 requirement shall be traced back to its level 3 parent,
etc

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-7 Verification Reports

3\. [Reference:]{.underline}

MAR

SOW 4.2.10

4\. [Use:]{.underline}

Provide summary of each integration and test result, conformance,
non-conformance, and trend data. A Verification Report for all
verification types indicated in the System Performance Verification Plan
(Test, Analysis, Inspection, Demonstration) shall be generated.

5\. [Preparation Information:]{.underline}

Verification reports are required for all integration and test and
environmental test activities commencing at component level testing
through testing at the integrated instrument level. Contents of these
reports shall include, as a minimum:

A.  Summary of the test results of each activity and an assessment of
    the quality and acceptability of the item tested, including
    pass/fail criteria and performance against the criteria.

B.  Summary of non-conformances occurring during the test and the
    resolution and corrective actions taken

C.  Trends in the performance of critical components

D.  Actual sequence of these operations including dates and times

E.  For thermal testing, tabulation of test target temperatures and
    actual test temperatures for all equipment and components along with
    the location of temperature Instruments used during the test

F.  For thermal balance testing, a tabulation of test prediction and
    actual temperatures and a tabulation of other pertinent targeted
    parameters vs. their actual test values, such as heater powers,
    heater place temperatures, solar intensity, etc.

G.  Across-reference to the test procedure number(s) or analysis used in
    the verification.

Contractor format may be used for these reports as long as the required
information is included.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-8 configuration item identification list and Computer Software
Configuration Items

3\. [Reference:]{.underline}

SOW 1.10

4\. [Use:]{.underline}

To establish a structure for controlling the configuration of the OLI by
identifying all Configuration Items (CIs) and Computer Software
Configuration Items (CSCIs) used on the program and correlating those
CIs/CSCIs to their Specification and test requirements documents.

5\. [Preparation Information:]{.underline}

The Configuration Item Identification List (CIIL) identifies all CIs and
CSCIs. This CIIL shall conform to the following:

> a\. The CIIL shall be organized and broken down as follows:

1\) All system level CIs and CSCIs.

2\) All subsystem level CIs and all CIs/CSCIs within each subsystem.

> b\. For each CI listed, the following information shall be provided:

1\) Assigned CI Number.

2\) The CI top drawing number.

3\) The CI nomenclature.

4\) The applicable specification number. For those CIs not governed by a
specification, the word "NONE" shall be entered in this column.

5\) Acceptance test procedure number and, if qualification tested, the
qualification test procedure number. If the CI is neither acceptance nor
qualification tested, the functional test procedure number should be
entered in this column.

> c\. For each CSCI listed the following information shall be provided:

1\) Assigned CSCI Number.

2\) The CSCI nomenclature.

3\) The applicable specification number. For those CSCIs not governed by
a specification, the word "NONE" shall be entered in this column.

4\) Acceptance test procedure number and, if qualification tested, the
qualification test procedure number. If the CSCI is neither acceptance
nor qualification tested, the functional test procedure number should be
entered in this column.

d\. This list shall be prepared in the contractor's format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-9 Instrument design specification

3\. [Reference:]{.underline}

SOW 4.1

4\. [Use:]{.underline}

To ensure that the Instrument design requirements flow correctly from
the OLI Requirements Document.

5\. [Preparation Information:]{.underline}

The Instrument Design Specification shall delineate the design for the
OLI Instrument that flows from the OLI Requirements Document. It shall
establish the top-level interface specification(s) placed on the
Instrument that flows from the OLI to Spacecraft Interface Control
Document.

The lower level Instrument subsystem level specifications shall be
directed and controlled by the Instrument Design Specification. This
specification shall divide and allocate the design responsibilities and
interfaces between all of the elements of the Instrument.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-10 Focal Plane Array Documentation

3\. [Reference:]{.underline}

SOW 4.2.4

4\. [Use:]{.underline}

To provide insight into the focal plane array (FPA) design and
development.

5\. [Preparation Information:]{.underline}

Delivered FPA documentation shall consist of:

1\. FPA delivery schedule

> \- at a minimum, include start times and durations of design effort,
> manufacturing effort, Engineering Model effort, qualification, and
> testing

2\. Manufacturing plan

\- at a minimum, include processes to be used and their heritage, parts
to be manufactured or purchased, number of lots to be processed, parts
assembly plan and procedure

3\. Qualification plan

> \- at a minimum, include criteria for screening candidate chip
> assemblies, number of qualification test units, environmental testing
> criteria, pull test criteria, electrical test criteria, and
> accept/reject criteria for all qualification tests

4\. Test plan

a\. What is to be tested, what tests are to be run, at what stage, and
to what test level.

b\. Test objectives

c\. Test Methods

d\. Required configuration for each test

e\. Test Equipment

f\. Test Instrumentation

g\. Environmental and/or other conditions to be maintained, including
contamination controls

h\. Expected results

i\. Test analysis method(s)

j\. Accept/Reject Criteria

k\. Test Termination Procedure

l\. data archival location

5\. Qualification procedures

\- At a minimum, include nature of qualification units, qual tests, qual
levels, and pass/fail criteria.

6\. Test procedures

\- At a minimum include test set-up and validation, test sequence, test
data format, test criteria, pass/fail criteria, raw data storage

7\. FPA acceptance test results

\- At a minimum, include FPA performance requirements versus recorded
FPA performance prior to acceptance of each FPA deliverable from the FPA
vendor.

8\. FPA design specification

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-11 Instrument Interface Information

3\. [Reference:]{.underline}

SOW 2.2.1

4\. [Use:]{.underline}

To provide inputs to the prospective spacecraft vendor trade studies
related to instrument interfaces.

5\. [Preparation Information:]{.underline}

The current best estimates of the following information, at a minimum,
is required:

a.  Pointing budgets and allocations, including estimated required
    spacecraft allocations

b.  Power, average and peak

c.  Thermal fields of view and

d.  Volume, including swept volumes of any deployables or apertures

e.  Fields of View, including instrument aperture, thermal radiators,
    any others

f.  High speed data interface

g.  Data rates, compression, and format

h.  Mass

i.  Lunar and solar calibration spacecraft requirements

j.  Observatory level instrument testing

Margins included in any estimates will be provided.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-12 Specification tree

3\. [Reference:]{.underline}

SOW 2.3

4\. [Use:]{.underline}

To provide a reference for contractor's specification breakout.

5\. [Preparation Information:]{.underline}

The specification tree shall document the breakout of the contractor's
specifications starting at the top-level Instrument Design
Specification, showing all lower-level specifications to the
sub-assembly (box/board) level, and indicating the relationships and
interfaces between the documents.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-13 Inputs to OLI to Spacecraft interface control document

3\. [Reference:]{.underline}

SOW 4.1.3

LDCM Interface Requirements Document

4\. [Use:]{.underline}

To establish interface definition and control between the OLI and the
LDCM spacecraft.

5\. [Preparation Information:]{.underline}

This document shall provide detailed information regarding the interface
of the OLI instrument to the LDCM spacecraft.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-14 Instrument Concept of Operations Document

3\. [Reference:]{.underline}

SOW 4.3.1

4\. [Use:]{.underline}

To provide information on the instrument Concept of Operations derived
from unique aspects of the Contractor's design.

5\. [Preparation Information:]{.underline}

The LDCM Space Segment Operations Concept Document shall describe the
methodology required to operate the instrument. Relative to the
contractors design (including any and all unique features) the
operations concepts shall address:

a)  Instrument operational environment and limitations

b)  Operational requirements over and above existing instrument
    requirements necessary to accommodate design unique factors

c)  Unique ground command and data handling operations

d)  User support operations

e)  Contingency and emergency instrument unique operational scenarios.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-15 OLI to TIRS Interface Control Document

3\. [Reference:]{.underline}

SOW 2.2

4\. [Use:]{.underline}

To control and document the interface of the OLI to the Thermal Infrared
Sensor (TIRS).

5\. [Preparation Information:]{.underline}

TBD

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-16 Structural and Dynamic Models and Model Verification Plan

3\. [Reference:]{.underline}

SOW 4.1.1.6

4\. [Use:]{.underline}

To provide test verified mathematical models that represent the static
and dynamic structural characteristics of the instrument and can be
utilized with other data to predict structural accelerations,
deflections and internal loads.

5\. [Preparation Information:]{.underline}

A.  [Structural and Dynamic Mathematical Models and
Documentation]{.underline}

The contractor shall develop and document test-verified mathematical
structural models of the OLI instrument in the launch configuration.
These shall include a structural finite element model and a dynamic
model in Craig-Bampton form, developed, verified, and documented as
described below. The finite element model shall represent the structural
and dynamic characteristics of the instrument. Interface degrees of
freedom shall be compatible with corresponding attachment degrees of
freedom on the model of the spacecraft. The dynamics model shall be
based on the finite element structural model using standard reduction
techniques such as Guyan reduction.

The structural finite element models and dynamic models shall be
provided on electronic medium in a format acceptable to LDCM Project The
dynamic model shall be accompanied by documentation necessary for use of
the model. The test verified dynamic model shall also be delivered for
use in the verification loads cycle analyses.

The dynamic models shall:

a\. Include the entire instrument and any auxiliary equipment,

b\. Be in Craig-Bampton form with modes that represent the dynamic
characteristics of the instrument to at least 200 Hz, with all modes
through 50 Hz test verified by dynamic modal survey testing,

c\. Define dynamic degrees of freedom to allow calculation of
acceleration levels and relative deflections at critical points, and

d\. Include Load Transformation Matrices (LTM) described in the next
section.

The finite element model documentation shall include the following:

a\. A listing of the input data for the model,

b\. Model definition plots, coordinate system definition, definition of
stiffness properties, nodal mass distribution, and any other pertinent
model definition information, along with documentation of the
correlation between the modeled properties and the instrument design.

c\. Mode shapes, frequencies, modal damping, modal participation
factors, modal effective weights, orthogonality and cross orthogonality
between analytical and test modes, and all data required to demonstrate
test-verification of the models, and

d\. Characterization of all significant frequencies and mode shapes for
the instrument constrained at the mechanical interface to the
spacecraft, in addition to the constraint modes, one for each boundary
degree of freedom.

B. [LOAD TRANSFORMATION MATRICES (LTMs)]{.underline}

The Load Transformation Matrices shall be fully documented and provided
on electronic medium in a format acceptable to the LDCM Project. The
LTMs shall:

a\. Consist of influence coefficients relating selected output variables
to the associated dynamics model response variable,

b\. Include, at a minimum, all mechanical interface reaction forces at
the instrument mounting interface, and at support locations for
deployables,

c\. Include force, shear, and moment coefficients for determining
internal loads in critical structural members, and

d\. Include coefficients for determining absolute and relative
deflections of instrument internal elements.

The LTM documentation shall provide:

a\. A description of the model(s) from which the LTMs were generated,

b\. A description of each row of the LTM,

c\. Instructions for use of the LTM, including discussion of the
equations used for computing internal transient loads, and

d\. Results of standard analyses performed for verification of the LTM
(e.g., response to 1g accelerations and unit displacements at the
interface).

C. [STRUCTURAL MODEL VERIFICATION PLAN]{.underline}

In support of the development of the test-verified structural models,
the contractor shall develop a verification plan which includes:

a\. Identification of the modeling techniques and analysis programs to
be utilized,

b\. Analytical and testing techniques to be used to verify the
analytical models and, where required, plans for revising models and
repeating analyses based on verification results,

c\. A description of analyses to be performed, along with the objective,
scope, and output of each analyses, and description of testing which
will be used for model verification accompanied by associated schedules

> d\. A compilation of required loads interface data (e.g., loads to
> components or deployables, or loads from spacecraft, etc.), and a
> schedule of need dates.

[SPECIAL PREPARATION INSTRUCTIONS]{.underline}

All models, simulations, and/or databases required by this DRD shall be
delivered on electronic media compatible with the hardware platform on
which it is to execute and include everything necessary to provide a
fully functioning computer model whose execution requires only
commercially available hardware and software.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-17 analysEs REPORTS

3\. [Reference:]{.underline}

SOW 4.1.1.7

SOW 4.1.4

4\. [Use:]{.underline}

To provide reports of specific analyses for review.

5\. [Preparation Information:]{.underline}

[STRUCTURAL AND MECHANICAL ANALYSIS:]{.underline}

Use: To document the analyses and data which demonstrate that all
structural and mechanical subsystem performance requirements are
satisfied.

Preparation Information:

This report shall contain the following:

Design limit loads: This data item shall define the observatory design
limit loads. The philosophy used in the derivation of the design limit
loads shall be described in detail. Factors of safety and uncertainty
factors applied to or utilized in the development of the design limits
loads shall also be addressed.

Flight loads analyses: This data item shall provide observatory flight
loads analysis data and results, for each flight loads analysis
performed either by the observatory contractor or by the launch services
provider.

Observatory alignment and stiffness: This data item shall document the
analyses, tests and test data required to verify all observatory
alignment and stiff requirements. The document shall also address
observatory mechanical design verification with respect to dynamic
interactions with the launch vehicle.

Observatory clearances: This data item shall document all observatory
critical clearances and loss of clearances, with the associated
analyses. This shall include dynamic loss of clearance between the
observatory and the launch vehicle, and between various observatory
elements. Clearance loss shall be determined for critical clearances
throughout all mission phases, including launch, on‑orbit deployments
and on‑orbit operations. Components contributing to each clearance loss,
such as manufacturing and assembly tolerances, clearance loss due to
observatory dynamics and thermal gradients, as well as observatory
insulation, harnesses and grounding provisions, shall be quantified.
Analytical and measured data used for clearance verification shall be
provided.

Mechanical performance. This data item shall fully document the tests
and analyses performed to verify the performance of the observatory
mechanisms and deployment devices. Analyses and test data used to verify
the observatory structural performance and workmanship shall also be
provided. This document shall also address any methods utilized during
fabrication and assembly which verify workmanship of the observatory
structure and mechanical components.

[STRESS ANALYSIS:]{.underline}

The contractor shall provide a detailed "hand" stress analysis and
margins of safety calculations for all components of the observatory.
Margins of Safety shall be summarized in tabular form, providing a
description of each structural element, its critical loading condition,
including thermal and mechanical loadings, failure mode, margin of
safety, and reference to the detailed analysis. Primary load-paths shall
be identified and all simplifying assumptions clearly stated. If
separate finite element models are developed for use in analyzing
structural components, these models shall also be documented and
included in the final stress report. The documentation shall also
include any parametric studies and analyses directed toward minimizing
component loads and stresses.

All important structural requirements shall be assembled and provided in
conjunction with the stress analysis report. It shall serve as the
source for design loads, stresses, deformations, margins of safety and
information which defines the structural materials such as alloy type,
strength, heat treatment, hardness, chemical treatment, finish, and
other physical properties that have an influence on structural analysis.
It shall also address the structural requirements of the launch vehicle
that are related to the observatory.

[Stress Report Updates]{.underline}

The stress analyses shall be provided to verify margins of safety using
the design coupled flight loads analysis results. The stress analyses
shall be updated and provided using the verification coupled flight
loads analysis results, to verify that modifications to the structural
models to achieve correlation with modal test data and hardware
modifications encountered during observatory manufacturing and
integration maintain positive margins of safety.

[JITTER ANALYSIS]{.underline}

[Use:]{.underline} To show that the potential sources of mechanical
disturbances from the spacecraft and Instrument have been properly
assessed and measured and that the resulting effects on the Instrument
line-of-sight stability have been analyzed to ensure that high frequency
jitter will not unacceptably degrade spatial or geometric performance.
This report will document the expected vibration environment used to
predict system performance in the Optical Analytical Model (CV-5).

Jitter Analysis Preparation Information:

Jitter Sources

1)  Instrument Jitter

> Show the expected angular jitter and linear acceleration disturbances
> created by any Instrument mechanisms or moving parts as a function of
> frequency, based on either component specifications or direct
> measurements, and mechanical analysis.

2)  Line-of-Sight Jitter

```{=html}
<!-- -->
```
a)  Line-of-Sight Sensitivity

> Provide an analysis of the combined effects of mechanical jitter from
> all spacecraft and Instrument sources on the instrument line of sight.
> Include the effects of any jitter suppressing mounting fixtures.
> Spacecraft jitter sources will be provided by the Government.

[THERMAL ANALYSIS:]{.underline}

Use: To document the thermal analyses used in the design of the
instrument. Several analysis reports are required as noted in the table
of CDRL deliverable models and reports.

Preparation Information: This document shall describe in detail the
various analysis cases (e.g., launch, transfer orbit, on-orbit, on‑orbit
hot and cold cases, etc.). This description shall include:

a\. List of all parameters and assumptions used

b\. Interrelationships between various models and how boundary
conditions are obtained

c\. Detailed calculations and descriptions of computer models and
analyses

d\. Results of final analyses including predicted thermal performance
over worst case extremes and design margins

RADIOMETRIC ANALYSIS:

TBD

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-18 Electrical Systems Requirements Document

3\. [Reference:]{.underline}

SOW 4.1.4

4\. [Use:]{.underline}

To document allowable methods and practices for electrical harnessing,
grounding, shielding, fusing and interfaces on the OLI instrument.

5\. [Preparation Information:]{.underline}

The Electrical System Requirements Document (ESRD) shall include, as a
minimum, the following information as requirements on the instrument to
guide the design of and interfaces between components on the instrument:

-   System electrical block diagram

-   System grounding design

-   Grounding practices for components, harness, blankets

-   System fusing design

-   Harness shielding

-   Power quality requirements including steady state voltage, ripple,
    transients, and inrush

-   Instrument charging requirements and design practices

-   Electrical isolation of power services, returns, and chassis

-   General electrical interface requirements

-   Breakout/Test Points

-   Connector requirements

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-19 Spare Parts Plan and list

3\. [Reference:]{.underline}

SOW 4.6

4\. [Use:]{.underline}

To review contractor's spares plan and list.

5\. [Preparation Information:]{.underline}

The Spares Parts Plan shall define and justify the contractor's position
for the spares proposed for the Instrument. This plan shall also present
the schedule and method for obtaining the spares. The Plan shall provide
a listing of Spare Parts. For the purposes of this CDRL, the contractor
should concentrate on parts that are not commonly available, or may
cause schedule problems if out of stock.

Further, this plan shall address all of the requirements of SOW
paragraph 4.6.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-20 Acceptance Data Package

3\. [Reference:]{.underline}

SOW 4.4.4

SOW 4.4

NPR 7120.6, Lessons Learned Process

4\. [Use:]{.underline}

To ensure that the deliverable contract end-items are in accordance with
contract requirements prior to Government acceptance.

5\. [Preparation Information:]{.underline}

This acceptance data package, as a minimum, shall be comprised of the
following:

A.  Contract End Item Specification

B.  As-built configuration list

C.  Hardware parts lists

D.  Hardware materials and processes lists

E.  Test Log Book (including total operating time and cycle records)

F.  Open item lists (including reasons for being open)

G.  Safety compliance data package

H.  Limited life items listings and status

I.  Environmental tests results

J.  Subsystem tests results

K.  Calibration tests results

L.  Critical parameters trend data

M.  On Orbit Performance Report

N.  Anomaly reports and FRB disposition information

Item A above, the Contract End Item Specification, establishes the
architecture, configuration, function, and performance of the OLI, and
shall address design compliance with and traceability to the OLI
Requirements Document, and other applicable requirements documents.

[]{.mark}

Item M above, the On Orbit Performance Report, shall contain the
following:

A.  Launch and early orbit operations results

B.  On-orbit checkout results, including a summary of results of each of
    the tests and verifications performed per the On Orbit
    Initialization and Validation Plan.

C.  Calibration/Validation results, including a comparison to
    observatory-level pre-launch environmental test results and
    baselines

D.  Algorithms and calibration coefficients used throughout the test
    period

E.  Onboard environmental models (magnetic field, solar ephemeris, star
    catalog)

F.  AOCS Instrument alignments, biases, scale factors, etc

G.  The onboard Orbit Determination validation results, if performed

H.  Anomalous behavior and resolution including any anomaly reports

I.  Current Status of the LDCM Observatory, including redundancy

J.  Lessons learned

A copy of this package shall accompany each end item, in addition to the
delivery requirements in Table 3-1.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-21 Instrument SIMULATOR Specification

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

The Instrument Simulator Specification establishes the design parameters
required to meet the functionality required of the Instrument Simulator.

5\. [Preparation Information:]{.underline}

> The Instrument Simulator Specification shall contain at a minimum the
> following items:
>
> All Instrument Simulator design parameters necessary to meet the
> Instrument Simulator requirements established in the OLI Requirements
> Document.
>
> All design parameters relating to:
>
> Simulator external interfaces to the spacecraft simulator
>
> Simulator internal interfaces
>
> Fault detection and handling
>
> Modes of operation of the Simulator
>
> Simulator displays
>
> Allowable data types and data conversions
>
> Simulator alerts and warnings
>
> Access control requirements.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-22 Instrument SIMULATOR Users Guide

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

The Instrument Simulator User's Guide describes the operation of the
Instrument Simulator for use by operators and the software maintenance
team.

5\. Preparation Information:

[]{.mark}

The Instrument Simulator User's Guide shall contain the information
required to use the software, including detailed procedures and
functionalities. It shall show a screen-shot of all Instrument Simulator
Graphical User Interfaces (GUIs) and detail the usage of each GUI. It
shall give detailed descriptions of major functionality provided by the
Instrument Simulator, then give step-by-step instructions (with the use
of the screen-shots) on how to use the Instrument Simulator to achieve
these functionalities. The Instrument Simulator User's Guide shall
detail the various modes of operation based on access control, and show
screen-shots indicating the difference in screen activations based on a
user's role.

The Instrument Simulator User's Guide shall give a list of all alerts or
notifications produced by the Instrument Simulator along with their
meanings.

The Instrument Simulator User's Guide shall indicate how to start the
simulator, including cold and warm starts if applicable.

The Instrument Simulator User's Guide shall indicate recovery methods in
cases of irrevocable errors or faults.

The Instrument Simulator User's Guide shall indicate data types expected
within each field of each GUI.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-23 Instrument SIMULATOR INTERFACE Verification Report

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

To document how each interface requirement of the OLI to Spacecraft ICD
and the OLI to TIRS ICD is simulated by the Instrument Simulator.

5\. Preparation Information:

The Instrument Simulator Interface Verification Report shall document
how each interface of the OLI to Spacecraft ICD and the OLI to TIRS ICD
is simulated by the Instrument Simulator and the results of the
verification of the simulation of each of these interfaces.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-24 Instrument SIMULATOR Test Plan

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

The Instrument Simulator Test Plan describes test activities planned for
the Instrument Interface Simulator.

5\. Preparation Information:

[]{.mark}

The Instrument Simulator Test Plan shall:

1.Describe the test activities associated with the Instrument Simulator
in detail along with expected outcomes and results. It lists the
executables under test, describes the test environment in detail (so
that tests may be duplicated) and the specific version of the
executables under test.

2\. List and describe the utilities and tools needed or recommended to
setup the environment, load the database, convert output data into
readable reports, generate test data, etc.

3\. List the test cases to be run on each executable in the subsystem.

4\. Indicate the input data to be used for each test case along with the
location of the data, whether in a flat file or database table.

5\. Indicate the name and location of output files used to verify the
outcome of each test case.

6\. Indicate any and all errors/defects found in the course of running
each test case.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-25 Instrument SIMULATOR Software Test Reports

3\. [Reference:]{.underline}

SOW 4.1.3.1

[4. Use:]{.underline}

Provide summary of the Instrument Simulator software test results.

5\. [Preparation Information:]{.underline}

These reports shall be developed for each test described in the Software
Test Plan and shall include the following, as a minimum:

1.  Version number of software tested

2.  Identity and number of planned tests that have been completed

3.  Conformance of test results to expected results

4.  Number, type, and criticality of discrepancies

5.  Identification of software areas tested

6\. Analysis of any performance

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-26 Instrument Interface SIMULATOR Specification

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

The Instrument Interface Simulator Specification establishes the design
parameters required to meet the functionality required of the Instrument
Interface Simulator.

5\. [Preparation Information:]{.underline}

> The Instrument Interface Simulator Specification shall contain at a
> minimum the following items:
>
> All Instrument Interface Simulator design parameters necessary to meet
> the Instrument Simulator requirements established in the OLI
> Requirements Document.
>
> All design parameters relating to:
>
> Interface Simulator external interfaces to the spacecraft
>
> Interface Simulator internal interfaces
>
> Fault detection and handling
>
> Modes of operation of the Interface Simulator
>
> Interface Simulator displays
>
> Allowable data types and data conversions
>
> Interface Simulator alerts and warnings
>
> Access control requirements.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-27 Instrument Interface SIMULATOR Users Guide

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

The Instrument Interface Simulator User's Guide describes the operation
of the Instrument Interface Simulator for use by the spacecraft
contractor and the Government TIRS provider.

5\. Preparation Information:

[]{.mark}

The Instrument Interface Simulator User's Guide shall contain the
information required to use the Interface simulator, including detailed
procedures and functionalities. It shall show a screen-shot of all
Instrument Interface Simulator Graphical User Interfaces (GUIs) and
detail the usage of each GUI. It shall give detailed descriptions of
major functionality provided by the Instrument Simulator, then give
step-by-step instructions (with the use of the screen-shots) on how to
install and use the Instrument Interface Simulator to achieve these
functionalities. The Instrument Interface Simulator User's Guide shall
detail the various modes of operation based on access control, and show
screen-shots indicating the difference in screen activations based on a
user's role.

The Instrument Interface Simulator User's Guide shall give a list of all
alerts or notifications produced by the Instrument Simulator along with
their meanings.

The Instrument Interface Simulator User's Guide shall indicate how to
start the simulator, including cold and warm starts if applicable.

The Instrument Interface Simulator User's Guide shall indicate recovery
methods in cases of irrevocable errors or faults.

The Instrument Interface Simulator User's Guide shall indicate data
types expected within each field of each GUI.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-28 Instrument Interface SIMULATOR INTERFACE Verification Report

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

To document the resluts of each interface verification of the OLI to
Spacecraft ICD and the OLI to TIRS ICD is simulated by the Instrument
Interface Simulator.

5\. Preparation Information:

The Instrument Interface Simulator Interface Verification Report shall
document the results of each verification (test, demonstration,
analysis, inspection) of the simulation of the interfaces between the
OLI and the spacecraft and between the OLI and TIRS.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-29 Instrument Interface SIMULATOR INTERFACE Verification Plan

3\. [Reference:]{.underline}

SOW 4.1.3.1

4\. [Use:]{.underline}

To document the plan for verifying how each interface requirement of the
OLI to Spacecraft ICD and the OLI to TIRS ICD is simulated by the
Instrument Interface Simulator.

5\. Preparation Information:

The Instrument Interface Simulator Interface Verification Plan shall
documentthe plan for verifying each interface of the OLI to Spacecraft
ICD and the OLI to TIRS ICD by the Instrument Interface Simulator.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-30 Instrument Interface SIMULATOR Software Test Reports

3\. [Reference:]{.underline}

SOW 4.1.3.1

[4. Use:]{.underline}

Provide summary of the Instrument Interface Simulator software test
results.

5\. [Preparation Information:]{.underline}

These reports shall be developed for each test described in the Software
Test Plan and shall include the following, as a minimum:

6.  Version number of software tested

7.  Identity and number of planned tests that have been completed

8.  Conformance of test results to expected results

9.  Number, type, and criticality of discrepancies

10. Identification of software areas tested

6\. Analysis of any performance

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-31 OLI Performance Margin Analysis

3\. [Reference:]{.underline}

SOW 2.1

[4. Use:]{.underline}

Provide analyses conducted to perform Beginning of Life to End of Life
performance degradation estimates.

5\. [Preparation Information:]{.underline}

**SYSTEMS ASSURANCE DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-1 Quality Manual/Systems Assurance Plan

3\. [Reference/Related Documents:]{.underline}

MAR 2.1

MAR 5.1

ANSI/ISO/ASQC Q9001:1994, ANSI/ISO/ASQC Q9001:2000, SAE AS9100 and ISO
10013.

4\. [Use:]{.underline}

Documents the developer's QMS.

5\. [Preparation Information:]{.underline}

Prepare a Quality Manual addressing all applicable requirements of
relevant quality standard (see above related documents). Refer to ISO
10013 for further guidelines on the preparation of a quality manual.

The Quality Manual shall contain:

a.  The title, approval page, scope and the field of application.

b.  A table of contents.

c.  Introductory pages about the organization concerned and the manual
    itself.

d.  The quality policy and objectives of the organization.

e.  The description of the organization, responsibilities and
    authorities, including the organization responsible for the EEE
    parts, materials, reliability, safety, and test requirements
    implementation.

f.  A description of the elements of the quality system, developer
    policy regarding each element and developer implementation procedure
    for each clause or reference(s) to approved quality system
    procedures. System level procedures shall address the implementation
    of all requirements cited in this document.

g.  A definitions section, if appropriate.

h.  An appendix for supportive data, if appropriate.

Quality Manual distribution and changes shall be implemented by a
controlled process. The Quality Manual shall be maintained/updated by
the developer throughout the life of the contract.

The Systems Assurance Plan must define how each of the MAR requirements
will be met. The developer is encouraged to make use of in house
procedures to the maximum extent provided they are approved by GSFC.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-2 Problem Failure Reports (PFRs)

3\. [Reference/Related Documents:]{.underline}

MAR 2.3

4\. [Use:]{.underline}

To report failures promptly to the FRB for determination of cause and
corrective action.

5\. [Preparation Information:]{.underline}

Reporting of failures shall begin with the first power application at
the start of end item acceptance testing of the major component,
subsystem, or instrument level (as applicable to the hardware level for
which the developer is responsible) or the first operation of a
mechanical item. It shall continue through formal acceptance by the GSFC
Project Office and the post-launch operations, commensurate with
developer presence and responsibility at GSFC and launch site
operations.

All failures shall be documented on existing developer PFR form, which
shall identify all relevant failure information. PFRs and updated
information shall be submitted to GSFC by hard copy or in electronic
format. PFRs submitted to the GSFC for closure include a copy of all
referenced data and shall have had all corrective actions accomplished
and verified.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-3 System Safety Program Plan

3\. [Reference/Related Documents:]{.underline}

MAR 3.3

4\. [Use:]{.underline}

The approved plan provides a formal basis of understanding between the
GSFC Code 302 and the developer on how the System Safety Program will be
conducted to meet the applicable launch range safety requirements (ELV
launch). The approved plan shall account for all contractually required
tasks and responsibilities on an item-by-item basis.

5\. [Preparation Information:]{.underline}

The SSPP shall describe in detail tasks and activities of system safety
management and system safety engineering required to identify, evaluate,
and eliminate and control hazards, or reduce the associated risk to an
acceptable level throughout the system life cycle.

Provide a detailed SSPP to describe how the project will implement a
safety program in compliance with launch range requirements. Integration
of system/facility safety provisions into the SSPP is vital to the early
implementation and ultimate success of the safety effort. The SSPP
shall:

a.  Define the required safety documentation, applicable documents,
    associated schedules for completion, roles and responsibilities on
    the project, methodologies for the conduct of any required safety
    analyses, reviews, and safety package.

b.  Provide for the early identification and control of hazards to
    personnel, facilities, support equipment, and the flight system
    during all stages of project development including design,
    fabrication, test, transportation and ground activities.

c.  Ensure the program undergoes a safety review process that meets the
    requirements of NASA-STD-8719.8, "Expendable Launch Vehicle Payloads
    Safety Review Process Standard." Address compliance with the system
    safety requirements of range requirements.

d.  Address compliance with the baseline industrial safety requirements
    of the institution, range safety, applicable Industry Standards to
    the extent practical to meet NASA and OSHA design and operational
    needs (i.e. NASA STD 8719.9, "Std. for Lifting Devices and
    Equipment"), and any special contractually imposed mission unique
    obligations (including applicable safety requirements).

e.  Address the software safety effort to identify and mitigate
    safety-critical software products in compliance with
    NASA-STD-8719.13 "NASA Software Safety Standard."

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-4 Preliminary Hazard Analysis

3\. [Reference/Related Documents:]{.underline}

MAR 3.3.1

AFSCM 91-710, "Range Safety User Requirements"\
NPR 8715.3, "NASA Safety Manual"\
MIL-STD-882, "System Safety Program Requirements" (provides guidance)

4\. [Use:]{.underline}

The developer shall perform and document a Preliminary Hazard Analysis
(PHA) to identify safety critical areas, to provide an initial
assessment of hazards, and to identify requisite hazard controls and
follow-on actions. Safety provisions and alternatives needed to
eliminate hazards or reduce their associated risk to a level acceptable
to Office of Systems Safety and Mission Assurance (OSSMA) GSFC.

5\. [Preparation Information:]{.underline}

Perform and document a PHA, based on the hazard assessment criteria
provided in Chapter 3 of NPR 8715.3, and AFSCM 91-710, "Range Safety
User Requirements" to obtain an initial risk assessment of the system.
Based on the best available data, including mishap data (if assessable)
from similar systems and other lessons learned, hazards associated with
the proposed design or function shall be evaluated for hazard severity,
hazard probability, and operational constraint. Safety provisions and
alternatives needed to eliminate hazards or reduce their associated risk
to an acceptable level shall be included. The PHA shall consider the
following for identification and evaluation of hazards at a minimum:

a.  Hazardous components.

b.  Environmental constraints including the operating environments.

c.  Operating, test, maintenance, built-in-tests, diagnostics, and
    emergency procedures.

d.  Facilities, real property installed equipment, support equipment.

e.  Safety related equipment, safeguards, and possible alternate
    approaches.

f.  Safety related interface considerations among various elements of
    the system. This shall include consideration of the potential
    contribution by software to subsystem/system mishaps. Safety design
    criteria to control safety-critical software commands and responses
    shall be identified and appropriate action taken to incorporate them
    in the software (and related hardware) specifications.

g.  Malfunctions to the system, subsystems, or software. Each
    malfunction shall be specified, the causing and resulting sequence
    of events determined, the degree of hazard determined, and
    appropriate specification and/or design changes developed.

Additionally, the PHA shall include a system description and a
description of the methodology used to develop the analysis.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-5 Operations Hazard Analysis

3\. [Reference/Related Documents:]{.underline}

MAR 3.3.2

540-PG-8715.1.1, "Mechanical Systems Division Safety Manual -- Volume
I"\
540-PG-8715.1.2, "Mechanical Systems Division Safety Manual -- Volume
II"

NPR 8715.3, "NASA Safety Manual"

4\. [Use:]{.underline}

The operations hazard analysis (OHA) shall consider safety requirements
for personnel, procedures, and equipment used during testing,
transportation, storage, and integration operations in the 7/10/15/29
complex at GSFC. An engineering design analysis shall be accomplished
for review and for developing recommendations concerning system
integration and test operations.

5\. [Preparation Information:]{.underline}

The OHA shall include the following information:

1.  Introduction

```{=html}
<!-- -->
```
a.  Provide an abstract summarizing the major findings of the analysis
    and the proposed corrective or follow-up actions.

b.  Define any special terms, acronyms, and/or abbreviations used.

```{=html}
<!-- -->
```
2.  System Description

```{=html}
<!-- -->
```
a.  Provide a description of the system hardware and configuration. List
    components of subsystems.

b.  The most recent schedules for integration and testing of the
    instrument/SC.

c.  Photographs, diagrams, and sketches should be included to support
    the test.

```{=html}
<!-- -->
```
3.  Analysis of System Hazards

```{=html}
<!-- -->
```
a.  The analysis shall identify all real or potential hazards presented
    to personnel, equipment, and property during I&T processing.

b.  A listing of all identified hazards shall be provided in a tabulated
    format. Each hazard shall be numbered and shall include the
    following information:

    1.  System Component/Phase. The particular phase/component that the
        analysis is concerned with. This could be a system, subsystem,
        component, operating/maintenance procedure or environmental
        condition.

    2.  System Description and Hazard Identification, Indication.

        a.  A description of what is normally expected to occur as the
            result of operating the component/subsystem or performing
            the operating/maintenance action.

        b.  A complete description of the actual or potential hazard
            resulting from normal actions or equipment failures.
            Indicate whether hazard will cause personnel injury and/or
            equipment damage.

        c.  A description of crew indications which include all means of
            identifying the hazard to operating or maintenance
            personnel.

        d.  A complete description of the safety hazards of software
            controlling hardware systems where the hardware effects are
            safety critical.

    3.  Effect on System. The detrimental results an uncontrolled hazard
        could inflict on the whole system.

    4.  Risk Assessment. A risk assessment for each hazard as defined in
        paragraph shall be provided.

    5.  Caution and Warning Notes. A complete list of specific warnings,
        cautions, procedures required in operating and maintenance
        manuals, training courses, and test plans.

    6.  Status/Remarks.

        a.  The status of actions to implement the recommended, or
            other, hazard controls.

        b.  Any information relating to the hazard, not covered in the
            other blocks, for example, applicable documents, previous
            failure data in similar systems, or administrative
            directions.

```{=html}
<!-- -->
```
4.  References. List all pertinent references such as test reports,
    preliminary operating and maintenance manuals, and other hazard
    analysis.

5.0 Appendices. The appendix will contain charts, graphs, or data which
are too cumbersome for inclusion in the previous sections, or are
applicable to more than one section. It may also contain detailed
formulation or analysis which is more conveniently placed in an
appendix.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-6 Safety Requirements Compliance Checklist

3\. [Reference/Related Documents:]{.underline}

MAR 3.4

AFSCM 91-710, "Range Safety User Requirements Manual"

4\. [Use:]{.underline}

The operations hazard analysis (OHA) shall consider safety requirements
for personnel, procedures, and equipment used during testing,
transportation, storage, and integration operations in the 7/10/15/29
complex at GSFC. An engineering design analysis shall be accomplished
for review and for developing recommendations concerning system
integration and test operations.

5\. [Preparation Information:]{.underline}

A compliance checklist of all design, test, analysis, and data submittal
requirements shall be provided.

The following items are included with a compliance checklist.

a.  Criteria/requirement.

b.  System.

c.  Compliance

d.  Noncompliance.

e.  Not applicable.

f.  Equivalent Level of Safety (ELS)

g.  Resolution.

h.  Reference.

i.  Copies of all Range Safety approved non-compliances, including
    waivers and equivalent levels of safety certifications.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-7 Reliability Program Plan

3\. [Reference/Related Documents:]{.underline}

MAR

4\. [Use:]{.underline}

TBD

5\. [Preparation Information:]{.underline}

TBD

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-8 Safety Assessment Report

3\. [Reference/Related Documents:]{.underline}

MAR

AFSCM 91-710, "Range Safety User Requirements Manual"

4\. [Use:]{.underline}

The Safety Assessment Report (SAR) is used to document a comprehensive
evaluation of the mishap risk being assumed prior to the testing or
operation of an instrument or subsystem not being developed by the SC
contractor. The SAR will be provided to the SC contractor as an input to
their preparation of the MSPSP, which is one of the media through which
missile system prelaunch safety is obtained.

5\. [Preparation Information:]{.underline}

The SAR will identify all safety features of the hardware, software, and
system design as well as procedural, hardware, and software related
hazards that may be present in the system being acquired. This includes
specific procedural controls and precautions that shall be followed. The
safety assessment will summarize the following information:

1)  The safety criteria and methodology used to classify and rank
    hazards and any assumptions upon which they were based or derived,
    including the definition of acceptable risk (as specified by Range
    Safety).

2)  The results of those analyses and tests performed to identify
    hazards inherent in the system, including:

    a.  Those hazards that still have a residual risk and the actions
        taken to reduce the associated risk to a level contractually
        specified as acceptable

    b.  Results of tests conducted to validate safety criteria,
        requirements, and analyses

3)  Hazard reports documenting the results of the safety program
    efforts, including a list of all significant hazards, including
    specific safety recommendations or precautions required to ensure
    safety of personnel, property, or the environment. NOTE: List
    categorization shall denote whether the risks may be expected under
    normal or abnormal operating conditions.

4)  Any hazardous materials generated by or used in the system.

5)  The conclusion, with signed statement, that all identified hazards
    have been eliminated or their associated risk has been controlled to
    acceptable levels, and the system is ready to test, operate, or
    proceed to the next phase.

6)  In order to aid the SC developer/observatory integrator in
    completing an orbital debris assessment, it is necessary to identify
    any stored energy sources (e.g., pressure vessels, batteries, etc.)
    that can be passivated at end of life.

7)  Recommendations applicable to hazards at the interface of Range User
    systems with other systems.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-9 Verification Tracking Log

3\. [Reference/Related Documents:]{.underline}

MAR

AFSCM 91-710, "Range Safety User Requirements Manual"

4\. [Use:]{.underline}

To provide a Hazard Control and Verification Tracking process, or
"closed-loop system," to assure safety compliance has been satisfied in
accordance to applicable launch range safety requirements.

5\. [Preparation Information:]{.underline}

Provide documentation that demonstrates the process of verifying the
control of all hazards by test, analysis, inspection, similarity to
previously qualified hardware, or any combination thereof. All
verifications listed on the hazard reports shall reference the
tests/analyses/inspections. Results of these tests/analyses/inspections
shall be available for review and submitted in accordance with the
contract schedule and applicable launch site range safety requirements.

The VTL shall contain the following information in tabular format:

a.  Log

b.  Hazard report number

c.  Safety verification number

d.  Description (Identify procedures/analyses by number and title)

e.  Constraints on Launch Site Operations

f.  Independent Verification Required (i.e., mandatory inspection
    points)? Yes/No

g.  Scheduled completion date

h.  Completion date

i.  Method of Closure

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-10 Ground Operations Procedures

3\. [Reference/Related Documents:]{.underline}

MAR

AFSCM 91-710, "Range Safety User Requirements Manual"\
KNPR 8715.3, "KSC Safety Practices Procedural Requirements"

NPR 8715.3, "NASA Safety Manual"

Note: Other launch vehicle and/or contractor or commercial facility
requirements may apply.

4\. [Use:]{.underline}

All hazardous ground operations procedures to be used at developer
facilities, other integration facilities, or the launch site shall be
submitted to the GSFC Project Safety Manager for review.

.

5\. [Preparation Information:]{.underline}

All hazardous operations, as well as the procedures to control them,
shall be identified and highlighted. All launch site procedures shall
comply with the applicable launch site safety regulations.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-11 Safety Variances

3\. [Reference/Related Documents:]{.underline}

MAR\
AFSCM 91-710, "Range Safety User Requirements Manual"\
KNPR 8715.3, "KSC Safety Practices Procedural Requirements"\
NASA Problem Reporting/Problem Failure Reporting Module Web-based Online
System

4\. [Use:]{.underline}

The hardware developer shall submit to GSFC Code 302 an associated
safety noncompliance request that identifies the hazard and shows the
rationale for approval of noncompliance when a specific safety
requirement cannot be met, as defined in the applicable launch site
safety regulation. Range Safety concurrence may be required for the
noncompliance request to be approved..

5\. [Preparation Information:]{.underline}

The noncompliance request shall include the following information
resulting from a review of each waiver or deviation request.

a.  A statement of the specific safety requirement and its associated
    source document name and paragraph number, as applicable, for which
    a waiver or deviation is being requested.

b.  A detailed technical justification for the exception.

c.  Analyses to show the mishap potential of the proposed alternate
    requirement, method, or process, as compared to the specified
    requirement.

d.  A narrative assessment of the risk involved in accepting the waiver
    or deviation. When it is determined that there are no hazards, the
    basis for such determination shall be provided.

e.  A narrative on possible ways of reducing hazard severity and
    provability, and existing compliance activities (if any).

f.  Starting and expiration date for waiver/deviation.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-12 Orbital Debris Assessment

3\. [Reference/Related Documents:]{.underline}

MAR\
NPD 8710.3, "NASA Policy for Limiting Orbital Debris Generation"\
NSS 1740.14, "Guidelines and Assessment Procedures for Limiting Orbital
Debris"

4\. [Use:]{.underline}

Ensure NASA requirements for post mission orbital debris control are
met.

5\. [Preparation Information:]{.underline}

The assessment shall be done in accordance with NSS 1740.14. The
preliminary debris assessment shall be conducted to identify areas where
the program or project might contribute debris, and to assess this
contribution relative to the guidelines in so far as feasible. Prior to
CDR another debris assessment shall be completed. This report shall
comment on changes made since the preliminary report. The level of
detail shall be consistent with available information of design and
operations. When design changes are made after CDR that impact the
potential for orbital debris generation, the updated of the debris
assessment report shall be prepared, approved, and coordinated with the
Office of System Safety and Mission Assurance.

Orbital Debris Assessment Software is available for download from JSC
at:\
http://sn-callisto.jsc.nasa.gov/mitigate/das/das.html

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-13 Probabilistic Risk Assessment Inputs

3\. [Reference/Related Documents:]{.underline}

MAR\
NPR 8705.4, "Risk Classification for NASA Payloads"\
NPR 8705.5, "Probabilistic Risk Assessment Procedures for NASA Programs
and Projects"

4\. [Use:]{.underline}

Probabilistic Risk Assessments (PRAs) provide a structured, disciplined
approach to analyzing system risk to enable management decisions that
ensure mission success, improve safety in design, operation maintenance
and upgrade, improve performance, and reduce design, operation, and
maintenance costs.

5\. [Preparation Information:]{.underline}

The PRA prepared shall identify what types of analyses are to be
performed for each scenario and what modeling tools and techniques are
to be used (e.g., Master Logic Diagrams \[MLD\], FMEAs, FTAs, Event Tree
Analyses \[ETA\], and Event Sequence Diagrams).

The PRA inputs shall include:

a.  A definition of the objective and scope of the PRA, and development
    of end-states-of-interest to the decision maker.

b.  Definition of the mission phases and success criteria.

c.  Initiating event categories.

d.  Top level scenarios.

e.  Initiating and pivotal event models (e.g., fault trees and
    phenomenological event models).

f.  Data development for probability calculations.

g.  An integrated model and quantification to obtain risk estimates.

h.  An assessment of uncertainties.

i.  A summary of results and conclusions, including a ranking of the
    lead contributors to risk.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-14 Failure Mode and Effects Analysis

3\. [Reference/Related Documents:]{.underline}

MAR\
FAP P-302-720, "Performing a Failure Mode and Effects Analysis"\
MIL-STD-1629, "Procedures for Performing an FMECA"

4\. [Use:]{.underline}

The Failure Mode and Effects Analysis (FMEA) is a reliability analysis
to evaluate design relative to requirements, to identify single point
failures, and to identify hazards to guide preventative design actions.

5\. [Preparation Information:]{.underline}

The FMEA report shall document the reliability analysis including
approach, methodologies, results, conclusions, and recommendations. The
report shall include objectives, level of the analysis, ground rules,
functional description, functional block diagrams, reliability block
diagrams, bounds of equipment analyzed, reference to data sources used,
identification of problem areas, single-point failures, recommended
corrective action, and work sheets as appropriate for the specific
analysis being performed.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-15 Critical Items List

3\. [Reference/Related Documents:]{.underline}

MAR\
FAP P-302-720, "Performing a Failure Mode and Effects Analysis"\
MIL-STD-1629, "Procedures for Performing an FMECA"

4\. [Use:]{.underline}

The Critical Items List (CIL) provides a list of critical items, which
require the highest level of attention in design, fabrication,
verification, and problem correction during the development, handling,
and mission use of the system

5\. [Preparation Information:]{.underline}

The CIL shall include item identification, cross-reference to FMEA line
items, and retention rationale. Appropriate retention rationale may
include design features, historical performance, acceptance testing,
manufacturing product assurance, elimination of undesirable failure
modes, and failure detection methods.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-16 Fault Tree Analysis

3\. [Reference/Related Documents:]{.underline}

MAR\
NPR 8705.5, "Probabilistic Risk Assessment Procedures for NASA Programs
and Projects"

4\. [Use:]{.underline}

A fault tree is an analytical technique, whereby an undesired state of
the system is specified, and the system is then analyzed in context of
its environment and operation to find all credible ways in which the
undesired event can occur. The analysis provides a methodical approach
to understanding they system, its operation, and the environment it will
operate in. Through this understanding, informed decisions regarding
system design and operation can be made.

5\. [Preparation Information:]{.underline}

The Fault Tree Analysis (FTA) Report shall contain:

1)  Ground rules for the analysis, including definitions of the
    undesirable end states analyzed.

2)  References to documents and data used.

3)  The fault tree diagrams.

4)  Statement of the results and conclusions.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-17 Contamination Control Plan

3\. [Reference/Related Documents:]{.underline}

MAR

4\. [Use:]{.underline}

To establish contamination allowances and methods for controlling
contamination.

5\. [Preparation Information:]{.underline}

Data on material properties, design features, test data, system
tolerance of degraded performance, and methods to prevent degradation
shall be provided to permit independent evaluation of contamination
hazards. The following items shall be included in the plan:

1.  Materials

    a.  Outgassing as a function of temperature and time.

    b.  Nature of outgassing chemistry.

    c.  Areas, weight, location, and view factors of critical surfaces.

2.  Venting: size, location, and relation to external surfaces.

3.  Thermal vacuum test contamination monitoring plan, including vacuum
    test data, QCM location and temperature, pressure data, system
    temperature profile and shroud temperature.

4.  On-orbit SC and instrument performance as affected by contamination
    deposits.

    a.  Contamination effect monitor.

    b.  Methods to prevent and recover from contamination in orbit.

    c.  How to evaluate on-orbit degradation.

    d.  Photopolymerization of outgassing products on critical surfaces.

    e.  Space debris risks and protection.

    f.  Atomic oxygen erosion and re-deposition.

5.  Analysis of contamination impact on the satellite on-orbit
    performance.

DESCRIPTION OF REQUIRED DATA

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-18 Parts Control Plan (PCP)

3\. [Reference/Related Documents:]{.underline}

MAR 11.1

Parts Identification List (PIL)

4\. [Use:]{.underline}

Description of developer's approach and methodology for implementation
of the Parts Control Program.

5\. [Preparation Information:]{.underline}

The PCP will address all EEE parts program requirements. The PCP will
contain, at a minimum, detailed discussions of the following:

a.  The developer's plan or approach for conforming to the EEE parts
    requirements.

b.  The developer's parts control organization, identifying key
    individuals, and specific responsibilities.

c.  Detailed PCB procedures, to include membership, designation of
    Chairperson, responsibilities, review and approval procedures,
    meeting schedules and notification method, meeting minutes, etc.

d.  Parts tracking methods and approach, including tools to be used such
    as databases, reports, PIL, etc. Description of the system for
    identifying and tracking parts approval status.

Parts procurement, processing and testing methodology and strategies.
Identify internal operating procedures to be used for incoming
inspections, screening, qualification testing, derating, testing of
parts pulled form stores, DPA, radiation assessments, etc.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-19 Parts Identification List (PIL)/ABPL

3\. [Reference/Related Documents:]{.underline}

MAR 11.7

Parts Control Plan

4\. [Use:]{.underline}

Listing of all EEE parts intended for use in spaceflight hardware

5\. [Preparation Information:]{.underline}

The PIL/ADPL will be prepared and maintained throughout the life of the
project. They will be compiled by the developer and will include the
following information at a minimum:

a.  Part name

b.  Part number

c.  Manufacturer

d.  Manufacturer's generic part number

e.  Procurement specification

f.  GIDEP Alert status

Any format may be used, provided the required information is included.
All submissions to GSFC will be provided in an electronic spreadsheet
format, with changes from the last revision shall be clearly noted
(identified with date and revision level).\
Note: The ABPL will include the following information in addition to the
above list:

a.  Lot date code

b.  Quantities

c.  Parts use location to the sub-assembly level or reference designator

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-20 Materials and Processes Control Program Plan

3\. [Reference/Related Documents:]{.underline}

MAR

4\. [Use:]{.underline}

Description of developers approach and methodology for implementing
MPCP, including flow-down of applicable MPCP requirements to
sub-developers.

5\. [Preparation Information:]{.underline}

The MPCP shall address all M&P program requirements. The MPCP shall
contain, at a minimum, detailed discussions of the following:

a.  The developer's plan or approach for conforming to M&P requirements.

b.  The developer's M&P control organization, identifying key
    individuals and specific responsibilities.

c.  M&P tracking methods and approach, including tools to be used such
    as databases, reports, etc. Describe system for identifying and
    tracking M&P approval status.

d.  M&P procurement, processing and testing methodology and strategies.
    Identify internal operating procedures to be used for incoming
    inspections, screening, qualification testing, derating, testing of
    M&P pulled from stores, DPA, radiation assessments, etc.

e.  M&P vendor surveillance and audit plan.

f.  Electrostatic Control Plan

g.  Flow-down of MPCP requirements to sub-developers.

h.  May be part of the developer/contractor Assurance Implementation
    Plan

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-21 As-Designed/ As-Built Materials and Processes List

3\. [Reference/Related Documents:]{.underline}

MAR 12.4

4\. [Use:]{.underline}

Listing of Materials and Processes intended for use in space flight
hardware.

5\. [Preparation Information:]{.underline}

The As-Designed Materials and Processes List (ADMPL) shall be compiled
by instrument, instrument component, or SC component, and shall include
the following information at a minimum:

a.  Materials and Processes name

b.  Materials and Processes number

c.  Manufacturer

d.  Manufacturer's generic Materials and Processes number

e.  Procurement specification

Any format may be used, provided the required information is included.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-22 Parts Stress Analysis

3\. [Reference/Related Documents:]{.underline}

MAR 4.3.3

NASA Parts Selection List

4\. [Use:]{.underline}

Provides EEE parts stress analyses for evaluating circuit design and
conformance with derating guidelines. Demonstrates that environmental
operational stresses on parts comply with project derating requirements.

5\. [Preparation Information:]{.underline}

The stress analysis report shall contain:

a.  Ground rules for the analysis.

b.  References to documents and data used.

c.  Statement of the results and conclusions.

d.  Analysis worksheets, which shall include (at a minimum):

    -   Part identification (traceable to circuit diagrams)

    -   Environmental conditions assumed (consider all expected
        environments)

    -   Rated stress

    -   Applied stress (consider all significant operating parameter
        stresses at the extremes of anticipated environments)

    -   Ratio of applied-to-rated stress

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-23 Worst Case Analysis

3\. [Reference/Related Documents:]{.underline}

MAR 4.3.4

NPD 8720.1, "NASA Reliability and Maintainability (R&M) Program Policy"\
NASA-STD-8729.1, "Planning, Developing and Managing an Effective R&M
Program"

4\. [Use:]{.underline}

To demonstrate the adequacy of margin in the design of electronic and
electrical circuits, optics, and electromechanical and mechanical items.

5\. [Preparation Information:]{.underline}

These analyses shall address the worst case conditions for the analysis
performed on each component. Each analysis shall cover the mission life
and consider the critical parameters set at maximum and minimum limits,
including the effect of environmental stresses on the operational
parameters being evaluated.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-24 Limited Life Items PLAN AND List

3\. [Reference/Related Documents:]{.underline}

MAR 4.4

NPD 8720.1, "NASA Reliability and Maintainability (R&M) Program Policy"\
NASA-STD-8729.1, "Planning, Developing and Managing an Effective R&M
Program"

4\. [Use:]{.underline}

Defines and tracks the selection, use and wear of limited-life items,
and the impact on mission operations.

5\. [Preparation Information:]{.underline}

List limited-life items and their impact on mission parameters. Define
expected life, required life, duty cycles, and basis for selecting and
using the items. Include selected structures, thermal control surfaces,
solar arrays, and electromechanical devices. Atomic oxygen, solar
radiation, shelf-life, extreme temperatures, thermal cycling, wear and
fatigue are used to identify limited-life control surfaces and
structural items.

When aging, wear, fatigue, and lubricant degradation limit their life,
include batteries, compressors, seals, bearings, valves, tape recorders,
momentum wheels, hinge assemblies, drive assemblies, gyros, actuators,
and scan devices.

would require a resolution prior to launch.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SA-25 Pre-MISHAP Plan

3\. [Reference/Related Documents:]{.underline}

SOW 3.2

4\. [Use:]{.underline}

Provides a plan for procedures to be followed to respond to and control
a mishap or an emergency that may have personnel or hardware safety
implications or may cause flight or GSE hardware damage.

5\. [Preparation Information:]{.underline}

The plan shall identify the processes and procedures to be followed to
respond to and control a mishap or an emergency, as well as identify the
chain of individuals to be contacted in the event hazardous events
occur. \"Hazardous events\" include any and all situations and unplanned
happenings that have resulted in, or could have resulted in, danger or
actual harm to people, capital facilities, flight and ground equipment,
and the environment.

The Contact Plan shall ensure emergency shut-down procedures are
available and reviewed prior to the execution of each integration and
test procedure, as needed. The Government will review and approve the
plan and the contact chain. The intent of this plan is to make sure that
in the event personnel, facilities, or hardware is/are damaged or if
there is a \"close-call\", clear and simple steps are quickly taken to
ensure correct recovery actions are immediately invoked, the appropriate
Government and contractor management staff are promptly notified,
secondary or collateral damage is minimized, and corrective procedures
are ultimately implemented to avoid a recurrence.

When a hazardous event occurs, at least one Government person on the
contact chain shall be spoken to directly; text messaging, voice
messages, email, paging, written notification, and any other indirect
means shall not be acceptable forms of contact. After direct contact is
made, indirect means may be used for any others on the contact list.

**ON ORBIT DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-1 OLI On-Orbit Commissioning Plan

3\. [Reference:]{.underline}

SOW 5.4.1

4\. [Use:]{.underline}

To define how the OLI will be activated, calibrated, and tested
(functionally and performance); and how its on-orbit performance will be
verified. The Plan should include test activities, test equipment and
plans for inclusion of the Government test team.

5\. [Preparation Information:]{.underline}

The On Orbit Commissioning Plan shall be the governing document for
initialization and validation of the OLI during the pre-operational
check-out period. The plan shall include:

a\. A summary of the initialization and verification methodology

b\. A matrix or list of the OLI requirements to be verified on-orbit
which are cross-referenced to the appropriate OLI On-Orbit Test
Procedures or Calibration/Validation Procedures.

c\. A list of the calibration of attitude determination hardware and
propulsion system requirements to be verified on-orbit which are
cross-referenced to the appropriate OLI On-Orbit Test Procedures or
Calibration/Validation Procedures.

d\. The schedule of initialization and verification activities,
including start times and durations.

e\. Procedure numbers of the OLI On-Orbit Test Procedures to be used
during initialization and verification

f\. Constraints to operations

g\. The roles and responsibilities for conducting operations

h\. Contact information for operators, engineers and system support

i\. Plans for handling communications and decision-making in the event
of non-nominal results during testing. These plans shall include,
contact information for critical personnel, and identify contingency
procedures.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-2 Instrument Users manual

3\. [Reference:]{.underline}

SOW 2.3

4\. [Use:]{.underline}

The report shall be a self-contained document in that a reader not
familiar with the instrument can obtain a reasonably complete
understanding of the instrument without recourse to another document or
drawing. The document is not meant to be an engineering working document
but a reference document for LDCM Instrument data users including:
Observatory operators, Government personnel, scientists, Observatory
contractor personnel, and the general public.

5\. [Preparation Information:]{.underline}

The Instrument User's manual shall provide non-proprietary description
of the system, subsystems, functions and operations, with illustrations,
block diagrams and circuitry descriptions. The instrument to spacecraft
interface shall be described. The report shall be a self-contained
document in that a reader not familiar with the instrument can obtain a
reasonably complete understanding of the instrument and its operation
without recourse to another document or drawing. The document is not
meant to be an engineering working document but a reference document for
Government personnel, scientists, Observatory contractor personnel, and
the general public of LDCM Instrument data users.

The LDCM Instrument User's Manual shall characterize instrument
performance with respect to: relative spectral response; radiometric
accuracy, sensitivity, and stability; and line-of-sight accuracy. Each
Manual shall provide pre-flight test results characterizing performance
and a flight performance evaluation with updates at major milestones.
The document shall describe the Instrument modes of operation and the
equipment, methods, accuracies, and concepts of operation for in-flight
calibration of radiometric response and line-of-sight. The document
shall include a description of the data format and packet structure.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-3 On Orbit test ReportS

3\. [Reference:]{.underline}

SOW 5.4.1

4\. [Use:]{.underline}

For documenting the results of each on-orbit test.

5\. [Preparation Information:]{.underline}

[]{.mark}

For each test required to validate on-orbit performance, per the On
Orbit Commissioning Plan, the following information shall be reported:

a\. The requirement(s) being validated by the test

b\. Test date(s)

c\. Test procedure number used

d\. Configuration of the Observatory

e\. Expected test results

f\. Test results

g\. Any test anomalies or failures

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-4 On-Orbit Anomaly Resolution Support Plan

3\. [Reference:]{.underline}

SOW 5.4.1

4\. [Use:]{.underline}

The on-orbit anomaly resolution support plan describes the contractor's
plan for the timely identification and resolution of OLI problems and
potential problems during on-orbit operations. It also includes the plan
for collection, archival, retrieval, and trending of OLI performance
data.

5\. [Preparation Information:]{.underline}

The on-orbit anomaly resolution support plan shall include:

a\. A description of how the contractor will conduct its anomaly
identification and resolution process during launch, initialization,
commissioning, and on-orbit support phases.

b\. a description of the anomaly reporting system mechanisms for problem
identification, investigation, resolution, and formal closure.

c\. a description of the interfaces between the contractor's resolution
team to Government personnel. d. manpower support requirements,

e\. location of the resolution team, and

f\. reports/ documentation needed to ensure that the problem(s) is/are
tracked and properly resolved.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-5 OLI Launch Commit Criteria

3\. [Reference:]{.underline}

SOW 4.3.2

4\. [Use:]{.underline}

To provide a list of conditions that must be met to proceed with launch.

5\. [Preparation Information:]{.underline}

This deliverable documents the launch commit criteria and the criteria
to be used to commit the OLI instrument for launch.

This document shall include each telemetry parameter, tabulated
(cross-referenced) with its acceptable values, tolerances, and
out-of-limits conditions.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-6 telemetry and command Handbook

3\. [Reference:]{.underline}

SOW 4.3.3

4\. [Use:]{.underline}

Establishes the command and telemetry definitions for the OLI.

5\. [Preparation Information:]{.underline}

The Telemetry and Command Handbook shall be delivered in two volumes.

Volume 1 shall contain the telemetry information. This volume shall
provide at least, but not be limited to, the following:

a\. Detailed listing of all telemetry assignments and Parameter IDs.

b\. Key parameters necessary for description of the telemetry
requirements as a part of the list.

c\. Summary quantifying the number and type of telemetry assignments for
each subsystem and the number of spares remaining.

d\. Description of telemetry interfaces, telemetry format, telemetry
requirements data, and caution and warning levels.

e\. Descriptive information necessary for interpretation of the
telemetry requirements.

f\. Listing of telemetry assignments that confirm commands.

g\. Schematic reference for each telemetry assignment.

h\. Data format, to include: detailed bit definitions, command, meta and
ancillary data definitions for all telemetry and command data (command
and telemetry list), detailed data format and content of the specific
Instrument data and ancillary data files as stored on the flight data
recorder and specific detailed data formats and outputs of the flight
data recorder for Instrument and ancillary data transferred via the
Instrument mission data downlink interfaces.

Volume 2 shall contain the command information. This volume shall
provide at least, but not be limited to, the following:

a\. Detailed listing of all serial and digital commands

b\. Key parameters necessary for description of the commands as part of
this listing

c\. Summary quantifying the number of types of commands used by each
subsystem and by each unit and the number of spares remaining

d\. Description of command input, command verification, command rate and
filler (no‑op) commands.

e\. Description of command requirements data and information necessary
for interpretation.

f\. Listing of commands verified by telemetry and the telemetry
verifiers.

g\. Schematic reference for each command.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-7 OLI Launch and Early Orbit Procedures

3\. [Reference:]{.underline}

SOW 4.3.2

4\. [Use:]{.underline}

The Launch and Early Orbit Procedures are required to coordinate the
launch operation between the launch vehicle organization, the LDCM
Project, the Flight Operations Team (FOT), the Mission Operations
Element (MOE), and the Mission Operations Center (MOC).

5\. [Preparation Information:]{.underline}

The OLI Launch and Early Orbit Procedure contains OLI sequences required
for the FOT and MOE/MOC to support the OLI state of health monitoring
and operational events during the launch phase of the mission. These
procedures are applicable from launch vehicle-Observatory separation
until the LDCM Observatory is configured for on-orbit operation prior to
the start of the on-orbit system test activities.

The procedure shall include

a.  a detailed flight time line and

b.  script of each communication event including required actions and
    responses by communication stations, launch sites, FOT, and MOE/MOC

Each Procedure shall contain the following information:

a)  Procedure Purpose

b)  Procedure Methodology

c)  Support Resources Required

d)  Observatory and OLI configuration before and after the procedure is
    executed

e)  Step-by-step commands to be issued and expected OLI response after
    each step

f)  Cautions and warnings

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-8 OLI on-orbit Operations and Contingency Procedures

3\. [Reference:]{.underline}

SOW 4.3.2

4\. [Use:]{.underline}

The OLI On-Orbit Procedures document contains the complete set of
procedures required for operating the OLI following completion of
commissioning activities.

5\. [Preparation Information:]{.underline}

The OLI On-Orbit Procedures document shall provide a detailed set of
operations procedures for operating the OLI, including the Solid State
Recorder. These procedures shall include:

A. Normal on-orbit command and control operations

B. OLI State-of-Health Monitoring and management

C. OLI mode transition and mode operations

D. Contingency and recovery procedures

E. Calibration procedures

F. Instrument procedures for satellite reconfigurations

Each Procedure shall contain the following information:

a\. Procedure Purpose

b\. Procedure Methodology

c\. Support Resources Required

d\. Observatory and OLI configuration before and after the procedure is
executed

e\. Step-by-step commands to be issued and expected OLI response after
each step

f\. Cautions and warnings

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-9 OLI Training Materials

3\. [Reference:]{.underline}

SOW 4.3.4

4\. [Use:]{.underline}

The OLI Training Materials are used to train the Flight Operations Team
in the operation and functionality of the OLI.

5\. [Preparation Information:]{.underline}

> The OLI Training Material shall include training in the following
> items:

a.  OLI Operations concepts

b.  Functional description of the OLI

c.  All OLI modes of operation and functional description of the OLI

d.  OLI Procedures

e.  OLI Normal Imaging activities

f.  Describe and include execution of time lines for instrument-related
    launch, Observatory deployment, on-orbit checkout, and Observatory
    commissioning activities

g.  OLI operating constraints and rules

h.  OLI Anomaly scenarios and procedures

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-10 CONSTRAINTS, RESTRICTIONS, AND WARNINGS DOCUMENT

3\. [Reference:]{.underline}

SOW 4.3.2

4\. [Use]{.underline}:

The OLI Constraints, Restrictions, and Warnings Document provides the
operating contraints and restrictions for the OLI.

5\. **[PREPARATION INFORMATION]{.underline}**

The OLI Constraints, Restrictions, and Warnings Document shall include

a)  Operating constraints for each OLI operational mode and activity

b)  Operating restrictions for each OLI operational mode and activity

c)  Any warning conditions for OLI operational activities

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-11 Telemetry and Command Database

3\. [Reference:]{.underline}

SOW 4.3.3

4\. [Use]{.underline}:

The OLI Telemetry and Command Database will be used within the LDCM
Missions Operation Element to operate, control, and monitor the OLI.

5\. **[PREPARATION INFORMATION]{.underline}**

The OLI Telemetry and Command Database shall b e in a format/language
compatible with the Mission Operations Element and approved by the
Government. The telemetry and command database shall contain

a)  All commands required to operate, monitor, and control the OLI

b)  All telemetry parameters required to operate, monitor and control
    the OLI

c)  OLI command and telemetry identifiers

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

OO-12 OLI on-orbit TEST and CALIBRATION/VALIDATION Procedures

3\. [Reference:]{.underline}

SOW 5.4??

4\. [Use:]{.underline}

The OLI On-Orbit Test and Cal/Val Procedures document contains the set
of procedures required to conduct activation, testing, and
calibration/validation during the commissioning phase of the mission.
These procedures are unique to the activation and commissioning phase
and do not duplicate the procedures delivered under OO-8, OLI On-Orbit
Operations and Contingency Procedures.

5\. [Preparation Information:]{.underline}

The OLI On-Orbit Test and Cal/Val Procedures document shall provide a
detailed set of operations procedures for activating, testing, and
calibration/validation of the OLI. These procedures shall include:

A. OLI command and control operations

B. OLI State-of-Health Monitoring and management

C. OLI mode transition and mode operations

D. Contingency and recovery procedures

E. Calibration procedures

F. Instrument procedures for satellite reconfigurations

Each Procedure shall contain the following information:

a\. Test/Procedure Purpose

b\. OLI requirement(s) being verified

c\. Procedure Methodology

d\. Support Resources Required

e\. Observatory and OLI configuration before and after the procedure is
executed

f\. Step-by-step commands to be issued and expected OLI response after
each step

g\. Cautions and warnings