Systems engineering, MBSE & V&V
As a system grows more complex, it becomes impossible to optimize it by improving each subsystem independently. A larger battery changes mass and thermal design; a more powerful antenna changes power and pointing; a new procedure changes software, training and operations. Systems engineering organizes those dependencies from stakeholder needs to evidence that the realized product actually satisfies the mission.
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. Need, objective and requirement are not the same thing
A need explains why a capability matters. An objective describes what the mission seeks to achieve. A requirement imposes a verifiable property on the system. ‘Survive on Mars’ is not a good requirement; ‘maintain habitat pressure within a defined range for a defined time after a single failure’ can become one. A clear requirement has a subject, action, condition and measurable criterion.
Engineering habit. For “need, objective and requirement are not the same thing”, 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. ConOps: describe how the system will actually be used
A Concept of Operations describes actors, phases, environments, information flows, states and nominal or degraded scenarios. It prevents teams from designing machinery without understanding the human work around it. An excellent technical requirement can be useless if the operational scenario is wrong. ConOps therefore connects mission, operations and architecture.
Engineering habit. For “conops: describe how the system will actually be used”, 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. Functional decomposition and architecture
Start from required functions, then decide which physical or software elements perform them. This prevents premature attachment to a favourite solution. The function ‘reject heat’ may be implemented through different combinations of radiators, loops and operating modes. Architecture then allocates functions, performance and interfaces to subsystems.
Engineering habit. For “functional decomposition and architecture”, 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. Interfaces: where good subsystems can become a bad system
An interface is more than a connector. It includes mechanical, electrical, data, thermal, software, procedural and responsibility boundaries. Units, tolerances, allowed states and fault behaviour must be defined. Integration problems often come from implicit assumptions made differently by two teams.
Engineering habit. For “interfaces: where good subsystems can become a bad system”, 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. Budgets and margins as decision tools
Mass, power, energy, data rate, volume, crew time and performance are tracked as budgets. Margin is not a decorative percentage: it absorbs uncertainty and maturation. When margin shrinks, the decision should be visible. Budgets create a common language between disciplines that might otherwise optimize different criteria.
Engineering habit. For “budgets and margins as decision tools”, 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. MBSE: use models to connect engineering products
Model-Based Systems Engineering is not about producing attractive diagrams. A useful model connects requirements, functions, components, interfaces and V&V evidence so that a change leaves a trace. SysML can formalize these relations. The model does not replace judgement; it primarily reduces hidden inconsistency between independent documents.
Engineering habit. For “mbse: use models to connect engineering products”, 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. Verification and validation ask different questions
Verification asks whether the product meets its requirements through analysis, inspection, demonstration or test. Validation asks whether the product is actually suitable for mission use and stakeholder expectations. A system can be perfectly verified against bad requirements and still be useless. Both loops must remain visible from the beginning.
Engineering habit. For “verification and validation ask different questions”, 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. Verification matrix and traceability
For every important requirement, identify a method, level, test configuration, owner and expected evidence. This prevents discovering late that a requirement cannot be proven. Traceability also answers the reverse question: if a test fails, which requirements, functions and decisions are affected?
Engineering habit. For “verification matrix and traceability”, 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. Configuration and change
Space systems evolve. Configuration management establishes what constitutes the reference at a given time: requirements, software, drawings, parameters and procedures. A modification must be assessed for cross-system effects. Without a baseline and change control, a local fix can reintroduce a failure elsewhere — exactly what anti-regression work seeks to prevent.
Engineering habit. For “configuration and change”, 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.