Spacecraft: learning to think in systems

11. Build an interface matrix

Use five subsystems: power, thermal, avionics, propulsion and communications. At every row-column intersection write what crosses the interface: watts, heat, data, mechanical torque, fluid, timing or command. The matrix exposes hidden dependencies. Communications consumes power, rejects heat, constrains attitude and exchanges data with avionics.

12. First radiator estimate with Stefan-Boltzmann

An ideal radiator follows P = εσAT⁴. P is watts, ε emissivity, σ ≈ 5.670×10⁻⁸ W/m²/K⁴, A area in m² and T kelvins. Real geometry adds solar and planetary fluxes, but the equation shows the strong fourth-power temperature effect.

An interface matrix exposes hidden dependence

For every subsystem pair, the interface matrix records what crosses the boundary: power, data, heat, fluid, mechanical load, radio-frequency energy or command authority. Each interface has a normal envelope and failure cases. A computer may receive correct voltage yet lose a coherent time reference; a healthy radiator can become ineffective if coolant flow no longer carries heat to it. The matrix also assigns ownership of each requirement and a verification method. As the design evolves, this prevents a local modification from silently consuming another subsystem’s margin. Interface discipline is therefore one of the most practical tools for preventing common-cause failures.

13. Data rate, latency and criticality are different

A camera can produce high data volume without millisecond criticality. An IMU produces less data with strict timing. Avionics networks need priority, saturation handling and failure behaviour; redundant buses do not help if one software fault floods both.

14. Configuration means knowing exactly what flies

Long-duration spacecraft may receive updates. Configuration ties hardware, firmware, software, parameters, calibration tables and procedures together. A safe update process includes verification and rollback.

Data rate, latency and criticality must be separated

A high data rate does not guarantee useful control. Telemetry can arrive with delay, be incomplete or contain low-priority detail while a small critical state vector is missing. Communications design therefore classifies data by operational value. A fault message may need only a few bytes but must include time and configuration context; a science image can be megabytes and tolerate delay. Buffers are sized in bits or bytes from generation rate and outage duration. For example, 2 Mbit/s generated during a 30 min communications gap requires 2×10⁶ × 1,800 = 3.6×10⁹ bits, about 450 MB before protocol overhead and margin. Storage and link scheduling are therefore part of spacecraft architecture.

15. FDIR: detect, isolate, recover

Detection identifies inconsistency, isolation localises the likely fault, and recovery reconfigures the vehicle around it. Response time depends on the hazard: some loops need milliseconds, other problems allow minutes.

16. Verification matrix: requirement → evidence

Every requirement needs a verification method—analysis, inspection, test or demonstration—and explicit success criteria. Validation asks a different question: even if requirements are met, does the system satisfy the real mission need?

FDIR recovery has to be demonstrated

FDIR means Fault Detection, Isolation and Recovery. Detection recognises that the observed state is inconsistent with expectations; isolation identifies the responsible function or chain; recovery places the spacecraft in a safe or useful condition. The three steps need not reach perfect certainty at the same instant. A fault can be detected quickly and isolated later if the interim mode protects critical resources. Tests should inject realistic faults—stuck sensors, inconsistent data, bus loss, slow actuators—and verify not only that an alarm appears but that the final vehicle state is controlled. An FDIR design that launches an opaque cascade of automatic actions can be more dangerous than the initial fault.

17. Mini-project — review architecture under failure

1. Draw power, thermal, avionics, communications and propulsion services.
2. Add interfaces.
3. Remove the primary power bus.
4. List functions required for 30 minutes.
5. Calculate emergency energy.
6. Check thermal consequences.
7. Define minimum telemetry.
8. Describe return to service.

18. Next level: system models

Model-Based Systems Engineering tools can organise requirements, functions and interfaces when complexity grows. They do not replace reasoning. A sophisticated model with one wrong unit or missing dependency remains wrong, so Space Academy builds traceable hand calculations before tool complexity.

Mini-project: close a failure across subsystem boundaries

Choose one failure such as loss of a main power converter. Trace the immediate electrical effect, the loads that disappear, the thermal consequence of reduced dissipation, the telemetry still available and the action that attitude control or crew procedures must take. Then identify the independent path needed for recovery and the configuration evidence required before reconnecting loads. Quantify at least one resource, such as battery energy during the degraded interval. The exercise is successful when the recovery path crosses several subsystem boundaries without relying on the failed resource. This is the difference between drawing redundant boxes and demonstrating fault containment in a real architecture.

19. Mass, power and heat margins interact

Adding a processor may look like a small avionics change, but it draws electrical power, produces heat, needs data connections and may require shielding or spare capacity. The correct change request therefore updates several budgets. Systems engineering exists partly to prevent local improvements from breaking global margins.

Thermal rejection and configuration are first-class architecture concerns

Electrical power, internal dissipation and radiator capability must be closed together. A radiator is often estimated first with Stefan–Boltzmann radiation, P = εσA(T⁴-Tenv⁴), where P is radiated power in watts, ε emissivity without unit, σ the Stefan–Boltzmann constant, A area in m² and T absolute temperature in kelvins. The equation is only a first estimate because view factors, coatings, conductive paths and changing solar geometry matter. Configuration control is equally physical: a radiator model, heater setting or flight-software limit is valid only for the hardware and software version it describes. Long-duration spacecraft therefore need traceable configuration records so that an operational limit is never applied to the wrong vehicle state.

20. Fault containment is an architectural property

A fault should ideally remain inside a bounded region. Electrical protection prevents one short from collapsing the whole bus; network segmentation prevents one node from saturating all traffic; software partitioning reduces propagation between functions. Containment often matters more than simply adding duplicate hardware.

21. Crew interaction is another interface

Human operators need displays, procedures and controls that match the automation state. If the spacecraft changes mode autonomously, crew must know why, what authority remains, and which action is safe. A technically correct FDIR response can still create risk if humans misunderstand the configuration.

22. Architecture review exercise

Choose one requirement such as “survive eight hours without primary generation.” Derive the energy reserve, loads to shed, thermal consequences, communication minimum and recovery test. This converts a vague resilience statement into a cross-subsystem evidence chain.

Architecture review: ask what is not represented in the diagram

A block diagram is a model and therefore omits things. Reviewers should ask whether it shows timing, shared software, common cooling, ground tools, crew actions, calibration, configuration and maintenance access. A line labelled “data” may hide multiple protocols and clocks; a box labelled “power” may hide a single common converter. The most important review questions often concern those omitted dependencies. For each life- or mission-critical function, identify the first failure that removes it, the second failure that becomes dangerous after degradation, and the observation that proves recovery. This turns an architecture review from a presentation of boxes into a search for hidden coupling and unclosed evidence.