| 4.5.4-4-1 Ensure payload design including units, assemblies, sub-assemblies and parts meets the mission performance requirements |
Phase 0 |
Phase A |
Phase B |
Phase C |
|
Pre-Phase A, as applicable, ensure the design satisfies the requirements under the conditions specified by the Design Reference Mission. There should be a realistic worst-case scenario to show that the requirements can be met with margin. Phase A onward, the derived CONOPS should be in a particular document (Flight Requirements and Ops documents) or operations working group products. Some mission concepts may not be directly translated to payload requirements in terms of the overall mission operability. The payload must be validated against how the components will be used for that particular application.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B
|
| 4.5.4-4-2 Ensure trade studies were conducted and the design baseline satisfies mission requirements and the analysis of alternatives has identified the baseline as the best value |
Phase 0 |
Phase A |
Phase B |
Phase C |
|
Ensure that all trade studies are realizable in terms of technology used and conform to system requirement and physical constraints. Check that viable candidates received appropriate consideration. Disseminate and document/archive results of the trade studies.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.5.4-4-3 Ensure payload technology readiness and risk burn-down plan have been assessed |
Phase 0 |
Phase A |
Phase B |
Phase C |
|
Ensure payload system technologies, including manufacturing, supplier readiness and programmatic readiness, are mature enough to support the development timeline. Check that the risk mitigation plans are sufficient, funded and conclude at the right time.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.5.4-4-4 Ensure payload hardware and software (as applicable) functions are described in the payload specification |
Phase A |
Phase B |
Phase C |
|
Ensure that descriptive functions for subsystems and units (including software) are detailed enough for new personnel to understand how the unit or subsystem behaves both individually and within the system.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.5.4-4-5 Ensure payload hardware and software (as applicable) is identified as heritage, modified, or new |
Phase B |
Phase C |
|
Ensure heritage qualification adequacy is documented by analysis and test.
|
NA
|
NA
|
Objective Criteria for Heritage Hardware Reuse, TOR-2010(8591)-19; Reuse of Hardware and Software Products, TOR-2009(8546)-8604
|
| 4.5.4-4-6 Ensure all defined contract deliverables and relevant contractor data are complete and accurate to support design reviews |
Phase A |
Phase B |
Phase C |
|
Ensure all relevant data is readily available and delivered to support design reviews and design forums.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.5.4-4-7 Ensure functional, electrical, interface, and data flow block diagrams are baselined from system to unit level and are static |
Phase B |
Phase C |
|
The responsible POC for Communications Payload Systems Engineering coordinates with Program Systems Engineering to ensure that sub allocation of program requirements down to payload subsystem and unit level are appropriate and monitored throughout the program lifecycle. POC ensures that issues that arise through design, production and testing phases are flowed upwards against any impacted higher level requirements. Monitors Configuration Management to ensure that the most current and/or effective versions of designs are in use, utilizing program liens as necessary in the event of discrepancies. Requirements monitoring encompasses supporting documentation, including but not limited to functional block diagrams, detailed electrical connectivity, detailed data flow, interface compatibility, high power handling, and self-compatibility.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494. Standard/Handbook for Radio Frequency (RF) Breakdown Prevention in Spacecraft Components (TOR-2014)-02198; Standard/Handbook for Radio Frequency (RF) Breakdown Prevention in Spacecraft Components (TOR-2014)-02198
|
| 4.5.4-4-8 Ensure adequate margins for SW memory, bandwidth, and processing capabilities |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
Assess predicted worst case loading on hardware and software subsystems and appropriate amount of overhead (margin) necessary in the baseline design.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.5.4-4-9 Ensure telemetry content and sampling is adequate to diagnose state-of-health |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
Ensure sufficient telemetry points, content, and sampling resolution are designed into the monitoring subsystem to adequately assess the state of health of the PL and to allow troubleshooting of anomalies from the ground. Ensure that all self correcting (on-board automatic anomaly resolution SW) processes provide adequate telemetry fidelity of the anomaly as well as an option to shut the autonomy off, if it becomes necessary for ground controllers to take over manual commanding.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.5.4-4-10 Ensure that any potentially systemic design issues are considered for a Design Advisory |
Phase B |
Phase C |
Phase D1 |
Phase D2 |
Phase D3 |
|
Any design or architecture issue that has severe, systemic, or widespread consequences is a potential candidate for a Design Advisory. Design Advisories provide the community with timely and interim notification of an important design issue which may ultimately be captured in a specification or standard.
|
NA
|
NA
|
NA
|