systems engineering

Systems engineering is the discipline of going from a need to a system that demonstrably meets it, through written requirements, an architecture that divides the work, verification at every level and safety arguments a third party can review; it is used wherever a system is too large for one person to hold in their head, or where a failure can hurt someone and the builder must prove it will not. A drone that inspects a facade is a sensor, an estimator, a controller, a radio, a battery and a team for each. Systems engineering is what turns *the drone must be accurate* into numbers each team can design to, and what shows at the end, with evidence, that the assembled drone meets them.

Systems engineering is the discipline of going from a need to a system that demonstrably meets it, through written requirements, an architecture that divides the work, verification at every level and safety arguments a third party can review; it is used wherever a system is too large for one person to hold in their head, or where a failure can hurt someone and the builder must prove it will not. A drone that inspects a facade is a sensor, an estimator, a controller, a radio, a battery and a team for each. Systems engineering is what turns the drone must be accurate into numbers each team can design to, and what shows at the end, with evidence, that the assembled drone meets them.

It is the sibling of systems theory: theory studies how systems behave, engineering how to build one that behaves as promised. Its unit of work is the requirement, a statement of what, how much, under which conditions and how it will be checked, and its skeleton is the V-model: requirements, architecture and design going down the left side, each verified on the way up the right against its mirror, held together by traceability from every requirement to the code that implements it and the test that verifies it.

Everything in a closed loop is a cost against one requirement. The error budget is how a system requirement (position within 0.5 m, 95 % of the time) is split into derived requirements for the sensor, the latency and the controller, and it is also what says which subsystem to improve first.

Safety comes before requirements. Hazard analysis identifies what can go wrong and how badly, and functional safety grades the evidence demanded by the risk, through standards such as IEC 61508, ISO 26262 and DO-178C; a safety instrumented system and fail-safe design are the architectural answers, and a single point of failure is what architecture review hunts.

Verification finds each error where it is cheapest: in a model, in simulation, on the real processor, on a bench, in the field. The pyramid of X-in-the-loop testing, log replay and fault injection are its tools.

The systems it serves are cyber-physical systems, where a computation error becomes a wrong movement, and the platform that runs them is the embedded system, whose cycles, memory and certification bound what any requirement can ask.

Organizations shape the systems they build (Conway's law): where two teams do not talk, the interface between their subsystems is where the errors will live.

The full process costs time and paperwork that an internal prototype does not need; a requirements list and a test battery are enough there. It pays, and is often mandatory, when a failure can injure someone or when a product will be built in thousands and maintained for years (total cost of ownership).