Safe States and Fail-Silent Behaviour in Control Systems

The phrase “fail-safe” suggests a property of the equipment: when it breaks, it is safe. The engineering reality is narrower. A system does not fail safe in general; it fails to a specific state, and whether that state is safe depends on the process, the moment, and which hazard is being considered. A valve that closes on loss of power is safe for a tank that must not overflow and unsafe for a reactor that must not lose cooling. The design work is to pick a state, arrange the physics so that failures tend toward it, and then be honest about the hazards for which that state is not safe.

Why de-energisation became the default

Industrial safety instrumented systems use the convention that the safe state is the de-energised state, and the convention is visible in the terminology. A final element whose removal of power produces the trip is described as de-energise-to-trip; one whose application of power produces the trip is energise-to-trip. The first is the common case, and the reasoning is about failure modes rather than about safety in the abstract. Loss of power, a blown fuse, a severed cable, a failed output driver, and a disconnected terminal block all produce the same physical result, which is zero current. If the safe state corresponds to zero current, then a whole family of failures converges on safety without any detection, any diagnostics, or any software involvement. The failure is not detected, but it is not dangerous either, and the difference between the two is what the architecture is buying.

The same logic applies to the signal level on a discrete output. A circuit that requires a transistor to be actively driven to command a dangerous action means the dangerous action needs a live, functioning driver, while the safe action needs only the absence of drive. A pull-down resistor on the gate, a relay with a normally closed contact, and a watchdog-driven enable line that must be held high all convert “the processor stopped” into “the dangerous action is not commanded”.

The convention has a cost that is easy to overlook. De-energised equipment consumes no power when idle, so a plant that spends most of its life in the safe state is cheap to run, but a plant that spends most of its life in the operating state pays for the holding current continuously. A large solenoid bank holding valves open consumes power, generates heat, and adds a supply that must itself be monitored, because a supply failure now trips the plant. The choice between energise-to-trip and de-energise-to-trip is therefore partly an availability decision, and the standard allows either as long as the failure modes are analysed and the diagnostics cover the chosen direction.

When no single state is safe

Multi-hazard processes break the single-state assumption. A furnace has a hazard from over-temperature and a hazard from loss of flame with unburnt fuel present; the first needs the fuel valve closed, the second needs it closed too but only after a purge, and closing it while the burner is hot can create a different problem. A hydraulic press needs the ram retracted to be safe for the operator and needs the ram held to be safe for the part; retracting it drops the load.

The usual resolution is not a single global safe state but a set of states, one per hazard, with an arbitration that decides which applies. In a safety instrumented system the arbitration is part of the cause-and-effect specification: each trip cause names the final elements it acts on and the state it drives them to, and the specification records the conflicts explicitly. Where two causes demand opposite states of the same final element, the design either adds a second element, sequences the actions, or accepts one hazard as dominant and documents the argument. What is not acceptable is an arbitration implemented as a priority scheme in software with no written record, because the resulting behaviour is then a property of whichever condition arrived first.

The sequencing case deserves attention because it is where timing becomes part of the safe state. Closing a fuel valve is safe only after the combustion air has purged the chamber for a defined period; the state “valve closed, fan running” is safe, “valve closed, fan stopped” is not, and “valve open, fan stopped” is worst. A safe state is therefore a vector of actuator positions plus a required ordering and duration, and the output stage that implements it must be able to hold that sequence without depending on the processor that just failed. That is what a hardwired interlock or a final-element with a mechanical time delay provides, and it is why such elements appear in architectures that also contain a programmable controller.

Fail-silent, fail-stop, and fail-operational

A unit that stops producing outputs when it fails is fail-silent. A unit that stops producing outputs and signals that it has stopped is fail-stop. A unit that keeps producing correct outputs despite an internal failure is fail-operational. The three are increasingly expensive and decreasingly common, and the choice is driven by what the system must do when one unit is lost. The order matters: fail-silent is the minimum a channel can contribute to a redundant arrangement, because a channel whose failure is silent in the sense of absent can be outvoted, while a channel whose failure is silent in the sense of plausible cannot.

Fail-silent is the cheapest useful target, and it is what most safety architectures aim for at the level of a single channel. The requirement is not that the unit detect its own failure perfectly but that its failure not produce plausible-looking wrong output. A channel whose output can be wrong but valid-looking is worse than a silent one, because the voter or the downstream logic has no way to reject it. Achieving silence is largely a hardware property: an output stage that is enabled by a signal derived from the unit’s own health, a communication controller that stops transmitting when its internal check fails, and a supply monitor that clamps the output driver disabled on undervoltage. Each of these is a mechanism that converts an internal fault into an absent signal rather than a false one.

Fail-operational is required where stopping is itself hazardous: a flight control surface must keep moving, a steering actuator must keep steering, a braking system on a moving vehicle must retain some braking. This is where redundancy becomes mandatory rather than optional, because a single unit cannot both fail and continue, and the architecture must contain at least two units plus a means of deciding between them. The decision mechanism is the subject of Voting Redundancy and Average Probability of Failure on Demand.

The availability cost of fail-silent deserves naming. A fail-silent unit that trips the plant on any detected internal fault converts a hardware defect into a production stoppage. A plant that must run continuously will therefore be tempted to widen its detection thresholds until nothing trips, which is a slow erosion of the safety function. The disciplined answer is to separate the detection of a fault from the action taken: some faults warrant an immediate trip, others warrant a degraded mode with reduced capability and a maintenance alarm, and the classification belongs in the safety requirements rather than in the diagnostic code.

Output gating below the software

The processor is the least trustworthy element in the chain because it is the most complex, so the mechanisms that guarantee the safe state should not depend on it. The standard pattern places a gate between the processor’s output and the actuator, controlled by something simpler than the processor.

/* The processor's job is to keep a heartbeat alive; the gate hardware
   decides whether the output reaches the actuator. The code below shows
   the ordering: outputs are set before the gate is opened, and the gate
   is closed by the same path that handles any detected fault. */
static void enter_safe_state(void)
{
    /* Order matters: drive the actuator command to its safe value while
       the gate is still closed, so the transition is not seen downstream. */
    pwm_set_duty(PWM_CH_ACTUATOR, 0);
    gpio_write(GPIO_ACTUATOR_ENABLE, 0);

    /* Only then drop the gate. A fault detected after this point cannot
       leave a stale command applied. */
    gpio_write(GPIO_OUTPUT_GATE, 0);

    /* Latch the reason for the trip for the maintenance log. */
    fault_record(FAULT_SAFE_STATE_ENTERED);
}

The gate itself is typically a windowed watchdog’s output, a separate supply monitor’s enable, or a relay driven by a hardware comparator. Its defining property is that the processor cannot hold it open without continuing to satisfy a condition the processor does not control, which is exactly the independence argument made for the supervisor in Windowed Watchdogs and the Program-Flow Contract.

Testing a state that is only supposed to happen on failure

A safe state that has never been entered is a claim, not a mechanism. The transition path, the ordering of the output changes, the gate’s response time, and the behaviour of the plant during the transition all have to be exercised, and exercising them on a live process is usually impossible.

The usual approach is partial stroke testing: the final element is moved a small fraction of its travel while the process continues, which proves the actuator is not seized and the command path is intact without stopping production. The test is bounded by how much disturbance the process tolerates, so it proves the first few percent of the travel and nothing about the remainder. A full proof test requires the process to be offline, which sets the proof-test interval and therefore the PFD, as described in Voting Redundancy and Average Probability of Failure on Demand.

For the electronics, the equivalent is a diagnostic that drives the gate and observes the result, run at startup and periodically thereafter. The observation must be independent of the driver being tested, which in practice means the monitor reads a separate feedback signal or a supply current rather than the driver’s own status bit. A gate whose test consists of asking the gate whether it is closed is testing nothing, and the diagnostic coverage figures claimed for it will not survive review.