ISO 13849-1 · Validierung und FehlerausschlussGerechnet istnoch nicht nachgewiesen.
Die quantitativen Größen — MTTFd, DCavg, CCF — erfassen ausschließlich zufällige Hardware-Ausfälle. Konstruktions-, Spezifikations- und Softwarefehler kommen darin nicht vor; sie werden nicht errechnet, sondern durch Maßnahmen vermieden. Ein rechnerisch erreichtes PL e ist wertlos, wenn diese Maßnahmen fehlen. Die beiden Nachweise sind UND-verknüpft, nicht ODER.
Insight 13, Reihe B, Konformität und Dokumentation. Die Rechnung, um die es hier geht, steht auf Insight 11; der Weg, der zu ihr führt, im CE-Weg.
Der Maßstab ist die Spezifikation. Wer prüft, darf sie nicht gebaut haben.
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.
Zwei Begriffe, zwei Abschnitte, zwei verschiedene Fragen.
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.
Erst durchrechnen und durchsehen, dann prüfen und protokollieren.
„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.
Was vorher festzulegen und was nachher aufzuschreiben ist.
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 gerechnete Zahl ist die eine Hälfte.
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.
Wer einen Fehler nicht ansetzt, muss das begründen können.
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.
Die Sprachwahl entscheidet über den Aufwand.
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.
Unabhängigkeit, Plan und Fehlerausschluss.
Was ist der Unterschied zwischen Verifizierung und Validierung?
Die Verifizierung bestätigt, dass festgelegte Anforderungen erfüllt sind (3.1.53) — in der Praxis der Abgleich des erreichten Performance Levels gegen den geforderten, je Sicherheitsfunktion, nach Abschnitt 8. Die Validierung bestätigt, dass die Anforderungen für eine speziell beabsichtigte Verwendung erfüllt sind (3.1.54), und zwar durch Analyse und Prüfung nach Abschnitt 10. Rechnen ist Verifizieren; der Nachweis, dass das Gebaute der Spezifikation entspricht, ist Validieren.
Muss eine externe Stelle validieren?
Nein. Die Norm verlangt Unabhängigkeit vom Entwurf, nicht vom Unternehmen: Der Prozess „sollte von (einer) Person(en) durchgeführt werden, die vom Entwurf des SRP/CS unabhängig ist/sind“ (10.1.1), und Anmerkung 2 stellt klar, dass das „nicht unbedingt“ eine dritte Partei bedeutet. Es genügt eine Person, die am Entwurf nicht beteiligt war. Nicht genügt: derselbe Konstrukteur.
Was gehört in einen Validierungsplan?
Fünf Festlegungen nach 10.1.2: die Dokumente für die Spezifikationen; die Betriebs- und Umgebungsbedingungen während des Tests; die durchzuführenden Analysen und Tests; die Verweisung auf anzuwendende Prüfnormen; und für jeden Schritt die verantwortlichen Personen oder Parteien. Der Plan ist den Beteiligten verfügbar zu machen. Dazu kommen ein Prüfplan vor der Prüfung (10.4.1) und die Aufzeichnung danach (10.8).
Wann ist ein Fehlerausschluss zulässig?
Wenn er auf einer der drei Grundlagen aus 6.1.10.3 beruht, auf bekannten physikalischen Gesetzen begründbar ist, die Ausfallart spezifisch benennt, unter allen erwarteten Umgebungsbedingungen gilt und dokumentiert ist. Zwei Grenzen: Der PL e darf nicht allein auf Fehlerausschluss beruhen, und ein Ausschluss ersetzt keine Maßnahmen gegen systematische Ausfälle. Die anerkannten Ausschlüsse stehen in ISO 13849-2:2012, Anhang A bis D.
Welche Sprache darf ich für die Sicherheitslogik verwenden?
Beide Wege sind zulässig, sie kosten unterschiedlich viel. Mit eingeschränktem Sprachumfang (7.2.1) — Kontaktplan, Funktionsbausteinsprache, Ablaufsprache — läuft der Nachweis über das vereinfachte V-Modell nach Bild 14. Mit nicht eingeschränktem Sprachumfang (7.2.2) — C, C++, Java, Assembler — steigt der Aufwand erheblich. Die Entscheidung zwischen beiden regelt 7.2.3.
Wer hat bei Ihnen zuletzt unabhängig validiert?
In kleinen Teams ist das die Frage, die niemand gern stellt — und die im Audit als Erstes kommt. Dazu: wo der Validierungsplan und das Protokoll zu genau dieser Ausführung liegen. 30 Minuten, keine Präsentation.
30-Minuten-Gespräch vereinbaren →Belegt an Teil 1. Teil 2 lag nicht vor.
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.