| 4.4.11-4-1 Ensure subsystem design including units, assemblies, sub-assemblies and parts meets the mission performance requirements |
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 subsystem requirements in terms of the overall mission operability. The subsystem 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.4.11-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 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.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-3 Ensure subsystem technology readiness and risk burn-down plan have been assessed |
Phase A |
Phase B |
Phase C |
|
Ensure subsystem 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.4.11-4-4 Ensure subsystem hardware and software (as applicable) functions are described in the subsystem 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.4.11-4-5 Ensure subsystem 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.4.11-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.4.11-4-7 Ensure H/W technology insertion is addressed |
Phase B |
Phase C |
|
Ensure H/W computing technology insertion issues are addressed and mitigated before incorporation into any program development. Ensure risk mitigation plans are implemented if technology is still immature.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-8 Ensure FMS subsystem architecture has been adequately defined and reviewed |
Phase A |
Phase B |
|
Ensure that architecture is fault tolerant.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-9 Ensure that safe mode entry is initiated autonomously by the Fault Management System (FMS) only for specific fault conditions that have been identified, approved, and implemented before launch |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
Ensure that Requirements identified at SDR and final at PDR.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-10 Ensure safe mode is provided for all mission phases |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
NA
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-11 Ensure that safe mode sheds all non-essential space vehicle loads |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
NA
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-12 Ensure that safe mode adequately maintains spacecraft health |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
Ensure that safe mode maintains attitude and rates, ground communication, a positive power condition, and a thermally safe environment.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-13 Ensure that safe mode uses an independent processor and associated hardware and software different from the processor used in failed path mode |
Phase B |
Phase C |
|
Ensure that safe mode circuitry and S/W processing use independent paths for fault identification and control/isolation and that those in the path that has failed are isolated.
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-14 Ensure that redundant normal mode units are used if dedicated units are not available or practical (e.g. Reaction Wheel Assembly or Solar Array Wing Drive) |
Phase A |
Phase B |
Phase C |
|
NA
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-15 Ensure that safe mode is exited only via ground command |
Phase B |
Phase C |
Phase D1 |
|
NA
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-16 Ensure design reference mission results are adequate for FMS subsystem |
Phase B |
Phase C |
|
NA
|
NA
|
NA
|
Space Vehicle Systems Engineering Handbook, TOR-2006(8506)-4494
|
| 4.4.11-4-17 Ensure that the system can handle Double bit error (computers) |
Phase B |
Phase C |
Phase D1 |
|
Ensure that double bit errors are handled (requires a swap) as the computer cannot be trusted in the presence of double bit errors
|
NA
|
NA
|
TOR 2009(8591)-14, Effective Fault Management Guidelines
|
| 4.4.11-4-18 Ensure that fault detection is done for every path and unit |
Phase B |
Phase C |
Phase D1 |
|
Ensure that every unit and path has a positive check for data sanity
|
NA
|
NA
|
TOR 2009(8591)-14, Effective Fault Management Guidelines
|
| 4.4.11-4-19 Ensure that data sanity checks do not use stale data |
Phase B |
Phase C |
Phase D1 |
|
Ensure that data sanity checks use the latest data from the interface interrogation and that sequential complimenting patterns are used
|
NA
|
NA
|
TOR 2009(8591)-14, Effective Fault Management Guidelines
|
| 4.4.11-4-20 Ensure that the fault response for a given path considers ALL components of that path |
Phase B |
Phase C |
Phase D1 |
|
Ensure that fault responses swap all of the suspect path for a given fault. This includes ALL copper paths, interfaces, units.
|
NA
|
NA
|
TOR 2009(8591)-14, Effective Fault Management Guidelines
|
| 4.4.11-4-21 Ensure that any internally redundant designs have physical separation between prime and redundant functions |
Phase B |
Phase C |
Phase D1 |
|
NA
|
NA
|
NA
|
TOR 2008(8546)-7335, Separation and Isolation Guidelines for Printed Wiring Boards Intended for Space Use
|
| 4.4.11-4-22 PLACEHOLDER |
Phase B |
Phase C |
Phase D1 |
Phase D2 |
Phase D3 |
|
PLACEHOLDER
|
NA
|
NA
|
NA
|