Gerechnet istnoch nicht nachgewiesen.

10.1.1 sagt es in einem Satz: „Der Zweck des Validierungsprozesses ist es, zu bestätigen, dass das SRP/CS der gesamten SRS entspricht“. Die SRS ist die Spezifikation der Sicherheitsanforderungen, erstellt nach Abschnitt 5 und 7. Ohne sie gibt es keinen Maßstab und damit nichts zu validieren.

Die Validierung muss dreierlei belegen: die funktionalen Anforderungen der Sicherheitsfunktionen, die Anforderungen des festgelegten Performance Levels nach 6.1.1 — Kategorie, Maßnahmen gegen systematische Ausfälle, Software und die Fähigkeit unter vorhersehbaren Umgebungsbedingungen — und die ergonomische Gestaltung der Bedienerschnittstellen.

Dazu eine Anforderung an die Besetzung: Der Validierungsprozess „sollte von (einer) Person(en) durchgeführt werden, die vom Entwurf des SRP/CS unabhängig ist/sind“. Anmerkung 2 stellt klar, was gemeint ist: eine Person, die am Entwurf nicht beteiligt war. Eine dritte Partei ist nicht erforderlich — der Konstrukteur, der seinen eigenen Entwurf validiert, genügt aber nicht.

Beide Begriffe sind festgelegt, und beide stammen aus fremden Regelwerken. Verifizierung (3.1.53) ist die „Bestätigung durch Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind“. Validierung (3.1.54) ist das „Bestätigen aufgrund einer Untersuchung und durch Bereitstellung eines objektiven Nachweises, dass die besonderen Anforderungen für eine spezielle beabsichtigte Verwendung erfüllt worden sind“.

Der Unterschied liegt im letzten Halbsatz: festgelegte Anforderungen auf der einen Seite, die beabsichtigte Verwendung auf der anderen. Praktisch trennen ihn zwei Abschnitte. Abschnitt 8 verifiziert den erreichten Performance Level gegen den geforderten, je Sicherheitsfunktion. Abschnitt 10 validiert, und zwar durch Analyse und Prüfung.

„Die Validierung besteht aus der Durchführung einer Analyse (siehe 10.3) und der Ausführung von Tests (siehe 10.4) unter vorhersehbaren Bedingungen in Übereinstimmung mit dem Validierungsplan“ (10.1.1). Bild 17 der Norm zeigt den Ablauf.

In die Analyse gehen nach 10.3 ein: die Sicherheitsfunktionen nach 5.2, die Systemstruktur nach 6.1.3.2, die quantifizierbaren Aspekte MTTFd, DCavg und CCF, die qualitativen Aspekte einschließlich Software, deterministische Betrachtungen, die Fehlerlisten und die Kriterien für den Fehlerausschluss.

Die Prüfung nach 10.4 erfolgt möglichst „mit seiner endgültigen Betriebskonfiguration“, also mit allen peripheren Geräten und mit allen Abdeckungen an ihren vorgesehenen Stellen. Zwei Einschränkungen sind praktisch bedeutsam: Bei Kategorie B oder 1 sind keine Prüfungen unter Fehlerbedingungen erforderlich. Und die Analyse „sollte so früh wie möglich und parallel zum Entwurfsprozess gestartet werden“ — nicht danach.

Der Validierungsplan „muss die Anforderungen an die Durchführung des Validierungsprozesses festlegen und beschreiben und muss betroffenen Personen und Parteien verfügbar gemacht werden“ (10.1.2). Er ist damit kein internes Arbeitspapier.

Die quantitativen Größen erfassen zufällige Hardware-Ausfälle. Was daneben steht, ist eine eigenständige Nachweispflicht; sie wird nicht erfüllt, wenn links eine größere Zahl steht.

Zu den Maßnahmen gehören zwei Gruppen: solche zur Beherrschung systematischer Ausfälle — Abschalten bei Energieausfall, Schutz gegen Überspannung, definierte Programmabläufe — und solche zu ihrer Vermeidung beim Entwurf: Review, geeignete Werkstoffe und Fertigung, EMV-Festigkeit. In der Dokumentation sind die getroffenen Maßnahmen anzugeben, nicht vorauszusetzen.

Ein Fehlerausschluss erlaubt, einen bestimmten Fehler in der Bewertung nicht anzusetzen. 6.1.10.3 nennt ihn einen „Kompromiss zwischen den technischen Sicherheitsanforderungen und der theoretischen Möglichkeit des Auftretens eines Fehlers“ und lässt drei Grundlagen zu: die technische Unwahrscheinlichkeit des Auftretens, die allgemein anerkannte technische Erfahrung unabhängig von der Anwendung, und die technischen Anforderungen im Bezug zur Anwendung und zur spezifischen Gefährdung.

Zwei Grenzen stehen ausdrücklich in der Norm. „Der PL e darf nicht allein auf Fehlerausschluss beruhen.“ Und der Ausschluss bestimmter Fehler „schränkt die Notwendigkeit von Maßnahmen gegen systematische Ausfälle nicht ein“.

Praktisch wird das an einer Kategorie-3-Struktur mit einkanaligem mechanischem Teil, etwa der Betätigungsmechanik eines Türschalters. Sie ist häufig nur über den Ausschluss des Betätigungsbruchs haltbar. Dann trägt dieser eine Ausschluss den gesamten Performance Level, und die fünf Anforderungen oben gelten für ihn einzeln. Wo das nicht gelingt, bleibt die redundante Ausführung.

Sicherheitsbezogene Software zerfällt in zwei Teile, und nur einer davon liegt beim Integrator. Welcher Nachweisweg für diesen gilt, hängt an der Sprache: 7.2.1 regelt die Programmiersprache mit eingeschränktem Sprachumfang, 7.2.2 die mit nicht eingeschränktem, 7.2.3 die Entscheidung zwischen beiden.

Für den Maschinenbau folgt daraus eine Weiche: Wer die Sicherheitslogik in einer Sprache mit eingeschränktem Umfang auf einer Sicherheits-SPS oder einem Sicherheitsrelais hält, führt den Nachweis über das vereinfachte V-Modell. Werden zuvor beurteilte Hardware- und Softwaremodule mit LVL kombiniert, gilt die kürzere Variante nach Bild 14 b). Sobald eigener Code in einer Sprache mit vollem Umfang dazukommt, ist es ein anderes Vorhaben.

Alle Fundstellen dieses Blattes stammen aus DIN EN ISO 13849-1:2023-12, der gültigen Ausgabe. Das Validierungsverfahren steht dort vollständig in Abschnitt 10. ISO 13849-2:2012 liefert die Fehlerlisten in Anhang A bis D; dieser Text lag beim Schreiben nicht vor. Was hier über ihn steht, ist über 10.1.3 des Teil 1 belegt, nicht aus dem Dokument selbst.

• [1] DIN EN ISO 13849-1:2023-12, Sicherheitsbezogene Teile von Steuerungen, Teil 1. Abschnitt 10 mit Bild 17 für den Validierungsprozess, 10.1.2 Validierungsplan, 10.3 Analyse, 10.4 Prüfung, 10.8 Aufzeichnung; 6.1.10.3 Fehlerausschluss; Abschnitt 7 mit 7.2.1 und 7.2.2 für LVL und FVL sowie Bild 14 für das vereinfachte V-Modell; Abschnitt 8 für die Verifizierung; 3.1.53 und 3.1.54 für die beiden Begriffe.
• [2] ISO 13849-2:2012, Teil 2: Validierung — lag nicht vor. Anhang A bis D enthält die Fehlerlisten für mechanische, pneumatische, hydraulische und elektrische Teile: die einzubeziehenden Bauteile, die zu berücksichtigenden Fehler, die erlaubten Fehlerausschlüsse und eine Spalte für deren Begründung. Berücksichtigt sind darin nur permanente Fehlzustände. Diese Angaben stammen aus 10.1.3 des Teil 1.
• [3] Weitere genannte Regelwerke. ISO 9000 als Quelle des Begriffs Verifizierung und IEC 61508-4 als Quelle des Begriffs Validierung — beide von der ISO 13849-1 selbst so ausgewiesen. IEC 61131-3 für die Programmiersprachen und ISO 14119 für Verriegelungseinrichtungen sind genannt, aber nicht gegengeprüft; diese Texte lagen nicht vor.
• [4] Das Blatt nennt keine Häufigkeiten. Wie oft ein Nachweis an der geforderten Unabhängigkeit scheitert, wie lange eine vollständige Validierung je Sicherheitsfunktion dauert und wie oft ein Fehlerausschluss im Audit beanstandet wird — dazu liegen keine Daten vor. Sie werden hier nicht geschätzt und nicht aus anderen Mandaten übertragen. Belegt sind die Anforderungen, nicht ihre Häufigkeit. Die Einordnung stammt aus Engineering-Praxis im Maschinen- und Pumpenbau und ist keine Rechtsberatung und kein Validierungsnachweis.
• [5] Eigene Lehrtätigkeit: Online-Seminar bei DIN Media, „Neue Maschinenverordnung: Vom Regelwerk zur effizienten Engineering-Praxis“, Termine 2027. Behandelt die Einbindung der Nachweise in Produktstruktur und PDM-Systeme — also die Frage, wo Validierungsplan und Protokoll später wiederzufinden sind.