Fail Safe vs Fault Tolerant PLC Systems: F, H, and FH Architecture Compared

Programmable Logic Controllers (PLCs) deployed in process and safety-critical applications must be classified by the way they behave when hardware faults occur. The two dominant design philosophies, Fail Safe (F) and Fault Tolerant (H), are not interchangeable; they target different safety lifecycle phases, different international standards, and different cost-of-ownership profiles. Siemens SIMATIC controllers formalize this distinction with three product families, F-CPU, H-CPU, and the combined FH-CPU, that map directly to the safety and availability requirements of IEC 61508, IEC 61511, IEC 62061, and ISO 13849-1. This reference explains the engineering differences, the underlying standards, the architecture choices, and the field-proven selection rules that determine which topology belongs in a given machine or plant.

1. Definitions and Core Engineering Goals

Per the Siemens SiePortal reference, the formal distinction in the SIMATIC line is that an F-CPU handles the standard and the fail-safe program in a single CPU; on error detection the system transitions to a defined safe state and the F-CPU enters STOP. A dedicated H-CPU is built on a 1oo2 redundant core, fault tolerant in execution but not in itself a safety controller. The FH-CPU combines both: a 1oo2 redundant core executing both standard and fail-safe programs, with switchover on fault and passivation of the safety program on detected dangerous fault. See the official thread: SiePortal: difference b/w failsafe(F), fault tolerant(H) and FH module.

2. Standards Mapping: SIL, PL, and Availability

Selecting a controller is a two-axis decision. Axis one is the safety integrity level demanded by the application; axis two is the availability demanded by the process. The two axes are often confused because a SIL 3 controller can be implemented in either a fail-safe or a fault-tolerant hardware topology.

Cross-mapping the most common targets:

• SIL 1 (IEC 61508) ≈ PL c (ISO 13849-1)
• SIL 2 (IEC 61508) ≈ PL d (ISO 13849-1)
• SIL 3 (IEC 61508) ≈ PL e (ISO 13849-1)

A safety function on a Fail Safe system is normally classified by its PFD_avg or PFH_d against a target SIL/PL. The same safety function executed on a Fault Tolerant system is also classified by SIL/PL, but the H system additionally contributes to availability metrics such as A% (target 99.99% - 99.9999% for redundant turbine or substation control). Be cautious: a SIL 3 rating does not imply a high A%. A non-redundant F-CPU running SIL 3 will still enter STOP on detected fault, dropping availability dramatically.

3. Hardware Architecture: F, H, FH Channel Topologies

The IEC 61508 vocabulary for hardware fault tolerance uses the M-out-of-N notation. The most common channel architectures are summarized below.

3.1 SIMATIC F-CPU internal structure

The SIMATIC S7-1500F / ET 200SP F-CPU is a single-channel controller with a second, diverse processing channel inside the same package, wired to the same I/O. The two channels execute identical code with diverse instruction scheduling, and the result is compared per safety cycle. On disagreement the F-CPU passivates the safety I/O and transitions the safety program to a safe state. This is the IEC 61508 1oo2D architecture. Examples of certified F-CPUs in the S7-1500 line include:

• CPU 1515F-2 PN (6ES7515-2AM02-0AB0)
• CPU 1516F-3 PN/DP (6ES7516-3AN02-0AB0)
• CPU 1517F-3 PN/DP (6ES7517-3AP00-0AB0)
• CPU 1518F-4 PN/DP (6ES7518-4AP00-0AB0)
• ET 200SP F-CPU 1510SP F-1 PN (6ES7510-1SK02-0AB0), 1512SP F-1 PN (6ES7512-1SK02-0AB0), 1514SP F-2 PN (6ES7514-2SN03-0AB0), 1516SP F-2 PN (6ES7516-2SN00-0AB0)

3.2 SIMATIC H-CPU internal structure

The H-CPU is two complete, independently powered controllers of identical design, synchronizing over a dedicated redundancy link. Each CPU runs the standard program, and either can take over the role of master within the synchronization cycle budget. The H-CPU is not in itself a safety controller, but the platform is the basis for FH. Examples in the S7-1500 line:

• CPU 1517H-3 PN (6ES7517-3HQ00-0AB0)
• CPU 1518HF-4 PN (6ES7518-4JP00-0AB0) - H with integrated fail-safe capability

The redundancy link is typically a dedicated fiber pair carrying the SIMATIC redundancy protocol, and the synchronization cycle is configurable between 1 ms and several hundred ms depending on the program size. Faster sync = faster switchover but less CPU time per cycle.

3.3 SIMATIC FH-CPU internal structure

The FH-CPU is the union of the two prior architectures: a 1oo2 redundant core, with each side internally a 1oo2D for safety. It is the topology used where the safety function must be available (not just safe) across the plant lifetime, and the operator cannot tolerate a spurious trip caused by CPU replacement. Example catalog members:

• CPU 1516F/F-2 PN (6ES7516-2GN00-0AB0)
• CPU 1517F/F-3 PN/DP (6ES7517-3GP00-0AB0)

4. Functional State Machines: STOP, RUN, RUN-Redundant, Passivated

The most useful mental model is the controller state machine, because the difference between F and H systems is exactly the set of states the controller can enter on a fault. The following inline SVG summarizes the legal transitions for an FH-CPU; the F and H variants are subsets of this diagram.

F-CPUs only traverse the STARTUP → RUN-Solo → PASSIVATED → STOP path; they have no RUN-Redundant state. H-CPUs traverse STARTUP → RUN-Redundant → RUN-Solo (after partner failure) but have no PASSIVATED state because the safety program does not run on a plain H. The FH-CPU visits every node.

5. Redundancy Topologies for Field I/O

Redundancy is not only a CPU-level concern. A common engineering error is to specify an H-CPU while connecting single-channel field wiring, which provides no fault tolerance for the sensor or actuator path. The IEC 61508 SIL budget consumes the sensor and final element; they must be redundantly wired to claim fault tolerance in the safety function.

For distributed I/O, Siemens ET 200SP F-modules and ABB S800 I/O support PROFIsafe over PROFINET, where the safety protocol is embedded in the PROFINET frame. For a fault-tolerant PROFINET ring, the Media Redundancy Protocol (MRP) provides < 200 ms recovery; for zero-loss, use Parallel Redundancy Protocol (PRP) or High-availability Seamless Redundancy (HSR) per IEC 62439-3. A HIMA HIMatrix controller typically uses HSR natively; SIMATIC H systems support PRP/H via the SCALANCE XC-200 or XC-300 managed switches.

6. Fault Detection and Diagnostic Coverage

A fail-safe system relies on diagnostic coverage (DC) to convert latent faults into detected faults, so the system can transition to a safe state before the second fault occurs. IEC 61508 Part 2 Annex A and IEC 61508 Part 2 Table 2 list the acceptable diagnostic techniques, each with an associated DC percentage.

The F-CPU implements most of the above internally. The H-CPU additionally detects partner failure, sync loss, and link errors within the redundancy monitor. Detailed diagnostic methods and DC figures are documented in the manufacturer safety manuals; for Siemens, the S7-1500F/ET 200SP F System Manual (entry ID 109751260) and the S7-1500H System Manual are the controlling documents.

7. Programming Differences: Safety Program Structure

In TIA Portal, a safety program on an F-CPU is written in a separate safety block (FB with the "F" attribute, e.g. FB 1 [F]) and is compiled with the F-Compiler. The F-Compiler adds diverse code paths, signature checks, and runtime tests; the standard program cannot call into the F-program and vice versa. Communication between the two is via standard tag accessors that are limited to a defined data set.

A minimal fail-safe block in Structured Text (LAD/FBD equivalent) for an emergency-stop function on an F-DI module:

// FB_SafetyEstop [F] - S7-1500F
// Inputs : i_estopN (BOOL, F-DI), i_feedback (BOOL, F-DI), i_run (BOOL, standard)
// Outputs: q_allow (BOOL, F-DO), q_ackRequired (BOOL, standard)

IF i_estopN OR NOT i_run THEN
    q_allow := FALSE;             // drive to safe state
    q_ackRequired := TRUE;
ELSE
    q_allow := TRUE;
    q_ackRequired := FALSE;
END_IF;

For an H or FH system, the same block is loaded into both sides of the redundant pair. The runtime additionally contains the redundancy synchronizer (sync OB, default OB 100 for warm restart). The standard program must be deterministic: any non-deterministic call (e.g. long file I/O) can cause the H partner to detect a sync violation and force a switchover, which by itself is not a dangerous fault but can disrupt the process.

8. Communication: PROFIsafe, CIP Safety, and Modbus/TCP

The protocol is not interchangeable with a redundant physical bus. PROFIsafe can be run over a single PROFINET line for SIL 3, or over a redundant ring (MRP) for combined safety and availability. Do not assume that running PROFIsafe on a non-redundant ring gives you an FH system; the redundancy is in the network, not in the CPU.

9. Selection Rules: When to Use F, H, and FH

Use this decision table at the Functional Safety requirements specification stage. Re-validate the choice at the HAZOP/LOPA study and again at the procurement gate.

9.1 Availability calculations

For a redundant pair, the steady-state availability assuming exponential failure distribution and an active repair is:

A = MTBF / (MTBF + MTTR) for a single channel.

For a 1oo2 redundant pair with perfect switchover:

A_red = 1 - (λ²·t²)/2 ≈ 1 - (MTTR/MTBF)²/2

A typical H system with MTBF ≈ 50 years (≈ 438 000 h) and MTTR ≈ 8 h yields A ≈ 99.999% (the "five-nines" mark), versus ≈ 99.4% for a single CPU. Always state the assumed MTTR in the calculation; some vendors publish MTTR figures, others assume 24 h, and the resulting A% can change by an order of magnitude.

10. Lifecycle Considerations: Proof Tests and Recertification

IEC 61508 and IEC 61511 both require a proof-test interval (T_proof) at which the safety function is exercised end-to-end. A common misunderstanding is that a redundant controller "never needs testing". In fact, the redundant controller still has the same dangerous-failure rate, just with the redundancy masking the first fault; the proof test must detect the first fault before the second occurs, otherwise a dangerous failure becomes possible. The simplified PFD_avg formula for a 1oo2 system with proof test is:

PFD_avg(1oo2) = 2·(λ_D·T_proof)² / 3

Compare to a 1oo1 system:

PFD_avg(1oo1) = λ_D·T_proof / 2

A 1oo2 system with the same λ_D and T_proof is roughly two orders of magnitude better in PFD_avg for the same dangerous-failure rate, which is why redundancy is so heavily favored in high-demand process paths. Detailed formulas and example spreadsheets are in IEC 61508 Part 6 Annex B; verify with the latest edition of the standard before claiming a SIL figure in a regulatory submission.

11. Common Failure Modes and Field-Proven Pitfalls

12. Cross-Platform Reference: Siemens, Allen-Bradley, Schneider, ABB, HIMA

13. Commissioning and Verification Checklist

1. Confirm the safety function's target SIL/PL from the Safety Requirement Specification (SRS).
2. Compute the achieved PFD_avg / PFH_d for the sensor, logic, and actuator paths with vendor SISTEMA or exida tools.
3. Verify the controller firmware revision matches the manufacturer's TÜV certificate.
4. Wire the safety I/O per the manufacturer's derating guidelines (e.g. F-DI input debounce, F-DO test pulse width).
5. Force a passivation by disconnecting each F-DI and verify the expected passivation log entry is generated.
6. On an H or FH system, force a partner failure (pull the redundancy link) and confirm switchover within the configured sync window.
7. Document the proof-test interval in the Safety Validation Plan and the operations/maintenance procedures.
8. Sign the Safety Validation Report and update the SRS to reflect any architectural changes.

14. Frequently Asked Questions