What a safety PLC is, and how it differs from a standard one
A standard PLC is designed to keep production running: if it detects an internal fault, it will typically try to keep operating or, at most, shut down in a controlled way to avoid losing the process. A safety PLC starts from the opposite premise: whenever a fault occurs, whether in itself or in the system it's monitoring, it must bring the machine to a safe state deterministically, and be able to prove it with a certified reliability level. That's not a nuance — it's the difference between a system that prioritizes uptime and one that prioritizes making sure nobody gets hurt.
That's why an emergency stop, a safety door, or a light curtain isn't simply wired into a digital input on a standard PLC and resolved with a line of Ladder logic. It requires a certified safety system end to end: safety-rated sensors, safety-rated processing, and safety-rated outputs, all built on redundant architectures with continuous self-diagnostics. Siemens' S7-1500F family is how that safety system gets integrated into the same CPU that's running the process.
The fail-safe CPU (F-CPU): two programs, one controller
An S7-1500F isn't a standard S7-1500 with a safety card bolted on. It's a fail-safe CPU (F-CPU) that runs two independent programs at the same time: the standard program, with the usual process logic, and the safety program, which executes in a separate, isolated context within the CPU. Internally, the safety program is processed twice using data diversity (the same calculations represented differently), and the two results are constantly compared; any discrepancy forces the safe state immediately.
That internal dual execution is what allows the whole system to be certified under IEC 61508 up to SIL 3 and under ISO 13849-1 up to PL e, without needing to physically duplicate the hardware with two PLCs and an external voting system, as many earlier-generation safety architectures required.
PROFIsafe: safety on the same network, no separate wiring
The other key piece is how the safety signal gets from the field sensor to the F-CPU. Siemens' answer is PROFIsafe, a protocol that runs over the same Profinet or Profibus network carrying the rest of the process data, with no separate safety bus or extra cabling needed. This works thanks to the black channel principle: PROFIsafe doesn't trust the underlying transport network to be reliable, so it adds a sequence number, a watchdog time, and a CRC check code to every telegram, meaning any delay, duplication, loss, or corruption of the message gets caught within the safety telegram itself, regardless of what happens on the network carrying it.
In practice, that means a cabinet with remote safety I/O (an ET 200SP F, for example) can share the exact same Profinet cable as standard I/O, cutting down on wiring and failure points without giving up certification.
SIL and PL: two standards, one goal
Machinery projects live under two regulatory frameworks that are often mentioned interchangeably even though they aren't quite the same: IEC 61508 / IEC 62061, which defines Safety Integrity Levels (SIL 1 to SIL 3 for machinery applications), and ISO 13849-1, which defines Performance Levels (PL a to PL e) based on architecture category, component reliability (MTTFd), and diagnostic coverage (DC).
| SIL (IEC 62061) | Equivalent PL (ISO 13849-1) | Typical risk |
|---|---|---|
| SIL 1 | PL c | Low risk, minor reversible injury |
| SIL 2 | PL d | Medium risk, serious injury possible |
| SIL 3 | PL e | High risk, serious injury or death likely |
The required level isn't picked by the control engineer: it's determined by the machine's risk assessment under ISO 12100, and that in turn drives which safety architecture — and which CPU, sensors and outputs — is actually needed. An S7-1500 F-CPU certified up to PL e comfortably covers the vast majority of industrial applications, but that doesn't remove the need to calculate the actual level required by each individual safety function.
Programming in TIA Portal Safety: what changes versus the standard program
The safety program isn't written with the same freedom as the standard one. TIA Portal Safety Advanced works with a certified subset of graphical languages (F-LAD and F-FBD) and with pre-certified safety blocks for the typical functions: emergency stop, interlocked safety door, light curtain, two-hand control, safe speed monitoring. Every compilation of the safety program generates a unique safety signature (F-signature), and any change, however small, requires repeating safety acceptance (a documented functional test) before the machine can run again.
This discipline is deliberately stricter than a standard control engineering project. It's not bureaucracy for its own sake — it's about making sure any change to safety logic is traced and verified before an operator is exposed to the risk that logic was designed to control.
Migrating safety when moving from S7-300F/S7-400F to S7-1500F
When we migrate a project following the process described in our S7-300 to S7-1500 migration guide, the safety program needs different treatment from the standard program. TIA Portal can automatically convert much of the standard logic, but the safety program, being tied to a certified signature and to blocks compiled with a specific compiler version, usually requires revalidation and a new safety acceptance after conversion — not a simple recompile. Any migration project involving an F-CPU should budget for that validation time from day one, not discover it during commissioning.
When you actually need a safety PLC
Not every safety function on a plant needs an F-CPU. A single machine with two or three simple safety functions can be handled with safety relays or a compact safety module, and that remains the more economical choice in those cases. An integrated F-CPU starts to pay off when there are several interconnected safety functions spanning different zones of a line, when safety logic needs to coordinate with process logic (for example, to safely resume production after a stop), or in installations with collaborative robots where safety perimeters change dynamically depending on the operating mode, as we discuss in our collaborative robot vs industrial robot comparison.
It's also worth not confusing functional safety (protecting people from mechanical and electrical hazards) with OT cybersecurity (protecting the system from unauthorized access): these are separate disciplines, governed by separate standards, and a well-designed project addresses both without conflating them.
How we do it at Bluemation
At Bluemation we build safety programming into the same PLC programming project rather than bolting it on at the end: we start from the machine's risk assessment, determine the PL or SIL required for each function, program the F-CPU with the corresponding certified blocks, and document the safety acceptance needed for CE marking. We apply the same criteria on new S7-1500 projects and on migrations from earlier platforms alike.
If your machine or line needs its safety functions reviewed, extended, or certified, check out our PLC programming service or get in touch with us. We'll review your installation and tell you what level of safety each function actually requires before proposing a solution.