GPR 8730.5 Reference Document.pdf

DIRECTIVE NO. GPR 8730.5A APPROVED BY Signature: Original Signed By

EFFECTIVE DATE: February 18, 2022 NAME: Deirdre Healey

EXPIRATION DATE: February 18, 2027 TITLE: Director, Safety and Mission Assurance

CHECK THE GSFC DIRECTIVES MANAGEMENT SYSTEM AT

http://gdms.gsfc.nasa.gov TO VERIFY THAT THIS IS THE CORRECT VERSION PRIOR TO USE.

08/16

Goddard Procedural Requirements (GPR)

COMPLIANCE IS MANDATORY

Responsible Office: 300/Safety and Mission Assurance Directorate

Title: Safety and Mission Assurance Acceptance of Inherited and Build-to-Print Products

PREFACE

P.1 PURPOSE

Define an efficient and effective process for dispositioning hardware or software that either is built-to-print from an existing design with or without minor modifications or already exists based on the risk of using the item in its current form. A prerequisite for deeming such inherited items as acceptable at a baseline level of risk when alternative practices are used is that the items are built using well-established successful processes and requirements for systems developed under a comparable risk posture. It should be noted, however, that some projects (or elements of projects) that have a high tolerance for risk are enabled by products that have no history or ability to control the internal aspects, and thus may be subject to the best possible characterization of inherent risk. This approach enables projects to take credit for inherited or Build-to-Print items having pertinent performance, qualification, operational, manufacturing, and/or reliability history applicable to their mission requirements and provides a means to tailor and/or provide relief to the application of specific Mission Assurance Requirements (MAR) and level of oversight or insight that do not sufficiently contribute to achieving mission success commensurate with their cost baseline and risk posture. This process applies to acquisition of hardware items, including any inherent software used within the item, but not for standalone blocks of software for reuse. If inherited items meet all requirements in the project MAR, then this directive may be used to right-size the levels of oversight on the developer. This directive should be used in lieu of waivers to the MAR for inherited and build-to-print items that are built to alternate requirements or under a reduced level of oversight.

P.2 APPLICABILITY

a. This directive applies to all GSFC space flight projects at Greenbelt and Wallops Flight Facility.

This directive is optional guidance for other projects, such as suborbital and atmospheric projects.

b. In this directive, all document citations are assumed to be the latest version unless otherwise noted.

c. In this directive, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall.” The terms “may” or “can” denote discretionary privilege or permission; “should” denotes a good practice and is recommended but not required; “will” denotes expected outcome; and “are/is” denotes descriptive material.

DIRECTIVE NO. GPR 8730.5A Page 2 of 18

EFFECTIVE DATE: February 18, 2022

EXPIRATION DATE: February 18, 2027

P.3 AUTHORITIES

NPD 8720.1, NASA Reliability and Maintainability (R&M) Program Policy

NPR 8735.2, Hardware Quality Assurance Program Requirements for Programs and Projects

P.4 APPLICABLE DOCUMENTS AND FORMS

NASA-STD-8739.1, Workmanship Standard for Polymeric Applications on Electronic Assemblies

P.5 CANCELLATION

GPR 8730.5-, Safety and Mission Assurance Acceptance of Inherited and Build-to-Print Products

P.6 SAFETY

N/A

P.7 TRAINING

None

P.8 RECORDS

Record Title Record Custodian Retention

Standard Components

Commodity Usage Guidelines

(CUG-1)

Reliability and Risk

Assessment Branch, Code

*NRRS 8/101- PERMANENT. Cut off records at close of program/ project or in 3-year blocks for long term programs/projects. Transfer to national archives 7 years after cutoff.

Software Commodity Usage

Guidelines (CUG-2)

Software and Ground

Systems Assurance

Branch, Code 372

*NRRS 8/101

Digital Electronics Commodity

Usage Guidelines (CUG-3)

Reliability and Risk

Assessment Branch, Code 371

*NRRS 8/101

Inherited Items Information

Package

Project record custodian NRRS 8/101

* NRRS – NASA Records Retention Schedule (NRRS 1441.1)

DIRECTIVE NO. GPR 8730.5A Page 3 of 18

P.9 MEASUREMENT/VERIFICATION

None

DIRECTIVE NO. GPR 8730.5A Page 4 of 18

PROCEDURES

1.0 Background

It has become common for significant elements of GSFC spacecraft and instruments to include hardware and software that is either already existing (e.g., a spare board or component from a previous development) or is build-to-print from an existing design. In the realm of these inherited items, it is also common for the items to be built or designed to different Safety and Mission Assurance (SMA) specifications than those in the project Mission Assurance Requirements (MAR) document, project system requirements, or in other NASA or GSFC directives. This directive provides a direct means of handling and accepting such items by understanding the previous history (including resolved and unresolved anomalies or failures) of the items, any changes in the item or its on-orbit or testing environment or application, the differences in requirements, and subsequently characterizing and communicating the risk of using the item in its current state. This directive may also be used to aid in accepting commercial-off-the-shelf (COTS) items that are outside of GSFC’s experience base. Note that existing hardware may be at any level of assembly, including electrical, electronic, and electromechanical (EEE) parts. For example, this process may be used as an alternative approach to disposition EEE parts that were either pulled from existing stock or procured prior to Parts Control

Board approval. Furthermore, this approach may preclude the need for source control drawings or other detailed design deliverables for EEE parts. There is an expectation when using such an alternative approach that the developer has followed some set of established processes and that there is a successful history of similar products under a comparable risk posture. Note that while the information provided may provide a basis for qualification of the items, in general this process should not preclude any elements of environmental test for acceptance, in particular to verify workmanship, although in some cases it may be used to defer the process to a developer’s own practices. The Standard Components

(SC) Commodity Risk Assessment Engineer (CRAE), in coordination with the CSO, Product Design

Lead (PDL) where applicable, Lead Systems Engineer, and Project may reasonably make a recommendation that the GSFC Inherited Item Risk Assessment process may be used in lieu of the component-level milestone reviews, Preliminary Design Review (PDR) and Critical Design Review

(CDR), for the inherited components.

2.0 Timing

The use of inherited products has multiple insertion points into the life cycle over time, and for each point, there are actions that can help ensure an efficient, risk-informed process for incorporating such items into GSFC systems. It is important to consider the attributes of inherited products in the proposal and selection phase, as well as at the point where the products are being delivered. In the earlier phases, GSFC may have less control over how inherited products factor into the overall system, but these phases are included here for those instances where GSFC’s interaction can have an impact.

The following represent the top-level guidance applicable to each element, from proposal through development:

DIRECTIVE NO. GPR 8730.5A Page 5 of 18

Announcements of Opportunity (AOs) and initiation of development partnerships: Define assemblies that are proposed to be inherited or built-to-print inside projects, require vendors to provide sufficient detail, including photographs of inherited hardware. At this point the approach for bringing forth inherited items should be formulated, and if the appropriate resources are available, an inherited items planning review should be held with a final product being an agreement on which items should be brought forward as inherited items.

Source Evaluation Boards (SEBs) and Technical Management Cost & Other (TMCO) panels: Provide this document to aid in evaluating list of inherited hardware.

Projects in formulation: Within one month of Mission Concept Review (MCR), vendor, developer, or project office provides the inherited item information in an inherited items information package, as articulated in this document. Representatives from Codes 300, 400, 500, and 600 should participate, Code 800 as applicable. The process may be revisited at any subsequent time when new inherited or

Build-to-Print items are added to the design baseline as a result of new requirements, corrective actions to unforeseen design or Integration & Test (I&T) issues, unexpected unavailability of planned hardware, etc.

As early as possible, the Standard Components (SC) Commodity Risk Assessment Engineer (CRAE) should make a recommendation for project concurrence as to whether the inherited items process is the most effective means of dispositioning the items at hand.

3.0 Information and data required/requested

In order to properly assess the risk of using an inherited item as is, several pieces of information are key to establishing the basis in risk. The vendor/developer should include the following materials as part of the inherited items information package:

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

b. 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. See Section 4.5 to consider designs qualified outside of GSFC.

c. 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.

d. 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).

DIRECTIVE NO. GPR 8730.5A Page 6 of 18

e. 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.

f. 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.

g. 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.

h. 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).

i. Materials list and approved Material Usage Agreements (MUAs). Materials list includes 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.

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

k. The reliability analyses performed for the most recent version of the product (including parts stress analysis and derating).

l. Identification of significant changes in manufacturing from qualified unit to current unit (facility, process, subtier supplier, testing changes, company change of ownership, etc.).

m. Results of major Material Review Boards associated with the product.

For items previously used in GSFC projects for which prior complete documentation exists, either in

CUG-1 or a comparable record, the vendor/developer may submit documentation that characterizes only the differences between the previous and current application, including the changes in the reliability analyses.

Clearly, it is possible that providing all of the information above may be more challenging than following standard practices for a new development, so the emphasis in compiling this information should be to provide enough to form a clear basis for establishing the risk for using the item without intrusive inspections and requirement verifications internal to the product. The intent is to avoid redesigning a successful design.

The inherited items review should focus on items a, c, d, and e above as these describe the inherited item as a system. These items along with item k should describe the minimum package to determine component-level risk, while the other items focus on risk internal to the item. It should be

DIRECTIVE NO. GPR 8730.5A Page 7 of 18 acknowledged, however, that even the minimum may not be available in some cases, and the result should be to characterize the uncertainty-based risk associated with the missing information.

4.0 Process elements

The following subsections define the process that culminates in a risk assessment used ultimately to disposition the item. The responsible party for determining the risk associated with use of an inherited item not built to project requirements is the Code 370 Standard Components Commodity Risk

Assessment Engineer (SC CRAE). For inherited items likely to be used on multiple projects, the SC

CRAE should document the results of the process defined in this directive within the Standard

Components Commodity Usage Guidelines (CUG-1), in addition to the risk assessment report.

4.1 Information/data submission

If the vendor/developer/project intends to submit several inherited items for consideration for the

Inherited Items Risk Assessment process, the vendor/developer/project shall submit an Initial Proposed

Inherited Items List no later than sixty (60) days after contract award for review. The vendor/developer/project office should provide an initial inherited items information package for each proposed inherited item including, but not necessarily limited to, the listed items in Section 3.0 no later than ninety (90) calendar days prior to need date agreed upon between SC CRAE and vendor/developer/project.

The SC CRAE shall perform and document an analysis that compares (1) the requirements to produce the item to the project requirements, (2) the environment of previous application in test and on-orbit, to the environments in the current application, and (3) any differences in parts, materials, or construction between the previous and current application.

4.2 Inherited Items Review

At least two months prior to the element PDR, the SC CRAE should chair an Inherited Items Review, including representatives from the project and selected subject matter experts that are independent from the project. This may take the form of a virtual or in-person meeting, or simply an exchange of documents and follow-up dialogue. The SC CRAE may delegate the chair responsibility as appropriate.

The review should cover the list of items in Section 3.0. The formality of the review should be commensurate with the project risk posture.

4.3 Performance assessment vs mission requirements

An assessment should be performed of the item’s performance against the mission requirements, to answer the question as to whether the item is suited for the application.

DIRECTIVE NO. GPR 8730.5A Page 8 of 18

4.4 Workmanship assessment

A qualitative assessment should be performed to determine if the item meets GSFC workmanship requirements commensurate with the risk classification or amounts to an equivalent level of risk. As with the statement in 3.0, this element is an internal look within the item, so a strong basis of successful flight history of the item in the appropriate environment may preclude the need for a detailed workmanship comparison. In most cases after a review of developer practices, workmanship may be verified through environmental testing.

4.5 Prior qualification of inherited item

The vendor/developer/project office may provide evidence that the item in its current form has been fully qualified. On the determination of the SC CRAE, this evidence may fully or partially supersede other requirements and guidance in this document. Note that acceptance of a specific item for flight use is not generally covered through an argument of prior qualification. Acceptance will include elements of workmanship verification, through inspections and/or environmental test. Clearly to fully benefit from this approach, in most cases, workmanship verification and other aspects of acceptance may only be performed through testing on an assembled product. For example, a Field Programmable Gate Array

(FPGA) that is an exact duplicate of a previously-flown FPGA may be considered fully qualified by prior flights if the new environment is enveloped by the previous environment and no anomalies have occurred that indicate defects in the design. Minor changes in the design and environment may be addressed by analysis of the differences or the performance of appropriate environmental testing. The digital electronics CRAE should make the determination as to whether analysis is sufficient to assess risk based on the particular design changes.

4.6 Updated reliability analysis

The provider shall ensure that any changes in the configuration, content, environment, or operation of the inherited item are incorporated into the reliability analyses of the previous product or addressed with supplemental analysis/explanation. If none of the aforementioned factors have changed, then the prior reliability analyses will suffice as reliability analyses for the current product.

4.7 Software

Special considerations should be given to the acceptance of software as an element of an inherited hardware component. The principles above should be selectively applied. The following guidance should be used specific to the software in an inherited item.

a. Review software requirements and specifications for compatibility with the project.

b. Evaluate previous build documentation for completeness to satisfy an effective Inherited Item Review.

c. Evaluate original development processes.

d. Evaluate failure analyses, on-orbit anomalies, and problem reports for impact to the project.

DIRECTIVE NO. GPR 8730.5A Page 9 of 18

e. Evaluate fault protection philosophy and assure appropriate analyses identify fault containment rationale and levels of redundancy to meet requirements.

f. Evaluate testing methodologies of previous programs.

g. Assure that configuration changes are well documented and understood.

Software assurance should make the assessment as to whether the software in the inherited item amounts to reuse, minor modifications to prior software, or re-engineering.

An appropriate representative from software assurance shall then perform a risk assessment, considering:

a. Criticality

b. Redundancy

c. Margins

d. Software impacts on life limited items

e. Statistics that would indicate failure

f. Successful time in test and on-orbit

The SC CRAE or project software quality assurance lead shall ensure that the results of the software inherited item risk assessment are documented in the software Commodity Usage Guidelines (CUG-2) document. Appendix C includes a checklist to aid in dispositioning inherited software.

4.8 Field Programmable Gate Arrays and related technologies

Special considerations should be given to the acceptance of previously flown, altered, or customized field programmable gate arrays (FPGAs), masked programmable gate arrays and other closely related hardware devices. The principles in Sections 1-4 should be selectively applied. The following guidance should be used specific to these types of inherited digital electronic items.

a. Review the original development plan or assurance plan associated with the part in its previous application.

(1) If no plan exists, then the design and environment should be identical to previously flown versions to make use of this process as an alternative to the requirements in the pertinent project mission assurance requirements document unless the Digital Electronics (DE) Commodity

Risk Assessment Engineer (CRAE) determines that the plan is not necessary.

b. Review peer review documentation from the previous application (Peer review information content is in Appendix D).

(1) Completeness of peer review documentation and level of similarity to previous design should drive the extensiveness of peer review for the current design required

(2) In some cases, previously flown designs proposed for environments enveloped by prior flight and testing history may not require additional peer review.

DIRECTIVE NO. GPR 8730.5A Page 10 of 18

c. Review records of failure analyses, on-orbit anomalies, and problem reports for impact to the project, and how they were dispositioned.

d. Evaluate testing methodologies of previous programs.

e. Assure that all configuration aspects, especially any differences, are well documented, such as with a

“was/is” table of:

(1) Full manufacturer part number

(2) Lot/Date code(s)

(3) Vendor part number (e.g., Altered Item Drawing number, etc.)

(4) Logic (e.g., any changes in the hardware description language code, etc.)

(5) Synthesis (e.g., not re-synthesized, re-synthesized to preclude GIDEP xyz, etc.)

(6) Layout (e.g., not re-routed, re-routed per GIDEP xyz, etc.)

(7) Verifications

(a) Simulations (e.g., not re-run, new simulations added, etc.)

(b) Analyses (e.g., not updated, timing analysis updated with values exported from latest software version that supports this FPGA, etc.)

(c) Tests

(8) Environments

(a) Operating temperature range

(b) Operating voltage range(s)

(c) Radiation

f. Assure any differences from the inherited item, such as a newer lot/date code, are agreed as producing an equivalent item

g. Review pertinent GIDEPs released prior to and since the FPGA was developed, including prior disposition reports, for both the FPGA and all software used to develop it

The Digital Electronics (DE) CRAE will make the determination of risk based on the information provided and will make the determination whether minor changes in the design from prior use are substantial enough to warrant a full peer review, a limited scope peer review, or no peer review at all.

The DE CRAE or SC CRAE shall ensure that results of the FPGA inherited item risk assessment are documented in the Digital Electronics Commodity Usage Guidelines (CUG-3) document. Appendix D includes a list to aid in dispositioning inherited FPGAs.

4.9 Application-Specific Integrated Circuits

Special considerations should be given to the acceptance of previously flown, altered, or customized

Application-Specific Integrated Circuits (ASICs). The principles in Sections 1-4 should be selectively

DIRECTIVE NO. GPR 8730.5A Page 11 of 18 applied. The following guidance should be used specific to these types of inherited digital electronic items.

a. Review the original development plan or assurance plan associated with the part in its previous application.

(1) If no plan exists, then the design and environment should be identical to previously flown versions to make use of this process as an alternative to the requirements in the pertinent project mission assurance requirements document unless the Digital Electronics (DE) Commodity

Risk Assessment Engineer (CRAE) determines that the plan is not necessary.

b. Review peer review documentation from the previous application (Peer review information content is in Appendix D).

(1) Completeness of peer review documentation and level of similarity to previous design should drive the extensiveness of peer review for the current design required

(2) In some cases, previously flown designs proposed for environments enveloped by prior flight and testing history may not require additional peer review.

c. Review records of failure analyses, on-orbit anomalies, and problem reports for impact to the project, and how they were dispositioned.

d. Evaluate testing methodologies of previous programs.

e. Assure that all configuration aspects, especially any differences, are well documented, such as with a was/is table of:

(1) Requirement specification

(2) Block diagram

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

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

(5) Synthesis constraint and report files

(6) Formal verification (e.g., equivalency checking) results/reports

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

(8) Static timing analysis results including best and worst case, and least margin/slack for each

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

(10) Disposition/analysis report of all clock domain crossings

(11) Verification plan

(12) Verification test bench/code and final code coverage metrics with list and explanation of any exclusions

(13) Listing of all bugs detected during verification and their disposition

(14) Final verification report showing all requirements have been verified (RTL and Back-annotated)

(15) Design review documentation, presentations, and action item dispositions

(16) ASIC vendor checklists, including ERC/DRC/LVS results

DIRECTIVE NO. GPR 8730.5A Page 12 of 18

(17) Final fault coverage (Was Scan implemented?)

(18) Listing of any anomalies seen in test or operation in prior projects and their disposition

The following items provide additional useful information to aid in determining risk:

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

b. Board(s) schematics containing this ASIC

c. Board netlist(s) (any American Standard Code for Information Interchange (ASCII) format such as

PADS, MGC, Allegro)

d. Board part list (any ASCII or common spreadsheet format)

e. PDF of the board layout, such as an assembly drawing

f. Signal integrity analyses relevant to this ASIC

g. Power integrity analyses relevant to this ASIC. Assure any differences from the inherited item, such as a newer lot/date code, are agreed as producing an equivalent item

The DE CRAE will make the determination of risk based on the information provided and will make the determination whether minor changes in the design from prior use are substantial enough to warrant a full peer review, a limited scope peer review, or no peer review at all.

The DE CRAE or SC CRAE shall ensure that results of the ASIC inherited item risk assessment are documented in the Digital Electronics Commodity Usage Guidelines (CUG-3) document.

4.10 Quality control, in-house vs out-of-house

For commercial products and standard components that are built repeatedly with minimal changes and that have substantial successful flight history, and procured under fixed-price contracts where the developer assumes the risk, quality control should be established by prior history, periodic audit or assessment, and in some cases by minimal key inspections (e.g., mandatory inspection points). In-house

NASA builds will follow pertinent NASA requirements and guidelines; however, for repeat builds of items where subsequent applications are under different risk classifications, changes to guidelines that are based on changes in risk classification should be avoided unless there is evidence of a problem associated with the requirements used for the prior build. A change to any requirements from an existing successful design, even if more stringent, is likely to increase the risk for the new build. Local approaches to quality control and assurance should apply for inherited items.

5.0 Risk Assessment

The SC CRAE shall perform a risk assessment based on the compilation of information and the inherited items review, resulting in risk statements with likelihood and consequence in the standard GSFC 5x5 format, or a statement that there is no elevated risk associated with use of the item. The SC CRAE is

DIRECTIVE NO. GPR 8730.5A Page 13 of 18 responsible for leading the risk assessment, with support from other individuals such as the project reliability and risk engineer, the product design lead, and other subject matter experts as needed. The risk determined will be forwarded to and subsequently managed by the project. Note that it is up to the project to make the decision to use as is, or whether mitigations will be performed. The risk may be per item or rolled up collectively over multiple inherited items as reasonable.

DIRECTIVE NO. GPR 8730.5A Page 14 of 18

Appendix A: Definitions

A.1 Build-to-Print Item: An item that per contract or up-front formal agreement within a project is built to a set of design documentation and drawings. Any changes from the documentation will result in costs outside of the budget for the item.

A.2 DE CRAE: Engineer responsible for tracking, qualifying maintaining lessons learned on, and assessing risk on the use of digital electronic components used on GSFC projects. Note that the DE CRAE may be temporarily appointed by Code 300 if the formal position is vacant.

A.3 Inherited Item: An item brought in to a project as a fully designed item that has some amount of prior history that may be built to different standards than those in project mission assurance requirements, and may not have had NASA insight into the design or construction.

A.4 Risk: The combination of a) the probability (qualitative or quantitative) that an organization will experience an undesired event such as cost overrun, schedule slippage, safety mishap, or failure to achieve a needed technological breakthrough; and b) the consequences, impact, or severity of the undesired event were it to occur.

A.5 SC CRAE: Engineer responsible for tracking, qualifying, maintaining lessons learned on, and assessing risk on the use of standard spacecraft components used on multiple projects.

A.6 Waiver: A specific written authorization granting relief from one or more requirements herein.

DIRECTIVE NO. GPR 8730.5A Page 15 of 18

Appendix B: Acronyms

AO Announcements of Opportunity

ASCII American Standard Code for Information Interchange

ASIC Application Specific Integrated Circuit

CDR Critical Design Review

COTS Commercial Off The Shelf

CRAE Commodity Risk Assessment Engineer

CSO Chief Safety and Mission Assurance Officer

CUG Commodity Usage Guidelines

DE Digital Electronics

EEE Electrical, Electronic, and Electromechanical

FPGA Field Programmable Gate Array

GIDEP Government Industry Data Exchange Program

GPR Goddard Procedural Requirement

GSFC Goddard Space Flight Center

I&T Integration & Test

MAR Mission Assurance Requirements

MCR Mission Concept Review

MUA Material Usage Agreement

NASA National Aeronautics and Space Administration

PCB Printed Circuit Board

PDF Portable Document Format

PDR Preliminary Design Review

PG Procedures and Guidelines

PWA Printed Wiring Assembly

RTL Register Transfer Level

SC Standard Components

SEB Source Evaluation Board

SMA Safety and Mission Assurance

TMCO Technical, Management, Cost, & Other

VHDL VHSIC Hardware Description Language

VHSIC Very High Speed Integrated Circuit

DIRECTIVE NO. GPR 8730.5A Page 16 of 18

Appendix C: Software Heritage Checklist

The following is a checklist that may be used to aid in dispositioning inherited software.

DIRECTIVE NO. GPR 8730.5A Page 17 of 18

Appendix D: FPGA Peer Review information

The following information should be provided from FPGA peer reviews for prior application

Peer review information from the prior application should encompass the following as available for inherited items:

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

b. Synthesis report files

c. Synthesis constraint files

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

e. Static timing analysis results including best and worst case, and least margin/slack for each

f. Disposition of all clock domain crossings

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

h. Requirements, specifications, and verification document(s), and any supporting material relevant to the FPGA

i. Design review documentation, presentations, and action item dispositions

j. Block diagram

k. Simulation code coverage analysis and simulation testbench/script code

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

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

n. Board(s) schematics containing this FPGA

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

p. The final peer review report

The following items provide additional useful information to aid in determining risk:

a. 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

b. Board(s) schematics containing this FPGA

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

d. Board part list (any ASCII or common spreadsheet format)

e. PDF of the board layout, such as an assembly drawing

f. Signal integrity analyses relevant to this FPGA

g. Power integrity analyses relevant to this FPGA

DIRECTIVE NO. GPR 8730.5A Page 18 of 18

CHANGE HISTORY LOG

Revision Effective Date Description of Changes

Baseline 03/28/2016 Initial Release

A 02/18/2022 • Expanded to emphasize the role in missions with high tolerance for risk, such as Class D, including the fact that for some products, even the minimum set of data may not be available.

• Added language to address dialing between insight and oversight using the process.

• Made some date of delivery adjustments based on lessons learned from the first version.

• Added further flexibility for how the Inherited Items

Review is performed.

• Removed section on white wires as it is now outdated and unnecessary.