SpaceDOC

Attachment J-2

This Plan shall be included as a separate document.

Draft - Due 30 days after contract award
Preliminary — Due 60 days after contract award

Final - Due 30 days after review and comment on the preliminary plan by the CoTR or his designee

Page 20



SpaceDOC Attachment J-2

Title: DID No.: PA-11
Safety and Health Plan

Reference:
GRC Safety Manual
GRC Environmental Manual

Purpose:

To identify all hazards related to tasks to be performed at NASA Glenn Research Center and the corrective
action plan to prevent any mishaps. in addition, it should describe the process to ensure regulatory
compliance with safety and health regulations.

Related Documents:
29 CFR 1910

Preparation Information:

This document will identify the potential hazards to all employees, equipment and property while tasks are
performed at NASA Glenn Research Center. The document should provide the processes to be used to
mitigate these hazards and to prevent any mishaps while the tasks are in progress. In addition, it should
describe the process to ensure regulatory compliance with safety and health regulations. The Safety and
Health Plan will cover the contractor’s personnel and tasks and the personnel and tasks of its subcontractor's.

The contractor will provide the Safety and Health Plan as part of the submittal to the RFP. Glenn Safety
Manual, Chapter 17, Appendix A provides guidance on the contents of a safety and health plan.

Final — Due 60 days after contract award

Page 41



SpaceDOC : Attachment J-2

Title: DID No.: PA-07
Problem Report and Corrective Action (PRACA) Plan

Reference:

GRC Product Assurance Manual (PAI #440)

Space Assurance Requirements and Guidelines (SARG) - Sections 7 & 8.

Program Requirement for Payload Developers (SSP 50431)

SSP30223 ~ Problem Reporting and Corrective Action for the Space Station Program

Purpose:

Define a system to identify, control, and disposition nonconforming hardware/software and the
remedial/corrective actions taken to resolve those problems.

Related Documents:

PA-01: Product Assurance Plan

PA-13: Problem Report and Correction Action Report
V-11; _Integration Data Package

Preparation Information:

The PRACA system shall describe a documented closed-loop problem reporting system for failures and non-
conformances. The system shall include documentation of problem, traceability of material or part, disposition
of problem, root cause corrective action, segregation of discrepant material, verification of corrective action,
and trending to help prevent similar discrepancies. Describe review Process including any review boards and
the problem report tracking and distribution process. NASA shall be informed of any reportable problem within
48 hours of occurrence. :

A reportable problem is any nonconformance which is, or is suspected of being, a failure, an unsatisfactory
condition, an unexplained anomaly, or an overstress occurring during or subsequent to production acceptance
testing or qualification testing (i.e. after manufacturing or development).

The problem report should include as a minimum: 1) description of problem; 2) analysis of root cause of
problem; and 3) description of corrective action; 4) corrective action follow-up.

Note: information required as part of the Product Assurance Plan but can be submitted as a separate
document. Level 1 PRACA Reports are to be submitted for NASA approval per CDRL DID# PM-05.

Page 37



SpaceDOC Attachment J-2

Title: DID No.: PA-16
Fastener Control Plan

Reference:

Space Assurance Requirements and Guidelines (SARG)

NSTS/ISS 13830, Payload Safety Review and Data submittal Requirements
NASA STD 6017 Design And Development Requirements For Mechanisms

Purpose:
Documents the contractor’s approach to fastener control and helps the Government understand how the

contractor will comply with applicable fastener control safety requirements for space flight hardware.

Related Documents:

PA-02: System Safety Plan

PA-05: Safety Compliance Data Package .
PA-06: Materials Identification and Usage List (MIUL); Material Usage Agreement (MUA)

Preparation Information:

This document shall define the overall approach for meeting fastener contro! requirements. The plan as a
minimum shall address the following areas:

a. Acquisition/supplier control
b. Documentation

c. Traceability
d. Receiving inspection
e. Testing

Timing/Purpose: if prepared, provide 30 days before the PDR.

Page 46



SpaceDOC Attachment J-2
— —— pena
Formula Acronym — Description

PV Planned Value (value of planned milestones)
AC Actual Cost
EV Earned Value (value of completed milestones)

PV =BCWS BCWSs Budgeted Cost of Work Scheduled

AC = ACWP ACWP Actual Cost of Work Performed

EV = BCWP. BCWP. Budgeted Cost of Work Performed

EV-AC=CV$ CV$ Cost Variance

CV/EV=CV% CV% Cost Variance %

EV/ AC = CPI CPI Cost Performance Index

EV-PV=SV$ SV$ Schedule Variance

SV/EV=SV% SV% Schedule Variance %

EV/PV = SPI SPI Schedule Performance Index

3. The Contractor's Delivery Order project team shall meet monthly with the Government to review Progress against the
EVM baseline, and to assure the Contractor is effectively managing to the baseline.

Page 14


SpaceDOC Attachment J-2

Titie: DID No.: OP-01
Integrated Logistics Support (ILS) Implementation Plan

Reference:

NHB 6000.1D Requirements for Packaging, Handling, and Transportation for Space Systems
NMI 5350.1A Maintainability and Maintenance Planning Policy

SSP 50018 Space Station Packaging and Configuration Requirements

MIL-STD-1388-1A Logistics Support Analysis

SSP 50277 Payload ILS Guidelines

SSP 50431

Purpose:
Document establishes the processes and specific plans for implementation of the ILS activities during

development, testing, and operational phases. It is intended to be a blueprint for the logistics infrastructure
needed to support operations and the transfer of logistics responsibilities among Contract Exhibits.

Related Documents:

OP-04: Launch Site Operations and Test Procedures

PA-01: Product Assurance Plan

PA-08: Failure Mode and Effects Analysis (FMEA) and Critical Items List (CIL)
PA-1
PA-14:

PA-15: System Maintainability/Availability Analysis
R-01: System Requirements Document

Preparation Information:

The data provided in the plan should address the following activities as a minimum with a schedule for
accomplishment of key tasks that meet project milestones:

A. Logistics Analysis - For preliminary document, develop summary of logistics needs. For final
document, develop detailed implementation plan, describing the logistics actions needed to
transport spares (up and down) and provide temporary on-orbit storage per the maintenance
requirements of a project.

‘aesigheTM

C. Supply Support - describe the approach for the provisioning, procurement, inventory, warehousing
and distribution of all spare and repair parts. Develop database for tracking actual lists of spares,
location, and configuration, available upon onset of project operations.

D. Packaging, Handling, Storage & Transportation - describe all of the processes and special provisions

necessary to support packaging, preservation, environmental controls and monitoring equipment,

storage, handling, and transportation of flight hardware and support equipment, including spares and

repair parts.

Logistic Support Facilities and Equipment - describe all of the processes required for the identification

and acquisition of all Ground, Flight, and Orbital Support Equipment and facilities required to support

on-orbit and ground functions.

Expected Roles and Responsibilities

Technical data and documentation

Logistics Management Responsibility Transfer — between Contract Exhibits

Contractor Logistics Support (CLS) — post launch responsibilities

m

~i@m

Preliminary: for CDR
Final: for PSR

Page 74


SpaceDOC Attachment J-2

Title: DID No.: D-04
Product Drawings

Reference:
Mil-Spec DOD-D-1000B
{SO 10303 Standard for the Exchange of Product model data

Purpose:
The purpose of the product drawings is to provide to the Government a set of drawings for sustaining

engineering or archive purposes. The drawings need to be compatible with the Government standards and
interchange format.

Related Documents:

PM-04: Configuration Management Plan
D-09: Systems Configuration Document
V-13: As Built Configuration List

Preparation Information:

The product drawings shall be prepared and furnished in accordance with establish drawings standards of
1SO-9001 or Military Specification DOD-D-1000B or equivalent. Contractor code identification and
documentation numbers will be used, unless otherwise specified in the Delivery Order. An electronic version
of the drawings in PDF shall be made available to the Government unless otherwise stated in the Delivery
Order. The electronic drawing (model) shall be provided to the Government in native format, upon request. If
the Government does not have appropriate software to access the native format an equivalent DXF or STEP
interchange format will be required.

The product drawings and associated lists shall provide engineering definition sufficiently complete to enable a
competent manufacturer to produce and maintain quality control of item(s) to the degree that physical and
performance characteristics are interchangeable with those of the original design without recourse to
additional design data.

The product drawing types shall include, as applicable, parts list, detail and assembly drawings, interface
contro! data, diagrams, performance characteristics, critical manufacturing limits, and details of new materials
and processes. The product drawings shall include detail processes, i.e., not published or generally available
to industry, when essential to design and manufacture; performance ratings; dimensional and tolerance data;
critical manufacturing assembly sequences; input and.output characteristics; diagrams; mechanical and
electrical connections; physical characteristics, including form and finish; details of material identification;
inspection, test, and evaluation criteria; necessary calibration information; and quality control data.

Flight Drawings, 90% complete release drawings for CDR
Release drawings prior to any fabrication

Page 56


SpaceDOC Attachment J-2

Title: DID No.: D-02
Engineering Trade and Analysis Data

Reference:
PM-02: Risk Management Plan

Purpose:
This report documents the trades and engineering analysis performed during the design stages of the project.

Alternative approaches will be captured for possible future use during the development of the project. The
analysis data may also be required to provide the carrier and ground system teams with payload interface
data, models, and analysis needed to assist them in their designs and preparations to support the payload for
launch and mission operations.

Related Documents:
R-03: Payload Interface Agreement & Annexes

Preparation Information:

The trade study report shall contain a description of the trade studies performed and the candidate concepts
that were considered. This description shall include the trade off factors considered such as, affordability,
technology, operations, infrastructure, content, risk, and potential procurement strategies. The results of the
systems analyses and lifecycle costing analysis shall be included in this trade study report. Trade study results
of risk assessment shall be included in this report if performed.

Page 54


SpaceDOC Attachment J-2

Title: DID No.: D-07
Safety-Critical Structures Data Package
Reference:

NSTS 1700.7 “For Payloads Using the Space Transportation System"
NSTS 1700.7, ISS Addendum “Safety Policy and Requirements For Payloads Using the International Space

Station"
SSP 52005B “Payload Flight Equipment Requirements and Guidelines for Safety-Critical Structures”

PA-02: System Safety Plan

Purpose:
This document presents the results of verification activities for Safety-Critical Structures to flight hardware

safety requirements.

Related Documents:

Safety-Compliance Data Package

: Materials Identification and Usage List; Material Usage Agreement
D-11: Fracture Control Summary Report

Preparation Information:

The following provides a summary of the requirements on the content and organization of the Safety-Critical
Structures Data Package. Specific requirements are found in SSP 52005B “Payload Flight Equipment
Requirements and Guidelines for Safety-Critical Structures”

41. Introduction - a brief description of structures/components being analyzed, load environments
used for determining low frequency and random vibration loads, and the Factors of Safety used
for analysis and test.

Reference list - includes all references used in the report or identified in the body of the

report.

Mass Properties - weight, cg, mass moment of inertias used in the report shal! be documented,

including source and date (use control weights unless actual weights have been measured).

5, Materials List - List the materials used in this data package and their material properties -
modulus of elasticity (E), modulus of rigidity (G) or Poisson's Ratio (1), ultimate tensile strength
of a material (Ftu), yield tensile strength of a materia! (Fty), etc., include temperature effects if
applicable. Also state the source of the property values listed.

6. Safety-Critical Structures List - List all safety-critical structural elements, components, and
assemblies, including attachment hardware. For each structural element, this list shall state the
Part Number, quantity, material, minimum Margin of Safety, and the page number that contains

“the calculation of this Margin of Safety. Also indicate which structural elements are also.
designated as Fracture-Critical.

7. Structural Modeling Description ~ This section shall discuss the load paths, boundary conditions
and modeling philosophy. For Finite Element Models, this section shall describe the structural
element representations, mass representation, constraints and releases in the model. 3-D
views of the model shall be provided. Results of Rigid Body Mode checks shall also be
presented.

8. Dynamic Analysis Results - This section shall contain the frequencies and mode shape plots of
all system modes in the range of interest. It shall also include FEM mass participation results or
other analyses which support random vibration or acoustic load factor calculation,

9. Load Analysis Results - Describe the loads used in the model and how/why they were chosen
(i.¢., location in STS, data source, mission phase, structural attachment, and test data).

10. Stress Analysis Results - The results of a stress analysis and supporting test results shall be
documented. The stress analysis shall be clearly presented such that a structural analyst not
involved in the project would be able to understand it. The stress analysis should include the
following:

i. A sketch of each area being analyzed showing pertinent dimensions and structurally-
important details. Drawing number references should also be included. Indicate if drawings
are “as built” or "design."

ii, A free-body diagram of the structural element being analyzed.

iii,__ The source of the loads used.

PON

Page 60



SpaceDOC Attachment J-2

Title: Parts-Stress Analysis DID No.: D-10

Reference: Space Assurance Requirements and Guidelines (SARG) — Section 7
PA-02: System Safety Plan

Purpose: Parts-Stress Analysis is a design task that evaluates electrical and mechanical parts to assure that
the parts can operate at the most stressful values that result from specified performance and environmental
requirements on the system design. Supports: (1) Deliberate design practice for Safety and reliability of all
parts. (2) overall system reliability (3) elimination of part failures and increases operational life with minimal
drifting of performance outputs.

Related Documents:

SSP 50431, Space Station Program Requirements for Payloads
D-10: Safety-Critical Structures Data Package

D-12: Worst-Case Analysis

Preparation Information:

Parts-Stress Analysis General Method

Parts-Stress Analysis typically considers the different stresses, under which, a part (electrical or mechanical)
has to be operate under. These are typically, but are not limited to, temperature, voltage, current, pressure,
torque, speed, angular speed, mechanical stresses, power, vibration, shock, etc. Parts, depending upon their
design, particular application, and environmentally induced stresses can withstand various types of stress (as
a population) over some statistical distribution. In this analysis, it should be demonstrated that the parts are
rated for the types and magnitudes of stress that will be encountered.

Analysis to be completed by COR

Page 64



SpaceDOC Attachment J-2

Title: DID No.: R-05
Software Interface Control Document

Reference:

NASA STD 2100-91 (NASA Software Documentation Standard) NASA-DID-M300
NASA STD 8719.13A (Software Safety NASA Technical Standard)

IEEE 12207 Software Development Standards

Purpose:

This document provides detailed design specifications for interfaces between this software/firmware entity and
its external users as well as its internal interfaces. The purpose of the software/firmware interface detailed
design is to record the physical design information for the interfaces to the software and firmware. This
includes the data types, physical data format or layout, message descriptions, data transmissions, and
protocols and priorities

Related Documents:

D-06 Software Design Document

R-04 Software Requirements Document,
R-01 System Requirements Document

Preparation Information:
This document shall describe each external and internal interfaces for the software and/or firmware entity for

which this document is provided. Internal interfaces shall be described to the next lowest logical entity (e.g. if
this document is for a rack entity consisting of multiple CSC! entities, the external interfaces are relative to the
tack and external entities, and the internal interfaces are between the rack's CSCI entities). For each
interface, the details of the interface shall be described, including:

a. (Interface Name/Identifier) External or Internal, Type and Purpose.

b. Data Transmission Interfaces. Provide a detailed specification of the data records and elements
transmitted across the interface in such terms as: Unique identifier for each record and data
element, description and purpose of each record and data element, source and destination for each
record or single data element transmission, data type and (if appropriate) unit of measure, limit and
range of values, accuracy, precision (in terms of significant digits). If shared memory is used, then
define the purpose for the shared memory, and the shared memory location(s) used for
transmissions across the interface.

c. Message Interface Descriptions. Identify each message transmitted across the interface and specify
the assignment of data elements to each message. Provide cross references between data
elements and messages, as a two-way sorted list.

d. Interface Priority Specify the relative priority of this interface and of each message transmitted
across it.

e. Interface Communication Protocols. Identify the protocol for the interface by name and describe its
technical details in terms of the following: fragmentation and reassembly of messages, message
formatting, error control and recovery procedures, including fault tolerance features,
synchronization, including connection establishment, maintenance, termination, and timing, flow
control, including sequencing, and buffer allocation, data transfer rate, whether periodic or
aperiodic, and minimum interval between transfers, routing, addressing, and naming conventions,
transmission services, including priority and grade, status, identification, notification, and other
reporting features , security, including encryption, user authentication, compartmentalization, and
auditing

The interface design shall be traceable to interface requirements.

For recommended document outline see NASA-STD-2100-91

Page 52



SpaceDOC Attachment J-2

NASA may direct the Contractor to prepare ECPs under the “Changes” clause of the contract.

Each ECP shall be expeditiously delivered for review to minimize the impact of delays during review and
disposition of change requests. In its ECP, the Contractor shall recommend a process cycle in the context of
the complexity of the work and the specific guidelines and requirements of the Delivery Order.

Delivery of Level 1 PRACAs

The Contractor shall deliver each Level 1 Problem Report and Corrective Action (PRACA) to NASA for
approval prior to submittal to funding program. The Contractor shail develop each Level 1 PRACA (PA-07)
using their closed-loop problem reporting system in accordance with the requirements specified in SSP30223,
Problem Reporting and Corrective Action for the Space Station, or equivalent for the specific program or
similar equivalent for the associated program.

Review and Disposition

Waivers and deviations shall be handled using MIL-STD-973 as a guide. The Contractor shall establish a
Change Control Board (Engineering Change Board) to process Class II ECPs and to provide
recommendations on Class | ECPs. ECPs, Deviations, Waivers, and Level 1 PRACA Reports are provided to
NASA for approval.

Page 24



SpaceDOC Attachment J-2

Title: DID No.: PA-12
Problem Report and Corrective Action (PRACA) Report

Reference:
PA-07: Problem Report and Corrective Action Plan
SSP30223 — Problem Reporting and Corrective Action for the Space Station Program

Purpose:
To provide a report, as required, that will be used to understand the Contractor’s problem reports being

generated and to be aware of the correction actions used by the Contractor to prevent recurrence of the
problem.

Related Documents:
PM-02: Risk Management Plan
PM-05: Engineering Change Proposals, Deviations, Waivers and Level | PRACAs

Preparation Information:

The problem report should include as a minimum: 1) description of problem; 2) analysis of root cause of
problem; and 3) description of corrective action; 4) corrective action follow-up.

NASA shail be informed of any reportable problem within 48 hours of occurrence. A reportable problem is any
nonconformance which is, or is suspected of being, a failure, an unsatisfactory condition, an unexplained
anomaly, or an overstress occurring during or subsequent to production acceptance testing or qualification
testing (i.e. after manufacturing or development).

The PRACA Report will be developed in accordance with the Contractor Product Assurance Plan, Level 1
PRACA Reports shall be submitted for NASA approval per CDRL DID # PM-05

Page 42



SpaceDOC Attachment J-2

Individual On Orbit Performance Acceptance Test Procedures
Preliminary Plans are required at VRR/TRR.

Einal procedures are required at FRR/PSR.

Update Procedures as_ required prior to launch.

Final Disposition
At the Acceptance Review a summary of all the On Orbit performance data (as run On Orbit Acceptance Test
Procedures) shall be presented and the Government shall make a final disposition within 60 days of the

Acceptance Review.

Page 73


SpaceDOC

Attachment J-2

1.4.2 Deliverable Fidelity

The following defines the document fidelity used to describe the delivered product:

a) Document Formats:
1.

The NDA document is formatted as a NASA document with an appropriate cover sheet
and have a NASA approval signature entry, identifying NASA's approval signatures.
These documents shall be submitted for NASA review and approval. For NASA-formatted
documents, the cover page shall contain only the NASA logo and NASA/GRC address,
the document title and number, revision status, and the date of the document release,
unless specific guidance to deviate from that format for a particular project has been
provided by the government. NASA signature approvals will be limited to the COTR and
the applicable NASA Project Manager, unless otherwise specified in the Delivery Order
instructions.

Non-NASA Documents Requiring Government Approval, but do not require the NASA
Approval format. Identified on the CDRL as A by the corresponding DID. The NASA
signature is included on the document signature page with the following heading,
“Reviewed by and Approved”. These documents should also identify NASA involvement in
the document change process. These documents shall be submitted for NASA review and
approval. NASA signature approvals will be limited to the COTR and the applicable NASA
Project Manager, unless otherwise specified in the Delivery Order instructions.

Non-DID Items are documentation deliverables not identified in the CDRL, but are called
out in an individual delivery order and.specified as requiring NASA approval. For these
documents, the Government will provide the Contractor with DIDs or a description of the
requirement and acceptance criteria with the delivery order request. As a NASA approved
document, the document must also specify NASA's involvement in the document change
process.

b) Documents

1.

Draft: Format and structure of the document is complete. The document details are being
developed and should reflect current design/concept. To Be Determined (TBD) items are

allowed, even to the extent that an entire section can be a TBD, provided no concept has

been developed for that area.

2. Preliminary: All sections are addressed and significant detail provided. Some level of
TBDs is acceptable where data is not yet available. Whenever possible, TBDs should
include a “bracketed” value that reflects the best current thinking for a particular value or
approach. Example: TBD [120 C].

3. Final: The document is complete. TBDs are allowed only on a case-by-case basis with
approval of the Government project manager. Updates to the “final” document are
controlled and classified as document revisions.

4. Current: Documents specifically called out in the SOW or CDRL that the Contractor is
required to update periodically to reflect changes and re-submit to the Government for
review.

c) Drawings
1. Working Level: Draft drawings in the early development stage. Geometrically complete
but may be missing dimensions, labeling, and notes.
2. Baselined: A version of a design that has been established as a basis for reference, for a

specified purpose, at a specified point in time. It is controlled and traceable. A baseline
may or may not be an approved version of the design.

Page 5


SpaceDOC Attachment J-2

Title: DID No.: OP-03
Operations Plan

Reference:
NPG 7120.5A, NASA Program and Project Management Processes and Requirements

Purpose:
To describe the plan for supporting the flight operations of the payload or facility on the International Space
Station or Shuttle. Also included is the method to provide anomaly resolution support during the mission.

Related Documents:
PM-06: Contractor Delivery Order Work Plan

Preparation Information:
Operations Plan contents:

A. Description of roles and responsibilities and plans to support the operations of the payload.

B. Description and designation of any ground systems and responsibilities needed for payload
operations. Include a discussion on how they will be supplied, maintained and operated.

C. Description of overall management approach, work breakdown structure, configuration management
approach, and training approach

D. Plan for anomaly identification, investigation, and resolution process.
—. Plan for periodic performance assessments to determine payload viability.

F. Description of complement of skills needed to provide required support and method utilized by the
Contractor to provide these resources.

G. Description of ISS resources required during the operations and timeline for usage.

Page 76



SpaceDOC Attachment J-2

Title:

Operator's Manual

DID No.: OP-02

Reference:
OP-03: Operations Plan

Purpose:
The Operator's manual is an instruction and reference manual for the hardware and software user to initiate,

operates, configure, maintain, calibrate, and monitor equipment.

Related Documents:
OP-08: TSC Training Manual

Preparation Information:

Operator's Manual contents:

A.

an m oo ®

Overview of the equipment in terms of its functions, initialization, maintenance, calibration, shutdown,
and restart procedures that includes operation of all equipment subsystems.

Operation procedures and generic information such as Cadre ID, voice loop definition, phone
numbers, pages, call signs and description of operations staff functions.

Overview of equipment interfaces to other equipment.

Description of overall function of the hardware and software along with relevant information, including
all options, restrictions, and limitations.

Step-by-step procedures for performing set-up, initialization, maintenance, calibration, operation,
shutdown, restart, tear down, and replacement of the software and hardware.

Description of any unique factors associated with the operation of the equipment.

Description of inputs, including user inputs and pertinent system inputs. User inputs shall be
described in terms of commands, data, and options. System inputs include inputs that may effect the
user's utilization of the equipment.

H. Description of subsystem outputs, including their destination information.

=

ZErR

Unique system logistics, software, software maintenance, and sustaining engineering required for
sustained equipment operations.

Contingency scenarios and procedures that includes step-by-step shut-down procedures for both
normal and abnormal shut-down of a function.

Error. messages, and, corrective actions. to be, taken. by, the operate
Redundancy management.

State of health monitoring, tracking, and tie to pertinent maintenance procedures.

Listing of operations limits, cautions, and constraints, and corrective actions to be taken by operator.

Page 75



SpaceDOC Attachment J-2

Title: DID No.: OP-05

Data Delivery Plan
Reference:

Purpose:
To define the activities, methods, and schedule for obtaining, processing, evaluating the data integrity,

archiving, and delivering the science and hardware performance data.

Related Documents:
OP-02: Operator's Manual

Preparation Information:

This plan shall describe and define all aspects of the science mission evaluation and data management
requirements that include real-time requirements and the off-line activities.

Suggested content consists of:

Introduction

Mission Description and Objectives

Facility Overviews - Describe experiment hardware and data gathering equipment

End-to-End Operational Data Flow - Describe the on-board and ground data flow that will be used
during the mission.

Post Mission Data Processing - Describe the post mission data processing to be performed, where the
processing will be performed, and when those data products are to be delivered.

Archives - Define the data archives that will be used, data to be archived, length of time the data will
be stored.

Experiment/Carrier Relationship

Roles & Responsibility

ZO-TM7 m com>

Page 78


SpaceDOC Attachment J-2

Title: DID No.: PA-05
Safety Compliance Data Package

Reference:

GRC Product Assurance Manual (PAI # 210, #211)

Space Assurance Requirements and Guidelines (SARG) - Section 4.

NSTS/ISS 13830 Payload Safety Review and Data Submittal Requirements

NSTS 1700.7B plus Addendum Safety Policy & Requirements for Payloads Using STS and ISS

Purpose:
Used in conjunction with the Space Shuttle/ISS Phased Safety Review Process. Helps NASA understand how

the contractor will comply with applicable safety requirements. Used to document and defend the identification,
control, and verification of all unique safety hazards associated with the installation and operation of the
experiment in space.

Related Documents:
PA-02: System Safety Plan
PA-03: System Safety Hazard Analysis

Preparation Information:

This document will identify potential hazards for individual space flight payloads, define the approaches to be
used to control the hazards identified and establish the methods by which all hazard controls will be verified.
(Note that a Safety Compliance Data Package will be required for each flight payload deliverable (Space Shuttle,
1SS), and the contractor shall use the required reporting format required by the carrier.)

Delivered for NASA review and approval 30 days before required submittal date to NASA JSC or NASA KSC,

Page 35



SpaceDOC Attachment J-2

ie: DID No.: PM-03
Software Management and Development Plan

Reference:
GRC Software Development Manual;
NASA-STD-2100-91 NASA Software Documentation Standard (NASA-DID-MO00 through M700)

Purpose:
To establish specific software management policies, schedules and budget and define the processes and

environment by which these policies and practices will be implemented.

Related Documents:

PA-11: Software Assurance Plan
PM-01: SpaceDOC Management Pian
PM-02: Risk Management Plan

PM-04: Configuration Management Plan

Preparation Information:

The Contractor Software Management and Development Plan shall provide detailed information on relative
schedules, activities, resources, and procedures necessary for successful planning and implementation of ali
software (flight, ground, support). The plan shail also include a description of the needed development
environment (equipment and software) as well as the chosen standards, languages, procedures, guidelines,
software development lifecycle, techniques, verification approach (including what simulations and/or test
environments and resources are needed), and milestones for developing and delivering software, including the
support software.

This plan shall include an indication of the control level and types of software to be developed and the
corresponding level of development and management activities such as risk management, configuration
management, internal and external reviews, problem reporting and corrective actions, training, metrics,
software safety and assurance planning including audits, expected verification and validation levels,
delivery/installation plans and procedures including the data acceptance package procedure, and internal and
external communications and reporting mechanisms.

Draft — Due 60 days prior to SRR
Preliminary — Due midway between SRR and PDR
Final- Due 60 days before ATP and /or PDR, update as required 30 days after ATP and/or PDR

Page 21



SpaceDOC Attachment J-2

2.2

2.3

2.4

25

2.6

27

2.8

2.9

2.10

Organization - Description of organizational elements and specific individuals to be given
responsibility for major work elements of the task on the contractor team. Provide an
organizational chart of the project that identifies key positions on the project and key external
interfaces.

Work Breakdown Structure - Description (charts and descriptive dictionary) reflecting the
Contractor Work Breakdown Structure (CWBS) for organizing the technical elements and
essential support for the Delivery Order; it should be based (primarily) on deliverable
hardware/software elements and sub-elements; the level of detail shall be adequate to support
the allocation of personnel and costs and to define a logical schedule through design,
implementation, delivery and operation phases (as appropriate for the Delivery Order. The
CWBS structure should relate to line items on the master schedule and to the resources
section.

Rick Management - Summarize how the Contractor will implement continuous risk
management and the process to identify, monitor, and mitigate risks in accordance with PM-02

Acquisition Plan ~ Identify all major proposed acquisitions in the relation to the CWBS and
provide summary information on each. Describe all agreements for collaborative and/or
cooperative relationships that support the Delivery Order.

Review Plan ~ Summarize the approach to conducting reviews for the delivery order content
including peer reviews if appropriate. Describe the reporting requirements for reviews to be
conducted along with the names, purposes, content and timing of the critical milestone
reviews.

Data Management Plan - Description of the management approach for data generated and
captured during execution of the Delivery Order. Include descriptions of how the data will be
generated, processed, distributed, analyzed and archived.

Documentation - Provide a project documentation tree that includes all governing, hardware
development, mission integration, and safety documentation. Describe the configuration
management approach in accordance with PM-04

Schedule - Provide an overall project master schedule that is consistent with the CWBS,
identifies key milestones for each chosen CWBS element, and is logically phased to address
all aspects of the Delivery Order.

Resources - Specify the funding and personnel requirements needed for execution of the

Delivery Order against the CWBS. Select appropriate CWBS level to be the cost reporting level.
Identify any use to be made of other facilities for which another entity will be financially responsible.

Final — Due at Delivery Order definitization

Page 27



SpaceDOC Attachment J-2

Title: DID No.:  PM-05

Engineering Change Proposals (ECPs), Deviations, Waivers
and Level 1 Problem Report and Corrective Actions (PRACAs)

Reference:

MIL-STD-973

Space Assurance Requirements and Guidelines (SARG) - Section 8.

SSP30223 — Problem Reporting and Corrective Action for the Space Station Program

CxP 70068 - Constellation Program Problem Reporting Analysis and Corrective Action Methodology

Purpose:
To document proposed changes to Government requirements or deliverables (Engineering Change Proposal)

or to request specific authorization to deviate from a particular Government controlled requirement before the
fact (Deviation) or accepting a departure from a particular Government controlled requirement after occurrence
(Waiver). To document Level 1 PRACAs for submittal to the International Space Station (ref. SSP30223).

Related Documents:

PM-01: SpaceDOC Management Plan

PA-13: PRACA Report

PM-04: Configuration Management Plan

PA-07: Problem Report and Corrective Action Plan

Preparation Information:

Classification of Change Proposals
The Contractor must designate each change proposal as either a Class | or Class I] change.

Class | designation is assigned to changes that affect:
* fit, form, function, external ICDs or physical characteristics (weight, balance, etc) of the end item;
* NASA approved and controlled documents (as identified in the Delivery Order (e.g., science or
engineering requirements) or applicable requirements documentation);
contractual cost, schedule or milestones;
safety, reliability, maintainability; interchangeability of the affected system or subsystems;
change that is associated with a previously accepted and/or delivered End Item;
software compatibility;
Government Furnished Equipment.

Class II designation is assigned to changes not in the above categories (editorial change is one example
of a Class II change).

Documentation of Change Proposals

The Contractor shall document each Engineering Change Proposal (using MIL-STD-973, ECP forms DG
1692 and DD1692-1 as guidelines). This document should describe the applicable requirement, the
nonconformance, the reason for and affect of the nonconformance, the proposed corrective action (if any),
and the reason(s) for approving the request. In addition to a description of the proposed change, the ECP
shall contain sufficient information (as attachments, drawings, test results, etc.) to enable evaluation by
NASA (or other oversight auditors) of the total impact of the proposed change.

The Contractor shall log and track each ECP from initiation to final disposition and closure within the
Configuration Contro! system.

Delivery of ECPs

The Contractor shall deliver each Class | change proposal to NASA for review and disposition. Class {I
change proposals need not be delivered to NASA but the status and disposition of all ECPs shall be
accessible for review by NASA at scheduled reviews.

Page 23



SpaceDOC Attachment J-2

Title: DID No.: PA-06
Materials and Processes, Materials Identification and Usage List (MIUL);
Material Usage Agreement (MUA)

Reference:
GRC Product Assurance Manual
Space Assurance Requirements and Guidelines (SARG)

Purpose:
Documents the Materials and Processes required to ensure the safety of the project through the proper

selection, application, processing, inspection and testing of the chosen materials for the flight hardware
subsystems and equipment.

Related Documents:
PA-01: Product Assurance Plan
PA-04: Fracture Control Plan

Preparation Information:

The Materials and Processes Element may be a part of the Product Assurance Plan or a separate document.

The Materials and Processes Element shall address the following topics:
¢ Formulating, reviewing and maintaining materials documentation, including a Material Identification
and Usage List (MIUL)
Organization, review and approval of Material Usage Agreements (MUA)
Organization, review and approval of Volatile Usage Agreements (VUA)
Fracture Control
Nondestructive Testing
Contamination Control
Coatings and Finishes
Special Processes (Welding , Bonding, Heat Treatment)

The MIUL and MUA element documents shall:

identify material usage (MIUL) and justify the use of non-A-rated materiais (MUA) in all space flight hardware.
The contractor's report format will be acceptable, but must contain adequate material identification to assist
the government in conducting their assessment and issuance of the Material Certification Letter.

The MIUL and MUA's must be delivered to NASA GRC at PDR and subsequent major milestone reviews (30
days prior to PSR)

Note:

MIUL/MUA’s may not be required for some (e.g. sounding rocket) payload deliverables. The Contractor must
satisfy NASA that the materials used provide adequate safety margin to receive materials certification. The
Contractor shall meet the materials and Processes requirements of SSP 30233 for all Space Station payloads,

Page 36


SpaceDOC Attachment J-2

m. Approach to property management of items procured under and in support of the SpaceDoc contract
that includes bonded storage of flight hardware components.

n. Description of facility usage in support of the SpaceDoc contract

0. Approach to data rights and intellectual property (IP), describing what patents, copyrights, trademarks,
and trade secrets shall be delivered to the Government and the cost of such data/IP. Approach to
how licensing agreements will be negotiated and how that data/IP will be treated, specifically
identifying any requested special license agreements

p. Approach to periodically assess the SpaceDOC contract operations to identify opportunities to
streamline the processes, procedures, and organization to provide greater responsiveness and
reduced schedule and cost.

q. Strategy and methodology for ensuring an efficient and effective transition of management and
technical responsibilities from the incumbent contractor during the transition period, as described in
Section TBD, Government/Contractor Design Transition Plan

This Plan shall be included as a separate document.

Draft — Due with proposal submittal
Preliminary ~ Due 60 days after contract award
Final — Due 60 days after review and comment of the preliminary Plan by the CoTR or his designee

Page 18



SpaceDOC Attachment J-2

Title: DID No.: OP-04
Launch Site Operations and Test Procedures

Reference:
Launch Vehicle Payload Planner's Guides as applicable

Purpose:
(1) To provide a detailed understanding of the launch site activities, operations and testing planned for a

particular mission, (2) to define the launch site support requirements and (3) to obtain launch site procedure
approvals.

Related Documents:
OP-01; Integrated Logistics Support Plan

Preparation Information:

Describe all aspects of the activities at the launch site beginning with arrival of the payload, including final
testing and preparations, transportation between buildings and the launch vehicle, launch vehicle integration
and testing, and removal of systems after launch. The data shall be originated to support the applicable
launch site “test and inspection plans” requirements and the “ground operations plan” requirements.

The plan shall include as a minimum:

Description of proposed sequence of ground processing operations

Description of proposed facilities, ground support equipment, and personnel required
Equipment placement and personnel area requirements

Specific operations, procedures, and instructions to integrate, test, and check out the payload
Summary of types of inspection and verification procedures

Explanation of schedule and personnel contingency methods

Description of roles and responsibilities

Summary of specific safety, security, reliability and quality assurance procedures for pre-launch
processing including any special requirements for hazardous systems

Description of cleanliness methods, purge gasses and lines, and garments

Description of any specific communication links needed between locations at the launch site to
perform testing and to support the payload on the launch vehicle up to the point of launch.

K. Description of processing operations required for post-landing

ZOnNmoOg>

or

Page 77



SpaceDOC Attachment J-2

Title: DID No.: D-08
Fracture Control Summary Report

Reference:

SSP 52005B — ISS Payload Flight Equipment requirements and Guidelines for Safety Critical Structures.
NASA-STD-5003 Fracture requirements for Payloads Using Space Shuttle

FCF Fracture Control Plan - FCF-PLN-0030B

PA-02: System Safety Plan

PA-04: Fracture Control Plan

Purpose:
Documents the contractor's approach for fracture control analysis and helps the Government understand how

the contractor will comply with fracture control safety requirements applicable in the References and Related
Documents as listed above and below. This report shall be submitted to the responsible fracture control
authority and payload safety review panel prior to the phase III payload safety review.

Related Documents:

NSTS 1700.7 ISS Addendum Safety Policy and Requirements for Payloads Using the
International Space Station.

NSTS-13830 Payload Safety Review and Data Submittal Requirements for Payloads Using the
Space Shuttle — International Space Station.

D-10: Safety-Critical Structures Data Package

Preparation Information:

This document shali define the overall approach for meeting the fracture control requirements, listing of all fail-
safe, fracture critical and low risk parts, stress analysis results and assumptions, methodology for performing
crack propagation analysis, the use of nondestructive inspection and testing techniques, and the fracture
control activities to be conducted during the various program phases. The acceptance Fracture Summary
Report and data package should consist of as a minimum the following areas:

a) List of all fail-safe, fracture critical and low risk parts

b) Summary of structural stress analysis results of elastic stresses for which the maximum elastic
stresses are used for crack growth analysis

c) List of available fracture mechanics material and newly developed fracture mechanics properties
used for crack growth analysis.

d) Crack model selections and assumptions

e) Nondestructive examination (NDE) and initial flaw size selections

~“"f) Identification of the cyclic loading conditions and assumptions ~~

g) Summary of crack growth/damage tolerance or test results including as a minimum, the summary
of fracture analysis data

h) Records of Non-Destructive Evaluation (NDE) inspection or proof test

i) Waiver/Deviation Records (affecting integration, safety)

j) Payload operations and maintenance on board the ISS

This fracture control analysis summary report shall apply to all types of fracture phenomena including fatigue
crack initiation, stress corrosion cracking, hydrogen embrittlement, and propagation of cracks due to cyclic or
sustained loadings.

Page 62



SpaceDOC Attachment J-2

CONTRACT DATA REQUIREMENTS LIST

| DID# Title Submission
DESIGN

D-01_| Review Presentation Package f
D-02_| Engineering Trade and Analysis Data $s
D-03 | Baseline System Description (Baseline Concept Description) NDA
0-04 | Product Drawings |
D-05_| Accommodations Handbook NDA
D-06_| Software Design Document A |
D-07 | Safety-Critical Structures Data Package NDA

| 2.08 Fracture Control Summary Report A
D-09_| Worst-Case Analysis |

I D-10_| Parts-Stress Analysis j

VERIFICATION

V-01 | Master Requirements and Verification Compliance Plan NDA

| Master Requirements and Verification Compliance Matrix/Summary i
V-02_| Individual Item Verification Test/Demonstration Procedure |
V-03_| Individual Item Verification Report NDA
V-04 | Software Verification and Validation Plan |
V-05_| integration Data Package (CoFR) NDA
V-06_| As Built Configured Item List |
V-07_| On-orbit Performance Acceptance Test Matrix/Plan NDA.

CONTRACT DATA REQUIREMENTS LIST

Title NDAVAIIS

OPERATIONS
Integrated Logistics Support Plan NDA
Operator’s Manual A
Operations Plan NDA
Launch Site Operations and Test Procedures
Data Delivery Plan
TSC Security Plan
Procedures
Training and Certification Plan
Firmware Support Manual
Decommissioning Plan
Concept of Operations

Page 10


SpaceDOC Attachment J-2

Title: DID No.: PA-03
System Safety Hazard Analysis

Reference:
GRC Product Assurance Manual (PAI #220)
Space Assurance Requirements and Guidelines (SARG) - Section 4.

Purpose:
Conducted to identify applicable hazards and methods to eliminate or contro! those hazards.

Related Documents:
PA-02: System Safety Plan
PA-05: Safety Compliance Data Package

Preparation Information:

This document will identify the potential hazards associated with a space flight payload and define the
approaches to be used to control (Phase 1) and verify (Phase 2) the hazards identified. The contractor's
report format will be acceptable (although it should be compatible with the requirements of the Safety
Compliance Data Package) unless specific forms are required by the Safety Review Panel.

Page 33



SpaceDOC Attachment J-2

Title: DID. No.: V-04
Software Verification and Validation Plans

Reference:

IEEE-12207 Software Engineering Standards (where applicable)

Software Engineering Institute Capability Maturity Model

SSP-57010 Pressurized Payloads Generic Payload Verification Plan (ISS Only)
SSP-57011 Payload Verification Program Plan (ISS Only)

Purpose:
Provide identification of software interface and performance requirements along with descriptions of
verification and validation methodologies that will be used to assure successful implementation.

This document(s) is a subset of the documents described in DID V-01 in scope, content, and level of detail. .

Note: Individual test procedures (DID V-02) will document each test in detail and the overall Verification and
Validation matrix (DID V-01) will summarize results and tracking of requirements/performance,

Related Documents:

Software Assurance Plan

Master Requirements and Verification Compliance Plan, etc.
individual Item Verification Tes/Demonstration Procedure

: Individual Item Verification Report

Preparation Information:

Analysis, inspection, test, or a combination of those (and other software unique) methods shall be used to
verify successful implementation of each relevant software requirement. All verifications shall be completed
prior to launch of hardware or launch/upioad of software. Some verifications may have to be repeated on-orbit
and will be captured in the On Orbit Performance Acceptance Test Matrix/Plan and individual test procedures
called out in DID V-07.

Preparation of the Software Verification and Validation Plan (V-04) documents shall be in accordance with the
applicable standards and in accordance with the software development process being used. To the extent
possible, the software verification and validation documents should maintain a similar appearance and format
to DID V-01, as applicable. At the option of the contractor, software verification and validation plans may be
the.V-01 documents because verification may often involve interaction of both hard e

Preliminary is required for PDR

Final is required for CDR

Revisions as required for VRR/TRR

Status of verifications (summary) and “as run” test procedures at SAR, FRR and PSR.

Page 69



SpaceDOC Attachment J-2

Title: DID No.: V-06
As Built Configured Item List

Reference:

GRC Product Assurance Manual (PAI #420, #450)

Space Assurance Requirements and Guidelines (SARG) ~ Section 7 & 8
GRC Microgravity Science Division Operating Instruction, OP-6700-4
SSP 41170 - ISSP Configuration Management Requirements

PA-01: Product Assurance Plan

PM-04: Configuration Management Plan

Purpose:
To document the component items that make up the delivered assemblies and provide traceability to EEE

Parts used in flight hardware. The document shall be used to (1) determine if a latent problem is in the
payload/hardware as discovered elsewhere in the industry, (2) to help evaluate on-orbit issues should any
arise, and (3) to review against the GIDEP failure experience data and NASA parts advisories and provide
traceability to EEE parts lot data codes needed for GIDEP review.

Related Documents:
D-03:; Baseline System Description
D-04: Product Drawings

Preparation Information:

As Built Configured List shall be prepared, maintained, and updated by the developer in accordance with the
developer's configuration control system and shall include an EEE Parts Identification List in compliance with
SARG and MSD Oi EEE Parts Policy. The As Built Configured Lists shall be prepared for the space flight
delivered hardware such as, Trainers, Qualification Units and ail Flight Systems, as appropriate.

The subject list should include all of the electrical and mechanical parts contained in the payload and provide
the following information for each item as a minimum:

* Name/Nomenciature
e Manufacturer
{tem number... os int nalnecte Oi yea toneranN

e Serial number

e Quantity

¢ As built drawing number, including latest revision letter and change notice

* Software Identification and version

° Location in the system

e Note any approved deviations or waivers affecting the installed configuration item

Final: PSR

Page 71



SpaceDOC Attachment J-2

Title: DID No.: V-07
On Orbit Performance Acceptance Test Matrix/Plan
Individual On Orbit Performance Acceptance Test Procedures

Reference:

PA-01:; Product Assurance Plan

R-01: System Requirements Document

SSP 41172 -ISSP Qualification and Acceptance Environmental Test Requirements

Purpose:
Describes how the delivered system (including hardware, software, ground operations support equipment,

operational procedures, and other items comprising the system) is fully suitable for its intended mission and
will meet its performance acceptance criteria. Successful completion of the on orbit activities described in the
test matrix/plan should lead to formal, final Government acceptance of the system. The plan should utilize
block diagrams that outline the groups of tests to be performed, the sequence of testing and the required flight
and flight support equipment required. The plan should also reference what (The purpose of the plan is to
determine if the appropriate tests/verifications will be performed and determine a ROM for the on orbit time
(schedule), and crew time required to perform the verifications/tests.) Individual On Orbit Performance
Acceptance Test Procedures will document each test in detail.

Related Documents:
V-01: Master Requirements and Verification Compliance Plan

Preparation Information:

The On Orbit Performance Acceptance Test Plan/Matrix shall describe how the contractor will use on orbit
operational tests and special tests to confirm that the deployed system is fully suitable for its intended mission
and will meet its performance criteria and is fully operational. The On Orbit Performance Test Matrix/Plan shall
describe the specific tests to be performed upon deployment on the flight vehicle/carrier (such as ISS or FCF)
and the initial integration/operations. Emphasis shall be given to verification of requirements that are
difficult/inconclusive to verify via ground tests or analysis, and validation that the system is operational. The
on orbit test matrix/plan shall include as a minimum the following:

1. Operational testing with the initial (for series hardware) on-orbit component(s) to validate overall
performance

a. Interface testing with vehicle/carrier (such as ISS or FCF) ~ (operational, mechanical,
electrical and software) which shouid include test scenarios on commanding, data handling,
downlinking and operations at the Glenn, Telescience. Center. (if applicable) =
“If deemed necessary, flight support equipment (such as a calibration comp. ) may be
employed to further validate performance requirements that may not be tested during the
initial. science test points
2. Testing to validate microgravity disturbance levels generated by the system and subsystems.

a. Testing to verify overall microgravity level experienced at the science phenomenon
3. Testing to validate thermal performance (thermally map subsystems and demonstrate performance).
4. Testing for power quality and performance of subsystems
5. Any additional on orbit testing that is required for acceptance

Note: These tests should be a subset of tests (with on orbit environment taken into account documented for
pre-flight Verification Plan (V-01)). These tests should be ordered to minimize risk to components (i.e. perform
tests at system level first and gradually add components.)

On Orbit Performance Acceptance Test Matrix/Plan

Draft is required at PDR.

Preliminary is required at CDR.

Final is required at VRR/TRR.

Results of ground tests (refer to V-01) shall be presented at FRR/PSR along with revisions to plan based on

tesults of ground tests

Page 72



SpaceDOC Attachment J-2

Title: DID No.: PM-09
Systems Engineering Management Plan

Reference:
NPR 7123.1A (NASA Systems Engineering Process and Requirements)

Purpose:
This document provides a single, integrated technical planning document for the conduct and management

of the required technical effort. The plan is to be used by the technical team responsible for generating
technical work products to integrate and manage the full spectrum of technical activities required to
engineer the system.

Related Documents:
PM-06: Contractor Delivery Order Work Plan
PM-01: SpaceDOC Management Plan

Preparation Information:

SEMP preparation guidance is provided in detail in NPR 7123.1A, Systems Engineering Process and
Requirements. SEMP information maybe incorporated into the project's plan and tailored according to the
project requirements. The general structure of the SEMP contains the following sections:

Purpose and Scope

Applicable Documents

Designated Governing Authority

Technical Summary

Technical Effort Integration

Common Technical Processes Implementation
Technology Insertion

Additional SE Functions and Activities
Integration with the project Plan Resource Allocation
Waivers

Appendices

RUT Te me@aggD

Each of these sections is describe in some detail in NPR7123.1A.

Page 30



SpaceDOC Attachment J-2

Title: DID No.: OP-09
Firmware Support Manual

Reference:
NASA-STD-2100-91 NASA Software Documentation Standard (NASA-DID-P410)

Purpose:
To provide an instruction and reference for the firmware/software programmer to program, support, maintain,

and monitor firmware that is part of the software.

Related Documents:
PM-04: Configuration Management Plan
PA-11: Software Assurance Plan

Preparation Information:

The Firmware Support Manual describes the ROM devices and support equipment and software required for
reprogramming. It does not need to provide information regarding the design and implementation within the
device. That information is contained in the Software Detailed Design document.

This manual shall minimum contains:

1. Introduction and purpose
2. Devices (Physical description, Installation and Replacement, Limitation)
3. Programming Tools (Equipment, Software package, Programming Procedures)
4. Safety and Security Implication.
Due at ADP

Page 82



SpaceDOC Attachment J-2

Approval of Documentation
1.7.1 Types of Approvals

17

1.7.2

There are three types of NASA approvals that can be exercised in accordance with the following
descriptions:

a)

b)

c)

NASA Formatted Documents with Government Approval: CDRL DID’s developed as a NASA
document with NASA approval signatures, identified on the CDRL as NDA by the
corresponding DID. Typically documents requiring this approval are distributed to the
international Space Station and Human Research Project Office or project customers; are
documents that identify high level system requirements, verification plans and reports,
integration agreements, interface control documents, integration schedules, safety
documentation, or operations protocols.

Non-NASA Documents Requiring Government Approval: CDRL DID's requiring NASA
approval, but do not require the NASA Approval format, identified on the CDRL as A by the
corresponding DID. These documents are typically contract-level documents describing
contractor processes or internal design activities that require NASA approval; they do not
have to be identified as a NASA document, however require a NASA approval signature.

Non-DID Items: Documentation deliverables not identified in the CDRL, but are called out in
an individual delivery order and specified as requiring NASA approval. These documents
may be unique deliverables not specified in the CDRL, with significant scope that require
NASA approval. For those documents, the Government will provide the Contractor with DIDs
or a description of the requirement and acceptance criteria with the delivery order request.
Additionally, any documents specified in the incentive fee criteria or contractor responses to
design review Request for Action (RFA) and RIDs will require NASA approval. As a NASA
approved document, the document must also specify NASA's involvement in the document
change process.

Process for Document Approval

Document approval is provided by NASA if the requirements specified in the DID are met, and the
document fidelity meets the definition in Section 1.4. Any documentation with a requirement for
NASA approval shall be in accordance with the following:

a)

b)

c)

q)

Documents (draft, preliminary and final) may be submitted to the Government for approval
either as part of a review package, or on an individual basis. If submitted as part of a review
package, the Government will provide approval, approval with modification, or disapproval of
each document within 30 calendar days of the review. If documents are submitted
individually, or resubmitted following a disapproval, within thirty (30) calendar days after
teceipt of the document and/or data, the TR or COTR shall provide (in writing or other agreed
to process with the Contractor) to the Contractor whether the documents are “Approved”,
“Disapproved", or “Approved as Noted”.

Government approvals of Draft and Preliminary documents with an NDA or A approval code
shail be provided to the Contractor in writing, but not via signature on the document signature
pages. The document signature pages will be used only for approvals of Final level
documents.

For documents that are “Disapproved” or “Approved as Noted”, rationale for rejection or
conditional acceptance is provided to the Contractor, who shail have thirty (30) calendar
days, or later for Draft or Preliminary level documents as specified by the Government, after
receipt to correct the document and returned it to the Government. At that point, the
Government has another 30 days to approve the document, and the approval process is
repeated.

In the event that documents or data marked "Approved" or "Approved as Noted," reflect
information which is not in full conformance with the contract requirements, the Contractor

Page 7


SpaceDOC Attachment J-2

1.5

1.6

3. Released: A version of a design that has been approved for a specified purpose, at a
specified point in time. Itis controlled and traceable. The design version shall be
reviewed and approved by all responsible individuals before being released.

Delivery Media

a)

b)

c)

The contractor will keep all documents and data in native format. There are two media in which
data will be documented and are defined as:

1. Hard Copy - Data typed, drawn or printed on paper by common, conventional practices. By
these means, the master, a reproducible copy or the record copy shall be reproduced for
distribution as printed copies. The reproducible copies shall be made from the original
signed document that will show actual signatures in lieu of electronic signatures.

2. Electronic - Data that is recorded in word processors, computerized data processing
systems, or electronic storage devices. Electronic copies should have an indication of the
signature and the date signed.

The contractor shall maintain native formats of all data. The electronic data delivery shall be in
the following formats:

1. Portable Data Format (PDF) - The preferred format, documents may be delivered via a
PDF format that is readable by the latest Adobe Acrobat PDF reader (currently version 6.0).

2. MS Word - The preferred format for word processing documents is in Microsoft Word
format that is version 2003 or higher and is both MS Windows and Mac OS compatible.

3. MS PowerPoint -The preferred format for presentation documents is in Microsoft
PowerPoint format that is in version 2003 or higher.

4. Drawing formats are defined in the appropriate DID.

Any unique documentation delivery (in hardcopy or electronic format) instructions shall be
specified in the delivery order. Additionally, all DO and CDRL data that has been generated
electronically, shall be delivered via electronic transfer into the Government's electronic storage
drop box.

Documentation Change Procedures

a)

b)

c)

q)

The contractor shall issue documentation change notices (DCNs) whenever minor (Class II)
changes or updates occur in final versions of data items that have been delivered to NASA.

Change tracking shail be used to indicate changes or updates when the document needs to be
reviewed again by NASA.

When major (Class 1) changes to a document are made, a complete revision of the document
shall be issued and delivered to NASA in accordance with the original instructions for the data
item. Any changes to documents requiring NASA approval shall first be submitted to NASA for
approval before the changes become effective.

Documentation title pages should reflect that Government approval is pending until
Government approval has occurred. Upon Government approval, the contractor will revise the
title page and signature page will be revised by the contractor to reflect the final, approved
version. Current versions of documents shall be made available to the Government via the
contractor CM system. The contractor will notify the Government that the final version with
updated title page and signature page has been posted in the contractor CM system.

Page 6


SpaceDOC Attachment J-2

Title: DID No.: PM-02
Risk Management Plan

Reference:

NPG 7120.5D, NASA Program and Project Management Processes and Requirements

NASA Continuous Risk Management Course (http://arioch.gsfc.nasa.gov/302/Risk/RMPage.htm)

Purpose:

The purpose of risk management is to identify risks early in the program so that appropriate abatement plans
can be implemented to reduce the consequences of the risk or likelihood that the risk will occur. This
document provides the overall approach, coordination, structure, and environment within which risk
management processes for the SpaceDOC contract reside and addresses how NASA risk requirements are to
be implemented by the Contractor through the Delivery Order implementation. This document describes the
methodologies and processes used to identify, analyze, control and communicate the Delivery Order's risks.
The identification, characterization, mitigation plan, and mitigation responsibilities associated with specific risks
are described and specific risk abatement strategies or contingency planning processes are discussed.
Related Documents:

PM-01; SpaceDOC Management Plan, PM-06: Contractor Delivery Order Plan

Preparation Information:

The Risk Management Plan documents the process that the Contractor will follow to manage risk throughout
the life cycle of the item covered in the Delivery Order and provide government insight to risk management.
“Risk” refers to anything that can prevent a team from meeting the Delivery Order objectives. All forms of risk
shall be managed. These include technical (hardware and software), programmatic, supportability, cost, and
schedule risks.

The Risk Management Plan shall provide descriptions of the processes to provide management at all levels
with 1) a disciplined system for early identification of technical uncertainties, 2) a disciplined assessment of
current project status, 3) key indicators of mission success and 4.) methads and procedures for integrating this
process with NASA’s approach to Continuous Risk Management. The plan shall describe the basis for taking
action to control risk and for measuring the effectiveness of that action.

The plan shall as a minimum cover:

a.) Risk identification - The process to determine and define all risks.

b.) Risk analysis - The process to convert risk data into decision-making information. This process should
include estimating the probability, impact and time frame of the risks, eliminating duplicates, identifying
key decision points, and grouping similar risks, and Prioritizing them according to consequences.

c.) Risk planning — The process to develop mitigation options and decide what to do with the risks.

d.) Risk tracking — The process to acquire, compile and report risk status data, including risk indicators and
mitigation actions. Appropriate risk metrics shall be identified so that the Government can evaluate the
quality of the risk management.

e.) Risk control ~ The process covering decisions to re-plan mitigation, close risks, invoke contingency
plans or continue to track risks. The plan shall define roles and responsibilities, typical
milestones/reviews, and describe the key risk control activities.

f.) Communications and documentation — Present in all the above processes, this is the means by which
the output of the processes is documented and communicated to all team members.

The plan shall also identify the information to be documented for each risk. For risks having both a high
probability and high impact/severity, the plan shall require, as a minimum, the following:

(1) Description of the risk

(2) Primary consequence should the undesirable event occur

(3) Estimate of probability of occurrence and the fidelity of the estimate

(4) Significant cost impacts, given its occurrence

(5) Significant schedule impacts, given its occurrence

(6) Potential mitigation measure not already taken and the cost to implement them

(7) Characterization of the risk as acceptable or unacceptable with rationale.

Page 19


SpaceDOC Attachment J-2

CONTRACT DATA REQUIREMENTS LIST

DID # Title* Submission
CONTRACTUAL DATA
CD-01_| CONTRACTOR FINANCIAL MANAGEMENT REPORTING A
CD-02_| EARNED VALUE MANAGEMENT REPORTING |
CD-03_| TECHNICAL REPORTING AND MANAGEMENT REVIEWS |
CD-04_ | AUTOMATED INFORMATION SECURITY PLAN A
PROGRAM MANAGEMENT
PM-01_| SPACEDOC MANAGEMENT PLAN A
PM-02_| RISK MANAGEMENT PLAN A
PM-03_| SOFTWARE MANAGEMENT AND DEVELOPMENT PLAN A
PM-04 | CONFIGURATION MANAGEMENT PLAN A
PM-05 | Engineering Change Proposals (ECPs), Deviations, Waivers and A
Level 1 Problem Report and Corrective Action Report
PM-06 | Contractor Delivery Order Work Plan A
PM-07_| Software Sustaining Engineering Plan A
PM-08 | Software Version Description Document A
PM-09 | Systems Engineering Management Plan A
PRODUCT ASSURANCE
PA-01_| PRODUCT ASSURANCE PLAN A
PA-02 | System Safety Plan A
PA-03_| System Safety Hazard Analysis s
PA-04 | Fracture Control Plan {
PA-05 | Safety Compliance Data Package NDA
PA-06 | Materials Identification and Usage List (MIUL); Material Usage NDA
Agreement (MUA)
Problem Report and Corrective Action Plan A
Failure Mode and Effects Analysis (FMEA) and Critical Items List f
(CIL)
Contamination/Cleanliness Control Plan $s
SOFTWARE ASSURANCE PLAN A
SAFETY AND HEALTH PLAN A
Problem Report and Corrective Action Report s
Reliability Report(s) Ss
Limited Life Items List s
System Maintainability/Availability Analysis A
Fastener Control Plan Ss
REQUIREMENTS
Systems Requirements Document NDA
Interface Definition Document & Interface Control Document NDA
Payload Interface Agreement & Annexes NDA
Software Requirements Document NDA
Software Interface Control Document NDA

* Contract Wide Documents are identified in UPPER CASE lettering.

Page 9


SpaceDOC Attachment J-2

Title: DID No.: OP-11
Concept of Operations Document

Reference:
TBD

Purpose:
To define an operations concept for the project that describes the flight and ground operations.

Related Documents:
OP-03: Operations Plan

Preparation Information:

This document identifies the operational scenarios that apply to project.
Suggested content includes:

Introduction

Reference documents

Document organization

Pre-increment support scenarios beginning with requirements definition and ending with operational
certification

Increment support scenarios during operations start-up, nominal operations, and off-nominal
operations

Post-increment scenarios for systems deactivation and reconfiguration to support future operations
Acronym list

Glossary of terms

m 9OMW>

zon

Page 84



SpaceDOC Attachment J-2

Title: DID No.: PM-06
Contractor Delivery Order Work Plan

Reference:

Purpose:
This document provides an integrated overview of the Contractor approach to accomplish the work defined in

the NASA provided Delivery Order. The Delivery Order Work Plan defines the contractor's approach,
technical plan to accomplish the deliverables, defines the management and reporting structure, and the
associated schedule and resource requirements. The Delivery Order Work Plan provides details on the
technical task, proposed resources, and applicable requirements necessary to accomplish the Delivery Order.
It clearly identifies all deliverables and provides a detailed development schedule with associated resource
requirements. The Delivery Order work pian shall include the Contractor approach to performance reporting
on technical progress, schedule adherence, and budget maintenance and analysis.

Related Documents:

CD-01: Contractor Financial Management Reporting
CD-02: Earned Value Management Reporting

CD-03: Technical Reporting and Management Reviews
PM-01: SpaceDOC Management Plan

PM-02: Risk Management Plan

PM-03: Software Management and Development Plan
PM-04: Configuration Management Plan

PM-09: Systems Engineering Management Plan
PA-01:__ Product Assurance Plan

Page 25



Contract Data Requirements List (CDRL)
Attachment J-2

July 15, 2008

Revision: Final

NASA Glenn Research Center
CLEVELAND, OHIO


SpaceDOC Attachment J-2

le: DID No.: R-02

Interface Requirements Document (IRD)
Interface Control Document (ICD)

Reference:
SSP57000, Pressurized Payload Interface Requirements Document (ISS Only)
SSP57001, Pressurized Payload Interface Contro! Document Blank Book (ISS Only)

NPR 7150.2, NASA Software Engineering Requirements

Purpose:

The purpose of the IRD is to define the interfaces between the payload and the carrier, define payload to
carrier interface constraints, and to levy the associated design requirements on the payload. The IRD also
establishes commonality with respect to analytical approaches, analytical models, technical data, and
definitions for payload integration into carrier.

The ICD is used to provide configuration controlled documentation in the form of drawings and/or written
records to identify necessary design definitions between one or more systems, elements, subsystems, or
computer software configuration items (CSCls) to provide control of and ensure a compatible interface. The
Interface Control Document (ICD) provides the design solutions to the requirements found in the requirements
specifications and/or the Interface Requirements Document (IRD); the iCDs are companion documents that
serve to communicate and control interface design decisions.

Related Documents:
R-01: System Requirements Document
R-04: Software Requirements Document

Preparation Information:

The IDD shall provide the definitions and requirements that control the design of all interfaces between the
carrier and the payload. The IDD shall be utilized as the basis for the development of the ICD. The ICD shall
provide detailed information regarding the payload interfaces to the carrier. The data provided by the
payload/instrument, in the form of written words, drawings, and schematics, will be incorporated into a
combined payload and carrier ICD for applicable signatures.

The payload to carrier interfaces are defined per the following topics as a minimum:

A. Physical Requirements - such as mass properties, structural/mechanical, carrier interfaces during
launch and landing, on-orbit carrier interfaces, footprint, clearance envelope, drill template, alignment,
orientation, fields-of-view (optical, thermal, glint, RF), including tolerances; electrical connectors
regarding sex (plug or receptacle), type, orientation, pin assignments, clocking and backshell type,
cable locations/runs; thermal control coatings, blankets, heat flow and operating limits; microgravity
quasi-steady state and transient sources.

B. Electrical Power and Signals - such as timing clock pulses, data busses, signal (name, type, function),

voltage and current limits, frequencies, waveforms, rise and fall time, duration, periodicity, shielding,

grounding, formats, line driver/receiver characteristics. Power fusing, voltage, currents, ripple,
regulation, power quality, power handling capability, source impedance limits, remote power controller
overload limits, electrical power consuming equipment.

Software - such as codes, processors, memory storage, application description, uses, data transfer

and command protocols.

Payload Environmental - such as vibration, shock, acoustic, EMI/EMC, ESD, thermal, contamination,

purges, air and water-cooling, pressure/vacuum.

Safety - such as pyrotechnics, energy storage, trip-over, hazardous materials or processes, fire

detection and suppression, gas interface, ionizing radiation, air and water thermal control.

Ground Support Equipment - such as mechanical, electrical, test specific, targets, simulators.

Ground System Interface - Data formats, communications protocols, data rates; compression

algorithms, error detection and correction schemes; antenna patterns, EIRP, G/T, beam width,

frequency, polarization; command and telemetry formats; scenarios for data transmission, operations,

en moo

Page 48



SpaceDOC Attachment J-2

The amount of unfilled orders outstanding is the difference between cumulative costs incurred
to date and amounts obligated to suppliers and subcontractors. A prime or subcontractor’s
unfilled orders include open purchase orders (including negotiated changes), against which
materials have not been received nor services rendered, and the difference between a
subcontractor’s actual costs reported by the prime and fund limitations for the subcontractor.
A fund limitation is often less than the total estimated amount to be purchased, just as the
amount reported in block 4, “Fund Limitation”, may be less than that reported in block 3,
“Contract Value”, for the prime contract.

2. A Reconciliation of Changes from the original negotiated Delivery Order baseline shall be included
as part of the Contractor's Narrative Remarks for the month in which the changes occur. Changes
shall be reconciled first to the present Delivery Order value by including only negotiated changes
(supplemental agreements) and then to the Contractor's Estimated Final Cost by including changes
authorized but not finalized. if the Contractor's Estimated Final Cost includes any overruns or
underruns, they should be fully identified and explained. In addition, the Contractor may have
proposed changes which have not been approved by NASA but for which tentative costs have been
determined. These items should be reported as changes “Under Consideration but not Authorized”.

3. New change order direction to Delivery Orders may require identification of the cost effect on
subdivisions of work. The Contractor shall identify shifting work from one WBS item to another, A
current contract/Delivery Order change log shall also be provided on a monthly basis.

There are many other factors that may influence the final cost on a contract/Delivery Order. Significant items

of this nature should also be included under this section of the report. The following examples are typical:
1. Pending union negotiations (e.g., changes in pay, fringe benefits).

Changes in the Contractor’s organizational structure

Business backlog, e.g., changes in customer mix, product

Changes in manufacturing processes.

Changes in policies affecting the following:

Subcontracting (makes or buys decisions)

Fixed asset improvement programs

Direct/indirect method of charging

Cost centers

Accounting or estimating methodologies

ARON

g@a0cn

The requirements of this DID shall be flowed down to the major Subcontractors. Detailed Subcontractor 533
reporting shall be provided directly to the Government.

Page 12



SpaceDOC Attachment J-2

Title: DID No.: CD-01
Contractor Financial Management Reporting

Reference:
NPG 9501.2D NASA Contractor Financial Management Reporting
Contract Provision F.X Financial Management Reports

Purpose:
To provide data necessary for reporting costs, projecting costs, evaluation of Contractor cost and fee data and

planning, monitoring, and controlling project resources.

Related Documents:
CD-02 Earned Value Management
CD-03 Technical Reporting and Management Reviews

Preparation Information:

The report shall be in accordance with the NFS 1852.242-73 entitled “NASA Financial Management Reporting
(NASA Form 533 reports) and NPG 9501.2D entitled “NASA Contractor Financial Management Reporting.
NPG 9501.2D provides basic requirements and instructions to assist in the preparation of Contractor Financial
Management Reports (NASA Form 533 reports), The document information can be found at:

htto//ifmp.nasa.gov/codeb/library/forms.htm

The Contractor 533 reporting structure shall include 1) a summary at the contract level, and 2) individual
reports for each Delivery Order issued. Delivery Order reports shall be consistent with each Delivery Order
WBS and Delivery Order schedule. At the initiation of each Delivery Order, the Contractor and Government
shall meet to establish the detail of 533 reporting that will be required by the Government. The Government
will meet monthly with the Contractor project team associated with each Delivery Order to review progress
against the schedule and resource plan, and to assure the Contractor is effectively managing to the Delivery
Order project plan baseline.

The contractor shall perform semi-annual Estimate to Complete (ETC) reviews and submit your ETC changes
with the March and September Quarterly reports.

Variance Reporting: The Contractor shall provide a monthly assessment of each Delivery Order project
variance item. Variance Reporting on either schedule or cost plan performance (per the 533) shall be reported
monthly and provided at a Delivery Order WBS level approved by the Government and will be based on
cumulative expenditures compared to the baseline plan. Variance Reporting shall include rationale for
variance, current and future impact to Delivery Order project plan, and corrective action planned.

FOR DELIVERY ORDER COST VARIANCES: Variances of +/- 10% or any variance that is +/- $25K
regardless of the percentage shall be assessed and reported monthly.

FOR DELIVERY ORDER SCHEDULE VARIANCES: Variances at the WBS level specified in the DELIVERY
ORDER SOW of +/- 10% and milestone variances of +/- 2 months shall be assessed and reported monthly.

Types of variances include the following:

1. Actual Cost and Hours versus Plan.

2. Lateral or vertical shift in planned resource utilization in support of performance between
consecutive reports.

3. Anticipated overruns or underruns.

The Contractor shail continue to maintain the following requirements:

1. Unfilled Orders Outstanding
* Reporting of unfilled order in column 10 of the NF 533M is optional, as directed by the NASA
Contracting Officer. Amounts of unfilled orders shall, however, always be included in the
values shown in columns 8 and 9 of the reports, as appropriate.

Page 11



SpaceDOC Attachment J-2

iv. A list of the failure modes to be considered.
v. The calculations of Margins of Safety for each failure mode.
vi. The minimum Margin of Safety for the structural element or group of elements should be
clearly marked.
vii. Each page of the analysis should be initialed and dated by both the analyst and the
checker. 100% checking is required if the no-test approach is used.
11. Fracture Control Analysis Results — List the reference for the Fracture Control Summary Report.

Page 61



SpaceDOC Attachment J-2

Title: DID No.: PA-14
Limited Life Items List

Reference:
Space Assurance Requirements and Guidelines (SARG) - Section 7
SSP 50431, Space Station Program Requirements for Payloads

Purpose: The Limited Life Items List identifies hardware items that are not expected to operate over the
duration of the mission and will require corrective action such as Preventative maintenance or calibration. The
Limited Life Items List directly supports the development of the Preventative Maintenance Analysis and plan
for the system. It will also support: (1) Spares planning, (2) System Safety verification/corrective action for
Safety Critical hardware items that are of limited life, (3) test planning, (4) mission planning, (5) preparation of
on-orbit maintenance inspections, (6) operational availability analysis, (7) logistics planning, and (8) waiver to
program requirements.

Related Documents:
PA-01: Product Assurance Requirements
PA-08: Failure Modes and Effects Analysis

Preparation Information:

Developing the Limited Life Items List

Limited Life Items are defined in section 7.4.2 of the SARG. System hardware parts/components/assemblies
are evaluated to determine if their useful life will be less than 125% of their total required operating time
planned to support the mission. Such items are limited life items ard are documented on the Limited Life Items
List.

Data elements that should be considered (and reported) for the limited life items are: Expected operating life,
required operating life, duty cycle, and planned corrective action. The limited life items list must also address
Limited Storage-Life Items: Items that have a storage life that will be less than their required storage time.

Preliminary ~ Due for PDR
Final — Due for CDR, update as required for PSR

Page 44



SpaceDOC Attachment J-2

Title: DID No.: PA-02
System Safety Plan

Reference:

NPD 8700.1 NASA Policy for Safety and Mission Success

NPG 7120.5A Program and Project Management Processes and Requirements
NPG 8715.3 NASA Safety Manual

Space Assurance Requirements and Guidelines (SARG) - Section 4

NSTS/ISS 13830 Payload Safety Review and Data Submittal Requirements

Purpose:
To define the system safety activities for identifying and eliminating or mitigating hazards. The System Safety

Plan provides the Government with an understanding of the Contractor's organized, systematic approach to
mitigate safety risks and compliance with the applicable safety requirements.

Related Documents:

PA-01: Product Assurance Plan

PA-03: System Safety Hazard Analysis
PA-04: Fracture Control Plan

PA-05: Safety Compliance Data Package

Preparation Information:

The plan shall define the functions and activities involved with Flight and Ground System Safety. This plan
defines the approach to be taken to assure applicable SARG safety requirements will be satisfied. The plan
shail include, but not be limited to, the following information:

A detailed description of how the system safety requirements shall be established, definition of safety
responsibilities, and tasks in sufficient detail to assure compliance with requirements, identification of the
safety process outputs, safety milestones, phasing, integration, and product delivery.

A detailed description addressing Section 8.1 of NSTS/ISS 13830 that includes defining at what Phases
separate or independent Safety Data Packages (SDPs) and reviews will be generated/conducted for both flight
and ground and at what Phase integrated SDPs and reviews will be generated/conducted for both flight and
ground.

The System Safety Plan for an integrated, multi-payload cargo compliment (IMPCC) as defined by Section 8.1
of NSTS/ISS 13830 shall also address the specific activities related to the review of SDPs developed by the
payload elements to be integrated into the IMPCC. including the timing of such review for both flight and
ground. The participation by the IMPCC in the associated safety reviews for the payload elements shall also
be addressed for both flight and ground.

The plan may be a part of the contractor's Product Assurance Plan (PA-01) or a separate, stand-alone
document.

Preliminary — Due by SRR
Final - Due by PDR

Page 32



SpaceDOC Attachment J-2

maintenance; number and types of downlinks.
H. Operational Factors - such as ground contacts needed per day, data storage capacity and

i. compression, general flight rules and limitations, real-time downlink, post-test downlink, ground
support personnel training during operation.

J. Training Simulators — crew training

Show sufficient detail on both sides of each interface to provide a clear picture of the resultant mated interface.
For example, electrical interfaces should be presented to schematic detail (logic elements and piece parts) to
the point where impedance and transfer characteristics no longer affect the interface.

Draft - Due for SRR
Preliminary — Due midway between SRR and PDR
Final — Due for PDR, update as required 60 days after PDR

Page 49



SpaceDOC Attachment J-2

Title: DID No.: PA-01
Product Assurance Plan

Reference:

GRC Product Assurance Manual (PAP #100)

GRC Space Assurance Requirements and Guidelines (SARG)

CxP 70059 - Constellation Program Integrated Safety, Reliability and Quality Assurance (SR&QA)
Requirements

Purpose:
Documents the assurance approach the contractor intends to use and helps the Government understand how

the contractor will assure the safety, quality and reliability of space experiment systems and components.

Related Documents:

PA-02: System Safety Plan

PA-06: Materials Identification and Usage List; Material Usage Agreement (MUA)PA-07: Problem Reporting
and Corrective Action

PA-11: Software Assurance Plan

Preparation Information:

This document will define the contractor's plan to apply relevant assurance principles and techniques to
ensure the FCF or Delivery Order will be successfully accomplished and the applicable SARG requirements
will be satisfied. The plan shall include, but not be limited to, the following information:

a) Reliability - A detailed description of how each specified Reliability management, engineering, and
EEE parts control task will be performed or complied with in performance of the hardware
development.

b) Quality Assurance - Identify all elements of the quality assurance organization, and describe the
objectives, implementation policies and procedures, and control systems utilized throughout design,
development, fabrication, delivery, and usage to provide quality products and materials.

¢) Maintainability - identify all elements of the maintainability assurance organization, and describe
objectives, implementing policies and procedures, and control systems to provide maintainability
assurance.

Note that Safety, Materials and Processes, Problem Reporting and Corrective Action, and Software Assurance
plans may be included in this plan or prepared as separate documents (see PA-02, PA-06, and PA-07)

Note: A general Product Assurance Plan can be established for the contract with each project determining any
deviations from that plan.

Draft ~ Due 60 days prior to SRR
Preliminary ~ Due midway between SRR and PDR
Final - Due 60 days before ATP and /or PDR, update as required 30 days after ATP and/or PDR

Page 31


SpaceDOC Attachment J-2

Title: DID No.: V-03
Individual Item Verification Report

Reference:
SSP-57010 Pressurized Payloads Generic Payload Verification Plan (ISS Only)
SSP-57011 Payload Verification Program Plan (ISS Only)

Purpose:
For verification requirements found in the Master Requirements and Verification Compliance Plan/Matrix (v-

01) and per the related Individual Item Verification Test/Demonstration Procedure (V-02), document in detail
the results of verification activities. Such data will be used to demonstrate compliance with applicable
requirements.

Related Documents:

V-01: Master Requirements and Verification Compliance Plan/Matrix
V-02: Individual Item Verification Tes’Demonstration Procedure
V-04: Software Verification and Validation Plans

PA-05: Safety Compliance Data Package

D-07: Safety-Critical Structures Data Package

0-08: Fracture Control Summary Report

Preparation Information:

Each Individual Item Verification Report shall describe the verification results and shall be prepared ina
manner that relates each result to the requirement(s) being satisfied. The following information shall be
included:
e Verification objective(s) (including Requirement Number)
¢ Description (as applicable) of: test setup; and/or analysis approach; and/or inspection
technique/criteria
° Identification of item(s) verified (name, part number, and serial number) as well as any differences
from the flight configuration.
* Copy of “as performed” procedure (e.g., could append "as performed" Individual Item Verification
Test/Demonstration Procedure, V-02), if a test or demonstration. .
e Summary of appropriate Product Assurance Procedures (including calibration procedures) used.
e Correlation of verification results with the requirements
_.Summary of deviations from_nominal results, failures, difficulties,, corrective actions, failure, reports,.
and nonconformance reports.
* Performance data, plots, pictures, and location of raw data and calibration curves as generated during
the verification activity.
* Conclusions and recommendations.
e Signed approval by the Quality organization

Verification Reports are due 45 days after completion of the test/analysis/inspection.

Page 68



SpaceDOC Attachment J-2

shall notify the Contracting Officer immediately, since any approval of documents or data is
not to be construed as a change in contract requirements.

e) Approval by the Goverriment shall not be construed as complete approval, but will indicate
only that the general method or data is satisfactory. Approval of the documents or data will
not relieve the Contractor of the responsibility for any error that may exist. If previously
approved portions of a document are disapproved by the Government at a later date due to
reason other than requirement changes (editorial, format, programmatic), an impact
assessment will be performed by the contractor.

Typically for documents provided for design review, the Government will screen the documents
for acceptability and will notify the Contractor in writing whether they are approved for submittal to
the design review process. The Government will also provide general comments for those
documents considered not acceptable. Any document screened and considered not acceptable
will be updated by the contractor prior to the review, or as agreed between the contractor and
Government. This screening should take place generally within 15 calendar days of document
receipt to allow the Contractor time for document improvements.

Contractor deliverables, requiring Government approval, are considered to be received on time
provided that; 1) the document is received by the NASA Delivery Order Project Manager on or
before the contractual due date; and 2) that the document is approved by the Government during
the initial review and approval process described in paragraph "1.7 a)” above.

1.8 RID and RFA Disposition Process:

Review Item Discrepancies (RIDs) are generated as part of the project design review process or on
documents submitted for the design review. RIDs should be limited to requirements issues, methodology
or process issues, or requirements compliance issues. Editorial comments to documents should be
provided in written format to the contractor, outside the RID process. Prior to the review, the Government
Project Manager shall determine the set of “RID-able” documents for the review. This listing should be
provided to the contractor four (4) weeks prior to the review.

Request for Action (RFAs) are also generated as part of the project design review process and are
generally identified by the Design Review Panel. RFA's are significant issues, either being specific to a
single requirement or may address a broad range of requirements/process issues.

RIDs are to be processed in the following manner:

1. The Government is to submit to the Contractor all RIDs and RFAs requiring the contractor's
response within 30 calendar days of the completion of the design review presentation.

2. The contractor shall have up to 30 calendar days upon receipt of each issue to assess,
document, and submit their position regarding the validity of each concern. The contractor's
submittal will identify the proposed action to address each individual RID finding or justify the
contractor's position that a specific RID is invalid. The Government will identify out of scope
RIDs that require impact assessments. Additional out of scope RIDs, or RiDs that will result
in contract cost or delivery schedule impacts, discovered by the contractor will be identified
for the Government's assessment.

3. Government has 30 calendar days upon receipt of the Contractor's response to finalize the
action plan and notify the contractor. The action plan will identify whether the response will
be accepted or rejected, the rationale for disposition, and the action to be taken. The
response can be a spreadsheet, or similar data management tool, that clearly identifies each
of the issues and the actions to be taken for each.

4. Within 30 calendars days of the cempletion of the acticn plan, both the Government and the
contractor will take the necessary steps to incorporate any changes required to the contract
documentation due the accepted action.

5. The Contractor will notify the Government when the action plan for accepted RIDs has been
completed.

6, The RID and RFA is officially closed by the Government.

Page 8


SpaceDOC Attachment J-2

DID No.:__PM-04

Configuration Management Plan

Reference:

MIL-STD-973 Configuration Management

NASA-STD-2100-91 NASA Software Documentation Standard

ISO 10007 Quality Management - Guidelines for Configuration Management

NPR 7150.2 NASA Software Engineering Requirements (Software Configuration Management Requirements
only)

Purpose:
To identify and describe the Contractor processes and methods for Configuration Management (CM) to be

used during the implementation of the contract and project/Delivery Orders. This plan establishes the basis for
a uniform and concise CM practice for all contractor-provided hardware/software elements and selected
documentation in a manner that is responsive to appropriate, applicable requirements.

Related Documents:

PM-01: Contractor Project Plan

PA-01: Product Assurance Plan

PM-03: Software Management and Development Plan

PM-05: Engineering Change Proposals (ECPs), Deviations and Waivers

Preparation Information:

The CM plan shall describe the Contractor's configuration management system in terms of applicable
requirements, planned implementation methods, configuration verification methods, schedules, and
organizational structure as well as management tools to be used by the Contractor in the execution of this CM
effort. The CM plan shall also describe the functions, responsibilities, and authority for the accomplishment
and implementation of configuration management to be performed during the full term of the contract. The CM
plan shall include both hardware and software aspects of configuration managements. The plan shall specify
the Contractor's management policies and identify, by specific reference, standard practices and detailed work
instructions to be used in implementing the configuration management process. This plan shail include, but is
not limited to, the following:

a. CM Organization (objectives, organizational structure, authorities and responsibilities (individual and
organizational))

b. CM Interfaces with oversight and control of work and assurance of integrated configurations
(Government and major subcontractors)

c. CM System Description (CM Standards, CM requirements stated or implied in particular, those driven by
a flight carrier, Processes, Software CM processes, etc.)

d. CM Tools (software tools, techniques, and equipment necessary for the implementation of the specified
software configuration management activities

e. CM Status Accounting (access to accurate, timely information about the product and its documentation,
reports of status to the Government or its auditors, verifiable trace for all deliverable end item
configurations)

f. inventory Management (tracks flight equipment, GSE equipment, and other operational support
hardware, etc.)

g. CM Schedule (sequence and coordination for the identified CM activities and for all events affecting the
CM plan's implementation)

h. CM maintenance information (identifies the activities and responsibilities necessary to ensure continued
CM planning during the lifecycle of the contract)

Draft — Due 60 days after contract award
Preliminary — Due 90 days after contract award
Final — Due 30 days after review and comment on the preliminary plan by the CoTR or his designee

Page 22


SpaceDOC Attachment J-2

Title: DID No.: D-06
Software Design Document

Reference:

GRC Software Development Manual;

NASA-STD-2100-91 NASA Software Documentation Standard (NASA-DID-MO00 through M700)
NASA STD 8719.13A (Software Safety NASA Technical Standard)

IEEE 12207 Software Development Standards

PM-03: Software Management and Development Plan

PA-10: Software Assurance Plan

Purpose:
This Software Design Document (SDD) is the top-level CSCI design document that describes the functional

requirements, interface design, data requirements and architectural design of the system CSCI in sufficient
detail to permit coding of the software.

Related Documents:
R-02: Interface Definition Document and Interface Control Document
R-04: Software Requirements Document

Preparation Information:

This document establishes the structure and organization of the systems Computer Software Configuration

Item (CSCI); allocates the CSCI functions specified in the applicable Software Requirements Document and
Interface Control Document to preliminary Computer Software Components (CSC) of the CSCI; and defines
the internal and interface requirements of each CSC.

A general organization of the document is outlined below and should be used as a guideline only:

A. Introduction
B. System Overview [Purpose of the system and the software]
C. Applicable Documents [List of documents referenced in the document]
D. Design Approach and Tradeoffs {Describes rational for major decisions affecting the design]
E. Design Model {Interaction Diagrams & Coding notes related to compiler
options & problems]
F. Computer Software Components [Subsection on each Computer Software Component]
G. Cross Reference to Software [Table which traces each requirement into a
Requirements Document specific CSC paragraph number in this document]
H. Notes
1. Appendices ° ° noe”
J. Glossary [Acronym list and definition of terms]
K. Index

Preliminary version at PDR
Final (Code-To) version for CDR, update as required 60 days after CDR

Page 59



SpaceDOC Attachment J-2

Title: DID No.: OP-10
Decommission Plan

Reference:
TBD

Purpose:
Define the end-of-life for the hardware and associated documentation. The plan should also define the

archiving of the data and final reports required.

Related Documents:

Preparation Information:
TBD

Page 83



SpaceDOC Attachment J-2

EMI/EMC/ESD Test (conducted and radiated)

Vibration Test

Acoustics Test

Toxic Off-gassing

Thermal Cycling Test

Thermal Vacuum Test, if applicable

Leak and Pressure Test, if applicable

Corona Test, if applicable

Thermal Balance Test (thermally map subsystems and verify performance and reliability).

For performance requirements portion of the Plan, the following should be included as a minimum:
e End-to-End Functional Tests, including commanding and communications
e Final Comprehensive Performance Tests and Acceptance Tests
e Mass Properties Measurements
e Optical and Mechanical Alignments

Master Requirements and Verification Compliance Plan & Matrix

Preliminary is required at PDR.

Final is required at CDR.

Revisions as required at VRR/TRR.

Status of verifications (summary) and “as run” environmental test procedures at PSR.

Page 66


SpaceDOC Attachment J-2

Title: DID No.: PA-9
Contamination/Cleanliness Control Plan

Reference:

JSC SN-C-0005 Contamination Control Requirements

SP-5076 NASA Contamination Control Handbook

MIL-STD-1246B Product Cleanliness Contamination Control Program
Space Assurance Requirements and Guidelines (SARG) - Section 8
GRC Product Assurance Manual (PAI #612, #615)

Purpose:
Describes the methods and procedures for controlling and assuring limited impact of contamination during

hardware development, transportation, flight and storage phases.

Related Documents:
PA-01 Product Assurance Plan

Preparation information:
The following items shall be included in the plan:

A) Hardware Control Requirements and design considerations that include surfaces, electrical, optical,
and fluids.

B) Facility Requirements and controls
C) Personnel requirements and work area controls
D) Description of what cleanliness control measures will be used.

Preliminary - Due for PDR
Final — Due prior to flight hardware development/assembly

Page 39


SpaceDOC Attachment J-2

Title: DID No.: OP-06
TSC Security Plan

Reference:
NMI 1600.2a, NASA Security Program

Purpose:
To provide security management planning and processes for the TSC facility and infrastructure (computers,

network, etc.)

Related Documents:
CD-04: Automated Information Security Plan

Preparation Information:

Suggested contents (but not limited to):

Roles and responsibilities of key personnel
Information security controls

Incident response

Awareness training

Facility access control

Computer access control

Foreign national security

Personnel security controls

Intrusion detection

Visitor policy

cr rommogm>

Page 79



SpaceDOC Attachment J-2

Title: DID No.: PA-10
Software Assurance Plan

Reference:

GRC Software Development Manual

NASA-DID-M400

Space Assurance Requirements and Guidelines (SARG)
GRC Software Product Assurance Procedure GRC-P.2.10.2

Purpose:
Documents the assurance approach the contractor intends to use for software development and helps the

Government understand how the contractor will assure the Management, safety, and contro! of the software
products.

Related Documents:

PM-04: Configuration Management Plan

PA-01: Product Assurance Plan

PA-03: Software Management and Development Plan

Preparation Information:

This document will define the contractor's plan to apply software assurance principles and techniques to
ensure the Delivery Order will be successfully accomplished and the applicable SARG requirements will be
satisfied. The Software Assurance Plan may be part of the Product Assurance Plan (PA-01) or written as a
stand-alone document for each task. The Contractor shall use the above references as a guide to preparing
this document.

(Note that a Software Assurance Plan will be required for each space flight payload deliverable.)
Draft — Due 60 days prior to SRR

Preliminary ~ Due midway between SRR and PDR
Final - Due 60 days before ATP and /or PDR, update as required 30 days after ATP and/or PDR

Page 40


SpaceDOC Attachment J-2

Title: DID No.: D-03
Baseline System Description (Baseline Concept Description)

Reference:
AFMC Pamphlet 800-62

Purpose: .
Aworking document that provides a comprehensive overview of the system, describing key requirements and

problems, proposed solutions and overall system and subsystem descriptions through an easily understood
format of pictures and narrative. The BCD, and then the BSD, is the single, authoritative summary document
that describes the primary system functions and the technical solutions that defines the system and the
interrelationships.

Related Documents:

R-01: System Requirements Document

R-02: Interface Definition Document and Interface Control Document
D-05: Accommodations Handbook

Preparation Information:

The Baseline Concept Description (BCD) is utilized in the formative development of the system (hardware and
software) that provides an overall description in an easily understood format used by the team and the
Government as a communication tool, and as a point of departure for briefings, studies and cost estimates.
The document begins as a brief record or overview of the system utilization environments, requirements,
boundaries, constraints and general concepts, and evolves, in parallel with system development, into a more
complete, formal structure.

The Baseline System Description (BSD) document evolves from the BCD, and documents the overall system
design that meets the system requirements and grows in depth as details of the system matures. A general
organization of the document is outlined below and should be used as a guideline only. In preparing a
BCD/BSD for a specific system, the document must reflect the requirements of that project being documented:

Introduction of System/Problem

Deployment Concept/Carrier Accommodations
System Technical Description

Operations Concept

Support Concept

Manufacturing Concept

Verification Concept

Design Safety Considerations

PNOAP ON >

Each of the areas should determine the environment, constraints, boundary conditions, interfaces, critical
tisks, and unknowns.

Preliminary: Due for SDR
Final: Due for PDR, convert to BSD for CDR

Page 55



SpaceDOC Attachment J-2

Title: DID No.: PM-07
Software Sustaining Engineering Plan

Reference:

NASA STD 2100-91 (NASA Software Documentation Standard) NASA-DID-M300
NASA STD 8719.13A (Software Safety NASA Technical Standard)

IEEE 12207 Software Development Standards

Purpose:
This document provides sustaining engineering and supporting operation of the software and firmware as

installed in the overail system in terms of activities, methods and approach, controls, and support environment
requirements. It is important to address activities after delivery of the software and firmware and prior to
initiation of sustaining engineering and operations for the software and firmware in question.

Related Documents:
PM-03: Software Management and Development Plan
PM-04: Configuration Management Plan

Preparation Information:

This document shall describe the methods to be used to specify modifications or new functional requirements.
Also describe how to translate these requirements into design and how to integrate and test the new release in
any system using the software or firmware being modified.

This document shall also describe the process by which change requests are to be submitted, classified and
analyzed, dispositioned, and scheduled in any entity containing the software or firmware being changed.
Include the process for tracking and maintaining software and firmware revisions in the configuration
management system for all entities using the software and firmware in question. Include classification
categories for requests and any variations in the process. Describe all associated products and reports.

This document shall also describe the engineering process, methods, etc., to be used to incorporate approved
change requests. Include a description of maintenance procedures for developing on-site and remote
diagnostics, Include the method for producing documentation updates (including user support materials) to
accompany a release and for distributing them to all operators and end users concerned.

This document shall describe the process interfaces between sustaining engineering (maintenance) engineers
and configuration management, assurance, and operator organizations. Describe interfaces with the user
community and how releases are generated and delivered.

This document shall describe the training plan for sustaining engineering, operations, and other support
personnel.

For recommended document outline see NASA-STD-2100-91

Page 28



SpaceDOC Attachment J-2

Preparation Information:

The Accommodations Handbook provides information on the system design, capabilities, performance
characteristics, and constraints to enable users to design experiment hardware to be accommodated by the

system.

The handbook will provide descriptions, definitions and requirements for user interfaces, support

systems, operations, environments, and safety aspects of the system so that users can properly design and
build payload equipment.

A general organization of the document is outlined below and should be used as a guideline only:

SLMNOARON>

Introduction

Applicable Documents

General Description of the System
Accommodations/Resources/Capabilities

Interfaces (Mechanical, Electrical, Software, Fluids, Optical, etc.)
Support Equipment and Facilities

Operating Environments

Integration & Verification Requirements/Services

Training & Operations

Safety Requirements

Items that should be covered in this document within the outline include:

Auxiliary equipment provided to the user (when applicable; e.g., facility-provided diagnostic
subsystems, standard containers, shipping containers, ground terminals, etc.)

General user design requirements and guidelines (e.g., materials constraints/controls, EMC
specifications, environmental test guidelines, etc.)

Required activities related to user integration and operation of the system (e.g., ground test and pre-
launch operations, training requirements, flight operation guidelines post-flight operation guidelines,
etc.)

Services and accommodations provided to the user in support of the design, development, and
utilization of the system (e.g., detailed documentation, access to existing hardware (simulators,
engineering hardware, custom test equipment, trainers, on-site laboratory support and services, etc.)
Guidance for user project planning (e.g., recommended schedule template for development, review,
test and delivery of documentation, etc.)

.This. document should reference applicable detailed design requirements and point.to the evolution of a
negotiated, detailed interface document when applicable.

Page 58



SpaceDOC Attachment J-2

Title: DID No.: V-02
Individual Item Verification Tes/Demonstration Procedure

Reference:
SSP-57010 Pressurized Payloads Generic Payload Verification Plan (ISS Only)
SSP-57011 Payload Verification Program Plan (ISS Only)

Purpose:
For test and demonstration verification requirements found in the Master Requirements and Verification

Compliance Plan/Matrix (V-01), provide detailed, step-by-step procedures to perform the verifications.

Related Documents:

Master Requirements and Verification Compliance Plan/Matrix (V-01)
Individual Item Verification Report (V-03)

Software Verification and Validation Plans (V-04)

Preparation Information:

For each individual requirement identified in the Master Requirements and Verification Compliance Plan/Matrix
(V-01) that is to be verified by test or demonstration, provide a detailed step-by-step procedure (set up much
like a checklist) to accomplish the verification. Multiple requirements can be covered in one procedure. These
step-by-step procedures shall be entirely consistent with the information in the standardized forms and table
found in the Master Requirements and Verification Compliance Plan/Matrix (V-01). They shall be of a common
format with the other Individual Item Verification Test/Demonstration Procedures (V-02). Each procedure shall
include drawings, graphics, tables and other information that is applicable to conduct the verification and
interpret the results. A given requirement may require two detailed plans -- one for pre-launch verification and
one for on-orbit acceptance.

The procedures shall be written and structured to facilitate quality assurance surveillance activities during
verification activities.

Page 67



SpaceDOC Attachment J-2

3. A proposed standard is expected for each and every CDRL DID. In some cases, a single
standard may be applicable to more than one CDRL item, and, therefore, may be proposed in
tesponse to multiple CDRL items. If no standard exists, indicate how you will generate one,

1.4 Distribution and Delivery

The contractor shall distribute and deliver data according to contract requirements and provisions.

An electronic copy of the transmittal letter and the deliverable document master copy will be deposited
into the Government's electronic storage drop box and notification of document drop shall be provided by
e-mail to:

SpaceDOC
Configuration Management Office
(E-mail address to be supplied with the DO)

Copies of the transmittal letter, deliverable document signature pages and electronic copy of the entire
document shall be provided to:

NASA Project Manager
(Address to be supplied with the delivery order)

Copies of the transmittal letter only, without the enclosures shall be provided to:

NASA Glenn Research Center
SpaceDOC Contracting Officer (CO)
MS 500-306

21000 Brookpark Rd.

Cleveland, OH 44135

NASA Glenn Research Center

SpaceDOC Contracting Officer Technical Representative (COTR)
MS 77-7

21000 Brookpark Road

Cleveland, OH 44135

1.4.1 Definition of Deliverables

The following defines the content of the items identified above and shall be provided for each data item
submission:

a) Original Document — Is the official final document which is signed in ink by all parties and
maintained by the contractor's Configuration Management organization. The contractor retains
signed originals until the completion of the project, when all original document records are
transferred to the Government for archiving. With the exception of drawings, electronic
signatures are not accepted as approval designations.

b) Master Copy - Is the official file copy submitted in the form in which it is intended to be
distributed and will be signed by the contractor's Configuration Management organization. The
Master Copy is suitable for reproduction and is a copy of the original, signed document.

c) Copies - The number of printed media copies of each document, if applicable, shail be
specified in the delivery order and shall be delivered in a condition suitable for immediate
distribution.

d) Electronic Data Delivery - Formats for electronic media delivery are defined in paragraph 1.5 of
this document, Attachment J-5. Delivery of electronic media data items shall occur per the
same delivery schedule as printed media.

Page 4


SpaceDOC Attachment J-2

Title: DID No.: R-01
System Requirements Document

Reference:
SSP-41171 International Space Station Program; preparation of program, unique specifications

Purpose:
This document will define the engineering requirements generated from the science requirements (if

appropriate), the performance, design, development and verification requirements for the hardware, and the
resource requirements, training requirements and quality assurance provisions. This document will also define
all requirements needed to successfully develop the hardware that includes interface requirements between
the payload and carrier by reference or inclusion.

Related Documents:

R-02: Interface Definition Document and Interface Control Document
R-04: Software Requirements Document

V-01: Master Requirements and Verification Compliance Plan, etc.

Preparation Information:

List all requirements needed to successfully build the hardware and how they are to be implemented. This
document will ensure that all requirements are by definition: quantifiable, verifiable, and specific. The
document shall provide detailed information tegarding the interface between the Payload and the carrier and
should provide per the following topics as a minimum:

a) Missions — Life cycle, operations, crew resources.

6) Science Requirements — as they pertain to capability of hardware provided.

c) Reliability - Failures Modes Effects Analysis (FMEA), Parts Stress Analysis (PSA), Worst Case
Analysis, Reliability Models/Predictions, Limited-Life !tems, Problem Report and Corrective Action
(PRACA)’s.

d) Mechanical Environment — Vibration, shock, acceleration, noise.

e) Thermal Environment — flight environment (on-orbit cabin temp, Ascent/Descent temp/press, surface
temp), atmospheric pressure.

f) EMVEMC Environment

g) Radiation Environment

h) Operations

i) Mechanical Design Requirements

j) Interface Requirements — Thermal, electrical Power, command/data handling, Ground Support
Equipment (GSE)

k) Induced Environment — natural and experiment

!) Operational Requirements

TMm) Material Controls — off-gassing, flammability, stress corrosion cracking, materials selection, process
selection, fracture control

n) Contamination and Cleanliness

©) Configuration Contro! Safety — Safety compliance, verifications (flight & ground handling)

Pp) Quality Assurance (including Software Product Assurance)

Draft — Due for SRR
Preliminary — Due midway between SRR and PDR
Final — Due for PDR, update as required 60 days after PDR

Page 47



SpaceDOC Attachment J-2

Title: DID No.: PA-15
System Maintainability/Availability Analysis

Reference:
Space Assurance Requirements and Guidelines (SARG) - Section 7

Purpose: The System Maintainability/Availability Analysis is utilized by the designers to estimate the steady-
state operational availability of a particular design within mission parameters. Operational Availability
estimates for sub-systems, Orbital Replaceable Units (ORUs) or Line Replaceable units (LRUs) are compared
to their availability allocations (design targets). This analysis serves to identify design risks that could limit
ability of the system to operate during the life of the mission and thereby threaten mission success.
Specifically, the analysis evaluates the system, subsystems and components to determine where: (1) reliability
improvement is required, (2) design changes are needed to improve maintainability, and (3) changes in
sparing approach, spares logistics planning, etc. are needed to improve design supportability. (Note that this
analysis requires performing and utilizing related analyses, such as, reliability analysis (e.g., PA-14),
maintainability analysis, limited life analysis (e.g., PA-15), preventative maintenance analysis, and spares &
logistics analysis (e.g., OP-13).)

Related Documents:

SSP 50431, Space Station Program Requirements for Payloads

LeR-W0510.061, Reliability Prediction/Maintainability Assessment/Availability Analyses
OP-13: Firmware Support Manual

PA-14: Reliability Report(s)

PA-15: Limited Life Items List

Preparation Information:

This Data Item Deliverable shall document system availability analyses performed by the developer. The
predicted steady-state operational availability for the system over the elapsed mission time shall be compared
to the specified overall system availability requirement. Availability allocations shall be developed for each
subsystem or major component of the system, which represent the availability design/supportability goals that
must be met for the system to meet its overall availability requirement. The analysis shall provide an
availability model of the system in terms of a reliability block diagram. It shall include the component mean-
time-between failures (MTBFs), mean-time-to-repair/replace (MTTRs), and mean-logistics delay times
(MLDTs) for each block and their data sources. Components for availability improvement shall be identified
and recommendations can be made for design improvement, higher quality level of parts, improved sparing,
improved cooling capability, additional active or passive redundancy or reduction in planned operating time.
This analysis shall also reflect the results of the developer's maintainability and preventative maintenance
analyses, including 1) identifying which components in the system are designated as ORUs/LRUs; 2) how
these components will be spared and maintained and 3) how preventative maintenance shall be conducted,
especially with respect to limited life items that are safety critical. The analysis shall include a list and
schedule of all recommended maintenance activities needed to keep the system equipment operating within
performance parameters and keep the entire system operational over the required mission life.

Allocation due 90 days prior to PDR.

Preliminary Prediction: to be complete for PDR.

Revised Prediction to be completed 30 days prior to CDR.
Final Prediction at PSR.

Page 45



SpaceDOC Attachment J-2

Title: . DID No.: V-05
Integration/Acceptance Data Package (Certificate of Flight Readiness)

Reference:

GRC Product Assurance Manual (PAI #332)

SSP 52054 - ISSP Payloads Certification of Flight Readiness Implementation Plan, Generic (ISS Only)
Space Assurance Requirements and Guidelines (SARG) - Section 8

Purpose:
Describes the deliverables required for submittal to the Government to certify that the delivered system

(including hardware, software, ground equipment, and other items comprising the system) is fully suitable for
its intended mission, will perform as required, and is ready for Government acceptance. The acceptance data
package shall meet the requirements to obtain COFR for the flight payload. Government review and approval
of all deliverables described in the plan should lead to formal, final Government acceptance of the system.

Related Documents:

V-01: Master Requirements and Verification Compliance Plan, etc
V-02: Individual Item Verification Test/Demonstration Procedure
V-03: Individual Item Verification Report

V-04: Software Verification and Validation Plan

V-06:_As Built Configured Item List

Preparation Information:

The Acceptance Data Package should consist of the following pertaining to the hardware history:

a) Index Page: identifies deliverable item name, type of hardware, content of package, and

appropriate deliverable data package approval signatures and date

b) DD250/1149 (or other recognized government shipping document)

c) Component/Equipment Historical Logs for Limited Operating/Age Sensitive Items

d) Identification of the As-Built Configuration

e) Waiver/Deviation Records (affecting integration, safety)

f) Failure Reports/Corrective Action Record/Unexpiained Anomalies

g) Maintenance Instructions

h) Verification Test Reports identified as Acceptance Criteria activities in the Verification Plans

i) Unplanned/Deferred Work (exception basis only)

j) Cleanliness Certification
ond) Developer. Certification:««: isin
!) Open Items from Phase Ill Ground Safety Review
m) MSDS - Material Safety Data Sheets
n) Pressure Vessel data
0) Program Listing (software)

p) Version Description Document (software)
q) User's Guide or System Operating Manual (software)

ISS Payloads shall meet the requirements of SSP-52054, "ISSP Payloads Certification of Flight Readiness
Implementation Plan, Generic." All other payloads shall meet the specific COFR requirements of the carrier.

Page 70



SpaceDOC Attachment J-2

Title: DID No.: CD-03
Technical Reporting and Management Reviews

Reference:

Purpose:

To provide a monthly report that will be used to measure the Contractor's progress in completing the activities
required by the contract.

Related Documents:
CD-01 Financial Management Reporting
PM-02: Risk Management Plan

Preparation Information:
A. Delivery Order Level Reporting

The Contractor shall deliver Monthly Technical Reports for each delivery order — The reports shall

contain as a minimum; schedule, technical accomplishments, problems/issues/risks and mitigation

strategies, and near-term activities and the EVM reporting when required in accordance with CD-02.
B. Contract Level Reporting/Reviews

The Contractor shall deliver:

1. Monthly Technical Report Summary - a. a listing of delivery orders with problems and/or issues
not resolved within the three (3) preceding reporting periods including associated performance
improvement plans, and b. a listing of delivery orders with SPI or CPI less than 0.90 (color coded
RED) including associated improvement plans.

2. Quarterly Management Review — The contractor shall attend a quarterly management review with
the Government and present:

i. asummary of contract activities associated with delivery orders which have met the
criteria for B. above during any month of the preceding quarter,

ii, particularly challenging accomplishments
iii. anticipated challenges for the following quarter and
iv. acontract cost, schedule and performance summary.
In addition, the Quarterly Management Review agenda may include presentation by the

Government regarding: COTR issues, management issues, and Contracting Office issues.

All written reports shall be submitted within 15 calendar days of the close of the Contractor's accounting
month.

Page 15



SpaceDOC Attachment J-2

Title: DID No.: D-05
Accommodations Handbook

Reference:

Purpose:
This document is the primary source of system data, interfaces and requirements levied upon each user for

experiment design and integration. The document shall provide information to users of the subject
hardware/software system including descriptions of the interfaces, resources, capabilities, performance
characteristics, and constraints provided by or due to the subject system. This document will provide
guidelines and assistance to payload developers or users who must integrate hardware/software subsystems
with the subject system and should provide support for the design, fabrication, and the operation of user
hardware/software that is accommodated within or utilized with the subject system. For complex systems (e.g.,
facility class hardware), this handbook should contain a comprehensive description of capabilities, interfaces,
and operations providing potential users with adequate detail to confidently approach conceptualization of
experiments.

Related Documents:

R-01: System Requirements Document

R-02: Interface Definition Document and Interface Control Document
D-03: Baseline System Description

Page 57



SpaceDOC Attachment J-2

Title: Worst-Case Analysis DID No.: D-09

Reference: Space Assurance Requirements and Guidelines (SARG) — Section 7
PA-02: System Safety Plan

Purpose: Worst-Case circuit design analysis is a design task that evaluates circuit designs to assure that
components and circuits can support safety and mission critical functions when subjected to worst-case circuit
parameter variations. Supports: (1) Safety and reliability of electrical circuits (2) overall system reliability (3)
elimination of circuit overheating or fire.

Related Documents:
SSP 50431, Space Station Program Requirements for Payloads
PA-08: Failure Modes and Effects Analysis (FMEA) and Critical Items List (CIL)

Preparation information:

Worst-Case Analysis General Method

Worst-Case Analysis has to be performed on all circuits that carry power or data signals that support safety
and mission critical functions. The analysis considers the most sensitive design parameters that could be
subject to variations and could degrade performance. The analysis should consider all circuit parameters set
at worst case limits and worst case environmental stresses for the function or operation being evaluated.
Depending on mission parameters and part selection methods, part parameter values typically include
temperature, voltage, frequencies, part type and design, aging effects from the environment, variability from
cumulative effects of radiation or variability due to manufacturing. The analysis should indicate if circuit
performance can be maintained under worst case conditions.

Final Worst-Case Analysis should be completed by Phase III Safety Review

Page 63



SpaceDOC Attachment J-2

Title:

SpaceDOC Management Plan

DID No.: PM-01

Reference:
NPR: 7120.5D, NASA Space Flight Program and Project Management Processes and Requirements
NPR: 7120.8, NASA Research and Technology Program and Project Management Requirements

Purpose:
The SpaceDOC Management Plan shall describe the contract implementation approach, including the

systems and processes, to provide overall coordination of contract management activities. It describes the
structure and environment within which the contract and subcontract management operates.

Related Documents:

PM-02: Risk Management Plan; PM-03:. Software Management and Development Plan;

PM-04: Configuration Management Plan; PM-09: System Engineering Management Plan; PA-01: Product
Assurance Plan; CD-05: Earned Value Management Plan

Preparation Information:

The Contractor shall provide information giving NASA insight into staffing, organizational structure,
approaches and processes used to manage activities across the SpaceDOC contract. The plan shall cover ali
aspects of contract and subcontract management for the SpaceDOC contract including, but not limited to, the
following:

a.

Narrative and graphical descriptions of the management approaches used to accomplish and monitor
contractual tasks including the establishment and implementation of a review board process

Narrative description of roles and responsibilities of responsibilities of the contract's key personnel
Management approach for Delivery Order work plan development and execution

Management approach to routinely review project Delivery Orders (DOs) internally to address cost,
schedule, technical progress, concerns, and issues including:

« Management approach to processes, plans and procedures for cost, schedule, and technical
baseline control and systems engineering including a process for change order review,
approval and implementation .

« Controls applicable to any tasks and activities exceeding established cost or schedule plans
including requirements for providing recovery plans

e Description of performance reporting to NASA in preparation for major milestone reviews

Management support system method, tools, and implementation

Methods for providing government insight, data accessibility, and/or deliverables

Approach to interfaces with other contractors or entities that are necessary and pertinent to the
accomplishment of contractual tasks, including such things as data, analyses, equipment, software
deliverables, schedules, interfaces, and other technical/managerial interactions.

Approach to establishing and implementing agreements and/or cooperative relationships with
associate contractors or with any other parties necessary for the completion of the work under this
contract.

Risk methodology and assessment of risks inherent in the management approach, including a process
for incorporating lessons learned from previous applicable contracts and continuous improvements

Acquisition strategy including a description of the procurement process and the make/buy decision
process

Approach to the establishment and management of subcontracts

Description of the approach for providing regularly scheduled Contract level reviews

Page 17



SpaceDOC Attachment J-2
SECTION 1 - Contract Data Requirements

4.1 Scope

a) The Contract Data Requirements List (CDRL) is the basic contractual document, which governs
data required by and for the contract.

b) The contractor shall furnish data described by the Data Item Descriptions (DIDs) included
herein and listed on the Contract Data Requirements Lists (CDRLs) for each item of data
requested as a deliverable in the Delivery Order. DIDs that are not called out ina specific
Deliver Order Statement of Work will not be required for that Delivery Order.

c) All data shall be prepared, maintained, and delivered to NASA in accordance with the
requirements of this document, Attachment J-5.

1.2 Contract Data Requirements List (CDRL)

The CDRLs provide a complete listing of the data requirements of the contract. Each CDRL contains the
following:

a) The data item number, which corresponds to the data item description number.
b) The data item title.
¢) The data item approval code defined as follows:

1, Code NDA [NASA Document with NASA Approval]: The initial submission and all
subsequent changes require approval of the NASA contracting officer or designee; Class |
changes (definition: no change to technical scope or cost) require this approval prior to
implementation.

2. Code A [Approval]: The initial submission and all subsequent Class 1 changes require
approval of the NASA contracting officer or designee prior to implementation

3. Code | [Information]: Deliverables are sent to NASA for information purposes only. NASA
will request changes on deliverables where errors or omissions are noted through the use
of Review Item Discrepancies (RID), if necessary.

4. Code S [Surveillance]: Document and/or data need not be delivered to NASA but should
be made available for information upon request or during surveillance activities.

Delivery Orders instructions may supersede these approval codes.

1.3 Data Items Description
a) Each data requirement listed on the CDRL is defined bya DID.

1. The DID describes the purpose and required content of the data item, and provides specific
format and preparation instructions as necessary. Each DID page has a “Reference” item box.
This reference item box may refer to a standard or a guidance document or may be empty.
Some DIDs will mandate the format and standard to be used and will be identified in the
“Preparation Instructions"; otherwise the reference is for guidance purposes, The "Related
Documents” item box refers to other data deliverables that will most likely have supporting
information that should be referenced with minimal duplication of information.

2. In many DiDs, the contractor shall propose the standard to be used that meets the DID item
requirement most cost effectively. Much of the information requested in the DIDs may already
exist in contractor documentation and format processes. The Government strongly encourages
the contractor to utilize existing documents and formats whenever it will meet the requirements
of the DID.

Page 3


SpaceDOC Attachment J-2

Title: DID No.: PA-08
Failure Mode and Effects Analysis (FMEA) and Critical Items List (CIL)
Reference:

GRC Product Assurance Manual (PAI #41 2)

Space Assurance Requirements and Guidelines (SARG) - Section 7

SSP 50431, Space Station Program Requirements for Payloads

SSP 30234, Failure Modes and Effects Analysis and Critical Items List Requirements for Space Station
Purpose:

To identify and document failure modes and effects analysis results and to identify critical items of space
experiment systems and components which require special risk assessment. This action will support; (1)
additional design action, (2) safety analysis to identify hazards, (3) test planning, (4) mission planning, {5)
Preparation of mandatory inspection points, (6) fault detection and isolation, (7) maintainability analyses and
planning, (8) reliability analysis to identify single point failures, (9) logistics planning, and (10) waiver to
Program requirements.

Related Documents:

PM-02: Risk Management Plan
PA-01: Product Assurance Plan
PA-02: System Safety Plan

Preparation Information:

This document will report the results of FMEAs conducted to determine possible failure modes and effects on
the local, system, and crew level. Failure Modes shail be categorized according to NASA criticality categories
(impact on mission objectives and system safety). The contractor shall use the listed NASA references as
analysis requirements. Deviations from the published instructions by NASA should be approved by NASA
Personnel managing the contract.

The Critical Items List will include item identification, cross-reference to FMEA line items, and retention
rationale. Appropriate retention rationale can include design features, historical performance and/or flight
success history, acceptance testing, manufacturing product assurance, operational workarounds,
maintainability, elimination of undesirable failure Modes, and failure detection methods. The retention
rationale should demonstrate how risk (probability of occurrence and worst case effects) has been minimized
for critical failure modes.

Preliminary - Due for PDR
Final — Due for CDR, update as required 60 days after CDR

Page 38


SpaceDOC Attachment J-2

Title: DID No.: OP-07
Procedures
Reference:

OP-02: Operator’s Manual

Purpose:
To provide the user a detailed understanding of the operation of the equipment. Operation may include

maintenance, calibration, set-up, initialization, changeout, shut-down, restart, tear-down, nominal and off-
nominal situations.

Related Documents:

Preparation Information:

Describe all aspects of the activities necessary to operate a particular piece of equipment. The procedure
shall include as a minimum:

“ZI @ mmo Opp

S

Purpose of the procedure.

Description of participants and their roles and responsibilities involved in the procedure.

Description of proposed facilities, tools, and other support equipment, as well as material and parts
with identification specifications, required te complete the procedure.

Referenced documentation.

List of Pre-requisite procedures to have been completed, prior to the start of the procedure.
Equipment configuration information, (both subject equipment and any interface equipment necessary)
including the pre-requisite initial state of equipment.

Step-by-step instructions to complete the procedure, including interim and final configuration
drawings, when appropriate.

Expected feedback or response of the equipment after each step of the procedure.

Summary of specific safety, security, reliability and quality assurance requirements, as related to the
subject procedure.

Description of end-state of equipment at the conclusion of the procedure.

Page 80



SpaceDOC Attachment J-2

Preparation Information:

The following provides the requirements on the content and organization of the Delivery Order Work Plan.
Where separate detailed planning documents are to be prepared (as defined by the Delivery Order) on specific
management functions, this document should include a summary of their content and a reference to them.

1.0 Technical Approach

14

1.2

1.3

1.4

15

1.6

1.7

2.0
2.1

Development Approach - Summary reflecting Contractor proposed overall approach for
implementing the task or project. Describe the overall development approach that includes:
interpretation of task requirements; identifying all ground units, flight units and test articles,
simulators, software development, and support hardware; a flow diagram to clarify
development and test approach to be used; key features and/or critical elements; and
summary of and rationale for any proposed significant work elements (e.g., specialized test
hardware development, engineering hardware development, alternative approach, etc.)
believed essential by the Contractor for successful and cost effective implementation of the
task but not explicitly called out in the Delivery Order.

Requirements Baseline — List or reference the requirements levied on the Delivery Order Work
Plan and discuss how these are flowed down to lower levels by summarizing the requirements
allocation process.

Technology/Risks - Indicate any existing feasibility issues or proof-of-concept issues that must
be taken into account in the development requiring additional testing along with any
requirements that offer significant technical challenge or risk of failure. Describe the
technology assessment, development, management, and acquisition strategies needed to
achieve the Delivery Order's objectives. Describe any cpportunities for leveraging on-going
technology efforts.

Logistics - Identify where the major project functions, such as hardware build, testing,
integration, etc., will take place and describe the facilities, special services, vehicles, systems,
and major equipment necessary to satisfy the identified logistic requirements. The spares
philosophy with quantity anticipated should also be identified.

Mission Operations, Training and Data Management - Describe the operations, training, and

data management approaches to the extent they are understood at the time, This should also
include a summary of the Contractor approach for managing documentation, technical data
and data deliverables in the context of the Delivery Order.

Safety - Define the ground and mission safety requirements of the project. Safety implications
related to implementation of the task should be described with any apparent or implied key
flight safety issues.

Product Assurance - Define the overall product assurance requirements of the project.
Provide an overview of the product assurance approach and its relationship to the contract's
overall Product Assurance Plan.

Management Approach

Management — Document the plan to monitor and contro! the Delivery Order requirements,
technical design, schedule, and cost to achieve the objectives levied by NASA. Describe the
performance measures in objective, quantifiable and measurable terms. Describe how the
Contractor plans to report technical, schedule, and cost status to NASA, including frequency
and detail or reporting. Include a description of the systems engineering management
approach in accordance with PM-09. Provide the approach for implementing Earned Value
Management (EVM) if applicable or other appropriate means to monitor and report on cost
status and budget analysis.

Page 26



CDRL Contract Baseline

Attachment J-2
REVISION AND HISTORY PAGE
PUB.
REV. DESCRIPTION OAS
draft | Modified CDRL from MRDOC contract 4/12/2007
Initial | Incorporated New CDRL and Revisions 6/24/2008
Final

Minor changes to the CDRL for grammer, due dates, references, etc

7/15/2008



SpaceDOC Attachment J-2

Title: DID No.: R-03
Payload Interface Agreement (PIA) and Annexes

Reference:
SSP-52000-PDS Payload Data-Sets Blank Book
SSP-52000-PIA-PRP Rev A: Payload Integration Agreement Blank Book for Pressurized Payloads

Purpose:
To develop a unique Payload Integration Agreement (PIA) for International Space Station (ISS) facility class.

and rack level pressurized payloads. The PIA is the Payload Developer (PD) and international Space Station
Program (ISSP) agreement on the responsibilities, tasks and requirements that directly relate to the

assignment and integration of the payload into the ISS. The PIA further defines the roles and responsibilities,
technical requirements, and integration schedules to launch, operate, and return an ISS pressurized payload.

Related Documents:
R-02: Interface Definition Document and Interface Control Document

Preparation Information:

The PIA for ISS payloads shall be developed, in accordance with SSP-52000-PIA-PRP, with three separate
parts as follows: main volume, the addendum, and the data sets. The main volume of the PIA describes the
static requirements and the general roles and responsibilities of the parties involved in the integration and de-
integration, pre-launch and post-landing processing, transportation and the on-orbit operation of the payload.
More specifically, it contains information pertaining to specific reviews, schedules, hardware commitments and
protocols required to manifest the payload. The addendum documents the tactical parameters, dynamic
requirements, schedules, and commitments associated with specific transportation flights and on-orbit
increment operations. Information in the addendum will be provided for each increment while the payload is
on-orbit. Finally, the data sets contain the engineering, integration, and operational details required and
agreed upon by the implementing organizations. Data sets define, on an increment and flight-specific basis,
the engineering, integration and operational details of the requirements in the Addendum. Data sets will be
updated, as agreed to by the implementing organizations, to meet increment and flight-specific needs. For
details of the payload integration processes, see SSP 50200-01, Station Program Implementation Plan,
Volume 1: Space Station Program Management Plan through SSP 50200-10, Station Program
Implementation Plan, Volume 10: Sustaining Engineering.

Draft - Due for SRR
Preliminary - Due midway between SRR and PDR
Final — Due for PDR, update as required 60 days after PDR

Page 50



SpaceDOC Attachment J-2

Title: DID No.: PA-04
Fracture Control Plan

Reference:
Space Assurance Requirements and Guidelines (SARG) ~
SSP-30558 Fracture Control Requirements for Space Station

Purpose:
Documents the contractor's approach to fracture control and helps the Government understand how the

contractor will comply with applicable fracture control safety requirements.

Related Documents:

PA-02: System Safety Plan

PA-05: Safety Compliance Data Package

PA-06: Materials Identification and Usage List (MIUL); Material Usage Agreement (MUA)

Preparation Information:

This document shall define the overall approach for meeting fracture control requirements, the methodology
for identifying fracture critical parts, the methodology for performing crack Propagation analysis, the use of
Nondestructive inspection and testing techniques, and the fracture control activities to be conducted during the
varlous program phases. The plan as a minimum shall address the following areas:

A) Structural Design

B) Material selection, procurement, and storage

C) Fabrication process control

D) Analysis and Testing

E) Quality assurance and nondestructive examination (NDE)

F) Payload operations and maintenance

This plan applies to all types of fracture phenomena including fatigue crack initiation, stress corrosion cracking,
hydrogen embrittlement, and propagation of cracks due to cyclic or sustained loading.

Page 34



SpaceDOC Attachment J-2

Title: DID No.: PA-13
Reliability Report(s)

Reference:

Space Assurance Requirements and Guidelines (SARG) - Section 7

SSP 50431, Space Station Program Requirements for Payloads

LeR-W0510.061, Reliability Prediction/Maintainability Assessment/Availability Analyses

Purpose: Reliability Analysis is utilized by the designers to estimate the reliability of a particular design within
mission parameters. Reliability estimates for sub-systems, Orbital Replaceable Units (or Line Replaceable
units) are compared to their reliability allocations (design targets). The purpose of the analysis is to identify
subsystems or components within the design where reliability improvement is required, areas of risk, and to
provide inputs to sparing analysis.

Related Documents:
PA-01: Product Assurance Plan
PM-02: Risk Management Plan

Preparation Information:

The developer shall perform a reliability allocation and prediction analysis. The predicted system level
reliability at the elapsed mission time shall be compared to the overall system reliability requirement specified
in the Product Assurance Plan. The reliability allocations shall be developed for each subsystem or major
component of the system, which are the reliability design goals that must be met for the system to attain its
overall reliability requirement. The prediction analysis shall provide a reliability model of the system in terms of
a reliability block diagram and shall include the component failure rates and failure rate sources. Components
for reliability improvement shall be identified and recommendations can be made for design improvement,
higher quality level of parts, sparing, improved cooling Capability, additional active or passive redundancy or
reduction in planned operating time. If the system is complex and many subsystems are involved, the
developer may desire to provide individual reliability prediction analysis reports for each subsystem and a
separate Reliability Summary Report for the system level prediction and the Reliability Allocations.

Allocations: 90 days prior to PDR
Preliminary Analysis: Due for PDR
Revised Analysis: CDR

Final: Due for PSR

Page 43


SpaceDOC Attachment J-2

Title: DID No.: PM-08
Software Version Description Document

Reference:
NASA STD 2100-91 (NASA Software Documentation Standard) NASA-DID-P500

NASA STD 8719.13A (Software Safety NASA Technical Standard)
IEEE 12207 Software Development Standards

Purpose:
This document provides a precise description of the particular version of software/firmware being released.

Related Documents:
D-09: System Configuration Document
PM-04: Configuration Management Plan

Preparation Information:

Whether the delivered entity is at the system, rack, CSCI or CSC level, this document shall include a
complete, precise description of the software and firmware being delivered for this entity, the CM'd version
numbers of the software and firmware being released, the location of the software and firmware source,
object and executable code, and all utility and support software and hardware equipment that is not part of
the entity version but is required to load, operate, and maintain this version. For software and firmware that
was not developed but purchased, identify the software and firmware by vendor, product name, version,
patch number, service pack number, signature information, etc. This document shall contain a precise
description of each target processor in the entity being released including vendor, product name,
configuration, version, serial number, etc. and which software executables are running on the target.

For recommended document outline see NASA-STD-2100-91

Page 29



SpaceDOC Attachment J-2

Title: DID No.: CD-02
Earned Value Management Reporting

Reference: :

NFS 1852.242-73 NASA Contractor Financial Management Reporting
Clause TBD Financial Management Reports

Clause TBD Technical Reports and Management Reviews

Purpose:
To provide comprehensive performance measurement information which integrates costs, schedule and technical

performance.

Related Documents:

SpaceDOC Surveillance Plan

CD-01: Contractor Financial Management Reporting
CD-03: Technical Reports and Management Reviews

Preparation Information:

A. EVM Planning. For work identified by the Government as having EVM reporting requirements, the Contractor shall
include with their Delivery Order Proposal for Government negotiation an EVM Plan including the following:

1. a Work Breakdown Structure (WBS) at a level of detail necessary to achieve integrated cost, schedule, and
performance-oriented management insight for the work executed under the Delivery Order work statement,

2. a task activity network schedule and month-by-month time-phased cost plan including cost-loaded task activities
and associated milestones,

3. a proposed work measurement scheme for determining earned value (e.g. discrete effort, apportioned effort, Level
of Effort, etc.) (This work measurement scheme once approved by the Government will be the basis for determining
earned value.) (Note: for this contract earned value for an activity shall not exceed 80% until such activity is
completed.)

(Note: The WBS shall map directly into the Delivery Order’s task activity network schedule and 533 financial report
see CD-01.)

Major sub-contract efforts shall be included in the above.

Upon negotiation, the EVM Plan included in the Delivery Order will serve as the baseline for performance measurement.
The EVM Baselines shall be subject to configuration management and shall not change without Government approval. The
negotiated EVM Plan shall be in-place within 30 days of Delivery Order start, or within 30 days of a government approval to
re-baseline. Re-baseline will occur only with contract change or under Government direction.

B. Monthly EVM Status. 1. During the course of the Delivery Order execution, the Contractor shall submit monthly the
WBS-based Delivery Order schedule in its entirety, with associated work measurement assessments. in addition, each of
the following shall be provided (see table below for description/definition):

a. Planned Value (PV), b. Actual Cost (AC), c. Earned Value (EV), d. Cost Performance Index (CP!) and e. Schedule
Performance Index (SPI).

2. Detailed variance explanations shall be provided as follows:
for CPI's and SPI’s > 0.95, no variance explanation required (color code GREEN),
for CPI's and SPI's > 0.90 and < 0.95, include detailed variance explanations (color code YELLOW),
for CPI’s and SPI’s < 0.90, include detailed variance explanations (color code RED),

Page 13


SpaceDOC Attachment J-2

Title: DID No.: V-01
Master Requirements and Verification Compliance Plan
Master Requirements and Verification Compliance Matrix/Summary

Reference:
SSP-57010 Pressurized Payloads Generic Payload Verification Plan (ISS Only)
SSP-57011 Payload Verification Program Plan (ISS Only)

Purpose:

The plan shall provide for overall hardware and software verification and requirements compliance for
qualification and acceptance of the hardware and software. The plan should utilize block diagrams that outline
the groups of verification activities to be performed and the sequence of testing. (The purpose of the plan is to
determine if the appropriate tests/verifications will be performed and determine a ROM for the time (schedule),
facilities and personnel required to perform the verifications/tests.) Software details should be included in the
Software Verification & Validation Plan (V-04), unless the contractor chooses to incorporate them in this plan.

The matrix shall summarize all design requirements, including applicable science, payload/hardware interface,
carrier, safety and environmental testing requirements. The requirements matrices shall document the
derivation of requirements from their source, hardware and software compliance to the requirements, and the
hardware/software capabilities to meet the requirements. The verification portion of the matrix shall document
the method of verification and a summary of results (i.e. Pass, Fail, Inconclusive), The matrix shall also
identify the test report where the detail results can be found. The document also notes any deficiencies
between hardware/software capabilities and the science requirements. The document also records any
waivers that are granted in cases where the hardware/software cannot meet the requirements and the
rationale for granting the waivers. Note: Individual test procedures will document each test in detail and the
Master Requirements and Verification Compliance matrix will summarize results and tracking of
requirements/performance.

Related Documents:

System Requirements Document

Software Verification & Validation Plan

Interface Definition Document and Interface Control Document

Payload Interface Agreement and Annexes

Baseline System. Description (Baseline Concept Description) (if applicable)...

The Master Requirements and Verification Compliance Plan/Matrix shall contain the external (science, carrier,
operations, safety and quality) requirements, derived requirements, system requirements, subsystem, and
component requirements for qualification and acceptance of the hardware and software. The plan should
teflect a document outlining all applicable activities and the rationale for performing the
test/analysis/inspection/demonstration or combination of these methods. The Master Requirements and
Verification Compliance Plan (coupled with the matrix) should include as a minimum the following:

e Derivation of all technology/program/science requirements to engineering (including software)
requirements (System Requirements and Specification Documents should be used as a reference).
The BSD (if applicable) can be referenced to show design implementation.

All verifications required for vehicle/carrier integration

Flight Payload/hardware to Vehicle/Carrier Attach Fitting Integration

Cleanliness, Control and Monitoring

All safety requirements

For environmental testing portion of the Plan, the following should be included as a minimum:

Page 65


SpaceDOC Attachment J-2

Title: DID No.: OP-08
Training and Certification Plan

Reference:

JSC-36307 NASA Training Implementation Plan

SSP 50200-07 Station Program implementation Plan, Volume 7: Training
SSP 41184-01 Multilateral Training Management Plan, Volume 1

SSP 41184-02 Multilateral Training Management Plan, Volume 2

Purpose:
To provide a comprehensive approach to training and certification of all personnel, both on-orbit and on the

ground, required to operate and/or physical integration of a system.

Related Documents:

Preparation information:

Describe an approach, which will address all aspects of the training necessary to integrate and operate a
system. The plan shall include as a minimum:

Description of participants involved in the training, and their roles and responsibilities.

List of types of training to be conducted, including traditional classroom, computer-based training, on-
the-job, simulations, etc., and what criteria will be used to select a particular method.
Description of proposed facilities, tools, and other support equipment, as well as materials and
documentation required to implement the training.

Description of the certification process (i.e. test administration, attendance, self-test, etc.).
Description of training flow, including any hierarchical relationships.

Listing of the detailed training curriculum.

Detailed discussion of the processes and activities, which will be performed to plan, develop,
implement, administer, and track the training and certification requirements.

Describe the recertification process, if one exists.

I e7mo oO w>

Page 81



SpaceDOC Attachment J-2

Title: DID No.: R-04
Software Requirements Document

Reference:

NASA STD 2100-91 (NASA Software Documentation Standard)
NASA STD 8719.13A (Software Safety NASA Technical Standard)
IEEE 12207 Software Development Standards

SSP 52050, ISPR to ISS Software Interface Control Document, Part 1
SSP 57002, Payload Software Interface Control Document Template

Purpose:
This document specifies in detail the requirements of the system Computer Software Configuration Item

(CSCI). It includes the function and performance, interfaces, and qualification requirements.

Related Documents:

PA-04: Fracture Control Plan

PA-10: Software Assurance Plan

D-06: Software Design Document

R-01: System Requirements Document

V-01: Master Requirements and Verification Compliance Plan, etc.

Preparation Information:

The Software Requirements Document defines the specific requirements to be satisfied throughout the
implementation of the software requirements for the system CSCI. The information contained within the
document provides the technical requirements to be implemented by the CSCI and enables the development
team to assess whether or not the completed CSC! complies with the requirements of the system. The data
included in this document provides the criteria for acceptance of the integrated software configuration. The
document shall provide detailed information regarding the payload software per the following topics as a
minimum; Flight Experiment Commanding Software, Diagnostics Software, Crew Interface Software, Ground
Control Software, Experiment Monitoring Software, Safety and Reliability Software (e.g. fail safe, fault
tolerance), Communication Interface Software, Software Simulation (check software without hardware), and
Ground-based experimentation Software.

A general organization of the document is outlined below and should be used as a guideline only:
Introduction

Applicable Documents {List of documents referenced in the document]

Requirements [List all system functional and performance requirements]

Qualification Requirements [Describes qualification requirements necessary to establish
that the above requirements have been met]

Notes

Appendices

Glossary [Acronym list and definition of terms]

Preliminary — Due at PDR
Final — Due at CDR

Page 51



SpaceDOC Attachment J-2

Title: DID No.: D-01
Review Presentation Package

Reference:

NASA NPR 7123.1A

Purpose:
The Review Presentation Package is for providing a viewgraph presentation and associated documentation to

meet the requirements of the specific review (i.e. PDR, CDR, PSR, etc.)

Related Documents:

Preparation Information:

The Review Presentation Package for each review shall summarize the information in the key document
deliverables and the requirements of the review as described in the SOW and/or Delivery Order.’ The Review
Presentation Package shall provide to the review panel the necessary information to make a determination to
proceed in the hardware and software development. As an example, the Phase 1 Safety Review shall provide
a presentation package that includes a description of the payload system, subsystems and the Hazard
Reports. The Review Presentation Package shall be prepared and distributed to the Government no later than
2 weeks prior to the review.

Page 53



SpaceDOC Attachment J-2

Title: . DID No.: CD-04
Automated information Security Plan

Reference:

NFS 18-4.470-4(b) Submission of Security Plan for Unclassified Automated Information Resources
NPD 2810, NASA Information Technology Security Program.

Public Law 100-235, Computer Security Act of 1987,

Purpose:
The purpose of the plan is to describe the management and technical controls required to implement and

operate an effective Information Technology (IT) Security process for the SpaceDOC contract at the Glenn
Research Center.

Related Documents:
OP-06: TSC Security Plan

Preparation Information:

A. This plan shall address the security measures and program safeguards that will ensure that all
information systems and resources acquired and utilized in the performance of the contract by
contractor and subcontractor personnel are in accordance with NFS 18-4.470-4(b).

B. The plan includes procedures and responsibilities for implementing the information Technology (IT)
Security process for the SpaceDOC contract team.

C. The plan complies with all NASA Information Technology (IT) Security and security management
regulations applicable to the SpaceDOC Contract,

D. An existing corporate security plan may suffice.

FINAL — due 60 days after contract award or after contract modification or change in company processes
affecting plan

Page 16