Spacecraft systems engineering

A spacecraft is a set of subsystems that are individually tractable and collectively not. Systems engineering is the discipline that keeps them consistent with each other and with the mission, and its central product is not hardware but a set of budgets that everyone agrees to.

Requirements

Requirements flow down from the science or service objective through a traceable chain. Each level is derived from the one above and verified against it, so that no requirement exists without a parent and no parent is left unsatisfied.

A requirement that cannot be verified is not a requirement, it is a wish. Every one carries a verification method, and the four are not interchangeable.

Test

Demonstrate by measurement on the actual article under representative conditions. The strongest and most expensive method.

Analysis

Demonstrate by calculation or simulation. Necessary where the environment cannot be reproduced on the ground, such as zero-g structural behaviour or multi-year radiation dose.

Inspection

Demonstrate by examination. Appropriate for physical properties such as mass, dimensions and markings.

Demonstration

Show the function operates. Appropriate for operational sequences where a quantitative measurement is not the point.

The pressure in every programme is to downgrade verification from test to analysis, because test is what costs money and schedule. That is sometimes correct and sometimes the direct cause of a failure. See Fault tolerance and reliability.

Budgets

Budgets are how a systems engineer holds a distributed design together. Each one is a scarce shared resource, allocated to subsystems, tracked against actuals, and defended.

The growth column is the important one. Mass and power always grow, and a programme that has not reserved for it will pay by deleting capability late, when deletion is most expensive. Margin policy is therefore set at the start and reduced on a defined schedule as the design matures.

A common practice allocates margin by phase: perhaps 30% at concept review, 20% at preliminary design, 10% at critical design and 5% at delivery. Margin is held by the project, not by the subsystems, precisely so that it cannot be quietly consumed by whoever asks first.

Mass and power are coupled in a way worth stating explicitly. More power means larger arrays and larger batteries, which means more mass, which means more structure, which means more mass. A design that is not converging on these two budgets is usually not converging at all.

Technology readiness levels

TRL is a nine-point scale describing how far a technology has been demonstrated, from basic principles at TRL 1 to flight-proven at TRL 9.

Its honest use is as a risk indicator, not a score. The single most useful fact about the scale is where programmes actually fail: the transition from TRL 4, a component validated in the laboratory, to TRL 6, a system demonstrated in a relevant environment. This gap is wide enough and expensive enough to have a name, and a project baselining a TRL 4 technology on the assumption it will be at TRL 6 when needed is taking a schedule risk that is rarely stated in those terms.

The corresponding discipline is that anything below TRL 6 at preliminary design needs either a funded maturation plan with milestones or a defined fallback to a flight-proven alternative.

Review gates

Gates exist to force a decision at a point where changing course is still affordable. The cost of fixing a defect rises by roughly an order of magnitude at each stage, so a requirements error caught at SRR costs almost nothing and the same error caught during integration costs a great deal.

The failure mode of review gates is passing them on schedule rather than on readiness. A PDR held with open trades and unquantified margin has not reduced risk, it has recorded a date.

Assembly, integration and test

The structure of that flow carries the essential idea. A full performance test is run before and after the environmental campaign, and the comparison is the actual deliverable. Environmental testing does not prove the spacecraft works; it proves the spacecraft still works after being shaken, shocked and thermally cycled, which is a different and stronger claim.

Test levels distinguish two purposes.

Protoflight is the norm for single-article science missions and is a real trade: it saves the cost of a dedicated qualification unit while putting the flight article through loads above what it will experience.

Where systems engineering actually earns its cost

The discipline is often described as paperwork, and badly practised it is. Its real function is to own the interactions that no subsystem owns.

Thermal wants a radiator where communications wants an antenna. Power wants a sun-pointing array while the payload wants a nadir-pointing bus, which determines whether the array needs a drive mechanism, which adds a disturbance torque that guidance, navigation and control has to reject. Propulsion wants thrusters at the extremities for torque authority, where their plumes will impinge on the arrays that power the whole vehicle.

None of those conflicts belongs to a single subsystem, and each is discovered by someone whose job is to look across all of them. That is the work.

References

• NASA/SP-2016-6105 Rev 2, NASA Systems Engineering Handbook.
• Wertz, J. R., Everett, D. F. and Puschell, J. J. (eds.) Space Mission Engineering: The New SMAD, Microcosm Press, 2011.
• ECSS-E-ST-10C, Space engineering: System engineering general requirements, European Cooperation for Space Standardization.
• NASA-STD-7002, Payload Test Requirements, and GSFC-STD-7000, General Environmental Verification Standard.
• Mankins, J. C. “Technology readiness assessments: A retrospective”, Acta Astronautica, 65:1216, 2009.