Power, avionics & flight software
A spacecraft does not have an ideal wall socket. Generation varies, batteries age, converters dissipate heat and some loads cannot operate simultaneously. Avionics must measure that state, execute flight software, command actuators and remain controllable when a sensor or computer fails. This module therefore connects electrical power, electronics and critical software.
Mastery objectives
- explain concepts with units and assumptions
- redo a simple calculation by hand before using a tool
- identify at least one failure mode or model limitation
- connect the discipline to a complete Mars architecture
1. Power budget and mission profile
The budget separates average power, peak power and energy over time. A 2 kW load for ten minutes does not consume the same energy as a 500 W load for ten hours. For each mission phase, engineers add loads, losses and margin, then compare them with available generation and storage.
Engineering habit. For “power budget and mission profile”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
2. Generation: solar, alternatives and pointing
Solar generation depends on incident flux, area, efficiency, temperature and orientation. On Mars, dust and seasons further change availability. Other architectures may use nuclear or hybrid sources. The systems question remains: what power can be guaranteed in the worst credible condition, not merely at local noon in the nominal case?
Engineering habit. For “generation: solar, alternatives and pointing”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
3. Batteries: energy, power, depth of discharge and ageing
A battery has energy capacity but also current, temperature and state-of-charge limits. Deep cycling and adverse temperatures accelerate ageing. Sizing must preserve margin after years of use, not only on day one. The battery management system protects cells but can itself become a critical function.
Engineering habit. For “batteries: energy, power, depth of discharge and ageing”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
4. Conversion and distribution
Solar arrays and batteries do not necessarily provide the voltage every load needs. Converters, buses, protection and switches distribute energy. The architecture must isolate a fault without blacking out the entire vehicle. Short-circuit currents, startup surges and conversion losses belong in the budget, as do return paths and electromagnetic compatibility.
Engineering habit. For “conversion and distribution”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
5. Sensors, data acquisition and onboard computing
Avionics converts the physical world into data: voltages, temperatures, accelerations, images and pressure. Computers timestamp, filter and interpret those measurements. A number is useful only if its range, precision, sample rate and status are known. A sensor frozen at a plausible value can be more dangerous than one that is obviously dead.
Engineering habit. For “sensors, data acquisition and onboard computing”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
6. Data buses and interfaces
Subsystems exchange commands and telemetry through buses and networks. Interfaces specify formats, units, cadence, latency, error behaviour and authority. Two pieces of equipment can work perfectly alone and fail after integration if one expects degrees while the other sends radians, or if a command is interpreted in the wrong state.
Engineering habit. For “data buses and interfaces”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
7. Flight software: states, tasks and determinism
Flight software executes periodic tasks, manages mission states and applies safety rules. In a critical system, engineers must explain which condition triggers a transition and which component has authority. Determinism means a critical function meets timing and ordering constraints; being ‘fast on average’ is not enough.
Engineering habit. For “flight software: states, tasks and determinism”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
8. FDIR and safe mode
Fault Detection, Isolation and Recovery covers detecting, locating and responding to faults. Automation can save a vehicle but can also amplify a bad measurement. Safe mode aims for a sustainable state where power, thermal control and communications are stabilized while diagnosis continues. It must be tested as a real configuration, not merely described in a document.
Engineering habit. For “fdir and safe mode”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
9. Critical software: requirements, testing and configuration
Software evolves until launch and often beyond. Code, parameters, interfaces and test evidence must therefore be version controlled. Every critical requirement must be verifiable. Unit tests alone are insufficient: integration, simulation, hardware-in-the-loop, fault scenarios and regression testing are needed to understand complete-system behaviour.
Engineering habit. For “critical software: requirements, testing and configuration”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
Worked example step by step
The work method is always the same: state what every symbol represents, convert all units into a coherent system, perform the operation, then translate the result into a sentence. Finally perform an order-of-magnitude check. If the answer changes by a factor of one thousand because millimetres were treated as metres, the conversion must be visible in the calculation.
Progressive exercise
- Choose a simple case and list every input with units.
- Compute the nominal result without margin.
- Vary the most uncertain parameter by ±20% and compare.
- Inject one credible failure and explain which indicator detects it.
- Decide whether the system continues, degrades or stops.
Reasoned solution
A good solution is not only the final number. It shows conversions, why the equation applies, sensitivity and the resulting decision. If different plausible assumptions lead to the same operational decision, the design is relatively robust to that uncertainty. If a small variation reverses the decision, the parameter becomes a priority for measurement or margin.
Validation mini-project
Build a two-to-four-page engineering note applying this course to one Mars subsystem. Include need, assumptions, functional sketch, hand calculation, second calculation or simulation, uncertainties, injected failure, decision criteria and three primary references. The goal is a chain of evidence that another reader can reproduce.
Common errors to detect
- mixing units or frames without explicit conversion;
- presenting calculated values as measured data;
- ignoring a model’s validity range;
- confusing numerical precision with physical accuracy;
- sizing only the nominal case with no margin or degraded mode.