Physical World Failure Mode
The failure classes that only exist once software controls or observes physical equipment, where the system cannot be restarted and the consequences are not confined to data.
Software architects reason about failures that are recoverable by retry or restart. Physical systems have a category that is not, and it changes the design.
Sensors lie before they die. A failed sensor returning nothing is easy; a drifting sensor returning plausible wrong values is the dangerous case, and it will be believed by every downstream control loop and dashboard. Plausibility bounds, rate-of-change checks and cross-sensor agreement are the countermeasures, and they must be explicit.
Actuators have state that survives your process. A valve left open when the controller crashed stays open. Safe-state-on-failure has to be a property of the equipment, and the software must assume it will be killed mid-operation.
The environment is hostile. Power interruption during a write, temperature outside the rated range, water, vibration, rodents, and human beings who unplug things.
Recovery requires a person. Mean time to repair includes travel, access permissions and possibly a maintenance window on production equipment, so it is measured in days rather than minutes — which means redundancy and graceful degradation have to carry far more weight than in a system where you can reprovision instantly.
The design consequence that follows from all of it: fail towards the physically safe state, not towards the state that preserves the software's model of the world.