Attachment_D_-_Restore-L_Mission_Assurance_Requirements_-_Sanitized.pdf

Attachment D

Restore-L MAR RESTORE-L-RQMT-000518

Effective Date: 05/04/2016

Restore-L Mission Assurance Requirements

Signature/Approval Page

Prepared by:

Signature on SSCO NGIN

Robert Dedalis Date

SSCO Chief Safety & Mission Assurance Officer

Code 383

Reviewed by:

Mary Reph Date

Restore-L Spacecraft Bus COR

NASA/GSFC Code 408

Bo Naasz Date

Restore-L Mission Systems Engineer

NASA/GSFC Code 599

Approved by:

Robert C. Smith Date

Restore-L Project Manager

SSCO/Code 408

Electronic Signatures available online at https://sscongin.ndc.nasa.gov

Preface

This document is a Restore-L Project Configuration Management (CM)-controlled document.

Changes to this document require prior approval of the applicable Configuration Control Board

(CCB) Chairperson or designee. Proposed changes shall be submitted to the SSCO Code 408

CM Office (CMO), along with supportive material justifying the proposed change. Changes to this document will be made by complete revision.

All of the requirements in this document assume the use of the word "shall" unless otherwise stated.

Questions or comments concerning this document should be addressed to:

NASA/Goddard Space Flight Center

SSCO, Code 408

Attention: Configuration Management Office Greenbelt, Maryland 20771

Goddard Space Flight Center

Greenbelt, Maryland 20771

Change History Log

Revision Effective Date Description of Changes

(Reference the CCR & CCB/ERB Approval Date)

Released per SSCO RESTORE-L-RQMT-000518

Table of TBDs/TBRs/TBSs

Action Item

No.

Location Summary

Individual/

Organization

Actionee

1. GENERAL

1.1 Systems Safety and Mission Assurance Program

The developer, whether Government or Contractor, shall implement a safety and mission assurance program that is consistent with Restore-L requirements. The mission assurance implementation program shall cover:

Flight hardware and software that is designed, built, or provided by the developer and its subcontractors or furnished by the government, from project initiation through launch and mission operations

The ground support equipment that interfaces with flight items to the extent necessary to assure the integrity and safety of flight items

The ground data system to the extent necessary to assure performance as required by the Statement of Work

The developer shall submit a mission assurance requirements compliance matrix that identifies variances and acceptance rationale for processes, procedures, and standards that are proposed as alternatives to those specified by the MAR (DID 1-1).

The developer shall submit a waiver request for the use of alternative processes, procedures, and standards.

Traceability: GPR 1280.1 P.2; NPD 1280.1 5.c

1.2 Management

The developer shall designate a manager for assurance activities. The assurance manager shall not be responsible for project costs and schedules other than those pertaining to assurance activities. The manager shall have direct access to management that is independent of project management and the functional freedom and authority to interact with all elements of the project.

Traceability: NPD 8700.1 NASA Policy for Safety and Mission Success, paragraph 1.b

1.3 Requirements Flowdown

The developer shall apply system safety and mission assurance requirements to subcontractors and suppliers to the extent necessary to ensure that the delivered product meets performance requirements.

Traceability: GPR 1280.1 The GSFC Quality Manual, paragraph 1.1

1.4 Suspension of Work Activities

The developer shall direct the suspension of any work activity that presents a hazard, imminent danger, or future hazard to personnel, property, or mission operations resulting from unsafe acts or conditions that are identified by inspection, test, or analysis.

Traceability: NPD 8700.1 NASA Policy for Safety and Mission Success, paragraph 5.e(2)

1.5 Contract Data Requirements List (CDRL)

The CDRL identifies Data Item Descriptions (DID) for deliverables. The developer shall deliver data items per the requirements of the applicable DID. The developer shall perform work in accordance with the following definitions:

Deliver for approval: The Restore-L Project Office approves the deliverable within the specified period of time before the developer proceeds with the associated work.

Deliver for review: The Restore-L Project Office reviews the deliverable and provides comments with the specified period of time before the developer proceeds with the associated work. The developer can continue with the associated work while preparing a response to the GSFC comments unless directed to stop work.

Deliver for information: For Restore-L Project Office information only. The developer continues with the associated work.

The developer may combine deliverables if the requirements for the individual deliverables are addressed.

Traceability: GPR 5100.1 Procurement, paragraph 3.1a

1.6 Surveillance

The developer shall grant access for National Aeronautics and Space Administration (NASA) and NASA assurance representatives to conduct an audit, assessment, or survey upon notice.

The developer shall supply documents, records, equipment, and a suitable work area within the developer’s facilities.

Note: See Federal Acquisition Regulations (FAR) Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5 for government quality assurance requirements at contractor facilities. See FAR Part 52.246 for inspection clauses by contract type.

Traceability: GPR 5100.1 Procurement, paragraph 1.1g; Part 46 Federal Acquisition

Regulations, paragraphs Parts 46.103, 46.104, 46.202-2, 46.4, and 46.5

1.7 Use of Heritage Product

For products that are planned to be used for Restore-L that have either been previously developed and exist (e.g., spares), or will be built-to-print (BTP) or are commercial-off-the-shelf

(COTS), the developer may follow an inherited items review process, in which the Government will perform an inheritance risk assessment on those developer’s heritage products. This process establishes a risk for using the item and may avoid routine waiver processing, based on the established prior history, the change in the design, environment, or operations, and the information provided about the processes used to develop the product. The risk determined shall be primarily based on prior usage, changes, and the approach to changes in standard products.

Just as with waivers, the government determines whether risks are acceptable or if mitigations are required. The developer shall assume ownership and responsibility for mitigation of any such risks.

If the developer elects to pursue this process, the developer shall provide the data specified in

Table 1-1 to substantiate the item as a baseline or very low risk product. The developer may optionally provide available items in Table 1-2 to help reduce the risk. The developer shall provide the initial Inherited Items package at ACA + 30 days and the final package at SRR + 1 month. The developer shall host and participate in up to five 2-hour Inherited Items Technical

Interchange Meetings (TIMs) to further explain the data to substantiate the item’s baseline risk and mitigation strategies.

Use of this process does not alleviate the developer from meeting spacecraft/observatory technical functional or performance requirements.

Table 1‑ 1. Inherited Items Data List

No. Data Needed for Inherited Items

1 List of inherited items and statement of approach – rebuild, modification of previous build, or use of existing hardware

2 Summary results of qualification, acceptance, and/or prototype/protoflight testing completed, or comparison of current qualification/protoqual requirements and what was performed/realized on the inherited design, including environments, required design margins, and life

3 Flight history of the items and specific attributes for each flight, including environments (compare previous environment to current, including duty cycle and general concept of operations)

4 Ground and on-orbit anomaly and failure history including the determination of root causes or information that root cause was not determined. Ground anomalies may be restricted to major anomalies, where component performance requirements were violated

5 The reliability analyses performed for the most recent version of the product.

6 Identification of significant changes in manufacturing from qualified unit to current unit (facility, process, sub-tier supplier, testing changes, company change of ownership, etc.), and any changes in design or materials, including electronic parts, printed circuit boards, and standards used (changing from an older revision of a standard to the latest revision need not be discussed).

Table 1‑ 2. Inherited Items Supplementary Information

No. Supplement Information for Inherited Items

1 Deviations of each item from original design (white wires, cut traces, splices, etc., if not objectively clear to be part of the design) and reasons for each deviation. If the design has been qualified on a previous GSFC project in the same environment and same risk posture, then the deviations may be declared relative to the previously qualified design.

2 Specifications and/or standards used to develop the items (e.g., IPC, J-STD, NASA, or GSFC requirements, including fastener integrity approach, or company standards). For items with minimal prior flight history, company standards or detailed synopses of such should be provided, if such are used to develop the product

3 Previous as-built parts list, including lot date codes, and the differences for new inherited item. This should include evidence that Government Industry

Data Exchange Program (GIDEP) alerts and advisories have been properly dispositioned, if the parts have already been procured. Note that GIDEP should always be used as an aid in procuring new parts or pulling parts from inventory. Reference to prior project deliveries to GSFC is acceptable, in which case, an amendment may be delivered to indicate any changes

4 Known obsolete parts that are intended to be supplied out of existing inventory, along with quantity required vs available in inventory. Sparing plan if available (including quantity required, quantity available, and sparing philosophy)

5 Materials list and approved Material Usage Agreements (MUAs). Materials list includes lot date codes and evidence that GIDEP alerts and advisories have been properly dispositioned, if the materials have already been procured. Such evidence should be encompassed in GIDEP closure records for each of the items that have impacts. Reference to prior project deliveries to GSFC is acceptable, in which case, an amendment may be delivered to indicate any changes

6 List of major electrical and mechanical analyses completed and summary of results.

Traceability: GPR 8730.5: Safety and Mission Assurance of Inherited and Build-to-Print

Products

2. QUALITY MANAGEMENT SYSTEM

2.1 General

The developer shall have a quality management system that is compliant with SAE AS9100

Quality Systems - Aerospace - Model for Quality Assurance in Design, Development, Production, Installation and Servicing.

Traceability: GPR 1280.1 The GSFC Quality Manual P.2; NPD 8730.5 NASA Quality

Assurance Program Policy, Attachment A, paragraph 2.a

2.2 Supplemental Quality Management System Requirements

2.2.1 Control of Nonconforming Product

The developer shall have a documented closed loop system for identifying, reporting, and correcting product nonconformances. The system shall ensure that the adequacy of corrective action is determined by audit or test, that objective evidence is collected, and that preventive action is implemented to preclude recurrence.

Traceability: GPR 5340.4 Problem Reporting and Problem Failure Reporting, paragraph 1.b;

NPD 8705.4 Risk Classification for NASA Payloads, Appendix A

2.2.2 Material Review Board (MRB)

The developer shall have a documented process for the establishment and operation of a MRB to process nonconformances, including the definitions of major and minor nonconformances. The developer shall appoint a MRB chairperson who is responsible for implementing the MRB process and functional and project representatives as MRB members. The MRB shall include a government representative who will be a voting member on all major MRBs involving procured hardware. The government representative shall be supplied with the applicable documentation 24 hours in advance of the scheduled MRB. The developer shall inform the government of MRB actions (DID 2-1).

The MRB shall use the following disposition actions:

Scrap — the product is not usable

Re-work — the product will be re-worked to conform to requirements

Return to supplier — the product will be returned to the supplier

Repair — the product will be repaired using a repair process approved by the MRB

Use as is — the product will be used as is

Traceability: GPR 5340.4 Problem Reporting and Problem Failure Reporting, paragraph 1.b;

NPD 8730.5 NASA Quality Assurance Program Policy, paragraphs 1.b(8)(a) and 1.b(8)(b)

2.2.3 Anomaly Reporting and Disposition

The developer shall have a documented process for anomaly reporting and disposition. The process will establish an anomaly review board (ARB) whose membership will include a government representative as a voting member with approval authority for proposed actions on all major nonconformances.

The process shall require major anomalies to be submitted to the ARB and the government

(DID 2-3). The developer shall report major hardware anomalies beginning with the first application of power at the component level, major software anomalies beginning with flight software acceptance testing and when interfacing with flight hardware, and major mechanical system anomalies beginning with the first operation. Major anomalies are those that have resulted in hardware or software test failures and damage or potential damage to hardware.

Examples of major anomalies are overvoltage or over current conditions, exceedance of test limits resulting in overstress, blown fuses, and unexpected system responses. The developer shall assess the failure risk ratings and failure effect risk ratings for major anomalies (see DID 2-3 for criteria) and shall identify those that have a failure effect risk rating of 2 or 3 and a failure corrective action risk rating of 3 or 4 as a significant residual risk in the risk list.

The process shall allow the developer to disposition minor anomalies with an appropriate subset of the ARB. Minor anomalies are those that have not resulted in hardware failure or have caused no damage or stress to hardware or required no change in flight software. Examples of minor anomalies are those that can be resolved immediately, procedural errors, database problems, operator errors, and exceedance of test limits that do not affect the end item.

Note: a component is defined as a functional subdivision of a subsystem and generally as a self-contained combination of items performing a function necessary for the subsystem's operation.

Traceability: GPR 5340.4 Problem Reporting and Problem Failure Reporting, paragraph 1.b

3. SYSTEM SAFETY

3.1 General

The developer shall document and implement a system safety program, support the ELV Safety

Review Process as defined in paragraphs 2.4 of NPR 8715.7 Expendable Launch Vehicle

Payload Safety Program, meet launch service provider requirements, and launch range safety requirements. Specific safety requirements include the following:

- The developer shall incorporate three independent inhibits in the design (dual failure tolerant) if a system failure may lead to a catastrophic hazard. A catastrophic hazard prelaunch is defined as a payload-related hazard, condition, or event occurring prior to launch (on ground) that could result in a mishap causing fatal injury to personnel or loss of ground facility. A catastrophic hazard post-launch is defined as a payload-related hazard, condition or event occurring post-launch (airborne) through payload separation that could result in a mishap causing fatal injury (including fatal injuries to the public) or loss of flight termination system.

- The developer shall incorporate two independent inhibits in the design (single failure tolerant) if a system failure may lead to a critical hazard. A critical hazard is defined as a condition that may cause a severe injury or occupational illness to personnel or major property damage to facilities.

- The developer shall adhere to specific detailed safety requirements, including compliance verification that must be met for design elements with hazards that cannot be controlled by failure tolerance. The process by which safety is incorporated into these design elements (e.g., structures and pressure vessels) is called "Design for

Minimum Risk".

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, Volume

3, paragraphs 2.4 and 3.2 and Volume 7 (definitions)

3.2 Mission Related Safety Requirements Documentation

The developer shall implement launch range safety requirements as applicable for the specific launch site. The most stringent applicable safety requirement shall take precedence in the event of conflicting requirements.

Western Test Range (WTR) Mission

NASA-STD 8719.24 (with Annex) NASA Expendable Launch Vehicle Payload

Safety Requirements

KNPR 8715.3, “KSC Safety Practices Procedural Requirements” (applicable at KSC property, KSC-controlled property, and offsite facility areas where KSC has operational responsibility)

NPR 8715.7, “Expendable Launch Vehicle Payload Safety Program”

Launch Site Facility-specific Safety Requirements, as applicable (e.g., Astrotech)

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraph 1.2a-c

3.3 System Safety Deliverables

3.3.1 System Safety Program Plan

The developer shall prepare a System Safety Program Plan (SSPP) that describes the tasks and activities of system safety management and engineering required to identify, evaluate, and eliminate or control hazards to the hardware, software, and system design by reducing the associated risk to an acceptable level throughout the system life cycle, including launch range safety requirements (DID 3-1).

The SSPP shall:

- Define the roles and responsibilities of personnel

- Define the required documentation, applicable requirements documents, and completion schedules for analyses, reviews, and safety packages

- Address support for Safety Reviews (as defined in NPR 8715.7), Safety Working

Group Meetings and TIMs

- Provide for early identification and control of hazards to personnel, facilities, support equipment, and the flight system during product development, including design, fabrication, test, transportation, and ground activities.

- Address compliance with the launch range safety requirements

- Address compliance with industrial safety requirements imposed by NASA and

OSHA design and operational needs and contractually imposed mission unique obligations paragraphs 2.4.2a(2), 2.4.2b(2)I, and 2.5.4

3.3.2 Safety Requirements Compliance Checklist

The developer shall document and implement a Safety Requirements Compliance Checklist to demonstrate that the payload is in compliance with NASA and range safety requirements

(DID 3-2). Noncompliances to safety requirements will be documented in waivers and submitted for approval.

paragraphs 2.4.2a(2), 2.4.2b(2)I and 2.5.4

3.3.3 Hazard Analyses

Traceability: NASA-STD-8719.24 NASA Expendable Launch Vehicle Payload Safety

Requirements, Volume 1, paragraph A2.2.3

3.3.3.1 Preliminary Hazard Analysis

The developer shall perform a Preliminary Hazard Analysis (PHA) to obtain an initial risk assessment and identify safety critical areas of a concept or system (DID 3-3). It will be based on the best available data, including mishap data from similar systems and other lessons learned.

The developer shall evaluate hazards associated with the proposed design or function for severity, control approach (fault tolerance or design for minimum risk), and operational constraints. The developer shall identify safety provisions and alternatives that are needed to eliminate hazards or reduce their associated risk to an acceptable level.

The PHA shall include the following for identification and evaluation of hazards as a minimum:

- Hazardous components (e.g., fuels, propellants, lasers, explosives, toxic substances, hazardous construction materials, pressure systems, and other energy sources).

- Safety related interface considerations among various elements of the system (e.g., material compatibilities, electromagnetic interference, inadvertent activation, fire/explosive initiation and propagation, and hardware and software controls). This shall include consideration of the potential contribution by software (including software developed by other contractors/sources) to subsystem/system mishaps that occur prior to separation from launch vehicle on-orbit. Safety design criteria to control safety-critical software commands and responses (e.g., inadvertent command, failure to command, untimely command or responses, inappropriate magnitude, or other undesired events) shall be identified and appropriate action taken to incorporate them in the software (and related hardware) specifications.

- Environmental constraints including the operating environments (e.g., drop, shock, vibration, extreme temperatures, noise, exposure to toxic substances, health hazards, fire, electrostatic discharge, lightning, electromagnetic environmental effects, ionizing and non-ionizing radiation including laser radiation).

- Operating, test, maintenance, built-in-tests, diagnostics, and emergency procedures

(e.g., human factors engineering, human error analysis of operator functions, tasks, and requirements; effect of factors such as equipment layout, lighting requirements, potential exposures to toxic materials, effects of noise or radiation on human performance; explosive ordnance render safe and emergency disposal procedures.

Those test unique hazards which will be a direct result of the test and evaluation of the article or vehicle.

- Facilities, real property installed equipment, support equipment (e.g., provisions for storage, assembly, checkout, proof testing of hazardous systems/assemblies which may involve toxic, flammable, explosive, corrosive or cryogenic materials/wastes;

radiation or noise emitters; electrical power sources) and training (e.g. training and certification pertaining to safety operations and maintenance).

- Safety related equipment, safeguards, and possible alternate approaches (e.g., interlocks; system redundancy; fail safe design considerations using hardware or software controls; subsystem protection; fire detection and suppression systems;

personal protective equipment; heating, ventilation, and air-conditioning; and noise or radiation barriers).

- Malfunctions to the system, subsystems, or software. Each malfunction shall be specified, the causing and resulting sequence of events determined, the degree of hazard determined, and appropriate specification and/or design changes developed.

Traceability: NPR 8715.7 Expendable Launch Vehicle (ELV) Payload Safety Program, paragraphs 1.3.6b, 2.3.1c, & 2.4.2b(2)

3.3.3.2 Operations Hazard Analysis (OHA) and Hazard Verification Tracking Log (VTL)

The developer shall perform and document an Operations Hazard Analysis (OHA) and a Hazard

Verification Tracking Log (VTL) to demonstrate that hardware operations, test equipment operations, and integration and test (I&T) activities comply with facility safety requirements and that hazards associated with those activities are mitigated to an acceptable level of risk

(DID 3-4). The developer shall update and maintain the Hazard Verification Tracking Log during I&T activities to track open issues.

paragraphs 1.3.6b, 2.3.1c & 2.3.1t

3.3.3.3 Lifting Device Safety Requirements

The developer shall implement the following safety requirements for lifting devices and equipment when performing NASA work at non-NASA facilities:

- Ensure that for critical lifts overhead cranes, winches, and hoists have dual holding brakes and dual upper limit switches installed as defined in NASA Standard 8719.9A paragraphs

5.4.1 and 5.4.2 respectively.. A single holding brake in combination with a motor drive that automatically tests the holding ability of the brake prior to every release of the brake is acceptable as a second brake as long as the crane has a notification device to alert operator of failure of the braking system.

- Perform periodic load testing in accordance with paragraph 4.5 of NASA-STD-8719.9A for the following lifting devices and equipment: overhead cranes; mobile cranes and derricks; hooks hydra-sets and load measuring devices; and slings and riggings.

- After the initial proof test of the lifting device or equipment (LDE), a load test of the rated safe working load (SWL) LDE shall be performed every four years. Proof tests will be

125% of the SWL for Lifting Devices, such as overhead and mobile cranes and include aerial platforms used near critical hardware. Proof tests will be at 200% of the SWL for

Lifting Equipment, such as shackles, turnbuckles and so forth. A load test will be at 100% of the labelled SWL for all LDE. If the LDE is de-rated to a lower SWL because of a lower proof or load test, the LDE shall be labelled as this new SWL and only be used to the maximum capacity as such.

- Perform NDT inspections using an American Society of Nondestructive Testing (ASNT) or equivalently trained inspector on critical lifting hardware equipment on critical welds

(weld failure would result in failure of hardware) after initial proof test and load testing.

- Label and tag lifting devices and equipment per NASA-STD-8719.9A paragraphs 4.9 or other acceptable means.

Traceability: NASA-STD 8719.9 Standard for Lifting Devices and Equipment

3.3.3.4 Operating and Support Hazard Analysis

The developer shall perform and document an Operating and Support Hazard Analysis

(O&SHA) (DID 3-6) to evaluate activities for hazards introduced during testing, transportation, storage, integration, and prelaunch operations at the launch site. Its primary purpose is to evaluate the adequacy of procedures used to eliminate, control or mitigate identified hazards in order to ensure implementation of safety requirements for personnel, procedures, and equipment used during activities at the launch site. The results of the O&SHA shall be submitted as a part of the SDP II and SDP III (DID 3-7).

Requirements, Volume 3: 2.2.3, 4.2, and Attachment 1

3.3.4 Safety Data Package (SDP)

The developer shall prepare an integrated SDP (DID 3-7) to document the results of hazard analyses identifying the prelaunch, launch and ascent hazards associated with the flight system, ground support equipment, and their interfaces in hazard reports.

Requirements, Volume 1, Attachment 1

3.3.5 Verification Tracking Log (VTL)

The developer shall prepare a VTL that provides documentation of a Hazard Control and

Verification Tracking process as a closed-loop system to ensure that safety compliance has been satisfied in accordance to applicable launch range safety requirements. The VTL shall demonstrate the process of verifying the control of all hazards by test, analysis, inspection, similarity to previously qualified hardware, or any combination of these activities. All verifications that are listed on the hazard reports shall reference the specific test/analysis/inspection reports with a summary of the pertinent results. Results of these tests/analyses/inspections shall be available for review.

The VTL shall identify hazard controls that are not verified as closed and shall be delivered to the Restore-L Project Office with the SDP III (DID 3-7). Regular updates to this log shall be provided to the Restore-L Project Office electronically for review until all hazard controls are verified as closed.

paragraph 2.2.3d

3.3.6 Hazardous Procedures for Payload I&T and Pre-launch Processing

The developer shall document and implement hazardous procedures that comply with applicable facility safety requirements when performing integration and test activities and pre-launch activities at the launch site (DID 3-8). The developer shall provide safety support for hazardous operations at the launch site.

paragraph 2.2.3f

3.3.7 Safety Waivers

The developer shall request waivers for variations from the applicable safety requirements per paragraph 1.4 of NPR 8715.7 (DID 3-9).

3.3.8 Orbital Debris Assessment Report (ODAR) and End of Mission Plan (EOMP)

The developer shall provide the inputs necessary for the development of the ODAR and the

EOMP deliveries per the content defined in NASA-STD 8719.14 Process for Limiting Orbital

Debris (DID 3-10).

Traceability: NASA-STD-8719.14 Process for Limiting Orbital Debris, Appendices A and B

3.3.9 Mishap Reporting and Investigation

The developer shall prepare a Pre-Mishap Plan that describes appropriate mishap and close call notification, reporting, recording, and investigation procedures in accordance with NPR 8621.1

NASA Procedural Requirements for Mishap and Close Call Reporting, Investigating, and

Recordkeeping. The developer shall report accidents, test failures, or other mishaps and close calls promptly to NASA. The developer shall promptly investigate so as to determine the root cause.

Traceability: GPR 8621.4 GSFC Mishap Preparedness and Contingency Plan, paragraph 1.9;

NPR 8621.1 NASA Procedural Requirements for Mishap and Close Call Reporting, Investigating, and Recordkeeping

3.3.10 Range Safety Forms

Tailoring note: listed forms are specific to the ETR and WTR; other forms or information may be needed to support other launch sites.

The developer shall prepare the following forms as applicable:

KTI-5212 Material Selection List for Plastic Films, Foams, and Adhesive Tapes

KSC FORM 16-294 NS Radiation Training and Experience Summary (Ionizing

Radiation)

KSC FORM 16-295 NS Radiation Use Request/Authorization (Radiation Materials)

KSC FORM 16-447 Laser Device Use Request/Authorization

KSC FORM 16-450 NS Radiation Training & Experience Summary (Non-ionizing

Radiation)

KSC FORM 16-451 NS Radio Frequency/Microwave System Use Request/

Authorization

KSC Form 26-551V2 Process Waste Questionnaire

AF Form 813 Request for Environmental Impact Analysis

Traceability: Required by Range as applicable

4. RELIABILITY

4.1 Reliability Program Plan (RPP)

The developer shall document and implement an RPP using both qualitative and quantitative techniques to support decisions regarding mission success and safety throughout system development (DID 4-1). The RPP shall include a detailed approach to the analysis of hardware and software for their contributions to system reliability and mission success. The RPP may be included as part of the MAIP as long as it addresses all of the elements contain in section 4.0 of the MAR.

Traceability: NPR 8705.4 Safety and Mission Success for NASA Programs and Projects,

4.2 FMEA/FMECA and Critical Items List (CIL)

The developer shall perform an FMEA/FMECA (Failure Modes and Effects/Failure Modes and

Effects Criticality Analysis) to identify potential failures with severity categories 1, 1R, 1S, 2, 2R, 3, and 4 per Table 4.1 and the process outlined in GSFC P-302-720.

The FMEA shall be updated throughout the development life cycle to address design changes resulting in corresponding failure modes, causes, effects, system impact, or mitigation status/corresponding retention rationale.

The developer shall prepare and maintain a CIL for severity categories 1, 1R, 1S, 2, and 2R per

Table 4.1 (DID 4-2).

The developer shall:

Analyze failure modes resulting in severity categories 1, 1R, 1S, 2, or 2R to determine the potential cause, corresponding mitigation actions, and retention rationale.

For each item on the CIL that is not addressed by having a Corrective Action taken which reduces the severity category to a 3 or 4, there shall be a retention rationale prepared/recorded which contains data that supports the premise that the risk presented by inclusion of the item in the design has been minimized by one or more of the following: detailed evaluation of probability of occurrence; proper design controls, inspections, and tests; and that no adverse failure history exists. The rationale also will contain data that describes operational constraints caused by occurrence of the failure and any measures that can be taken to restore the function on orbit.

Identify and assess common cause failure modes and causes for category 1R and 2R items

Address flight hardware and software that is designed, built, or provided by their organization or subcontractors, from project initiation through launch and mission operations.

Address the ground system that interfaces with flight equipment to the extent necessary to assure the integrity and safety of flight items.

Identify and address safety critical software, as defined in Section 5.

of operation (DID 4-3). The fault tree analyses shall be extended to include software contributions to loss of mission scenarios.

The FTA is meant to be a living document that is updated throughout the development life cycle to address the latest design and any changes to corresponding faults, fault consequences, fault logic, and/or fault propagation scenarios.

Appendix C

4.4 Parts Stress Analysis

The developer shall perform parts stress and derating analyses for electrical, electronic, and electromechanical (EEE) parts in accordance with GSFC EEE-INST-002 Instruction for EEE

Parts Selection, Screening, Qualification, and Derating (DID 4-4).

4.5 Trend Analysis

The developer shall prepare and maintain a list of subsystem and components to be assessed, parameters to be monitored, and trend analysis reports as defined in the Reliability Program Plan.

The developer shall begin the monitoring, collection, and analysis at component acceptance testing and continue through the system integration and test phases.

Traceability: NPD 8720.1 NASA Reliability and Maintainability Program Policy, paragraph 5

4.6 Analysis of Test Results

The developer shall document the analysis of test information, trend data, and failure investigations to assess reliability and identify potential or existing problem areas.

The developer shall report the results as defined in the approved Reliability Program Plan.

4.7 Limited Life Items

The developer shall prepare and implement a plan to identify and manage limited life items (DID

4-5).

4.8 Worst-Case Analysis

The developer shall perform worst-case analyses (WCA) for circuits (DID 4-6)

5 SOFTWARE ASSURANCE

5.1 Applicable Software Definitions

When identifying, developing, verifying, and maintaining software, the developer shall apply the following definitions:

Software is defined as computer programs, procedures, scripts, rules, and associated documentation and data pertaining to the development and operation of a computer system. Software includes commercial–off-the-shelf (COTS) software, government-off-the-shelf (GOTS) software, modified-off-the-shelf (MOTS) software, custom software, reused software, heritage software, auto-generated code, and code executed on microprocessors.

Mission-Critical Software - Software that can cause, contribute to, or mitigate the loss of capabilities that are essential to the primary mission objectives. The software reliability assessment and analysis is focused on failure modes specific to post-separation mission phases.

Safety-Critical Software - Software that can cause, contribute to, or mitigate human safety hazards or damage to facilities. The software safety assessment and analysis is focused on hazards specific to Integration and Test, launch, and up through spacecraft separation from the launch vehicle and re-entry/recovery (where applicable).

Note: The above definitions for Mission and Safety Critical Software are derived from Safety

Critical as defined by the NASA Software Standard. The delineation is meant only to provide clarification for organizations with separate processes for assessing pre-separation and post-separation hazards and failures. Both categories of software must comply with the NASA-STD-

8719.13 Software Safety Standard, which requires assessment of the entire lifecycle for potential injury, major damage, or mission failure.

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 3

5.2 Software Assurance Program

The developer shall plan and implement a Software Assurance Program that complies with the definitions in 5.1 and:

NASA-STD-8739.8 NASA Standard for Software Assurance

NASA-STD-8719.13 Software Safety Standard

The developer shall identify the person responsible for directing and managing the software assurance program and interfacing with government assurance personnel.

The developer shall document the software assurance program in a Software Assurance Plan

(DID 5-1). The plan will address the disciplines of Software Quality, Software Safety, Software

Reliability, Software Verification and Validation (V&V), and Independent Verification and

Validation (IV&V) and detail the role of assurance and their activities in ensuring quality products and processes for each discipline. The plan will include the software assurance processes, procedures, tools, and techniques to be used commensurate with the Software

Classification Assessment. The plan will address software assurance the necessary collaboration between software assurance, system safety, system reliability, and software engineering.

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 6.1

5.2.1 Software Quality

The developer shall evaluate software processes and work products as defined by NPR 7150.2 and commensurate with the software classification. The developer shall identify and document noncompliance issues, communicate the results of quality assurance activities, maintain records, and ensure disposition of non-compliances.

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 7.1

5.2.2 Software Safety Analysis

The developer shall identify safety critical software per Appendix A of NASA-STD-8719.13

Software Safety Standard. For software that is safety critical, the developer shall perform

Software Safety Analyses per NASA-STD-8719.13 Standard for Software Safety to a) identify whether software can contribute to a hazard (for example, as a cause or control), b) identify specific software modules or functions associated with the hazard cause, c) identify hazard elimination and hazard control methodologies and associated software safety requirements, and

d) verify that the inhibits and controls incorporated to eliminate or mitigate hazards are effective.

The developer shall incorporate the results from the Software Safety Analyses, including references to the associated software requirements, into hazard reports and deliver as part of the

SDP (DID 3-7).

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 7.2

5.2.3 Software Reliability Analysis

The developer shall include in the software plan processes and procedures to identify mission critical software and to design robust performance and fault tolerance into such components. The developer shall include details regarding the following:

Integration of software into system-level and component reliability analysis, and identifying software components critical to the success of nominal operations

Derivation and flow down of software fault and failure management requirements from system-level and component reliability analysis

Identification of mission critical software requirements and performance specifications

Traceability and consistency between reliability analysis and the software design

Provisions for high-fidelity validation of mission critical software

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 7.3

5.2.4 Verification and Validation

The developer shall review the software section of the Verification and Validation Plan/Test Plan and review and support walkthroughs of test procedures.

The developer shall witness or review results of software testing, review software discrepancy reports, and review software delivery documentation.

The developer shall document software discrepancy reports and participate in failure review boards to resolve outstanding software-related issues.

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 7.4

5.2.5 Reserved

5.3 Reviews

In addition to the reviews specified in NPR 7150.2 NASA Software Engineering Requirements

(Section 5.3), the developer shall conduct the following:

Software test readiness reviews

Software acceptance reviews

The developer shall provide advance notification and review materials to the Restore-L Project

Office prior to all reviews.

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Sections 7.1.1.10 and

7.1.1.11

5.4 Surveillance of Software Development, Maintenance, and Assurance Activities

The developer shall provide the following:

Direct access to the software problem reporting system

Electronic access to the software documentation (i.e., management plans, assurance plans, configuration management plans, requirements specifications, design documents, test plans, test cases, test procedures, test results, schedule, maintenance plans)

Electronic access to the software review results

Electronic access to source code

Schedule of software development activities and critical milestones

Schedule of assurance reviews, audits, and assessments of the developer’s processes and products

Access to the corrective actions from process and product audits

Access to review action item status and resolution

Access to requirements traceability matrices and data prepared per the requirements of NPR 7150.2 NASA Software Engineering Requirements

Software Assurance Status Report (DID 5-2)

Traceability: NASA-STD-8739.8 NASA Software Assurance Standard, Section 6.7

6 DIGITAL ELECTRONIC COMPONENTS

6.1 General

The developer shall document and implement an assurance plan for new covered digital electronic components and designs as specified below. The plan will address: parts selection;

version control; timing verification; routing analysis verification; monitoring, witnessing, and inspection points; system safety, including analyses of irreversible processes; reliability; peer reviews. An FPGA or ASIC development plan, with the same content will be sufficient to meet this requirement.

Covered digital electronic components are:

Gate array technologies, including mask programmed gate arrays, field programmable gate arrays, custom ASICs, and the digital sections of mixed-signal

ASICs

And-Or plane devices, such as PALs and PLAs

The plan does not apply to software or firmware executed on processors or memory devices; this is subject to the relevant requirements of software assurance in Section 5.

The developer shall identify the person responsible for directing and managing the digital electronic components assurance program and interfacing with government assurance personnel.

Traceability: 300-PG-8730.0.1 Assurance Activities for Digital Electronics for Spacecraft, Instruments, and Launch Vehicles P.2; NPD 8730.5 NASA Quality Assurance Program Policy, paragraph 1.b

6.2 Peer Reviews

The developer shall conduct peer reviews that encompass the following for new FPGA designs:

Design (place and route) database and any constraint file(s)

Synthesis report files

Timing analyses for external inputs and outputs, internal domain(s), etc.

Disposition of all clock domain crossings

Source code (e.g., VHDL or Verilog), PDF of schematics and/or state machines/tables

Requirements, specifications, and verification document(s), and any supporting material (e.g. block diagrams, presentation material) relevant to the FPGA

Simulation code coverage analysis and simulation test bench/script code

Source code for 3rd party intellectual property code and/or cores

FPGA Design Checklist as per 500-PG-8700-2.7, or equivalent

Board(s) schematics containing this FPGA

Board netlist(s) (any ASCII format such as PADS, MGC, Allegro)

System, box, and circuit board requirements, specifications, presentations, and/or verification document(s) relevant to the FPGA and its role in the system, box, and board

Signal integrity analyses relevant to this FPGA

Power integrity analyses relevant to this FPGA

Board netlist(s) (any ASCII format such as PADS, MGC, Allegro)

Board part list (any ASCII or common spreadsheet format)

PDF of the board layout, such as an assembly drawing

Traceability: 500-PG-8700.2.7 Design of Space Flight Field Programmable Gate Arrays, Appendix E; NPR 7123.1 NASA Systems Engineering Processes and Requirements, Table G-19

7 WORKMANSHIP

7.1 General

The developer shall implement a workmanship program to assure that electronic packaging technologies, processes, and workmanship meet mission objectives for quality and reliability per the requirements of the following standards:

NASA-STD-8739.1 Workmanship Standard for Staking and Conformal Coating of

Printed Wiring Boards and Electronic Assemblies

NASA-STD-8739.5 Fiber Optic Terminations, Cable Assemblies, and Installation

NASA-STD-8739.6 Implementation Requirements for NASA Workmanship

Standards

GSFC-STD-6001 Ceramic Column Grid Array Design and Manufacturing Rules for

Flight Hardware

IPC-J-STD-001FS Joint Industry Standard, Space Applications Electronic Hardware

Addendum (except Chapter 10 of IPC-J-STD-001F)

IPC-2221 Generic Standard on Printed Board Design

IPC-2222 Sectional Design Standard for Rigid Organic Printed Boards

IPC-2223 Sectional Design Standard for Flexible Printed Boards

IPC-2225 Sectional Design Standard for Organic Multichip Modules (MCM-L) and

MCM-L Assemblies

IPC-6011 Generic Performance Specification for Printed Boards (Class 3 requirements)

IPC-6013 Qualification and Performance Specification for Flexible Printed Boards

(Class 3 requirements)

MIL-PRF-50884F Performance Specification: Printed Wiring Board, Flexible or

Rigid-Flex, General Specification For

IPC-6015 Qualification and Performance Specification for Organic Multichip Module

(MCM-L) Mounting and Interconnecting Structures

IPC-6018 Qualification and Performance Specification for High Frequency

(Microwave) Printed Boards (Class 3 requirements)

The developer shall comply with one of the following standards for electrical cables and harnesses:

NASA-STD-8739.4 Crimping, Interconnecting Cables, Harnesses, and Wiring

IPC/WHMA-A-620-S Requirements and Acceptance for Cable and Wire Harness

Assemblies, Space Addendum

The developer shall comply with one of the following standards for rigid printed circuit boards:

IPC-6012 Qualification and Performance Specification for Rigid Printed Boards

(Class 3 requirements), Revisions B through D are acceptable

MIL-PRF-55110H Performance Specification: Printed Wiring Board, Rigid, General

Specification For

ECSS-Q-ST-70-10 Qualification of Printed Circuit Boards

Note: Agreements between the developer and supplier that deviate from or reduce a standard’s requirements are considered alternate standards and shall be identified in the compliance matrix

(DID 7-1). Revisions or other versions of the above standards that contain more stringent acceptability and quality assurance requirements are not considered alternate standards and do not have to be identified.

Note: The most current version of IPC-6012 should be used to clarify requirement ambiguities in prior versions.

Traceability: NPD 8730.5 NASA Quality Assurance Program Policy, Section 1

7.2 Design and Process Qualification

The developer shall perform and document qualification of designs and processes that are not covered by or do not conform to the above standards, including the establishment of quality controls and inspections for non-standard configurations and submit a waiver request for government approval.

7.3 Electrostatic Discharge Control (ESD)

The developer shall prepare and implement an ESD control program that conforms to the requirements of ANSI/ESD S20.20 Protection of Electrical and Electronic Parts, Assemblies and

Equipment (Excluding Electrically Initiated Explosive Devices).

Traceability: GPR 8730.6 Electrostatic Discharge (ESD) Control; NPD 8730.5 NASA Quality

Assurance Program Policy, Section 4; NASA-HDBK-8739.21 Workmanship Manual for

Electrostatic Discharge Control (Excluding Electrically Initiated Explosive Devices)

7.4 Splices, Circuit Board Trace Cuts, and Jumper Wires

The developer shall require approval by the Material Review Board for splices, board trace cuts, or jumper wires that result from repairs or design changes.

7.5 Printed Wiring Board (PWB) Test Coupons

The developer shall not populate printed circuit boards (PCBs) until all approvals to proceed are granted (DID 7-4).

The developer shall provide PCB procurement information (DID 7-2).

The developer shall provide sufficient detail in procurement instructions to ensure that test coupons are fabricated for each design and that sufficient numbers are produced to meet requirements for testing by the manufacturer in accordance with IPC-2221 Generic Standard on

Printed Board Design to satisfy required supplier acceptance testing per IPC-601X and for GSFC microsectioning evaluations. The developer shall provide PCB test coupons that are directly traceable to each board used in hardware to GSFC or to a GSFC-approved laboratory for structural integrity analysis (DID 7-3). Coupons do not need to be submitted for single-sided

PCBs or for double-sided PCBs with no plated through holes or vias. Coupons are required per lot for double-sided boards and per panel for all other board types. If no coupons are available, a qualification board may be submitted for destructive physical analysis. The developer shall provide supporting manufacturing information traceable to the flight boards in accordance with

GSFC Form 23-16 and to include the board drawing or drawing notes. Note: The developer should notify the project office regarding shipment of PCB test coupons. If a GSFC-approved laboratory is used for coupon evaluation, the developer shall deliver the laboratory results to

GSFC and shall store remnants and coupon micro-sections.

The system developer shall deliver to the Restore-L Project Office data for verification tests required by and defined in the standard and in the procurement instructions that are imposed on the PCB manufacturer by the system developer (DID 7-2).

For…