Why S7 Distributed Safety Applications Need TUV Re-Certification

1. Overview: The Two-Tier Certification Model in Functional Safety

Siemens S7 Distributed Safety (and its successor, S7 Failsafe in the TIA Portal) is delivered as a TUV-certified software toolchain. The certification covers the compiler, the F-runtime library, the editor's logical constructs, and the type-checking rules that prevent a developer from accidentally wiring a standard output to a fail-safe tag. What the tool certification explicitly does not cover is the application that the engineer produces with the tool.

This is the source of the most common confusion in safety automation: a certified tool is a necessary, but not sufficient, condition for a certified safety function. The application - the program logic, the sensor and actuator wiring, the PL/SIL calculation, the proof-test interval, and the documented operating modes - is a separate deliverable that must be assessed against the relevant functional safety standard (typically ISO 13849-1 for mechanical categories, or IEC 62061 / IEC 61508 for electrical/electronic/programmable systems) and, in many jurisdictions, audited by an external notified body.

The practical consequence is that an F-Block written in F-FBD or F-LAD in STEP 7 can be syntactically perfect, compile without warnings, and still be functionally dangerous. The tool guarantees that what was written will execute exactly as written. It does not guarantee that what was written is what the risk assessment requires.

2. The Certification Boundary: Tool vs. Application

Understanding the boundary between tool certification and application certification is the foundation of every safety discussion. The TUV certificate attached to S7 Distributed Safety (documented in the SIMATIC Safety Integrity manual and listed in the Siemens Industry Online Support functional safety FAQ) covers a defined scope.

The tool cannot decide whether an emergency stop should be wired in Category 1 (controlled stop with monitored decay) or Category 0 (uncontrolled immediate energy removal). The tool cannot verify that the dual-channel architecture actually uses two independent devices and not two outputs of the same module. The tool cannot confirm that the light curtain's muting sequence respects IEC 61496-1 and ISO 13849-1. All of those decisions belong to the application, and the application is what is being certified.

3. Why a Certified Tool Can Still Produce an Unsafe Application

The classic failure modes that pass tool validation but fail application validation are well-documented. The seatbelt analogy is precise: a TUV-approved seatbelt used incorrectly is still a hazard. The same applies in software.

3.1 Logic Inversion Errors

An F-application can be written so that the safety output is energized when the emergency stop is pressed. The F-block compiles, the signature is valid, and the F-CPU executes it deterministically. The behavior is unsafe. The only way to detect this is to read the program, walk the logic, and confirm the intended state - exactly what a TUV functional safety audit does.

3.2 Always-On Programming

A more subtle case is the F-block that always passes through the OK state because the developer never wired the diagnostic feedback. The E-stop circuit reports "OK" at all times because nothing is reading the auxiliary contact of the contactor. The tool reports no fault; the application reports no fault; the user sees no fault. The hazard is only revealed when the contactor welds and the auxiliary contact does not close - at which point the E-stop has been silently bypassed for the entire service life of the machine. An experienced TUV inspector will trace every diagnostic bit to its source, not just confirm that the F-block compiles.

3.3 PL/SIL Under-Calculation

A designer may select a single-channel sensor for a Category 3 / PL d function because the F-CPU itself is dual-channel. The architecture of the logic system is not the same as the architecture of the sensor subsystem. IEC 62061 and ISO 13849-1 require the subsystem PFH to be calculated, and the tool's compiler does not enforce a minimum PFH on a user-supplied sensor part number. A TUV audit will re-derive the PFH from the manufacturer's data sheet and confirm it meets the SIL/PL claimed in the safety requirements specification.

3.4 Response-Time Misuse

The F-CPU publishes a maximum cycle time and a worst-case F-runtime. The application must add to this the sensor de-bounce, the input filter, the network propagation delay (PROFIsafe over PROFINET), and the actuator dropout. The total response time must be below the safety distance calculation from ISO 13855. Tools such as SISTEMA (developed by the German IFA, formerly BGIA) and the Siemens Safety Calculator compute this, but they require correct inputs. A 50 ms sensor de-bounce entered in the wrong field by an inexperienced engineer can double the response time and invalidate the safety distance. The audit confirms the inputs as well as the result.

4. Legal Basis: Where Re-Certification Is Mandatory

Re-certification is not a voluntary best practice everywhere. The legal obligation depends on the jurisdiction, the application sector, and the conformity assessment route selected by the manufacturer of the machinery.

4.1 European Union - Machinery Directive 2006/42/EC

In the EU, Machinery Directive 2006/42/EC is the primary driver. Machinery listed in Annex IV (e.g., safety components, presses, vehicle lifts, roll-over protection) must undergo a conformity assessment by a notified body when the harmonized standards are not applied in full, or when the manufacturer chooses not to rely on internal production control. The notified body issues an EC type-examination certificate. For machinery not in Annex IV, the manufacturer may issue a Declaration of Conformity under the manufacturer's sole responsibility, but the safety functions must still be designed and verified per the relevant harmonized standards.

4.2 United States

In the US, OSHA 29 CFR 1910 generally requires machinery to comply with industry consensus standards (ANSI B11.0, ANSI/RIA R15.06 for robots, NFPA 79 for industrial machinery). OSHA does not directly certify safety applications; certification is by a Nationally Recognized Testing Laboratory (NRTL) such as TUV SUD America, UL, or FM Global. For collaborative robot applications, ANSI/RIA R15.606 may also apply. The legal basis is product liability law: an unsafe machine exposes the manufacturer, integrator, and end-user to civil tort claims.

4.3 India and Other Non-EU Jurisdictions

India's Factories Act 1948 and the more recent Occupational Safety, Health and Working Conditions Code 2020 establish employer duties but do not prescribe a single notified body for safety PLC applications. In practice, Indian corporations that export to the EU will often obtain TUV certification voluntarily for the EU market and apply that same documentation to the Indian domestic installation, since it is the most defensible record. The Bureau of Indian Standards (BIS) and the National Accreditation Board for Certification Bodies (NABCB) accredit certification bodies, and the major German TUV organizations (TUV SUD, TUV Rheinland, TUV Nord) all maintain Indian operations that issue TUV certificates recognized under IEC schemes (IECEE CB Scheme for functional safety).

The pragmatic answer is to commission a TUV functional safety audit under IEC 61508/62061 even when not legally required, because the deliverable is the same globally defensible certificate.

5. The TUV Certification Process for a Safety Application

A typical engagement for a Siemens S7 Distributed Safety application follows a defined sequence. The exact deliverables depend on the certification body, but the structure is broadly consistent. The standard reference is IEC 61508-1 Annex A for the SRS template, and IEC 61511-1 §11.5 for the process-side equivalent.

5.1 Phase 1 - Documentation Review and Risk Assessment

The applicant submits the Safety Requirements Specification (SRS) per IEC 61508-1, Annex A, or the Safety Function Specification per ISO 13849-1. The TUV assessor reviews the risk assessment (typically an ISO 12100 worksheet) and confirms that every identified hazard has a corresponding safety function with a defined PL or SIL, response time, and proof-test interval.

5.2 Phase 2 - Architecture and PFH Verification

The assessor re-derives the PFH (Probability of dangerous Failure per Hour) for each safety function. The deliverable is a SISTEMA file, a PAScal file, or an equivalent calculation. The assessor confirms that:

• Subsystem architectures (Category 1/2/3/4 for ISO 13849, or SIL 1/2/3 for IEC 62061) are achievable with the selected components.
• Common Cause Failure (CCF) score meets the minimum per ISO 13849-1 Annex F (greater than or equal to 65 for Category 3/4).
• DCavg (Average Diagnostic Coverage) meets the minimum for the target PL.
• MTTFD values are sourced from the manufacturer's data sheet, not from generic "10 years" defaults.

5.3 Phase 3 - Program Code Review

The F-program source (F-FBD, F-LAD, F-STL) is reviewed. The assessor confirms:

• All F-blocks are from the version-locked TUV-certified F-library shipped with S7 Distributed Safety.
• No F-tag is driven by a non-F source (e.g., a standard DB written by a non-safety program).
• All F-variables have a defined passivation behavior.
• Passivation and reintegration are implemented per the safety requirements.
• Operator acknowledgment of safe states is forced, not optional.

5.4 Phase 4 - On-Site Witness Testing

The assessor (or a qualified auditor) is present for a defined set of fault injection tests. Typical test cases include:

• Single-channel fault on E-stop: press the E-stop, confirm Category 1 stop, confirm restart requires manual reset.
• Cross-fault between redundant channels: simulate a short between the two E-stop channels, confirm detection within the F-runtime diagnostic cycle.
• Sensor power loss: remove 24 V from a safety light curtain, confirm safe state.
• Communication loss: drop the PROFINET connection, confirm the F-CPU enters the safe state on the affected PROFIsafe slot.
• Watchdog test: induce a CPU cycle-time overrun, confirm the F-CPU goes to STOP with safe outputs.

5.5 Phase 5 - Report and Certificate Issue

The assessor issues a Functional Safety Report and, if the application passes, a TUV Certificate for the specific application (not a generic certificate). The certificate is version-locked to a specific F-library version, a specific hardware revision, and a specific F-application checksum. Any change to any of those values requires a new certificate.

6. Required Roles and Competencies

A common question is whether the safety PLC programmer must personally hold a TUV certificate. The answer is no, but the project must be supervised by a qualified Functional Safety Engineer.

6.1 CFSE and TUV FSE

The two main qualifications are:

• CFSE (Certified Functional Safety Expert) issued by exida. Valid for three years, requires renewal by exam.
• TUV FSE (Functional Safety Engineer) issued by TUV Rheinland, TUV SUD, or TUV Nord under the IEC 61508 scheme. Levels are typically TUV FSE Level 1 (machinery) and TUV FSE Level 2 (process industry, higher SIL).

A project targeting PL d / SIL 2 generally requires a Level 1 engineer; PL e / SIL 3 generally requires a Level 2 engineer. The TUV assessor will look at the engineer's certificate copy as part of the project documentation.

6.2 The TUV Inspector's Scope

The TUV inspector does not write the program. The inspector's role is to assess the work product. A typical TUV project team on the applicant's side therefore includes:

• A TUV FSE-certified project lead.
• A hardware designer competent in ISO 13849 architecture rules.
• A software engineer trained in S7 Distributed Safety.
• A risk-assessment specialist competent in ISO 12100.
• A validation engineer who builds the test cases.

The TUV inspector will demand to see competency records for each of these roles, plus the CVs of the people actually doing the work, not just the project lead.

7. Re-Certification Triggers and Change Management

A TUV certificate is not perpetual. The certificate will normally include a validity period (commonly 3-5 years) and a list of change triggers that void the certificate.

7.1 Triggers That Require a New Assessment

7.2 Change Control Procedure

Most TUV-certified sites operate a formal change control procedure (often a Management of Change, or MoC, document). The flow is:

1. Initiate change request (CR).
2. Risk assessment impact analysis.
3. Decision: like-for-like (no re-cert), minor (re-issue, no witness test), major (full re-certification with witness test).
4. Implementation under MoC.
5. Re-test per the original validation matrix plus any new test cases.
6. Update the SISTEMA file and the Functional Safety Report.
7. Archive for the lifetime of the machine plus a defined retention period (commonly 10 years).

A major change can add 4-8 weeks to project schedule. The mitigation is a forward-compatible design - using F-library versions that have a known support horizon, and a hardware architecture that can absorb likely future sensor changes without restructuring the safety function.

8. Documentation Requirements: What the Auditor Will Request

A complete TUV submission for an S7 Distributed Safety application typically includes:

• Risk assessment per ISO 12100 (hazard list, severity, frequency, possibility of avoidance, PLr derivation).
• Safety Requirements Specification (SRS) per IEC 61511-1 §11.5 (process) or the equivalent machinery-side document.
• Architecture diagrams with marked Category / SIL for each subsystem.
• SISTEMA or PAScal calculation file.
• Bill of materials with manufacturer, part number, and PFH/MTTFD for every safety component.
• F-application source code (print-out, not the live project).
• F-application checksum (for traceability to the deployed version).
• F-library version manifest.
• I/O wiring diagrams with cross-circuit fault analysis.
• Validation plan, test cases, and test results.
• Competency records of the project team.
• Operating instructions and maintenance procedures.
• Proof-test interval and proof-test procedure.
• Software modification history.

The auditor may also request the STEP 7 project archive (S7P file) and the GSD/GSDML files for any PROFIsafe slave, since the F-host configuration and the slave's F-iPar-CRC must be consistent.

9. Common Pitfalls in Safety Application Design

The recurring issues observed in TUV audits include:

9.1 Bypassing the F-Block for Convenience

A maintenance mode that writes a non-F tag over an F-tag, then reads the result back into a standard DB. The F-block signature is preserved, but the safety function is no longer in the path. Auditors check for "F-tag shadowing" - any read of a standard tag that logically drives an F-tag's effect.

9.2 Incorrect Use of F-I/O Acknowledgment

Some F-modules require a user acknowledgment (QVZ - Qualifier Verzugszeit, or passivation acknowledgment) after a recoverable fault. If the application auto-acknowledges, the diagnostic information is lost and the same fault may recur unnoticed.

9.3 PROFIsafe Address Misconfiguration

A F-Slave address switch set to the same value as another F-Slave on the same PROFINET segment. The F-host will see two valid responses and the diagnostic is ambiguous. The S7 Distributed Safety F-Address Assignment Tool catches this, but only if the engineer uses the tool and the result is documented.

9.4 Cross-Circuit Faults in Mixed I/O

A standard 24 V wire run parallel to an F-input wire in the same cable tray. ISO 13849-2 §D.4 requires that cross-circuits be considered, and Category 3/4 architectures require either physical separation or protected wiring (e.g., sheathed cable) to defend against them. The F-application will detect a cross-circuit only if the diagnostic cycle is short enough and the wiring is laid out per the design rules - both of which are application decisions, not tool decisions.

9.5 Insufficient Proof-Test Interval

A proof-test interval that is too long for the calculated PFD. For SIL 2 with a 1E-06 PFH target, the proof-test interval is typically 1-3 years. If the maintenance schedule calls for a 10-year overhaul, the PFD over the full 10 years may exceed the target, requiring the architecture to be tightened (e.g., dual-channel with continuous diagnostics instead of single-channel with periodic proof-test).

10. Verification Checklist: Pre-Audit Self-Assessment

Before engaging the TUV, the project team should self-audit against this checklist. Each "No" is a likely finding.

If any item is "No", the project is not yet ready for TUV submission. Resolving findings internally before the audit is faster and cheaper than during it.

11. Notes on Insurance and Legal Defense

Beyond regulatory compliance, a TUV certificate is a tool for managing product-liability exposure. In a typical industrial accident claim, the plaintiff's expert will examine the machine's safety design. The presence of a TUV Functional Safety Report, signed by a notified body, materially shifts the burden of proof: the plaintiff must show that the certificate was negligently issued, not merely that the machine was unsafe. In jurisdictions with strict liability for defective products, this is often the difference between dismissal and settlement.

The insurance dimension is also material. Major industrial insurers (Allianz, HDI, Liberty Mutual, the Marsh carrier panel) routinely offer premium reductions of 5-15% for machinery with a current TUV functional safety certificate, and they may decline coverage entirely for high-hazard machinery (press lines, robots, hoists) without one. The reduction is in part actuarial (certified machines have lower claim frequency) and in part procedural (a certified machine is easier to defend, reducing legal cost).

12. Frequently Asked Questions