J1a_4_-_PTD_L1_and_L2_Requirements-000001.xlsx

XLSX spreadsheet 139 KB Posted Mar 15, 2016

Attached to: Pathfinder Technology Demonstrator (PTD)
Solicitation number: NNA16574335R
Issued by: National Aeronautics and Space Administration Ames Research Center

About this file

From the source

J1a4 - PTD L1 and L2 Requirements (Amendment 000001)

View the file

Other files

File	Type	Posted
J1a_3_-_PTD_Spacecraft_to_Payload_ICD_Rev1.pdf	PDF	Mar 16, 2016
J1a_1_-_Pathfinder_Technology_Demonstrator_SOW_(Rev1).pdf	PDF	Mar 16, 2016
NNA16574335R-000002.pdf	PDF	Mar 16, 2016
NNA16574335R-000001_(Changes).pdf	PDF	Mar 15, 2016
NNA16574335R-000001_(Q A).pdf	PDF	Mar 15, 2016
J1a_4_-_PTD_L1_and_L2_Requirements.xlsx	XLSX spreadsheet	Feb 12, 2016
NNA16574335R_-_PTD_Solicitation.pdf	PDF	Feb 12, 2016
J1b_8_-_PTD_RFP_Costing_and_Staffing_Tables.xlsx	XLSX spreadsheet	Feb 12, 2016
J1a_2_-_APR8070.2.pdf	PDF	Feb 12, 2016
J1b_7_-_PTD_Operational_Concept.pdf	PDF	Feb 12, 2016
J1b_6_-_PTD_Thrust_Measurement_Approach.pdf	PDF	Feb 12, 2016
J1a_5_-_Safety_and_Mission_Assurance_Plan.pdf	PDF	Feb 12, 2016
J1a_3_-_PTD_Spacecraft_to_Payload_ICD.pdf	PDF	Feb 12, 2016
J1a_1_-_Pathfinder_Technology_Demonstrator_SOW.pdf	PDF	Feb 12, 2016
DRAFT_L1_L2_Requirements_(12182015).xlsx	XLSX spreadsheet	Dec 22, 2015
DRAFT_SOW_-_Pathfinder_Technology_Demonstrator_(12182015).pdf	PDF	Dec 18, 2015
DRAFT_ICD_(12182015).pdf	PDF	Dec 18, 2015

Show all 17

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Title

Pathfinder Technology Demonstrator Project Requirements Document Level 1, Level 2

March 08, 2015

NASA’s Pathfinder Technology Demonstrator project will test the operation of a variety of novel satellite technologies in low Earth orbit, providing significant enhancements to the performance of these small and effective spacecraft.

Requirements are grouped by WBS level and contained in separate tab sheets below. The Program Level 1 requirements are also provided in a separate tab for reference. Trac, allocation and V&V method is shown for each requirement. V&V methods are:

T=Test, D=Demonstration, A=Analysis, I=Inspection

Program L1

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I

1.0	Pathfinder Technology Demonstrator MISSION OBJECTIVE
L1-PTD-01	The purpose of the Pathfinder Technology Demonstrator (PTD) mission is to demonstrate novel satellite technologies in Low Earth Orbit (LEO).	Project-wide

&"Arial,Bold"&14LUNAR CRATER OBSERVATION AND SENSING SATELLITE

(LCROSS)

MISSION REQUIREMENTS&"Arial,Regular"&10 &A

1. Project

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I

1.0	Project-Wide requirements
1.1.1	The PTD Project shall produce flight-ready cubesat technology demonstration solutions capable of characterizing payloads in LEO orbit (maximum 800km).	Project-wide			X	Since Launch manifest is unknown, requirement is to have flight solutions ready to be placed on available launch opportunities.
1.1.2	The PTD flight-ready cubesats shall be developed to allow for a one year shelf-life prior to launch.	Project-wide		X		Launch opportunities may require being shelved until a launch is available
1.1.3	The PTD flight-ready cubesats shall be developed to be compliant with USA cubesat launch providers.	Project-wide	X			Do not want to create a solution requiring custom deployment solutions making it harder to find a launch opportunity
1.1.4	The PTD mission shall be conducted in a manner compliant with a tailored NPR 7120.5C and 8705.4 Class D light, Category III mission.	Project-wide		X	X	Follow SSTP tailored Class D NASA standards
1.1.5	The PTD shall follow NPR 8715.6 to limit orbital debris and document in an Orbital Debris Assessment Report (ODAR).	Project-wide		X		Follow ODAR standard

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

3. SS&MA

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I

	3.0	Risk Management, System Safety & Mission Assurance
	3.1	Risk Management
	3.1.1	PTD shall conduct a continuous risk management (CRM) program in compliance with NPR 7120.5C and NPR 8000.4.	ESMD RMP
NPR 7120.5C NPR 8000.4	Project-wide			X	Project plan on using ePort. Vendor will have their own RM system.

3.2	System Safety
3.2.1	PTD hardware will be designed and operated to prevent damage to personnel and flight hardware in both nominal and off-nominal situations.		Project-wide	X	Follow standard safety best practices for safety
3.2.2	PTD shall comply with the applicable requirements of the following documents: Expendable Launch Vehicle Payload Safety Review Process Standard, NASA-STD-8719.8; Eastern and Western Range (EWR) 127-1, Range Safety Requirements, EWR 127-1; Range Safety Program, NPR 8715.5; NASA Safety Manual, NPR 8715.3	NASA-STD-8719.8 NPR 8715.5 NPR 8715.3 EWR 127-1	Project-wide	X	These are the standards for a KSC launch, but may need to add some others, ISS standards SSP51700?

3.3	Mission Assurance
3.3.1	PTD shall comply with the requirements of NASA Quality Assurance Program Policy, NPD 8730.5, and NASA Policy for Safety and Mission Success, NPD 8700.1C, as tailored for a Category IV Tailored Class D secondary payload	NPD 8730.5 NPD 8700.1C	Project-wide	X		Tailoring of requirements will be captured in the SMA plan and the Mission Assurance Requirements documents
3.3.2	PTD shall comply with the tailored requirements of NASA Quality Assurance Program Policy, NPR 7150.2 Software (flight code).	NPR 7150.3	Project-wide	X		Tailoring of requirements will be captured in the SMA plan and the Mission Assurance Requirements documents
3.3.3	PTD shall follow NASA EEE Parts Assurance Group (NEPAG) guidance for EEE part selection and meet a minimum Level 3 grade for parts in critical subsystems.		Project-wide		X	Level 3 is the lowest flight grade recognized by NASA and are those produced by reputable manufacturers under a recognized quality assurance system (QML, QPL, ISO 9000) or their equivalent.

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

4. Science

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
4.1	Science Requirements

4.1.1	The PTD project shall provide a PI to lead any required scientific analysis necessary for characterization of Payload system performance	Project	X		The PTD project PI is responsible for Prop system
4.1.2	The PTD Payload PI shall be responsible for providing a daily H&S assessment of the Payload subsystem.	PI	X		(Level 3 to perform look up table assessment of prop remaining?)
4.1.3	The PTD PI shall be the final arbiter for decisions on nominal Payload operation.	PI	X		Decisions about Payload operation are made by the Payload PI for operation of the payload. In the event of a health and safety issue with the spacecraft, the payload PI will be a participant/contributor in the decision process, but Flight Director will make final decisions.
4.1.4	The Payload PI shall provide limits, task orders and command scripts to MOC/I&T necessary to operate the Payload.	PI	X		The Payload PI provides payload tasking and input to Operations for operation of the payload.
4.1.5	PTD MOC shall provide simulator checkout of PI provided Payload tasking prior to upload and execution on-orbit.	PI, MOC	X
4.1.6	PI shall provide a Payload system characterization report within 60 days of flight completion documenting compliance with mission success criteria.	PI		X

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

5. Payload System (MEP)

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
5	Payload System Requirements
5.1	Pathfinder Payload Requirements
5.1.1	The Payload shall not exceed the total volume defined in the Spacecraft to Payload ICD.		Payload			X	X	The exact volume and locations will be negotiated at formation of the ICD.
5.1.2	The Payload developer shall document the measured thrust direction, variability, and location of thrust relative to reference system as documented in the Spacecraft to Payload ICD.		Payload	X		X		Document forces that will be produced by the Payload thrust.
5.1.3	The Payload shall conform to CG and total mass limits specified in the Spacecraft to Payload ICD.		Payload			X	X	Payload mass allocation and CG issues will be negotiated at ICD formation
5.1.4	The Payload shall be capable of operating from spacecraft-supplied power as specified in the Spacecraft to Payload ICD.		Payload	X		X		The exact voltage and whether unregulated or regulated will be negotiated at formation of the ICD.
5.1.5	The Payload shall be configured to communicate signals and data to the Flight System as specified in the Spacecraft to Payload ICD.		Payload	X		X		Most likely RS-422 asynchronous
5.1.6	The Payload shall support a 90 day mission lifetime on orbit.		Payload			X		Operation on orbit could be as long as 90 days. Not meant to infer a 90 day continuous firing capability, but that the payload could be utilized off and on during a 90 day period.
5.1.7	The Payload shall be thermally controlled as specified in the Spacecraft to Payload ICD.		Payload	X		X		The intent of this requirement is to have the Flight system provide some thermal control support for the Payload.
5.1.8	The Payload shall be designed to withstand the maximums allowed for the LV dynamics (vibration, shock, acoustics) as per GEVS (GSFC-STD-7000A) levels		Payload	X		X		This standard encompasses all the potential launch vehicles we may be manifested on
5.1.9	The Payload shall be capable of being powered off for launch and powered on by the Spacecraft at any time during the flight.		Payload			X		Power supply interface from Payload will be switched
5.1.10	The Payload shall provide harnesses and cabling for the Payload System as specified in the Spacecraft to Payload ICD.		Payload	X				The definition of the exact cable/harness interface, as well as cable routing, will be negotiated in the Spacecraft to Payload ICD
5.1.11	The Payload shall be developed to allow for a one year shelf-life prior to launch.		Payload			X		We could be shelved awaiting launch manifest. If fuels, seals, etc. may degrade in that time, then will need a plan to fuel/refuel at LV integration.
5.1.12	The Payload shall be responsible for supplying mounting structures as specified in the Spacecraft to Payload ICD.		Payload				X	Exact interface definition will be negotiated and documented in a Spacecraft to Payload ICD.
5.1.13	The Payload shall provide a simulator of the Payload to support System Integration testing.		Payload		X		X	Support electrical, command and control interfaces to allow for integration testing .
5.1.14	The Payload shall be able to acquire Health and Status information from its instruments.		Payload	X				Necessary to monitor status of subsystem and for diagnostics.
5.1.15	The Payload shall be able to provide Health and Status information for the Payload to the Spacecraft as specified in the Spacecraft to Payload ICD.		Payload, Vendor	X				Necessary to send H&S information to the GDS for analysis and review.
5.1.16	The Payload shall provide engineering telemetry sufficient for MOC to determine the quantity of propellant remaining to within 5% (TBR).		Payload, Vendor, MOC			X		Provide data to determine propellant level, e.g. firing times that can be correlated with lookup tables on the ground.
5.1.17	The Payload shall provide engineering telemetry sufficient for MOC to determine the thruster performance ISP within 5% (TBR).		Payload, Vendor			X		Provide data to model thruster performance to calculate future thrust command durations. The Spacecraft provides engineering telemetry to measure orbit change. Engineering telemetry may be combined with lookup tables or ground analysis to determine actual ISP, the requirement is to make sure whatever data is needed on thruster operation is provided.
5.1.18	The Payload shall provide a safe plug to inhibit unsafe operation on the ground per the electrical interface in the Spacecraft to Payload ICD.		Payload, Vendor	X			X	S&MA safety requirement (and probably also the LV) to physically prohibit a thruster being activated.
5.1.19	Payload bus solution shall provide Payload electrical interfaces as specified in the Spacecraft to Payload ICD.		Payload, Vendor	X		X
5.1.20	Payload bus solution shall provide Payload mechanical interfaces as specified in the Spacecraft to Payload ICD.		Payload, Vendor	X		X
5.1.21	Payload bus solution shall provide Payload thermal interfaces as specified in the Spacecraft to Payload ICD.		Payload, Vendor	X		X
5.1.22	Payload bus solution shall provide Payload communication interfaces as specified in the Spacecraft to Payload ICD.		Payload, Vendor	X		X
5.1.23	Payload shall provide and EIDP upon delivery containing:

•Propulsion System Specs •Propulsion System Drawings (MICD/EICD) •Propulsion Assembly/Handling Procedures •Propulsion System Limits/Constraints •Propulsion System Test Data and Scripts •Propulsion System CMD/TLM Requirements

•Propulsion System Acceptance Test Procedures		Payload			X
	5.1.24	The Payload shall provide EMI/EMC test data and analysis (TBD).		X	X		Need to define specifics. Looking for self-compatible, measured output provided to SC vendor, and documenting any particular sensitivities that may disrupt thruster operation.
	5.1.25	The Payload shall be shipped to the spacecraft vendor appropriately packaged in a shipping container.	Payload			X
	5.1.26	The Payload developer will provide any required GSE necessary for I&T and/or LV integration of the Payload.	Payload			X

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

6. Flight System

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
6	Flight System Requirements
6.1	Tracking, Telemetry, and Control (TT&C)
6.1.1	Tracking
6.1.1.1	PTD shall be capable of producing tracking and ephemeris solutions based on collected GPS telemetry from the spacecraft.		MOC	X		X		GPS captured on-board, tracking construction and ephemeris can be on-board or on the ground
6.1.1.2	PTD shall collect GPS position solutions using an on-board GPS at a 1 Hz rate, with <100m (3 sigma) position (X,Y,Z) accuracy.		Vendor	X		X		GPS captured on-board, tracking construction and ephemeris can be on-board or on the ground
6.1.1.3	PTD shall collect GPS velocity solutions using an on-board GPS at a 1 Hz rate, with accuracies of <0.2 m/s (3 sigma).		Vendor	X		X		GPS captured on-board, tracking construction and ephemeris can be on-board or on the ground
6.1.1.4	PTD shall collect GPS measurements time-stamped with <10ms (3 sigma) accuracy.		Vendor	X		X		GPS captured on-board, tracking construction and ephemeris can be on-board or on the ground

6.2.1	Telemetry
6.2.1.1	PTD shall store MOC-specified engineering and health telemetry generated by the Spacecraft during the last 6 days.	Vendor/MOC	X	X	To enable reconstruction of spacecraft performance & trajectory, model spacecraft state, and to support anomaly analyses. Mission design will ensure three day maximum between Command passes. MOC-specified telemetry is specified by other requirements.
6.2.1.2	PTD shall be capable of selectively transmitting stored telemetry upon command of the MOC.	Vendor	X		Allow for selective downlink of portions of the on-board telemetry buffer.
6.2.1.3	PPS shall provide engineering telemetry to allow the MOC to reconstruct maneuver and attitude control events with at least a 10hz resolution.	Vendor	X	X	S/C may change trajectory in a way that was not commanded (reconstruct errors or disturbances). Actual telemetry downlinked should be configurable for sampling/decimation rate.
6.2.1.4	The Spacecraft shall be capable of radiating telemetry to the ground at a rate and duration able to downlink 250Mbits per day.	Vendor	X	X	Based on number of available passes and data rates available, the RF solution needs to be able to achieve this much data per day. Data will be divided up between Payload and Spacecraft H&S data. For purposes of throughput analysis, NEN 11M ground stations (Wallops, McMurdo, Svalbard, Alaska) and a high inclination polar orbit should be assumed.
6.2.1.5	The Spacecraft shall be capable of radiating telemetry to the ground with greater than 3db link margin.	Vendor	X	X	For purposes of data throughput analysis, Ground antenna elevations of >10deg and link margins of >3db should be considered
6.2.1.6	PTD shall radiate telemetry on a specified S-band frequency.	Vendor	X		Spacecraft, MOC must use agreed upon frequency and receive certification to use. Note: if the vendor supplies the GDS, then RF solution is up to the vendor.
6.2.1.7	PTD shall be capable of providing telemetry defining the state of any quantity or function monitored or capable of being updated by the FSW.	Vendor		X	to verify spacecraft state by MOC
6.2.1.8	The Spacecraft shall be capable of maintaining TLM transmission while performing payload system characterization.	Vendor		X	Must simultaneously track target with instruments and transmit resulting high-rate data
6.2.1.9	The Spacecraft shall be capable of operating PTD payload and transmitting data at full rate during orbital eclipses up to 35min.	Vendor	X	X	Battery-size requirement
6.2.1.10	PTD shall monitor SC elements necessary for the MOC to assess the state of the spacecraft.	Vendor		X	Provide data for health analysis and to determine spacecraft state.
6.2.1.11	PTD shall be capable of transmitting any or all of its memory contents on command by MOC.	Vendor	X	X	Validate state of the spacecraft memory. Memory may become corrupted or be in an off-nominal state.
6.2.1.12	PTD shall provide engineering telemetry sufficient for MOC to determine the battery state-of-charge within 10%.	Vendor		X	Battery state is needed to calculate duration the s/c can operate with solar panel off sun.
6.2.1.13	PTD shall indicate receipt and execution of all commands and command sequences in Telemetry.	Vendor

6.3.1	Commanding
6.3.1.1	PTD shall be capable of performing its required functions through the use of on-board stored operating programs, stored command sequences, and real-time commands radiated by the MOC.	Vendor	X
6.3.1.2	PTD command sequences shall support absolute time and relative time commands.	Vendor	X			Absolute time means execute at a specified time. Relative time means execute after a period of time (like a delay statement).
6.3.1.3	PTD shall be capable of storing and deleting command sequences as commanded by the MOC.	Vendor	X			Memory management for on-board command sequences
6.3.1.4	PTD shall execute commands radiated by the MOC on receipt.	Vendor	X		X
6.3.1.5	The PTD shall be capable of executing specified command sequences only after confirmation by the MOC.	Vendor	X		X
6.3.1.6	The PTD shall be capable of executing specified command sequences upon detection of a fault or limit exceedance.	Vendor	X			For fault conditions or limits being exceeded, automatically run a stored sequence if configured to do so
6.3.1.7	PTD shall ignore commands that are not sent by the MOC or improperly formatted.	Vendor	X		X	This is largely taken care of within CCSDS and COP1 support. Not meant to require encryption.
6.3.1.8	PTD shall be capable of receiving commands radiated by the MOC using a specified S-band frequency.	Vendor	X		X	Spacecraft, MOC must use agreed upon frequency and receive certification to use. Note: if the vendor supplies the GDS, then RF solution is up to the vendor.
6.3.1.9	PTD primary receiver shall be continuously receptive to commands in case of a failure that disrupts nominal MOC to Spacecraft communications.	Vendor	X		X	After initial ejection and power-up, the CMD receiver must be on at all times and able to receive commands.
6.3.1.10	PTD shall receive commands at a minimum 4kbps.	Vendor		X		Higher rates are acceptable based on power margin in Link Budget. Command link should ensure >10dB in all conditions.

6.4	GNC
6.4.1	PTD shall be capable of controlling maneuver magnitude to within +/- 5%, of the magnitude commanded by the MOC	Vendor		X	X	Thruster payload specific requirement for Delta-V maneuvers.
6.4.2	PTD shall be capable of maintaining an attitude of +/- 1 degree in all axes during nominal (cruise) operations.	Vendor	X		X	Reduce risk of trajectory changing that could cause loss of the spacecraft
6.4.3	PTD shall be capable of changing the attitude pointing tolerance of the spacecraft by command from the MOC.	Vendor	X			Different ACS deadbands are suitable at different mission phases.
6.4.4	PTD shall have a control mode that maintains one axis pointed Earth-nadir, while the payload is pointed in the velocity or anti-velocity direction, as commanded by the MOC.	Vendor	X			For thrusting payload, nadir point is used to raise or lower orbit in a circularized manner by increasing or decreasing velocity.
6.4.5	PTD shall provide a precision control mode that points payload to a fixed Earth surface location within +/- 0.1 degree while that location is in view.	Vendor	X		X	For Earth pointing payloads like optical comms, need to point payload to a ground station. This mode would be for one of the Option flights.
6.4.6	During fixed Earth-point tracking mode, the S/C shall accept pointing error updates, with a relative accuracy of +/- 2 microradians (TBR), provided by the payload at 30Hz (TBR) to implement attitude corrections.	Vendor	X			Optical payload will provide pointing corrections to be implemented by SC
6.4.7	During fixed Earth-point tracking mode, S/C shall point (within 1 Hz (TBR) bandwidth), once tracked to Payload error updates, to < 10 microradians RMS absolute pointing error.	Vendor			X	Drives wheels and update frequency/precision
6.4.8	During fixed Earth-point tracking mode, S/C shall provide GPS time data to Payload at a a rate of 1Hz.	Vendor	X
6.4.9	PTD shall provide a stellar inertial control mode that holds spacecraft attitude to a fixed point in space relative to an Earth-Centered-Inertial Frame.	Vendor	X		X	For optical payloads to point to celestial objects, or to point solar arrays at sun for maximum efficiency.
6.4.10	PTD attitude control shall be capable of being enabled/disabled by a MOC command or command sequence	Vendor	X		X	Payload may be a precision attitude control capability, so need to be able to turn off PTD ACS control.
6.4.11	PTD shall support a torque-rod only course attitude control mode capable of supporting stellar inertial and nadir pointing submodes.	Vendor	X		X	This may be the same or similar mode used for safe mode but without potential power shedding. Control deadband should be best effort and inertial and nadir point submode capable.
6.4.12	PTD shall support MOC commanded reaction wheel desaturation with magnetic torques or propulsive solution.	Vendor	X		X	Allow commanded desaturation
6.4.13	PTD shall provide a mode for automated reaction wheel desaturation with torque rods.	Vendor	X		X	Perform desaturation when momentum exceeds some set limit
6.4.14	PTD shall provide an attitude control detumble rate reduction mode to null rates up to 20 degs/sec (TBR) in each axis.	Vendor	X		X	detumble spacecraft after ejection from canister
6.4.15	PTD shall provide a sun-safe mode that will orient SC to a power-positive attitude from any starting attitude and then maintain a power positive state.	Vendor	X		X	Safe mode that ensures SC is power positive. Assumes post solar array deployment if power solution is a deployable solar array.
6.4.16	PTD shall be capable of automatically entering a power-positive safe-mode in the event of a critical fault unless the fault keeps this mode from being entered.	Vendor	X		X	Enter safe mode for critical faults
6.4.17	PTD shall provide a reaction-wheel desaturation mode using a hybrid of torque rod(s) and thrusters for propulsion payloads.	Vendor	X		X	This is a MEP-specific control mode to allow off-axis torque from the thrusters to be used to desaturate wheels.

6.5	Supply and Connectivity
6.5.1	PTD shall be interface compliant with selected Cubesat launcher and launch vehicle.	Vendor		X	X	CubeSat will need to be compatible with the LV and dispenser(s) supported.
6.5.2	PTD FSW and avionics shall be configured to communicate signals and data to and from the Payload as specified in the PTD to Payload ICD.	Vendor	X	X		PLS - Spacecraft interface will be RS-422, which will be more fully specified in an PTD to PLS ICD
6.5.3	PTD shall be able to receive and packetize Payload transmitted data at a peak data rate of 32kbps (TBR).	Vendor	X	X		This is the planned data rate from the MEP Thruster payload that the Spacecraft will need to support. Other payloads could have significantly higher rate requirements
6.5.4	PTD shall provide the payload with a 1PPS signal for clock synching purposes as specified in the PTD to Payload ICD.	Vendor	X			Provides a mechanism for avionics and payload clock synchronization.
6.5.5	PTD shall be capable of supplying power during 35 minutes of eclipse operations.	Vendor	X	X		Payload specific power to be called out in payload reqts.
6.5.6	PTD shall supply the Payload at least 45 (TBR) Watts on-orbit-average power.	Vendor		X
6.5.7	PTD shall be powered off for launch and powered on after 45 minutes from launcher ejection.	Vendor	X	X
6.5.8	The PTD shall reset its comms if a command has not been received from the ground for a MOC-configurable length of time.	Vendor	X			Reset comms if the ground has not communicated in case the problem is with the spacecraft e.g., 4 days.
6.5.9	The PTD shall begin periodic broadcast of a CW tone beacon if a command has not been received from the ground for a MOC-configurable length of time.	Vendor	X			Assume spacecraft is lost by the ground, transmit a tracking beacon to facilitate getting located.

6.6	Spacecraft
6.6.1	PTD shall be designed to support a 4 month mission lifetime in a 350km to 800km altitude LEO orbit.	Vendor			X		2 week commissioning + up to 76 days of propulsion characterization
6.6.2	PTD shall provide a 6U Cubesat in a 2Ux3U form factor.	Vendor			X		Follow Cubesat design standards as managed by California Polytechnic State University definitions
6.6.3	PTD shall not exceed 12 Kg total wet mass.	Vendor	X				Standard 6U Cubesat mass allocation and includes any Payload mass (up to 3kg).
6.6.4	PTD shall use an error-correcting memory solution to help ensure memory integrity.	Vendor	X		X
6.6.5	PTD shall maintain Payload components to thermal environments specified in the PTD to Payload ICD.	Vendor			X		Defines safe operating range for PLS components, this could be highly variable for different prop systems, so may not be a relevant requirement to constrain
6.6.6	PTD shall be designed to withstand the maximums allowed for the LV dynamics (vibration, shock, acoustics) as per GEVS (GSFC-STD-7000A) levels	Vendor	X		X		Constrains SC components to be developed for the expected Launch vehicle characteristics
6.6.7	PTD shall provide the Cubesat launcher assembly.	NASA				X
6.6.8	PTD shall supply the Payload power in accordance with the PTD to Payload ICD.	Vendor	X		X		Standard power from the spacecraft
6.6.9	PTD shall provide structural/mechanical interface definitions for the payload as specified in the PTD to Payload ICD.	Vendor			X
6.6.10	CubeSats shall be passive and self-contained from the time they are loaded into the dispenser until after deployment from the dispenser. No charging of batteries, support services, and or support from the integration team is provided after final integration.	Vendor				X
6.6.11	CubeSats shall not contain pyrotechnics unless the design approach is pre-approved by NASA Ames. Electrically operated melt-wire systems for deployables that are necessary controls for hazard potentials are permitted.	Vendor				X
6.6.12	CubeSats must have a timer (set to a minimum of 30 minutes) before satellite operation or deployment of appendages. If deploy switches should be released causing the time to run, the timer must automatically re-set whenever the Remove Before Flight (RBF) feature is replaced and/or the deploy switches are returned to the open state.	Vendor	X
6.6.13	RBF pins must be capable of remaining in place during integration with dispenser. It shall not be necessary to remove the RBF to facilitate loading into the dispenser.	Vendor		X
6.6.14	CubeSats should not have detachable parts or create any space debris during launch or normal mission operations.	Vendor				X
6.6.15	CubeSats shall use secondary locking feature for fasteners external to the CubeSat chassis. An acceptable secondary locking compound is Loctite. Other secondary locking methods must be approved by NASA Ames.	Vendor				X
6.6.16	A description of the frangible materials (e.g. solar cells) must be provided to NASA Ames for approval.	Vendor				X
6.6.17	Deployable systems shall be designed such that there is no intentional contact with the inside walls of the dispenser.	Vendor
6.6.18	CubeSats are accessible only through the access panels when integrated with the dispenser.	Vendor				X
6.6.19	Mass limits are derived from the maximum ballistic number (BN) allowed for launch vehicle deployed payloads. Exceeding these values requires approval by NASA Ames.	Vendor		X			<May change depending on dispenser>
6.6.20	The CubeSat center of gravity shall be within 2cm of its geometric center.	Vendor		X
6.6.21	No CubeSat components or structure, other than rails or rail roller/slider switch (if used), shall contact the dispenser interior.	Vendor		X			<May change depending on dispenser>
6.6.22	CubeSat rail surfaces that contact the dispenser guide rails shall have a hardness equal to or greater than hard anodized aluminum (Rockwell C 65-70).	Vendor				X	<May change depending on dispenser>
6.6.23	During deployment, the CubeSats must be compatible with deployment velocities between 0.5 m/s to 1.5 m/s and accelerations no greater than 2g’s in the +Z direction.	Vendor					<May change depending on dispenser>
6.6.24	All electrical power shall be internal to CubeSat.	Vendor				X
6.6.25	The CubeSat powerup shall not begin until a minimum of 45 minutes (TBD) after deployment. Only an onboard timer system may be operable during this 45-minute post deploy time frame.	Vendor	X				<May change depending on dispenser>
6.6.26	The CubeSat electrical system design shall incorporate a minimum of three (3) inhibit switches actuated by physical deployment switches.	Vendor				X	<May change depending on dispenser>
6.6.27	The CubeSat electrical system design shall not permit the ground charge circuit to energize the satellite systems (load), including flight computer. This restriction applies to all charging methods.	Vendor	X				<May change depending on dispenser>
6.6.28	The RBF pin shall preclude any power from any source operating any satellite functions with the exception of pre-integration battery charging.	Vendor	X				RBF (Remove Before Flight)
6.6.29	All RBF pins, switches, or jumpers utilized as primary electrical system and RBF inhibits must be accessible from the access panels for removal at the completion of loading into the dispenser	Vendor				X	<May change depending on dispenser>
6.6.30	CubeSats that utilize on-board batteries shall comply with NASA requirements for battery safety.	Vendor	X
6.6.31	CubeSats shall comply with NASA guidelines for hazardous materials as shown in MSFC-HDBK-527, Materials Selection List for Space Hardware Systems.	Vendor				X
6.6.32	CubeSat developers shall submit a Bill of Materials (BOM) to NASA Ames for assessment.	Vendor				X

	6.7	Flight Software
	6.7.1	The s/c vendor shall participate in software reviews as specified in the SOW (e.g. SRR, PDR/CDR, SIR, ORR/FRR)	Vendor			X
	6.7.2	The s/c vendor shall provide NASA with a test plan to verify software functionality and quality at an L2 level.	Vendor
	6.7.3	The s/c vendor shall provide the results of any trade studies performed in the development of the flight software.	Vendor
	6.7.4	The s/c bus vendor shall track software changes and non-conformances and provide the data to the customer for review.	Vendor			X
	6.7.5	The s/c bus vendor shall maintain a documented software development process.	Vendor
	6.7.6	The s/c vendor shall have a software configuration management process.	Vendor
	6.7.7	The software development and configuration management processes shall be audited and approved by NASA.	Vendor, NASA
	6.7.8	The s/c bus provider shall provide NASA with a software development schedule and maintain that schedule throughout the project lifecycle.	Vendor			X
	6.7.9	The s/c bus vendor shall notify NASA as to whether or not open-source software will be used, and in what manner.	Vendor			X
	6.7.10	The project manager shall establish, record, maintain, report, and utilize software management and technical
measurements.		Vendor		X	Note: IEEE Standard Adoption of ISO/IEC 15939 - Systems and Software Engineering - Measurement Process is a good generic model for developing a software measurement process for a project or Center. This international standard contains a set of activities and tasks that comprise a measurement process that meets the specific needs of organizations, enterprises, and projects. The NASA Chief Engineer may identify and document additional Center measurement objectives, software measurements, collection procedures and guidelines, and analysis procedures for selected software projects and software development organizations. This includes collecting software technical measurement data from the project's software supplier(s).

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

7. Mission Ops(NASA GDS)

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
7	Mission Operation Requirements
7.1	General Requirements
7.1.1	The PTD shall develop a Mission Operations Center (MOC) compatible with existing MMOC GDS infrastructure.		MOC,				X
7.1.2	The PTD MOC shall staff at least one command pass per weekday.		MOC			X
7.1.3	The PTD GDS shall support up to 14 lights-out automated data downlink passes per day.		MOC			X
7.1.4	The Vendor shall provide personnel on-site for Operational Readiness Testing (ORTs) and training activities for 2 weeks.		Vendor		X			Travel to NASA Ames and support MOC operations and training on-console in preparation for flight operations.
7.1.5	The Vendor shall provide on-site MOC support for 1-week of on-orbit checkout of the spacecraft.		Vendor		X			Travel to NASA Ames and support MOC operations on-console
7.1.6	The Vendor shall provide on-call MOC support for 1-month of on-orbit operation of the spacecraft.		Vendor		X			Support questions or anomaly resolution on operation of the spacecraft
7.1.7	The PTD MOC shall perform necessary NEN scheduling activities to support up to 14 passes per day		MOC		X
7.1.8	PTD shall develop ground systems to control and monitor the PTD Spacecraft in accordance with the PTD SC - GDS ICD.		MOC		X
7.1.9	PTD shall conform to CCSDS Blue Book standards for communications between MOC and the Spacecraft.		MOC					CCSDS.org has latest standards. If the vendor supplies the GDS, then the CCSDS interface would be between the MOC and VGDS.
7.1.10	The PTD MOC and GDS shall be designed to have an operational lifetime to achieve full mission success.		MOC			X		Reason:

The operational lifetime of the MOC cannot simply be bounded by the operational lifetime of S/C. The MOC must be able to operate in all phases of the mission from Pre-Launch through Post-Mission data delivery, i.e., whatever it takes to assure full mission success.

Assumptions:

* Budget allocates funds for keeping MOC fully operational (facilities, staffing) during all phases of the mission.

7.1.11	The MOC shall be capable of determining the Spacecraft orbit using GPS.	MOC		X
7.1.12	The MOC shall generate and deliver any necessary orbit data needed for scheduling and antenna pointing by NEN.	MOC	X
7.1.13	The MOC shall use GPS data to determine the thruster force for thrusting payloads to within 10% (TBR) within a 24 hour (TBR) measurement period.	MOC/PI		X
7.1.14	The MOC shall be capable of accommodating any LEO launch manifest assigned to PTD.	MOC/Vendor		X		40deg Lat or above inclination to be compatible with NEN, lower would require USN which is a cost and qualification increase.
7.1.15	The Vendor shall provide a Spacecraft Operator's Handbook providing information on the configuration and operation of the spacecraft.	Vendor			X
7.1.16	The Vendor shall provide detailed rules, limits and constraints for operation of the spacecraft	Vendor			X	Used by MOC to develop Flight Rules for operation of the spacecraft.
7.1.17	The Vendor shall provide a detailed summary of the fault management capabilities of the Spacecraft, automated fault responses, fault monitor configuration, and responses.	Vendor			X

7.2	System Requirements
7.2.1	The PTD MOC Ground Element shall be capable of radiating Spacecraft commands on a specified S-band frequency.	MOC	X	Spacecraft, MOC must use agreed upon frequency and receive certification to use.
7.2.2	The PTD MOC Ground Element shall be capable of receiving telemetry radiated by the SC on a specified S-band frequency.	MOC	X	Spacecraft, MOC must use agreed upon frequency and receive certification to use.

7.3	Measurement and Data Product Requirements
7.3.1	The PTD MOC shall operate the SC and GDS to characterize the Payload in accordance with full mission success criteria.	MOC/PI	X
7.3.2	The PTD MOC shall operate the Spacecraft to acquire Payload and sensor data necessary to characterize propulsion.	MOC	X

7.4	Data Processing and Policy Requirements
7.4.1	Processing of MOC Data Products
7.4.1.1	The MOC shall provide the PI access to payload and spacecraft data transmitted by the Spacecraft and spacecraft trajectory data.	MOC/PI	X
7.4.1.2	The MOC shall provide Payload and PTD telemetry to the PPS PI within 24 hours (TBR).	MOC	X
7.4.1.3	The PTD MOC will incorporate Payload PI activity requests into daily command pass activities	MOC/PI	X

&"Arial,Bold"&16&A

I - Inspection D - Demonstration,

SRR Version	T -Test
A - Analysis	30 June 2006

I - Inspection

D - Demonstration,	T -Test
A - Analysis	&P

I - Inspection

D - Demonstration,	T -Test
A - Analysis	&P

7. Mission Ops (Opt Vendor GDS)

	This requirements tab is only applicable to Vendors that will be proposing to use a GDS solution other than the default NASA-provided NEN S-Band and supersedes the "Mission Ops (NASA GDS)" tab. This is an option available to allow for solutions where the vendor has access to their own facilities and/or wishes to use something other than a NEN-Compliant S-Band solution for RF. This Tab should be ignored for Vendors going with the NASA GDS default.
RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
7	Mission Operation Requirements
7.1	General Requirements
7.1.1	The Vendor shall develop a Ground Data System (GDS) compatible with existing NASA Ames Multi-Mission Operations Center (MMOC) infrastructure.		Vendor/MOC				X	Vendor GDS Solution must be able to tie into existing NASA ARC MMOC infrastructure via IONET, NISN, or secure Internet VPN and SFTP.
7.1.2	The PTD MOC shall staff at least one command pass per week day		MOC			X		NASA will staff operations for one command pass per day. If vendor GDS requires support staffing for these periods, vendor support is implied.
7.1.3	The Vendor shall provide personnel on-site for Operational Readiness Testing (ORTs) and training activities for 2 weeks.		Vendor		X			Travel to NASA Ames and support MOC operations and training on-console in preparation for flight operations.
7.1.4	The Vendor shall provide on-site MOC support for 1-week of on-orbit checkout of the spacecraft.		Vendor		X			Travel to NASA Ames and support MOC operations on-console
7.1.5	The Vendor shall provide on-call MOC support for 1-month of on-orbit operation of the spacecraft.		Vendor		X			Support questions or anomaly resolution on operation of the spacecraft
7.1.6	The Vendor GDS shall support the necessary quantity of daily data downlink passes to meet spacecraft downlink throughput.		MOC/Vendor		X			Expected to be lights-out passes, but if vendor staffing is required, those costs should be included
7.1.7	The PTD MOC and vendor GDS shall be able to support scheduling activities for the number of communication contact opportunities available daily for the duration of flight.		MOC/Vendor	X				NASA will perform pass scheduling requests periodically according to the needs of the Vendor GDS, requirements of which must be stated by the Vendor.
7.1.8	The Vendor shall document the SC to GDS ICD defining space to/from ground data interfaces.		Vendor	X			X	Vendor responsible for documenting data interfaces between Spacecraft and Ground
7.1.9	The Vendor shall document the SC to GDS RF ICD defining space to/from ground RF interfaces.		Vendor	X			X	Vendor responsible for documenting RF interfaces between Spacecraft and Ground
7.1.10	The Vendor shall document the GDS to MOC ICD defining GDS to/from MOC data interfaces.		Vendor/MOC	X			X	The data interfaces will be CCSDS compliant.
7.1.11	PTD shall develop ground systems to control and monitor the PTD Spacecraft in accordance with the PTD SC to GDS ICD and GDS to MOC ICD.		MOC, ARC		X			The vendor PTD SC to GDS ICD and GDS to MOC ICD.
7.1.12	PTD shall conform to CCSDS Blue Book standards for communications between MOC and the Vendor GDS.		Vendor/MOC	X				CCSDS.org has latest standards. Communication between the Vendor GDS and NASA MOC must be CCSDS format. The Vendor may use proprietary interfaces if desired, but they will be responsible for repackaging data into CCSDS format for transfer to MOC.
7.1.13	The PTD MOC and Vendor GDS shall be designed to have an operational lifetime to support all phases of the mission and Optional flights.		MOC/Vendor			X		Reason:

The operational lifetime of the MOC and Vendor cannot simply be bounded by the operational lifetime of S/C. The MOC must be able to operate in all phases of the mission from Pre-Launch through Post-Mission data delivery. Budget and staffing allocations must cover all flights and options.

7.1.14	The MOC shall generate and deliver any necessary orbit data needed for scheduling and antenna pointing by Vendor GDS solution.	MOC	X				Vendor must specify antenna tracking data formats, antenna locations, horizon map and obstruction constraints (if any), elevation transmit restrictions, etc. So NASA can us this information in scheduling antenna(s).
7.1.15	The MOC shall use GPS data to determine the thruster force for thrusting payloads to within 10% (TBR) within a 24 hour (TBR) measurement period.	MOC/PI			X
7.1.16	The Vendor GDS shall be capable of accommodating any LEO launch manifest assigned to PTD with an orbital inclination 40deg or higher.	Vendor/MOC			X
7.1.17	The Vendor GDS shall support near real-time spacecraft telemetry to the MOC for active command passes.	Vendor/MOC					NASA MOC needs 'live' telemetry from the spacecraft before commanding it and to verify receipt and processing of commands
7.1.18	The Vendor GDS shall support near real-time spacecraft Commanding from the MOC for active command passes.	Vendor/MOC		X			NASA MOC needs near real-time transfer of commands sent from the ground to the spacecraft.
7.1.19	The Vendor GDS solution shall ensure transfer of spacecraft data to the MOC within 1 hour of receipt on the ground for non-command passes.	Vendor	X				For "lights-out" passes where the MOC is not actively monitoring, the spacecraft data can be processed and packaged into CCSDS parameterized files and SFTP transferred as long as it is within 1 hour.
7.1.15	The Vendor shall provide a Spacecraft Operator's Handbook providing information on the configuration and operation of the spacecraft.	Vendor				X
7.1.16	The Vendor shall provide detailed rules, limits and constraints for operation of the spacecraft	Vendor				X	Used by MOC to develop Flight Rules for operation of the spacecraft.
7.1.17	The Vendor shall provide a detailed summary of the fault management capabilities of the Spacecraft, automated fault responses, fault monitor configuration, and responses.	Vendor				X	Details how the Spacecraft will respond to fault events.

7.2	System Requirements
7.2.1	The Vendor shall be responsible for documentation and Spectrum access approvals necessary for Ground and Spacecraft RF transmitters.	Vendor	X		NASA will provide some support and access to appropriate organizations for this approval process.
7.2.2	The Vendor shall be responsible for RF compatibility validation between the SC and Vendor.	Vendor	X		The Vendor will need to perform live RF compatibility verification and validation tests to ensure RF links and configurations work in all communication modes/rates.
7.2.3	The Vendor shall provide a GDS simulator to the MOC to allow for interface testing and verification of command, telemetry, and scheduling products..	Vendor	X		The Vendor will need to provide a simulation of the interfaces the MOC will be working with so the MOC can test and verify interface compatibility.
7.24	The Vendor GDS solution shall comply with Federal Information Security Management Act (FISMA) Implementation requirements for a FIPS 199 Moderate level.			X	NASA Mission Operations Facilities are certified to FISMA Moderate levels, in order for a Vendor GDS to be tied in, it will also have to be certified to this level.

http://csrc.nist.gov/groups/SMA/fisma/

7.3	Measurement and Data Product Requirements
7.3.1	The PTD MOC shall operate the SC and GDS to characterize the Payload in accordance with full mission success criteria.	MOC	X	Payload characterization activities will vary with payload.
7.3.2	The PTD MOC shall operate the Spacecraft to acquire Payload and sensor data necessary to characterize the Payload.	MOC	X	Payload characterization activities will vary with payload, but require that necessary data is provided.

7.4	Data Processing and Policy Requirements
7.4.1	Processing of MOC Data Products
7.4.1.1	The MOC shall provide the PI access to payload and spacecraft data transmitted by the Spacecraft and spacecraft trajectory data.	MOC, ARC		X	Spacecraft telemetry and assessments will be forwarded to the PI for use in Payload performance analysis and operation.
7.4.1.2	The MOC shall provide Payload and PTD telemetry to the PPS PI within 24 hours (TBR).	MOC		X	This will likely be much faster, but provides a worst case for non-nominal situations.
7.4.1.3	The PTD MOC will incorporate Payload PI activity requests into daily command pass activities	MOC, ARC		X	Requests and command scripts from the PI for operation of the Payload will be incorporated into the daily command products to upload to the spacecraft
7.4.1.4	The MOC shall be capable of determining the Spacecraft orbit using GPS.	MOC	X		MOC will process received GPS position data and produce necessary ephemeris products.

&"Arial,Bold"&16&A

I - Inspection

D - Demonstration,	T -Test
A - Analysis	&P

8. Launch System

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
8	Launch System Requirements
8.1	Pre-Launch Phase
8.1.1	The PTD project shall support any necessary documentation and analysis to get launch approval for potential safety hazards.		Project-Wide				X	e.g., hazardous propulsion chemicals, pressure vessels, etc. Likely required by primary, launch provider, ISS, etc.

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

10. Systems I&T

RQMT	REQUIREMENT	TRACEABILITY	ALLOCATION	Verification				Rationale/Comment
ID				T	D	A	I
10	Systems Integration and Test (I&T) Requirements
10.1	Systems I&T Data and Documentation
10.1.1	The Vendor shall provide the MOC electronic versions of the command and telemetry database used by Vendor for integration and test of the avionics and the spacecraft.	Vendor					X	Reduce cost and risk for MOC.
10.1.2	The Vendor shall provide the MOC electronic versions of the command sequences and sequence language documentation used for integration and test of the spacecraft and the associated telemetry it generates.	Vendor					X	Reduce cost and risk for MOC.
10.1.3	The Vendor shall provide the MOC electronic versions of the input, output, display pages, and configuration files developed by the Vendor and used for the avionics integration and test software system.	Vendor					X	Reduce cost and risk for MOC.
10.1.4	The Vendor shall provide the MOC any spacecraft dynamics models.	Vendor/MOC/ Payload					X	Dynamics models coordinated between the Payload and Spacecraft Vendors must be made available to the MOC

10.2	Launch System I&T
10.2.1	The Vendor shall provide any required support to integrate and test launcher/dispenser with the manifested Launch System.	Vendor	X	X
10.2.2	The Vendor shall provide any necessary GSE support of LV integration.	Vendor			X	Vendor must provide any SC ground support equipment that might be required for LV integration
10.2.3	The Vendor shall deliver a fully qualified spacecraft/payload system to the launch dispenser integration site in a shipping case monitored for shock.	Vendor		X	X
10.2.4	PTD shall be delivered VC+UV (visibly clean+ultra-violet).	Vendor			X	Contamination requirement. This could change for option flights depending on Payload needs.

10.3	Payload Integration
10.3.1	The Vendor shall integrate the payload with the spacecraft system per payload handling and checkout procedures.	Vendor/Payload			X	Payload developer ships to SC vendor, flies to vendor and supports integration. Also provides handling and checkout procedures.
10.3.2	The Vendor shall support a payload fit check (on-site) with the spacecraft system.	Vendor/Payload	X
10.3.3	The Vendor shall integrate provided payload scripts into the flight software segment.	Vendor/Payload			X
10.4	System Integration and Test
10.4.1	The Vendor shall perform a comprehensive performance test before and after environmental testing.	Vendor	X
10.4.2	The Vendor shall support Operational Readiness Tests (ORT) and mission simulations.	MOC/Vendor	X			Flight-like simulations and training for flight operations done in the MOC
10.4.3	The Vendor shall provide MOC a spacecraft simulator for MOC testing and command validation during I&T and the flight phase of the mission.	MOC/Vendor			X
10.4.4	The Vendor shall perform an integrated end-to-end test of the spacecraft and MOC with the NEN compatibility van for NEN emulation to validate commanding and telemetry.	MOC/Vendor	X	X		Verifies ground networking and SC RF interfaces between MOC, NEN and SC
10.4.5	PTD shall be space qualified per GEVS (GSFC-STD-7000A) levels.	Vendor	X
10.4.6	The Vendor shall provide any necessary GSE support for environmental testing.	Vendor			X
10.4.7	The Vendor shall correlate environmental testing thermal results with thermal models.	Vendor		X
10.4.8	The Vendor shall provide support for flight controller collocation at spacecraft vendor facility for participation in FSW and spacecraft level testing	Vendor			X
	The Vendor shall provide I&T test scripts and procedures to the MOC.	Vendor				Operations uses these to develop flight operations scripts and procedures.

&"Arial,Bold"&18&A

SRR Version Page &P 30 June 2006

11. Globalstar (Opt Tech Demo)

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated Nov 14, 2017.