Fail-Safe vs Fail-Operational

Some L1 functions must fail into a safe state; others must keep operating through a fault. Kronos chooses per function based on which failure is worse.

Two failure philosophies

When a component fails, a system can be designed to fail-safe (go to a defined safe state) or fail-operational (keep working despite the fault). Neither is universally right. Kronos assigns each L1 function the philosophy whose failure mode is less harmful, given what the function protects and what a safe state costs.

Fail-safe functions

• Magnet quench dump: loss of power or signal fires the dump (de-energize-to-trip).
• Vacuum interlocks: default to the state that protects the vessel.
• Actuator drivers: loss of valid command holds or reverts to a safe output.

For these, the safe state is well-defined and reaching it is protective, so failure should drive toward it. The hardware failsafe is the archetype: it is biased so that any failure of its own path still results in protection, not exposure.

Fail-operational functions

• Vertical stability: cannot simply 'go safe' mid-discharge — must keep controlling.
• DEC train: rides through a single-stage fault to keep converting.
• State-vector ingress: imputes a dropped channel to keep the loop running.

Here an abrupt safe-state jump would itself cause the harm — dropping vertical control ends in a disruption. So these functions carry redundancy and graceful degradation to keep operating through faults, escalating to a controlled safe shutdown only if degradation runs out. This is why vertical control is redundant and DEC ride-through exists.

Choosing correctly

The choice follows the safety-integrity analysis: if the safe state is quickly reachable and protective, fail-safe; if reaching it abruptly is itself dangerous, fail-operational with a controlled path to safety. Most machines mix both, and the boundaries between them are exactly where careful design pays off.