PL ≥ PLr – nachgewiesen, validiert, dokumentiert.
Funktionale Sicherheit ist der Teil der Maschinensicherheit, der durch die Steuerung erreicht wird. Wenn eine Schutztür die Bewegung stoppt oder ein Laserscanner die Fahrt verlangsamt, muss diese Funktion mit nachgewiesener Zuverlässigkeit arbeiten – für jede Sicherheitsfunktion einzeln, rechnerisch belegt und durch Prüfung bestätigt.
Wir begleiten die gesamte Kette: von der Sicherheitsfunktion, die aus Ihrer Risikobeurteilung entsteht, bis zur unterschriebenen Validierungsaufzeichnung.
Die Nachweiskette in fünf Schritten
Jeder Schritt baut auf dem vorherigen auf – und die häufigste Ursache für unbrauchbare Nachweise liegt schon im ersten. Zu jedem Schritt finden Sie die fachlichen Einzelheiten auf der Detailseite.
Sicherheitsfunktion ableiten und PLr bestimmen
Aus Ihren Gefährdungssätzen entstehen benannte Sicherheitsfunktionen. Der erforderliche Performance Level wird über den Risikographen bestimmt – mit dokumentierter Begründung je Parameter, nicht per Gefühl. Vorrangige Typ-C-Normen prüfen wir mit.
Anforderungen spezifizieren
„Not-Halt vorhanden" ist keine Sicherheitsfunktion. Je Funktion werden Auslöseereignis, sicherer Zustand, Betriebsarten, Ansprechzeit, Verhalten im Fehlerfall und die Priorität bei konkurrierenden Funktionen festgelegt.
Architektur und Kennwerte
Bevor gerechnet wird, muss die Architektur stehen: Blockdiagramm je Funktion, Kanäle und Diagnosepfade zugeordnet. Dazu die Kennwerte – MTTFD, DC und CCF – belastbar recherchiert, umgerechnet und mit Quelle belegt.
Nachweis rechnen
Der Nutzen entsteht nicht durch das Werkzeug, sondern durch die korrekte Abbildung: Was ist ein Teilsystem, was ein Kanal, welcher Baustein trägt welchen DC? Wir modellieren die Funktionen vollständig in SISTEMA und kombinieren die Teilsysteme zum Gesamt-PL.
Validieren
Rechnen allein genügt nicht. Validierungsplan, Analyse, Prüfung an der realen Steuerung und Fehlersimulation führen zur Validierungsaufzeichnung – mit klarer Aussage je Sicherheitsfunktion, nicht mit einem Gefühl.
Was Sie am Ende in der Hand halten
Keine Präsentation, sondern die Unterlagen, die im Prüffall tragen und die Ihre Konstruktion weiterverwenden kann.
Spezifikation je Sicherheitsfunktion
Vollständige SRS in prüffähiger Tabellenform, abgestimmt auf Ihre Betriebsarten – die Grundlage, auf die sich später jede Prüfung bezieht.
Sicherheitsbezogene Blockdiagramme
Je Funktion, mit Kanälen, Testkanälen und Diagnosepfaden – und mit klarer Abgrenzung gegenüber zugekauften Baugruppen. Nach EN ISO 13849-2 Pflichtbestandteil der Validierungsunterlagen.
SISTEMA-Projektdatei
Übergabefähig, mit Herstellerbibliotheken. Sie können damit selbst weiterarbeiten, wenn sich später ein Bauteil oder eine Schaltung ändert – ohne uns erneut beauftragen zu müssen.
Validierungsaufzeichnung
Mit Validierungsplan, Analyse- und Prüfprotokollen, Fehlerlisten und begründeten Ausschlüssen – und der eindeutigen Aussage „PL ≥ PLr erfüllt" oder „nicht erfüllt", je Sicherheitsfunktion.
Drei typische Ausgangslagen
Sie müssen nicht am Anfang der Kette stehen, um mit uns zu arbeiten.
Neues Projekt
Die Maschine entsteht gerade, die Risikobeurteilung liegt vor. Dann führen wir die Kette von Anfang an – das ist der günstigste Zeitpunkt, weil nichts nachträglich umgebaut werden muss.
Nachweis vorhanden, Vertrauen fehlt
Es gibt Berechnungen, aber niemand weiß, ob sie einer Prüfung standhalten. Wir bewerten vorhandene Nachweise gegen EN ISO 13849-1 und -2, benennen die Lücken nach Schweregrad und liefern eine priorisierte Empfehlung.
Software ist beteiligt
Sobald Software eine Sicherheitsfunktion ausführt, gilt zusätzlich der Software-Sicherheitslebenszyklus. „Normale" Steuerungssoftware erfüllt das in aller Regel nicht – und Nachrüsten ist teurer als eine saubere Trennung von Anfang an.
Validierung durch jemanden, der nicht selbst konstruiert hat
EN ISO 13849-2 fordert in Abschnitt 4.1, dass die Validierung von Personen durchgeführt wird, die nicht an der Gestaltung der sicherheitsbezogenen Steuerungsteile beteiligt waren. Genau daran scheitert es im Alltag oft, weil im eigenen Haus dieselben Personen konstruieren und prüfen.
„Unabhängig" bedeutet dabei nicht zwingend „Dritte" – es bedeutet: nicht dieselbe Person, die gestaltet hat. Wir übernehmen diese Rolle, ohne dass Sie dafür interne Kapazitäten aufbauen oder ein Zertifizierungsverfahren anstoßen müssen.
Wer das bei uns macht
Benjamin Fidelak
Referent und Experte für Funktionale Sicherheit – Erfahrener Referent und Experte für Risikobeurteilung, Funktionale Sicherheit und Beratung zur CE-Kennzeichnung. Er hält auch unser zweitägiges Inhouse-Seminar zu EN ISO 13849-1 und führt die Nachweiskette in Ihren Projekten – von der PLr-Bestimmung über die SISTEMA-Modellierung bis zur Validierungsaufzeichnung.
Matthias Schulz
Lead-Experte und Geschäftsführer – Seit 1990 als Berater, Referent und Fachautor für Risikobeurteilung, CE-Kennzeichnung und normgerechte Sicherheitsinformationen tätig. Aktiv im Expertenforum der tekom, im VDI Stuttgart und an der TAE Esslingen; langjährige Lehrtätigkeit an Hochschulen sowie Fachbuchautor. Er ordnet die normative Entwicklung ein – etwa die Software-Anforderungen nach IEC 61508 und EN ISO 13849-1 oder deren Verschärfung durch die Maschinenverordnung. Sein Fachbeitrag dazu, warum bestehende Steuerungssoftware oft nicht wiederverwendbar ist →
Häufige Fragen
Können wir unsere bestehende Steuerungssoftware für Sicherheitsfunktionen weiterverwenden?
In den meisten Fällen nicht ohne Weiteres. Software für Sicherheitsfunktionen muss nach IEC 61508-3 bzw. ISO 13849-1 entwickelt werden – mit eigenem V-Modell, empfohlener Programmiersprache MISRA C und formaler Verifikation. Normale Steuerungssoftware erfüllt diese Anforderungen in aller Regel nicht.
Was verlangt EN ISO 13849-1 von der Anwendungssoftware?
Kapitel 7 der EN ISO 13849-1:2023 fordert, dass die Anwendungssoftware nachvollziehbar spezifiziert, programmiert und validiert wird – lesbar, verständlich, testfähig und wartungsfreundlich, auch wenn zertifizierte Softwarebausteine des Steuerungsherstellers zum Einsatz kommen.
Was ändert sich durch die neue Maschinenverordnung?
Sicherheitsfunktionen müssen vom Betreiber testbar sein, Software mit Sicherheitsfunktionalität muss an der Steuerung erkennbar gemacht werden können, und der Quellcode sicherheitsbezogener Software muss Marktaufsichtsbehörden auf Verlangen zugänglich sein.
Wie hängt Funktionale Sicherheit mit der Risikobeurteilung zusammen?
Die Risikobeurteilung identifiziert die notwendigen Schutzmaßnahmen; sind darunter sicherheitsbezogene Steuerungsfunktionen, greift für deren Entwicklung und Nachweis die funktionale Sicherheit nach IEC 61508 bzw. ISO 13849-1.
Weitere Fragen zu PLr, Verifizierung, Validierung und SISTEMA →
Nächster Schritt
Senden Sie uns Risikobeurteilung und Schaltplan – wir melden uns mit einer Ersteinschätzung zum Aufwand. Wenn die Risikobeurteilung noch nicht die Angaben enthält, die die Norm verlangt, sagen wir Ihnen das offen und schauen zuerst dorthin.