What to record before recovering a fail-safe PLC CPU

A fail-safe CPU, usually written F-CPU, runs two programs at once: the normal control program and a separate safety program that the manufacturer's runtime keeps isolated from it. You pull out a CPU, read the family and the number, and everything looks standard. Then the machine refuses to accept a safety program. That is the fail-safe trap.

Enlarged system diagram

×

The split is functional, not physical: both programs run on the same unit, but the safety side is isolated by the runtime.

Siemens ships fail-safe variants inside the S7-1200F and S7-1500F families, and the F marking appears in the order number and on the housing label. The hardware does not announce the difference on its own, so the marking is the first thing to check and the first thing to record. One extra character in the order number separates a unit that accepts a safety project from one that cannot.

The two programs stay separate by design. The safety program runs under its own runtime rules, and the standard program cannot modify it. That isolation is why a standard CPU cannot simply be loaded with a safety project, and why the F status shapes every recovery question that follows.

You can spot the F marking without opening anything. In Siemens order numbers the fail-safe capability appears in the reference itself, and the housing label carries the marking as well. The engineering tool shows it too, once the unit is on the network. What you cannot do is infer it from the machine behavior, because a standard CPU can run the same process right up to the moment someone tries to load a safety project. The marking is a printed fact, so treat it as one and read it.

The marking changes what a matching reference has to include. Two CPUs that share the base number can differ in whether they accept a safety program at all, and that capability is bound to the specific unit and its configuration. This is why the F status belongs in the first line of your record, before the revision or the photos.

Enlarged system diagram

×

The base number opens the door, but the F record decides what can pass through it. This is a functional check, not a wiring one.

The safety program and its F configuration, the settings that bind the safety function to the unit, are part of the identity in a second way. A unit with the correct order number can still refuse to run a safety project if the configuration does not match what the project expects. No nameplate value proves that a replacement will accept the project. That evidence has to be recorded, never assumed. The F module list also protects the review from a second trap: a replacement CPU that looks complete on paper while the configured set around it stays unrecorded.

The connected fail-safe I/O modules, the F modules, belong to the same configured set. An F-CPU and its F-IO are configured together in the project, and a change to any member of that set can require the safety program to be revalidated. So the matching question never stops at the CPU; it extends to every F module around it. The distinction is invisible from outside the cabinet, which is why the printed marking carries so much weight.

For a request, the practical consequence is scope. Say that the CPU sits in a fail-safe application even when your question is only about the CPU, because the reviewer cannot know whether the F modules around it are part of the question until you say so. A reviewer who learns about the F modules mid-review has to reopen the intake, and the F module references you listed earlier become the reason the review did not have to.

Capture the full order number with its F marking, the firmware version as printed, and the hardware generation. Photograph the nameplate and any safety-related labeling in the cabinet, including signs or documents that name the safety function the CPU serves. Photographs carry the wording exactly, and paraphrased safety labels lose their meaning in a record. Two label sources for the same unit are normal, and each one photographed is one less detail reconstructed from memory.

Enlarged system diagram

×

Four record groups feed the pack. Each one answers a question a reviewer would otherwise have to ask twice.

List the connected F modules with their own references. Name each F module, its slot or station position, and its full order number, the same way you recorded the CPU itself. Where the modules sit matters, because the revalidation question follows the wiring.

If a project backup exists, record the safety program version and where the backup is stored, alongside the standard program version. The two versions can differ, and a reviewer needs both to judge what a restored unit would actually run. If no backup exists, write that fact into the record, because it changes every recovery route that follows. The storage location matters as much as the version; a backup nobody can find behaves like a missing backup.

Safety labeling is worth a deliberate pass. Look for warning signs at the cabinet door, documentation pockets, and any placard that names the safety function the CPU serves, and photograph what you find. Those items carry the wording that safety reviewers work with, and a paraphrase in your notes cannot reproduce it. If nothing is labeled, record that absence as a fact, because it tells the reviewer how much of the safety context is undocumented.

Date every entry and keep the pack factual. Opinions about what probably caused a fault, or what a supplier might have on the shelf, do not belong next to measured facts. The date is what turns a claim into a record, because a fact without a date cannot be re-checked against anything.

Enlarged system diagram

×

Trust comes from three fields per line. Stated gaps are part of the evidence, not a failure of the record.

A dated, sourced pack lets the next person verify each line instead of re-deriving it. Each value should carry its source: nameplate, engineering tool, or project file. When two sources disagree, record both readings rather than averaging them, and let the review resolve the conflict.

The same discipline applies to gaps. An unknown firmware state or a missing backup is a fact about the record, and stating it openly is stronger evidence than guessing. The gaps also tell the reviewer which identification steps to repeat first.

When two sources disagree, record both readings with their sources and dates, and leave the judgment to the review. A firmware value from the engineering tool and a different one from a parts list is a normal finding in an aging plant, and choosing one silently turns your record into a claim. Two recorded readings are evidence; one chosen reading is an opinion. The reviewer resolves the conflict once, with sources in front of them, instead of discovering it twice.

A fail-safe CPU is not a like-for-like exchange question alone. Safety-related work belongs to qualified personnel under the rules that apply to the machine, and no catalog entry, datasheet, or supplier claim changes that. The evidence pack is an input to that work, not a substitute for it.

Enlarged system diagram

×

The pack ends where safety qualification begins. Arrows show the handover of questions, not the handover of work.

Record what you know and state what you do not know, then route the safety program questions to the people responsible for the machine. A record that openly lists its gaps is more useful to a reviewer than one that papers over them. Where a gap exists, say who would normally close it and what tool they would need.

Treat compatibility and outcomes as open questions in the request. Whether a specific replacement accepts the existing safety project, and whether a repair can preserve the F configuration, are decisions for the review with the responsible people, supported by your evidence. Uncertainty here is normal, and stating it is what keeps a safety recovery honest.

• Capture the order number with its F marking, the firmware version, and the hardware generation.
• List every connected fail-safe I/O module with its own reference and position.
• Record both program versions, or state plainly that no backup exists.
• Safety program work goes to qualified personnel. Note that boundary in the request.

• the category page for PLC CPUs
• the nameplate field walkthrough
• the evidence pack for a PLC request