J1a_5_-_Safety_and_Mission_Assurance_Plan.pdf

Small Spacecraft Technology Program (SSTP) Safety and Mission Assurance Plan Rev 0.0

February 09, 2015 i

National Aeronautics and Revision Status: Baseline/Revision 0.0

Space Administration Effective Date: February 09, 2016

Ames Research Center Moffett Field, CA 94035

Safety and Mission Assurance Plan Baseline REV 0.0

SSTP Document

Title: SSTP Program Safety and Mission Assurance Plan

Document No: Rev: 0.0

Effective Date: February 09, 2015 ii

DOCUMENT HISTORY LOG

Status

Document Revision

Effective Date

Description

Draft - 12/01/15 Initial

Baseline Rev 0.0 02/09/16 RFP Release iii

SSTP Program Safety Plan

Signature Page

PREPARED BY:

SSTP Systems Engineer Date

NASA-ARC

CONCURRED BY:

SSTP Program Manager Date

SSTP Program Manager

NASA-ARC

NASA Ames Safety and Mission Assurance Manager Date

NASA-ARC

iv

Table of Contents

1.0 Introduction & Purpose:

2.0 Scope:

3.0 Safety

3.1 Small Spacecraft Hazard Focus Areas:

Propulsion System Safety Analysis:

Range Safety Orbit Debris Analysis Report (ODAR):

3.1.3.1 End of Mission Plan (EOMP):

Lithium Ion Batteries:

Laser Safety:

3.1.5.1 General laser safety practices in the lab:

Software Safety Assessment:

3.2 Safety Hazard Control Process:

4.0 Safety and Mission Assurance

4.1 Reference Documents:

4.2 Compliance Documents

4.3 Material Identification

4.4 Quality System

4.5 Right of Access

4.6 Flow Down Requirements

4.7 Control of Monitoring and Measuring Devices

4.8 Safety Critical Processes

4.9 Government Source Inspection

4.10 Limited Life Items

4.11 Packaging, Handling and Shipping

4.12 Non-Conformance Reporting

4.13 GIDEPS

4.14 Electrostatic Discharge

5.0 Software Assurance

5.1 Software Delivery Documentation

5.2 Control Of Test Software

5.3 Software Quality Management System:

5.4 Software Configuration Management System

5.5 Software Nonconformance Reporting

Data Requirements:

5.6 Software Definitions:

5.7 Software Testing:

5.8 Flight Software Margins:

5.9 Software Quality Assurance (SQA):

5.10 Software Configuration Control

6.0 NPR 7150.2A Software Compliance Matrix APPENDIX

Tables Table 2-1: Quality Management System Table 3-1: EOMP Status Items Table 3-2: Failure Modes Table 3-3: Requirements documents (reference) for Li-Ion Battery Safety Table 4-1: Hazard Analysis Process Table 4-2: SSTP Safety Plan Summary

Safety and Mission Assurance Plan Rev 0.0

February 09, 2015

1.0 INTRODUCTION & PURPOSE:

This document establishes the overall System Safety and Mission Assurance Program elements for projects under the purview of the SSTP. Safety is critical to everything NASA does, and shall not be compromised. The purpose of this plan is to provide guidance for SSTP projects in the area of System Safety and Mission Assurance that will be followed during the spacecraft design, development, fabrication, assembly, integration, and test (AI&T), and operation phases of mission hardware and software through launch and operations. For example, as more spacecraft in SSTP utilize propulsion systems, chemical and pressure safety are becoming of paramount importance.

It is the responsibility of the project(s) to adhere to this Safety and Mission Assurance Plan.

2.0 SCOPE:

At the project definition phase (MCR/SRR), system level hazards and mitigations shall be identified, and submitted to the SSTP as a critical project deliverable, with hazards and mitigations updated as the project progresses, and as a critical submittal at the aforementioned KDP’s. All documented hazards are required to be tracked through satisfactory completion of all identified hazard controls.

Any safety items that require launch vehicle provider approval shall also be coordinated by the project(s), and will be reported to the SSTP COR/POC and the designated NASA Safety Engineer as assigned.

Safety and Mission Assurance (S&MA) for SSTP is overseen by the Program Office with Mission Assurance support from discipline leads such as safety, reliability, contamination, EEE parts, materials and process, quality assurance, and inspection. Mission Assurance within SSTP ensures the products produced under surveillance of the Program office meet the required functionality, quality, safety, and level of reliability.

Mission Assurance within SSTP encompasses flight hardware, software, government-furnished equipment (GFE), qualification units, and spares. It also covers material and services provided by suppliers and subcontractors to projects. This applies to all program phases. Projects under SSTP shall follow the applicable quality system requirements as shown in

Table 2-1: Quality Management System

Notes on Responsibilities (Ref APR 8705.1):

1. For Projects: The Project Chief Safety Officer (CSO) or SS&MA Manager is responsible for determining the appropriate Quality Assurance (QA) requirements that are applicable to their project

2. For activities other than Projects, the responsible NASA Ames Research Center line manager is responsible for determining the appropriate QA requirements that are applicable to their work.

3. The NASA Ames Research Center SS&MA Division is responsible for providing support to Project/Line Managers with respect to determining QA requirements.

4. Conflicts arising in the above are resolved by following the appropriate Technical Authority chain, Engineering (via the Ames Chief Engineer’s Office) and the Safety & Mission Assurance (via the Ames Safety & Mission Assurance Director)

3.0 SAFETY

3.1 SMALL SPACECRAFT HAZARD FOCUS AREAS:

The following are considered safety critical items which shall be addressed as applicable for each flight project:

Propulsion System Safety Analysis:

The type of propulsion system should be defined along with type of propellant, chemical safety data sheet or equivalent, pressure, and associated safety analysis for tanks, feed systems/valves and tubing which constitute the propulsion system. For example, Solar Electric Propulsion (SEP) using ionized gas (like Xenon) is under 2,000 psi pressure, an analysis (preferably an FEA) should be performed with a minimum safety factor of 4.0. Weld inspection(s) should be performed of tank welds, and a proof pressure test conducted. If a caustic or hazardous propellant is used (e.g.

Hydrazine for example), the appropriate handling procedures and personal protective equipment (PPE) should be specified and utilized.

Range Safety

SSTP projects shall follow NPR 8715.3 “NASA General Safety Program Requirements” and the requirements imposed by the appropriate launch service provider/launch range safety representative.

Orbit Debris Analysis Report (ODAR):

A preliminary ODAR report is due at the PDR if the mission con-ops include orbital decay and re-entry. All NASA funded missions under SSTP will require NASA Headquarters approval for the Final ODAR and will be considered a mandatory deliverable item for the Flight Readiness Review (FRR). The requirements for the ODAR are specified in NASA-STD-8719.14A. Orbital debris assessment can be performed using the latest version of the NASA Orbital Debris Engineering Model, ORDEM 3.0, has been released. The model is appropriate for those engineering solutions requiring knowledge and estimates of the orbital debris environment (debris spatial density, flux, etc.). ORDEM 3.0 can also be used as a benchmark for ground-based debris measurements and observations. Material assessment is also critical for burn up during re-entry, per NASA-STD- 8719.14A, section 4.7.5-b: “Thermo-physical and physical material properties of the space structure components, such as thermal conductivity, specific heat capacity, heat of fusion, melt temperature, heat of ablation, and density, have a significant effect on reentry survivability. In general, materials with high melting temperatures, such as titanium, beryllium, and stainless steel, are more likely to survive than materials with low melting temperatures like aluminum. However, the configuration of the component is also very important.”

3.1.3.1 End of Mission Plan (EOMP):

In conjunction with the ODAR submittal an EOMP should also be provided, as this is done in an effort to reduce orbital debris. EOMP items should address state of the spacecraft at the end of the mission, and commencement and completion of passivation. Passivation is described in Appendix A of NPR 8715.6A as “The process of removing all forms of stored energy from the spacecraft. Passivation includes, but is not limited to depletion of all residual propellants, pressurants, electrical storage devices, and forms of kinetic energy to a level where the remaining internal stored energy is insufficient to cause breakup/disassembly” basically provide a list of hazardous materials and systems which might survive re-entry and/or explode creating orbital debris causing/during breakup. If any project spacecraft under the purview of SSTP are leaving

LEO, Planetary Protection issues will also need to be addressed as part of the EOMP. Typical status items in an EOMP are shown in the following table:

Table 3-1: EOMP Status Items

Status

Item Commencement of

Passivation

Completion of Passivation

Spacecraft

Power System Solar array tracking sun for max charge.

Solar array parked in fixed position and heaters on to deplete battery charge.

Attitude Control

System (ACS)

ACS in normal operations. Momentum wheels actively controlling S/C attitude in sun-pointing Safe Hold attitude.

Propulsion System All fuel expended due to ongoing operations and system fully purged at end of ops by multiple valve openings.

No additional fuel management to be conducted.

RF Communication S-band on (for example) S-band off (for example)

C&DH Nominal mode operations. Sun-pointing Safe Hold with

C&DH disabled to prevent recovery.

Lithium Ion Batteries:

Li-Ion batteries should have overcharging and over-discharging circuit’s in-place and tested.

Thermal analysis should be conducted for anticipated operational conditions to ensure that the batteries will not exceed the upper temperature limit of the manufacturer’s performance specifications. Li-Ion batteries should be tested for the following failure modes, or if COTS components cite approval source:

Table 3-2: Failure Modes

Type Failure Mode Failure Mode 1 Battery Internal short circuit.

Failure Mode 2 Internal thermal rise due to high load discharge rate.

Failure Mode 3 Overcharging and/or excessive charge rate.

Failure Mode 4 Excessive discharge rate or short circuit due to external device failure.

Failure Mode 5 Inoperable vents.

Failure Mode 6 Crushing.

Failure Mode 7 Low level current leakage or short-circuit through battery pack case or due to moisture-based degradation of insulators

Failure Mode 8 Excessive temperatures due to orbital environment and high discharge combined.

Failure Mode 9 Polarity reversal due to over-discharge

Failure Mode 10 Excessive battery temperatures due to post mission orbital environment and constant overcharging

Table 3-3: Requirements documents (reference) for Li-Ion Battery Safety

COTS: UL 1642 certified

JSC 20793C (Crewed Space Vehicle Battery Safety Requirements) if

ISS

EP-WI-031 (JSC-- Specification for Acceptance Testing of Commercial

Lithium Ion Cell Lots)

Laser Safety:

As there is a proclivity for use of lasers for optical communications, laser safety as applicable, will have to be addressed. Laser safety would encompass eye and skin damage safety in the lab/test environment, and also during integration. FAA approval for choice of wavelength for laser comm.

needs to be compliant with FAA/FCC restrictions for uplink/downlink for flight projects. Spacecraft flight lasers are required to go through the Laser Clearing House (LCH) to ensure safe and responsible laser activities. The LCH is operated by the Air Force/DoD.

3.1.5.1 General laser safety practices in the lab:

- Wear appropriate protective eyewear

- Use the minimum power/energy required

- Keep beam path away from eye level

- Conform to ANSI standard Z136.1 “Safe Use of Lasers”

Software Safety Assessment:

As part of the system safety and hazard assessment, any critical software identified as a potential safety critical item shall comply with the NASA-STD-8719.13, NASA technical standard for software safety, Appendix A in terms of performing a Software Safety Criticality Assessment (SSCA) Part 1:

“Litmus Test” , e.g. is software a safety critical item, and SSCA Part 2, Software Risk Assessment, to assess the highest potential hazard that software contributes to (if applicable per Part 1), and identify the likelihood and level of hazard severity. For example, software’s effect on safety can be through commands unexpectedly executed, executes the wrong commands, generates wrong data, and has a deleterious effect on the overall system safety.

3.2 SAFETY HAZARD CONTROL PROCESS:

The following process flow chart delineates the hazard analysis process. The closure of a hazard report requires concurrence from the assigned SSTP Safety Representative.

NASA Safety requirements

Close Hazard Reports

Designs & Processes

Risk Acceptable?

Hazard Analysis Hazard Reporting Process

Verification Plans yesno

Verification Procedures

- Analysis

- Test

- Inspection

- Demonstration

Hazard Controls Verified?

no yes

Table 3-4: Hazard Analysis Process

Table 3-5: SSTP Safety Plan Summary

Hazard Type Hazard Controls

Propulsion System Safety Analysis

- Pressure Safety

- Propellant Safety

Caustic issues

Explosive/handling issues o

Stress analysis (preferably FEA) for pressure vessel

- Isolation valve assessment

- Propellant safety

ODAR (Orbit Debris Analysis Report)

- ODAR Assessment addressed at the

KDP’s

- Final ODAR submitted as deliverable item for the FRR

- Provide an End of Mission Plan

(EOMP)

ODAR preliminary and final

- Materials used (e.g. Ti)

EOMP: Provide list of passivation items

(depletion of stored energy, particularly regarding items that could initiate spacecraft breakup

Lithium-Ion Batteries addressed (e.g.

battery thermal load, overcharge, venting, etc.)

Failure modes identified, and hazard controls in-place

Laser Safety

- Lab environment

- Flight Environment (FAA)

- Laser Clearing House (LCH)

Safety controls in the laboratory environment, and FAA and LCH clearance for on-board spacecraft laser operations

Software Safety Assessment with mitigations/controls as applicable

Software safety addressed (as/if applicable)

Other flight project specific safety item(s)

Hazard controls for other safety items specific for the flight project

4.0 SAFETY AND MISSION ASSURANCE

The Project shall adhere to the following mission assurance guidance:

4.1 REFERENCE DOCUMENTS:

NPD 8730.5 NASA Quality Assurance Program

NPR 8735.2 Management of Government Quality Assurance Functions for NASA Contracts

NPD 8730.1 Metrology and Calibration

NPR 1441.1 NASA Records Management Program

NPR 4100.1 NASA Materials Inventory Management Manual

NPR 7120.5 NASA Space Flight Program and Project Management Requirements

APR 6410.1 Material Control Handling Preservation and Protection

APR 5100.1 Purchasing

4.2 COMPLIANCE DOCUMENTS

The project shall comply with the following documents and standards:

NASA-STD-6016

Standard Materials and Processes Requirements for Spacecraft

SAE AS9100 SAE Aerospace Standard (AS) 9100, Quality Management Systems – Aerospace (certification not required)

NPR 8715.6A NASA Procedure Requirements for Limiting Orbital Debris

NPR 8715.3 NASA General Safety Program Requirements

NASA-STD-

8719.14A

NASA Standard Process for Limiting Orbital Debris

APR 8070.2 Ames Procedure Requirements - Class D Spacecraft Design and Environmental Test

4.3 MATERIAL IDENTIFICATION

Each article delivered under this Purchase Order will require positive identification with the part number ordered. All purchased materials and services are subject to inspection for compliance to this purchase order and all applicable quality clauses. No material or process substitutions, quantity variations or splits from the purchase order may be made without prior written authorization from the Customer. The Contractor shall provide a MEL that includes the following subsystem information: manufacturer, part number, lot, date code, serial number.

4.4 QUALITY SYSTEM

Project and supporting Contractors shall be compliant to AS9100 standards or equivalent, although certification is not required. http://standards.sae.org/as9100/. If the Contractor is not certified, then NASA retains the right to review vendor processes to determine if acceptable.

4.5 RIGHT OF ACCESS

Work under this purchase order/contract is subject to government or customer surveillance/inspection at organization’s plant or sub-tier supplier’s facility. The organization will be notified if a surveillance/inspection is to be conducted. The Contractor shall support an inspection at the ATP kick-off meeting.

4.6 FLOW DOWN REQUIREMENTS

This clause mandates that all applicable requirements that are invoked or applied to the customer’s purchasing document, including this clause, shall be flowed down to the organization’s sub-tier suppliers.

4.7 CONTROL OF MONITORING AND MEASURING DEVICES

The Project and supporting Contractors shall determine the monitoring and measurement to be undertaken and the monitoring and measuring devices needed to provide evidence of conformity of product to determined requirements. The Project and supporting Contractors shall ensure that environmental conditions are suitable for the calibrations, inspections, measurements and tests being carried out.

4.8 SAFETY CRITICAL PROCESSES

The following shall apply to Project and supporting Contractors designated “safety critical processes”. The Contractor shall notify the customer of proposed changes in safety related process definition and, will obtain approval from NASA prior to implementing the change.

4.9 GOVERNMENT SOURCE INSPECTION

All work on this Purchase Contract is subject to inspection and test by the Government at any time and any place.

4.10 LIMITED LIFE ITEMS

Limited life items shall be documented verifying that each item meets the minimum shelf life specified in the L2 requirements and provided in the end item data package.

4.11 PACKAGING, HANDLING AND SHIPPING

The Project and supporting Contractor’s Quality Control organization shall be responsible for ensuring that items provided under this Contract/Purchase Order are packaged in such a manner that the dimensional integrity is preserved, contamination and corrosion are prevented, and no physical damage occurs. The Project and supporting Contractors shall label the exterior of the package to ensure adequate identification of precautions needed to ensure the integrity of the product being shipped. The Project and supporting Contractors must specify the handling and shipping methods that ensure proper and on-time delivery without damage to the product. The Project and supporting Contractors shall ensure that special labeling requirements shall also be listed in the appropriate shipping documents and on each package. The Project and supporting Contractors shall furnish a Commercial Shipping Documents/Packing List.

4.12 NON-CONFORMANCE REPORTING

Any nonconformance discovered by the Project and supporting Contractors, on products in their control, shall be documented by the organizations’ approved method of nonconformance reporting.

It shall also list what type of inspection revealed the discrepant condition, and what, if any, subsequent actions were taken prior to disclosure. Notification shall be within 3 working days after the nonconformance is discovered.

4.13 GIDEPS

The Project and supporting Contractors shall review all GIDEP ALERTS, GIDEP SAFE-ALERTS, GIDEP Problem Advisories, GIDEP Agency Action Notices, and NASA Advisories to determine if they affect the Contractors products/services provided to NASA.

4.14 ELECTROSTATIC DISCHARGE

The Contractor shall document and implement an ESD Control Program in accordance with ANSI/ESD S20.20, ESD Association Standard for the Development of an Electrostatic Discharge Control Program for Protection of Electrical and Electronic Parts, Assemblies and Equipment (Excluding Electrically Initiated Explosive Devices). Parts must be properly packaged and identified as required in ANSI/ESD-S20.20. All goods will be placed in conductive or static-dissipative packages, tubes, carriers, conductive bags, etc., for shipment. The packaging must be clearly labeled to indicate that it contains electrostatic sensitive goods. Electrical parts that may be used or shipped in conjunction with ESD sensitive parts shall be treated as ESD sensitive.

5.0 SOFTWARE ASSURANCE

5.1 SOFTWARE DELIVERY DOCUMENTATION

Contractor shall deliver the software documentation as specified in the Contract/Purchase Order.

Software documentation shall be sufficient to establish that:

• All requirements are achieved or waivers have been submitted and approved.

• Configuration is correct and deliverables are properly identified and marked.

• Planned level of acceptance is achieved and/or deviations/waivers have been made part of the deliverable documentation package.

Operating instructions accompanying the developed software are sufficient to enable loading, initialization, and operation by NASA personnel.

5.2 CONTROL OF TEST SOFTWARE

Contractor shall provide and maintain a system for the control of software used in the qualification/acceptance testing of deliverable hardware, software, and firmware to be furnished per this Contract/Purchase Order. Contractor shall maintain procedures and test records for items delivered to NASA, including test software, and these records shall be available for NASA review.

5.3 SOFTWARE QUALITY MANAGEMENT SYSTEM:

The Project and supporting Contractor operations shall be consistent with a Software Quality management system that complies with SAE AS 9100.

5.4 SOFTWARE CONFIGURATION MANAGEMENT SYSTEM

Project and supporting Contractors shall be responsible for uniquely identifying, maintaining, and controlling copies of each version of every software unit, component, assembly, every computer file, and every software document produced by this contract. This includes deliverable, supporting, test, and simulation software, computer files containing more than one piece of software, and documents involving plans, procedures, requirements, interfaces, design documents, test plans, test cases run and test case results, Software Qualification Procedures, copies of Software Qualification Test (SQT) results provided by Quality Assurance, and SQT test reports. Project and supporting Contractors shall be responsible for controlling and tracking nonconformance reports against software, processes, and software documents. This includes tracking the status of all non-conformances from discovery until verification that corrections have been properly made.

Project and supporting Contractors shall be responsible for verifying that only authorized changes are made to the software, processes, and software documents.

If shipment of software is required, the Project and supporting Contractors shall submit “configuration documents,” which define the requirements, design, build/production, and verification for that contractual item. These documents shall be signed and dated by an official of the Project and supporting Contractor’s Quality Assurance department and shall include the aforementioned documentation and the following minimum information*:

Contractor’s Contract/Purchase Order number, including any changed orders.

Line item number.

Copy of all object code, source code, and associated non-COTS files necessary to produce the object code.

List of all documents and their revision level associated with this shipment, including procedures, requirements, interfaces, design documents, test plans and procedures, copies of test results provided by Quality Assurance, and test reports.

The procedure for converting source code into object code.

List of all open problem reports and all problem reports closed since the last shipment. The list shall identify the revision(s) of hardware, software, and documents caused by a change to close the problem report.

Copy of all problem reports on the list above with the associated Software Change Control Board activities.

NASA approved deviations and waivers (as applicable).

List of all object code, source code, and associated files necessary to produce the object code, including each piece of software's unique name, current version, date and time of this version’s creation, and size.

o The first eight items are usually combined into a document called the Release Description Document (RDD)"

5.5 SOFTWARE NONCONFORMANCE REPORTING

Project and supporting Contractors shall ensure that a product that does not conform to product requirements is identified and controlled to prevent its unintended use or delivery. The controls and related responsibilities for dealing with nonconforming product shall be defined in a documented procedure.

Project and supporting Contractor’s documented procedure shall define the responsibility for review and authority for the disposition of a nonconforming product and the process for approving personnel making these decisions.

Data Requirements:

Any nonconformance discovered by Contractor or NASA in products under its control shall be documented by Project and supporting Contractor’s approved method of nonconformance reporting. If affecting form, fit, or function, each nonconformance shall be reported on a separate report. This report shall include a detailed description of the nonconformance, location (by naming the software unit(s) and/or the documents involved) and the exact callout of the violation specification requirement (including sub-paragraph and/or illustration number). It shall also list what type of test revealed the discrepant condition, and what, if any, subsequent actions were taken prior to disclosure.

Nonconformance Preliminary Review: The preliminary review process shall be initiated with the identification and documentation of a nonconformance. A preliminary review shall be the initial step performed by Project and supporting Contractors to determine if the nonconformance actually applies to software. The documentation shall be reviewed by Contractor's SQA for completeness and submitted to Project and supporting Contractor’s corrective action procedure.

After unit test of software, all non-conformances shall be reported to NASA within 3 working days after the nonconformance is discovered.

5.6 SOFTWARE DEFINITIONS:

Nonconformance: A condition of any product, material, or service in which any characteristic does not conform to requirements specified in the contract, drawings, specifications, or other approved product description. This includes failures, discrepancies, defects, anomalies, and malfunctions.

Software Unit: The smallest stand-alone piece of code.

Software Component: A group of software units working together.

Assembly: A group of Hardware and Software units and components working together.

5.7 SOFTWARE TESTING:

Project and supporting Contractors shall develop tests and shall provide verification of flight software performance per the Level 2 requirements. In the event a level 2 requirement cannot be verified, then verification shall be performed at the next applicable level. All hardware and software in these tests, and the test results, shall be under the control of Configuration Management. The individuals writing the tests should not be involved in writing the code being developed, however, the developers may aid the testers in an advisory capacity.

5.8 FLIGHT SOFTWARE MARGINS:

Prior to hardware design or procurement, the system (computer, memory, and communication system) shall be analyzed to establish the value of critical parameters needed for proper performance of the software. These parameters are: CPU speeds, control cycle rates, interrupt rates and durations, communications bandwidth/throughput, Random Access Memory (RAM), and Erasable Programmable Read-Only Memory (PROM and EPROM). Performance of existing flight software and associated hardware systems can be demonstrated in lieu of the following requirements:

At hardware selection time, each critical parameter of the hardware shall have a minimum capability of 400% of the Current Best Estimate.

At PDR, each critical parameter shall have a minimum capability of 200% the Current Best Estimate.

At launch each parameter shall have a minimum capability of 15% of the Current measured value.

Project and supporting Contractors shall provide rationale and recovery options for significant deviations from the margin requirements.

5.9 SOFTWARE QUALITY ASSURANCE (SQA):

Project and supporting Contractors shall have Software Quality Assurance (SQA) personnel with access to the highest level of management - NASA and/or regulatory authorities' representatives.

The SQA shall have a reporting path to senior management above the Program/Project manager.

The SSTP SQA shall review and approve all CDRL documents delivered by a Contractor; witness the Software Qualification Test and monitor selected lower level software tests; review all software test results for completeness and accuracy; keep a set of records of their activities separate from the CM records (CM may have a copy of their records); act as the interface between Independent Verification and Validation (IV&V) and Contractor, if required.

A Contractor SQA engineer shall be a member of the Software Change Control Board and verify non-conformances were completely identified and properly tested after correction. A Contractor SQA engineer shall attend all Technical and Project Reviews and provide input as required.

5.10 SOFTWARE CONFIGURATION CONTROL

The Project shall utilize a software version control tool to maintain configuration control of the delivered software, including source code.

The Project shall maintain archived backups of the deliverable software, including source code.

6.0 NPR 7150.2A SOFTWARE COMPLIANCE MATRIX APPENDIX

NPR 7150.2A Software Compliance Matrix

NPR

7150.2A Primary Parent

SWE #

NPR

7150.2A Sect. #

R e s p o n s ib ili ty

Technical Authority

Review "B" Requirement Proposed Requirement Tailoring (for Critical Requirements).

Tailored for SSTP Projects Class D-Light (10-50M)

R=Required as written T =Tailored per

APR 7150.2

COST/SCHEDULE/PROJECT CONTROL

15 2.2.3 P CD* The software activity shall establish, document, and maintain at least one software cost estimate and associated cost parameter(s) that satisfies the following conditions:

a. Covers the mission's or software's life cycle, whichever is shorter.

b. Is based on selected software attributes (e.g., assessment of the size, functionality, complexity, criticality, and risk of the software processes and products).

c. Is based on the cost implications of the technology to be used.

Tailored: Captured in the project LCCE per the WBS structure documented in the SOW or agreed upon with

SSTP.

R

16 2.2.4 P CD* The software activity shall maintain a schedule that coordinates with the overall project schedule.

Required R

20 2.2.8.1 P CE Project will propose a classification for each software system, which will be reviewed and is subject to final approval by the Ames Engineering Technical Authority.

Required: Ref NPR7150.2A Appendix E.

SSTP projects are classified Class D which requires flight software developed as Class B. Proposed Class C or lower software systems need approval from SSTP and the Ames Engineering Technical Authority.

R

24 2.2.13 P CD* The software activity shall ensure that actual results and performance of software activities are tracked against the software plans.

Required R

86 4.2.1 P CE/ SA The software activity will identify software activity risks and provide those risk to the project's risk management processes.

Required R

REQUIREMENTS/

ACCEPTANCE CRITERIA

27 2.3.1 P CD* The software activity shall ensure that when a COTS, GOTS, MOTS, reused, or open source software component is to be acquired or used, the following conditions are satisfied:

a. The requirements that are to be met by the software component are identified.

b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).

c. Proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed.

d. Support for the software product is planned through the mission or software use, whichever is shorter.

e. The software component is verified and validated to the same level of confidence as would be required of the developed software component.

Required R

34 2.5.3 P CD* If software components will be provided by a supplier, the software activity management shall:

a. Require the software supplier(s) to provide a software schedule.

b. Define the milestones at which the software supplier(s) progress will be reported and/or reviewed and the scope/content of those reviews.

c. Define the acceptance criteria and conditions for taking delivery of software from the supplier.

d. Assure that the project has the right to use the delivered software for the intended mission purposes.

Required: Supplier developed flight software shall be managed and reported on consistent with in-house requirements for flight software development.

NASA flight software contractual requirements shall be flowed to the supplier.

T (C&D required)

50 3.1.1.2 P CD* The software activity shall derive, document, and maintain software requirements based on flowed-down project and sub-system requirements and mission operational concepts.

Required R

52 3.1.1.4 P CD* The software activity shall perform, document, and maintain bidirectional traceability between:

- Higher-level project requirements

- Software requirements

- Software architecture and design

- Code

- Verification & Validation activities and results

Required R

75 3.5.2 P CD* The project shall plan software operations, maintenance, and retirement activities, as appropriate to the life cycle of the software and mission.

Required T

125 6.3.2 P CE Software activity shall maintain a compliance matrix against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles.

Tailored: Software activity shall maintain a compliance matrix against requirements in this Appendix, including those delegated to other parties or accomplished by contract vehicles.

R

DESIGN

PRACTICES/DESCRIPTION

57 3.2.2 P CD* The software activity shall transform the allocated and derived requirements into a documented software architectural and detailed design sufficient to allow the lower-level units to be coded and tested. During design, the software activity shall assess options for software acquisition versus development.

Tailored: The software architecture and detailed design shall be derived from the allocated requirements sufficient to allow the lower-level units to be coded and tested.

T

61 3.3.2 P CD* The software activity shall review and adopt software coding methods/standards, and/or criteria appropriate to the software form (e.g., development environment and language), and function.

Tailored: The software activity shall conform to a uniform documented software coding standard.

R

136 3.3.7 P CD* The software activity shall validate software tool(s) required to develop or maintain software for their intended use.

Tailored: The software activity shall validate custom software tool(s) required to develop or maintain software for their intended use.

T

PROBLEM REPORTING/

CORRECTIVE ACTION

30 2.4.3 P CD* The software activity shall record, address, and track to closure the results of verification and validation activities including:

- Evaluate test results and document the evaluation, including recording and tracking to closure identified defects.

Required R

54 3.1.2.2 P CD* The software activity shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products.

Tailored: The software activity shall identify, initiate corrective actions, and track until closure.

Inconsistencies among software requirements, project plans, and software products shall be corrected or documented as a risk.

R

VERIFICATION AND VALIDATION

TEST PLANS/REPORTS

28 2.4.1 P CD* The software activity shall plan verification and validation activities, methods, environments, and criteria.

Required R

65 3.4.1 P CD* The software activity shall establish and maintain:

- Software Test Plan(s)/Procedure(s)

- Software Test Report(s).

Required T

62 3.3.4 P CD* The software activity shall ensure that the software code is unit tested.

Required R

67 3.4.3 P CD* The software activity shall ensure that each software requirement is verified by demonstration, test, analysis, or (in special cases requiring justification) inspection.

Required R

55 3.1.2.3 P CD* The software activity shall perform requirements validation to ensure that the software will perform as intended in the customer environment.

Required R

73 3.4.9 P CD* The software activity shall ensure that the software system is validated on the targeted platform or high-fidelity simulation.

Required R

70 3.4.6 P CD* The software activity shall verify, validate, and accredit software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment.

Required R

135 3.3.3 P CD* The software activity shall ensure that results from static analysis tool(s) are used in verifying and validating software code.

Tailored: Recommended but not required.

R

USER DOCUMENTATION

77 3.5.4 P CD* The software activity shall complete and deliver the software product to the project with appropriate as-built documentation to support the software's use to achieve the project's mission objectives.

Tailored: SSTP project negotiable for software product delivery.

Appropriate documentation to support the software's use to achieve the project's mission objectives is required.

T

CONFIGURATION MANAGEMENT/

VERSION CONTROL

79 4.1.1 P CD* The software activity shall develop, record, and maintain a software configuration process that includes:

- the functions, responsibilities, and authority for the implementation of software configuration management for the project.

- identifies the software configuration items (e.g., software documents, code, data, tools, models, scripts).

- the control processes for each identified configuration item.

- ensure that software configuration audits are performed.

Required R

85 4.1.7 P CD* The software activity shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products.

Required R

PEER REVIEW

87 4.3.1 P CD* The software activity shall perform peer reviews for:

a. Software requirements.

b. Any design items that the project identified for software peer review/inspections according to the software development plans.

c. Software verification and validation plans.

d. Software code deemed of sufficient criticality to require peer review.

Required T

88 4.3.3 P CD* The software activity shall, for each planned software peer review/inspections:

a. Use established readiness and completion criteria.

b. Track actions identified in the reviews until they are resolved.

c. Identify required participants.

Tailored: The software activity for planned software peer reviews/inspections shall follow processes as stated in the software development plans.

T

METRICS

91 4.4.2 P CD* The software activity shall select, record, and report (as requested) specific measures in the following areas:

a. Software progress.

b. Software defects.

Required T