If you size safety functions for a living, ISO 13849-1 is the document you reach for most. It is the standard that turns a risk assessment into a number you can engineer to: a Performance Level, built from the architecture category, the channel MTTFD, the diagnostic coverage and the common-cause failure score. The 3rd edition from 2015 has been the working reference for the better part of a decade. The 4th edition — ISO 13849-1:2023 — was published in April 2023, and it is the version your auditor will increasingly expect to see cited.
The categories and PL scale remain, but do not use that continuity as a blanket acceptance of a 2015 project. The revised requirements can expose a missing design condition, unsupported diagnostic claim or incomplete validation. Whether the result changes depends on the actual safety function and its evidence.
What actually changed in the 4th edition
Rather than quote clause numbers, it is more useful to talk about the areas where the revision lands, because that is where your re-verification effort should go. At a concept level, the 4th edition strengthens these themes:
- Safety-related software. The clearest expansion. Both the application software you write for a safety controller (SRASW) and the embedded-software (SRESW) aspects of components get fuller, more explicit treatment, with a software lifecycle expected to match the target PL.
- MTTFD, DC and CCF guidance. Clearer direction on how to derive and combine the reliability inputs, how to handle the data you rely on, and how the common-cause failure measures are scored and justified.
- Fault exclusion. Review the applicability and evidence for every excluded failure under the selected edition and relevant component/technology guidance; do not treat an old project note as sufficient justification.
- Safety lifecycle and validation. A fuller, more lifecycle-oriented treatment — specification through verification and validation — aligning the design process more closely with how functional safety is handled elsewhere.
- Design conditions and validation. Check category-specific assumptions and the safety requirements specification. A retained category name is not proof that every condition for using it remains satisfied.
The familiar simplified PL estimation framework remains useful; its conditions still have to be met. IFA assigns SISTEMA 3.x to the 2023 edition and 2.x to the 2015 edition. Preserve the original project and library versions before conversion. Read the migration messages and source data; opening an old file successfully is not its technical acceptance.
Why the timing matters: the 2027 Regulation
A standards revision and a legislative transition are separate checks. Regulation (EU) 2023/1230 generally applies from 20 January 2027. The technical file must identify the applicable legal framework and the precise standards used; do not assume a Machinery Directive harmonised reference automatically grants presumption under the Regulation.
Record the exact EN edition, the relevant Official Journal decision, any restrictions and the applicable withdrawal date. A newer international edition can inform design without yet carrying the same legal presumption as a cited EN reference. Check the official entry, not a generic catalogue badge; the harmonised-standards tracking guide explains that distinction.
The safety function is a chain, not a device
A point worth restating, because it is where PL calculations most often go wrong. ISO 13849-1 rates a complete safety function — the sensor that detects the hazard, the logic that processes it, and the actuator that removes the hazard — not any single box. Your input subsystem might be a safety light curtain; your logic a safety relay or safety controller; your output the contactors that drop the motor. The PL you can claim is governed by the whole chain.
This is why presence-sensing device choice feeds directly into the SRP/CS calculation. If your function must reach PL e, every subsystem in the chain has to be capable of supporting PL e. A Type 4 electro-sensitive protective equipment (ESPE) light curtain rated to PL e, built to IEC 61496-1 and -2 with dual OSSD outputs, gives you a high-integrity input you can carry into the calculation with confidence. Drop in a lower-rated sensor and the whole function is capped at that lower level, no matter how good the logic and output stages are. (For when PL e is actually required, rather than merely nice to have, see our note on when Type 4 / PL e / SIL 3 is mandatory.)
The 4th edition does not change ESPE device requirements — those live in IEC 61496 — nor the safety-distance rules in ISO 13855. What it asks is that you bring the device’s published safety characteristics correctly into the SRP/CS calculation, and that the logic between sensor and actuator carries proper software evidence where software is involved.
What to revisit: a practical checklist
Use this as a review sequence, not a promise that redesign will be unnecessary. Record each gap, its safety consequence and the evidence or engineering change needed to close it. Before the next audit, for each safety function:
- Confirm the required PL. Check it against a current risk assessment, not one that predates the latest machine configuration. If the required PL moved, everything downstream has to follow.
- Re-check MTTFD per channel. Validate the component reliability data and the mission time you assumed. Stale B10D figures or an over-optimistic mission time quietly erode a result.
- Verify diagnostic coverage. Make sure the DC you claimed is actually delivered by real diagnostics in the implementation — not a value copied from a template.
- Re-score CCF. Confirm the common-cause failure measures you scored are the ones genuinely implemented on the machine.
- Audit every fault exclusion. Record its technical basis, permitted operating conditions and validation evidence. An undocumented exclusion must not silently remove a failure from the calculation.
- Gather software evidence. Where the function includes safety-related software, assemble the lifecycle evidence — specification, design, verification and validation, configuration management — appropriate to the PL.
- Update the citation. Confirm the edition and harmonisation status you reference in the technical file are current for the framework you are claiming conformity to.
The bottom line for machine builders
Keep the old calculation as traceable history, then produce an edition-specific review record for the actual machine configuration. Close unsupported assumptions, software and validation gaps before claiming the achieved PL. The useful outcome is a defensible safety function, whether that requires better evidence, a corrected model or a design change.