Sicherheitsgerichtete Steuerung: Normen, PL und CE-Praxis

In vielen Maschinenbauprojekten wird die sicherheitsgerichtete Steuerung erst dann kritisch, wenn die Maschine bereits weitgehend konstruiert ist. Die Standard-SPS läuft, die Sensoren sind ausgewählt, und kurz vor der CE-Dokumentation stellt jemand die Frage, ob die Schutztürüberwachung wirklich den erforderlichen Performance Level erreicht. Zu diesem Zeitpunkt lassen sich Architektur, Verdrahtung und Software oft nur noch mit erheblichem Aufwand ändern.

Die richtige Reihenfolge ist umgekehrt. Die Risikobeurteilung nach EN ISO 12100 bestimmt, welche Sicherheitsfunktionen erforderlich sind. Daraus leitet der Konstrukteur den erforderlichen Performance Level, kurz PLr, ab. Erst danach werden Struktur, Komponenten, Software und Validierung festgelegt. Für bestehende Maschinen kommt eine weitere Frage hinzu: Wie wird eine Dokumentation, die auf der Fassung von 2016 beruht, sauber auf die DIN EN ISO 13849-1:2023 und auf die bevorstehende Maschinenverordnung (EU) 2023/1230 ausgerichtet?

Dieser Beitrag ordnet die sicherheitsgerichtete Steuerung aus Sicht der CE-Praxis ein. Die Inhalte sind allgemeine Information und ersetzen keine rechtsverbindliche Beratung im Einzelfall. Die Verantwortung für die Konformitätserklärung und die Konformität der Maschine bleibt beim Hersteller.

Inhaltsverzeichnis

• Was eine sicherheitsgerichtete Steuerung leistet
  • Die Risikobeurteilung entscheidet
• Rechtsgrundlagen und normative Einordnung
  • Welche Normengruppe greift
  • Anhang IV und der Übergang 2027
• Performance Level und SIL richtig bestimmen
  • Kategorie und erreichten PL auseinanderhalten
  • SIL ist nicht einfach eine andere Schreibweise
• Typische Architekturen und Komponenten
  • Drei Architekturen im Vergleich
  • Komponenten als Wirkungskette bewerten
• Retrofit, Cybersecurity und neue Anforderungen
  • Was bei der Migration geprüft werden muss
  • Safety und Security gemeinsam betrachten
• Design- und Validierungsschritte in der Praxis
  • Von der Gefährdung zur Sicherheitsfunktion
  • Nachweise, die in die technische Dokumentation gehören
• Häufige Fehler und Checkliste für CE-Konformität
  • Die häufigsten Schwachstellen
  • Projektcheckliste

<a id="was-eine-sicherheitsgerichtete-steuerung-leistet"></a>

Was eine sicherheitsgerichtete Steuerung leistet

Eine sicherheitsgerichtete Steuerung verarbeitet Signale und Befehle so, dass eine definierte Sicherheitsfunktion bei einem gefährlichen Zustand zuverlässig ausgelöst wird. Sie ist Teil der sicherheitsbezogenen Teile einer Steuerung, häufig als SRP/CS bezeichnet. Dazu gehören nicht nur die Logik, sondern die gesamte Wirkungskette aus Sensorik, Auswertung und Aktorik.

Die Standard-SPS kann beispielsweise einen Produktionsablauf steuern, Achsen positionieren oder Meldungen ausgeben. Sie darf aber nicht automatisch als geeignete Sicherheitssteuerung gelten. Entscheidend ist, ob die komplette Funktion sicherheitsgerichtet ausgelegt, bewertet und validiert wurde.

Typische Sicherheitsfunktionen sind:

• Not-Halt: Die Maschine wird bei Betätigung in einen sicheren Zustand überführt.
• Schutztürüberwachung: Das Öffnen einer Schutztür verhindert einen gefährlichen Anlauf oder beendet eine gefährliche Bewegung.
• Zweihandbedienung: Die Bedienperson muss zwei Stellteile in einer vorgegebenen Weise betätigen, damit der Arbeitszyklus startet.
• Sichere Bewegungsüberwachung: Drehzahl, Position, Stillstand oder Bewegungsrichtung werden überwacht, wenn eine Gefährdung davon abhängt.

<a id="die-risikobeurteilung-entscheidet"></a>

Die Risikobeurteilung entscheidet

Eine sicherheitsgerichtete Steuerung ist keine pauschale Pflicht für jede Maschine und auch kein Ersatz für eine sichere Konstruktion. Zuerst muss der Hersteller die Gefährdungen identifizieren und nach EN ISO 12100 bewerten. Dabei zählt die konkrete Maschine mit ihren Betriebsarten, Zugängen, Werkzeugen, Materialien, erwartbaren Fehlbedienungen und Wartungssituationen.

Ein Sondermaschinenbauer kann eine Quetschstelle möglicherweise durch eine konstruktive Änderung vermeiden. Wenn sich ein gefährlicher Bereich dadurch vollständig beseitigen lässt, ist diese inhärent sichere Konstruktion der technischen Schutzmaßnahme vorzuziehen. Bleibt die Gefährdung bestehen, kommen trennende Schutzeinrichtungen, verriegelte Zugänge oder eine sicherheitsgerichtete Abschaltung hinzu.

Praktische Regel: Die Sicherheitsfunktion muss aus der Gefährdung entstehen, nicht aus dem verfügbaren Steuerungsmodul.

Für Konstruktionsleiter bedeutet das, die Sicherheitsfunktionen früh als eigene Anforderungen zu spezifizieren. Eine einfache Liste mit „Not-Halt vorhanden“ genügt nicht. Zu dokumentieren sind unter anderem der gefährliche Zustand, der Auslöser, der sichere Zustand, die Reaktionsbedingungen, die Rückstelllogik und die erforderliche Performance. Genau diese Angaben bilden später die Verbindung zwischen Risikobeurteilung, Schaltplan, Software und Validierungsprotokoll.

<a id="rechtsgrundlagen-und-normative-einordnung"></a>

Rechtsgrundlagen und normative Einordnung

Für Maschinen in Deutschland ist zunächst zwischen dem geltenden Rechtsrahmen und der kommenden Rechtslage zu unterscheiden. Die Maschinenrichtlinie 2006/42/EG bleibt bis zum 19. Januar 2027 der relevante Rahmen. Ab dem 20. Januar 2027 gilt die Maschinenverordnung (EU) 2023/1230 verbindlich und ersetzt die Maschinenrichtlinie, wie die Veröffentlichung der Maschinenverordnung im EUR-Lex festlegt.

Die Richtlinie gilt in der EU und damit auch in Deutschland seit dem 29. Dezember 2009 für die entsprechenden Anforderungen an die funktionale Sicherheit. Die DGUV und das IFA ordnen die DIN EN ISO 13849-1 als wichtige Grundlage für die Bewertung komplexer Maschinensteuerungen ein. Mit dieser normativen Entwicklung wurde der frühere Begriff der Steuerungskategorie um den Performance Level ergänzt, wie die IFA-Systematik zur Sicherheit von Maschinensteuerungen beschreibt.

<a id="welche-normengruppe-greift"></a>

Welche Normengruppe greift

A-Normen beschreiben grundlegende Sicherheitsprinzipien. Die EN ISO 12100 liefert den methodischen Rahmen für Risikobeurteilung und Risikominderung. B-Normen behandeln Sicherheitsaspekte oder Schutzeinrichtungen, die für viele Maschinenarten relevant sind. Dazu zählen die funktionale Sicherheit nach EN ISO 13849-1 und die sicherheitsbezogene elektrische Steuerungstechnik nach EN 62061.

C-Normen gelten für bestimmte Maschinengattungen und können konkrete Anforderungen an Sicherheitsfunktionen, Abstände, Betriebsarten oder Schutzmaßnahmen enthalten. Wenn eine einschlägige C-Norm existiert, muss der Hersteller prüfen, welche Vorgaben sie für die konkrete Maschine macht. Die A-, B- und C-Normen stehen nicht in einem einfachen Rangverhältnis, sondern müssen im Zusammenhang mit der Maschine und ihrer Gefährdung betrachtet werden.

Die Anwendung einer harmonisierten Norm kann eine Konformitätsvermutung unterstützen. Sie ersetzt jedoch weder die Risikobeurteilung noch die Prüfung, ob die Norm die konkrete Maschine vollständig abdeckt. Für die praktische Normenrecherche kann neben den einschlägigen Sicherheitsnormen auch die Einordnung der DIN EN 61508 hilfreich sein, insbesondere wenn Komponenten oder Systeme aus der allgemeinen funktionalen Sicherheit betrachtet werden.

<a id="anhang-iv-und-der-ubergang-2027"></a>

Anhang IV und der Übergang 2027

Für Maschinen aus Anhang IV der Maschinenrichtlinie unterscheidet Artikel 12 mehrere Konformitätsbewertungspfade. Bei vollständiger Anwendung harmonisierter Normen kann unter den dort genannten Voraussetzungen eine interne Fertigungskontrolle vorgesehen sein. Werden Normen nicht oder nur teilweise angewendet, oder gibt es keine passende Norm, gelten andere Verfahren. Für den dritten Fall sieht die Richtlinie die Einbindung einer benannten Stelle vor, wie die Darstellung der Verfahren nach Artikel 12 der Maschinenrichtlinie zeigt.

Mit der Maschinenverordnung verschiebt sich die Zuordnung in den Anhang I. Das ist keine redaktionelle Nebensache. Hersteller müssen prüfen, ob die Maschine unter die dort beschriebenen Kategorien fällt und welches Konformitätsbewertungsverfahren daraus folgt. Die Normenauswahl beeinflusst damit unmittelbar die Nachweise, die technische Dokumentation und gegebenenfalls die Beteiligung einer benannten Stelle.

<a id="performance-level-und-sil-richtig-bestimmen"></a>

Performance Level und SIL richtig bestimmen

Der PLr ist der erforderliche Performance Level einer Sicherheitsfunktion. Er beschreibt nicht das Ergebnis der Konstruktion, sondern den Sollwert, den die gewählte Lösung mindestens erreichen muss. Die Ableitung beginnt bei der Risikobeurteilung und nicht bei der Auswahl eines Sicherheitsrelais.

Nach EN ISO 13849-1 wird der PLr typischerweise über die Parameter S, F und P bestimmt:

• S, Schwere der Verletzung: Wie schwer kann die mögliche Verletzung ausfallen?
• F, Häufigkeit und Dauer: Wie oft und wie lange ist eine Person der Gefährdung ausgesetzt?
• P, Möglichkeit der Vermeidung: Kann die Person die Gefährdung erkennen und rechtzeitig entkommen?

Der Risikograph führt aus diesen Eingangsgrößen zu einem erforderlichen Zielwert. Die Begründung muss zur konkreten Betriebsweise passen. Eine seltene Wartungssituation kann anders zu bewerten sein als ein wiederkehrender manueller Eingriff in einen automatisierten Arbeitszyklus.

<a id="kategorie-und-erreichten-pl-auseinanderhalten"></a>

Kategorie und erreichten PL auseinanderhalten

EN ISO 13849-1 arbeitet mit den fünf Strukturkategorien B, 1, 2, 3 und 4. Sie unterscheiden sich insbesondere hinsichtlich Redundanz, Diagnose und Fehlerbeherrschung. Eine höhere Kategorie allein garantiert aber keinen bestimmten Performance Level. Zusätzlich zählen unter anderem die Zuverlässigkeit der Komponenten, die Diagnosedeckung und die systematische Qualität der Entwicklung.

Die Übersicht zu EN ISO 13849-1 und SISTEMA ordnet die Kategorien und den Abgleich zwischen PLr und erreichtem PL praxisbezogen ein.

Die Tabelle ist keine automatische Zuordnung. Ein konkreter PLr kann je nach Risikograph und Maschinenfunktion zu unterschiedlichen Architekturen führen. Die gewählte Kategorie muss zusammen mit MTTFd, DC und den Anforderungen an systematische Fehler bewertet werden.

<a id="sil-ist-nicht-einfach-eine-andere-schreibweise"></a>

SIL ist nicht einfach eine andere Schreibweise

SIL gehört zur Systematik der EN 62061. In Ausschreibungen und Lieferantengesprächen werden PL und SIL häufig nebeneinander genannt, obwohl sie nicht ohne weitere Bewertung gleichgesetzt werden dürfen. Der Hersteller muss festlegen, nach welcher Norm die Sicherheitsfunktion bewertet wird und wie Komponentenangaben in das gewählte Verfahren passen.

Für die Berechnung nach EN ISO 13849-1 wird in der Praxis häufig SISTEMA eingesetzt. Das Tool dokumentiert die Teilfunktionen, Komponentenkennwerte und die erreichte Architektur. Entscheidend bleibt die fachliche Eingabe. SISTEMA kann keine falsche Risikobeurteilung korrigieren und keine unvollständige Sicherheitsfunktion erkennen, wenn der Anwender die Struktur falsch modelliert.

<a id="typische-architekturen-und-komponenten"></a>

Typische Architekturen und Komponenten

Die wirtschaftlich sinnvolle Architektur hängt vom erforderlichen PLr, von der Anzahl der Sicherheitsfunktionen, der räumlichen Verteilung und der Diagnoseanforderung ab. Ein einkanaliges System kann für eine überschaubare Funktion angemessen sein. Für anspruchsvollere Funktionen reicht ein einzelner Signalweg jedoch nicht aus, weil ein einzelner Fehler die Schutzwirkung aufheben kann.

<a id="drei-architekturen-im-vergleich"></a>

Drei Architekturen im Vergleich

Einkanalige Architektur: Ein Sensor, eine Auswertelogik und ein Abschaltpfad bilden die Sicherheitsfunktion. Diese Lösung ist einfach zu verdrahten und kann bei niedrigerem PLr sinnvoll sein. Ihr Nachteil liegt in der begrenzten Fehlerbeherrschung und in der geringeren Diagnosefähigkeit.

Redundante Architektur mit Diagnose: Zwei Kanäle überwachen die Sicherheitsfunktion, während die Steuerung bestimmte Fehler erkennt. Diese Struktur passt häufig zu Anforderungen im Bereich von PL d, sofern Komponentendaten, Diagnose und Testabstände die Berechnung tragen.

Redundante und testierte Architektur: Für hohe Anforderungen bis PL e braucht die Lösung eine konsequente Redundanz, wirksame Diagnose und eine Architektur, die gefährliche Einzelfehler beherrscht. Die technische Komplexität steigt, ebenso der Aufwand für Verifikation, Validierung und Wartungsnachweise.

Die Auswahl relevanter Normen für den Schaltschrankbau unterstützt die Einordnung der elektrischen Komponenten, ersetzt aber nicht die Sicherheitsfunktionsspezifikation.

<a id="komponenten-als-wirkungskette-bewerten"></a>

Komponenten als Wirkungskette bewerten

Typische Bausteine einer sicherheitsgerichteten Steuerung sind:

• Sichere Eingänge: Sie werten Not-Halt-Taster, Türschalter, Lichtgitter oder Zweihandgeräte aus.
• F-PLC oder Sicherheitsmodul: Diese Komponente verarbeitet die Sicherheitslogik und führt Diagnosefunktionen aus.
• Sichere Ausgänge: Sie schalten Schütze, Ventile oder Freigaben für Antriebe.
• Sichere Antriebsregler: Funktionen wie STO, SS1 oder SS2 können den sicheren Zustand eines Antriebs unterstützen.
• Positions- und Drehzahlsensorik: Sie liefert sichere Informationen für Bewegungsüberwachung und Stillstandserkennung.

Die Diagnose muss zur tatsächlichen Fehlerart passen. Ein Eingang, der einen Drahtbruch erkennt, entdeckt nicht automatisch jeden Fehler in der angeschlossenen Mechanik. Ebenso kann ein sicherer Antriebsregler seine Funktion nur dann wirksam erfüllen, wenn die Freigaben, Rückmeldungen und Abschaltpfade korrekt integriert sind.

Dezentral verteilte Sicherheitsmodule verkürzen bei großen Maschinen oft die Verdrahtung und erleichtern die Nähe zur Sensorik. Eine zentrale F-SPS bietet dagegen eine einheitliche Logik, kann bei vielen Sicherheitsfunktionen übersichtlicher sein und vereinfacht in manchen Projekten die Verwaltung der Software. Die Entscheidung sollte anhand von Diagnosekonzept, Reaktionszeiten, Erweiterbarkeit, Servicezugang und Validierungsaufwand getroffen werden, nicht allein anhand des Einkaufspreises.

<a id="retrofit-cybersecurity-und-neue-anforderungen"></a>

Retrofit, Cybersecurity und neue Anforderungen

Bei Retrofit-Projekten wird die funktionale Sicherheit häufig auf den Austausch einzelner Hardwarekomponenten reduziert. Das ist riskant. Sobald ein sicherheitsrelevanter Sensor, ein Antriebsregler, eine F-PLC oder das Anwenderprogramm geändert wird, muss der Hersteller oder Betreiber bewerten, welche Sicherheitsfunktionen und Nachweise betroffen sind.

Die DIN EN ISO 13849-1:2023 ersetzt die Vorgängerversion. Der frühere Stand bleibt für die Konformitätsvermutung jedoch noch bis zum 15. Mai 2027 anwendbar, wie die Normeninformation zur DIN EN ISO 13849-1 ausweist. Diese Übergangsphase bedeutet nicht, dass jede Altanlage automatisch vollständig neu dokumentiert werden muss. Sie verlangt aber eine belastbare Entscheidung, welche Änderung vorliegt und welche Auswirkungen sie auf die Sicherheit hat.

<a id="was-bei-der-migration-gepruft-werden-muss"></a>

Was bei der Migration geprüft werden muss

Eine belastbare Retrofit-Bewertung trennt mindestens drei Ebenen:

1. Technische Funktion: Hat sich die Sicherheitsfunktion, der sichere Zustand oder die Reaktionszeit verändert?
2. Sicherheitsgerichtetes Anwenderprogramm: Wurden Logik, Diagnose, Parameter, Firmware oder Kommunikationsbeziehungen geändert?
3. Technische Dokumentation: Stimmen Schaltpläne, Softwarebeschreibung, Berechnung, Validierungsprotokolle und Betriebsanleitung noch mit der Maschine überein?

Die alte PL-Berechnung einfach in eine neue Projektdatei zu kopieren, funktioniert nicht als Migrationsstrategie. Umgekehrt muss nicht jede unveränderte Seite der technischen Dokumentation ohne Anlass neu erstellt werden. Entscheidend sind Änderungsumfang, Risikowirkung und Nachweisführung. Der Hersteller sollte die Entscheidung mit Änderungsbeschreibung, betroffenen Sicherheitsfunktionen, aktueller Normenbasis und erneuter Validierung dokumentieren.

<a id="safety-und-security-gemeinsam-betrachten"></a>

Safety und Security gemeinsam betrachten

Vernetzte Steuerungen bringen zusätzliche Angriffspunkte in die Risikobeurteilung. Unbefugte Eingriffe, manipulierte Parameter, Firmware-Änderungen oder kompromittierte Kommunikationsverbindungen können eine Sicherheitsfunktion beeinträchtigen, auch wenn die Hardware ursprünglich korrekt nach PL ausgelegt wurde.

Ein deutscher Fachbeitrag zur überarbeiteten und korrigierten TRBS 1111 verweist darauf, dass Cybersicherheit ausdrücklich in die Gefährdungsbeurteilung einbezogen wird und TRBS 1115 für sicherheitsgerichtete Steuerungen heranzuziehen ist. Die Einordnung der neuen Sicherheitsregeln für deutsche Betriebe zeigt, warum Security-Maßnahmen nicht mehr isoliert von Safety geplant werden sollten.

In der Praxis gehören deshalb auch Rollen- und Berechtigungskonzepte, kontrollierte Firmware-Updates, Versionsnachweise, Wiederanlaufverhalten und die Reaktion auf Kommunikationsausfälle in die Betrachtung. Funktionale Sicherheit schützt vor zufälligen und systematischen Fehlern innerhalb des betrachteten Designs. Sie beantwortet nicht automatisch die Frage, was bei einem absichtlichen unbefugten Eingriff geschieht.

<a id="design-und-validierungsschritte-in-der-praxis"></a>

Design- und Validierungsschritte in der Praxis

Eine sichere und verlässliche Sicherheitssteuerung entsteht nicht durch die bloße Kombination zertifizierter Komponenten. Der Hersteller braucht einen nachvollziehbaren Entwicklungsprozess, der Anforderungen, Entwurf, Implementierung und Nachweis miteinander verbindet.

<a id="von-der-gefahrdung-zur-sicherheitsfunktion"></a>

Von der Gefährdung zur Sicherheitsfunktion

Der Prozess beginnt mit der Risikobeurteilung. Für jede relevante Gefährdung wird eine Sicherheitsfunktion formuliert, beispielsweise: „Beim Öffnen der Schutztür darf keine gefährliche Bewegung fortgesetzt werden.“ Die Spezifikation muss anschließend die Eingangsbedingungen, die Logik, den sicheren Zustand, die Rückstellung, die Diagnose und den erforderlichen PLr enthalten.

Darauf folgt der Entwurf der Architektur. Der Konstrukteur wählt Sensoren, sichere Eingänge, Logik, Ausgänge und Aktorik aus. Dabei müssen Herstellerdaten, MTTFd, Diagnosekennwerte, Ausschlüsse und Umgebungsbedingungen zusammenpassen. Ein einzelnes Datenblatt beweist noch nicht, dass die gesamte Kette den erforderlichen PL erreicht.

Die sicherheitsbezogene Software braucht denselben strukturierten Umgang wie die Hardware. Die DGUV/IFA beschreibt, dass DIN EN ISO 13849 und EN 62061 Anforderungen an die Softwareentwicklung von Sicherheitsfunktionen definieren und einen Entwicklungsprozess im V-Modell verlangen. Dieser Ansatz hilft, gefährliche systematische Fehler durch getrennte Spezifikation, Implementierung, Verifikation und Validierung zu vermeiden, wie die DGUV-Hinweise zu Steuerungen und Sicherheitskomponenten erläutern.

<a id="nachweise-die-in-die-technische-dokumentation-gehoren"></a>

Nachweise, die in die technische Dokumentation gehören

Für die technische Akte sollten mindestens folgende Unterlagen zusammengeführt werden:

• Sicherheitsfunktionsliste: Eindeutige Beschreibung von Auslöser, sicherem Zustand und Rückstellung.
• PL-Berechnung: SISTEMA-Projekt oder SISTEMA-Report mit nachvollziehbaren Eingaben.
• Schaltpläne: Vollständige Darstellung der sicherheitsbezogenen Signal- und Energiepfade.
• Softwarebeschreibung: Struktur, Bausteine, Parameter, Diagnose, Version und Änderungsstand.
• Verifikationsnachweise: Prüfung einzelner Anforderungen und Implementierungsdetails.
• Validierungsprotokolle: Tests unter realistischen Betriebsarten, einschließlich Fehler- und Diagnoseverhalten.
• Betriebsanleitung: Sicherheitsinformationen, Restrisiken, Prüfungen, Rückstellung und Wartung.

Die Validierung muss den realen Ablauf prüfen. Dazu gehören nicht nur das Auslösen eines Not-Halts, sondern auch verschweißte Kontakte, Leitungsunterbrechungen, fehlerhafte Rückmeldungen, unerwartete Wiederanläufe und Kommunikationsausfälle, soweit diese für die konkrete Funktion relevant sind. Ein bestandener Funktionstest ohne dokumentierte Randbedingungen ist als Nachweis zu schwach.

<a id="haufige-fehler-und-checkliste-fur-ce-konformitat"></a>

Häufige Fehler und Checkliste für CE-Konformität

Die meisten Probleme entstehen nicht durch fehlende Sicherheitskomponenten, sondern durch Lücken zwischen Risikobeurteilung, Konstruktion und Dokumentation. Typische Fehler sind eine unvollständige Gefährdungsanalyse, ein pauschal angenommener PLr oder eine Kategorie, die ohne Nachweis ausgewählt wurde.

<a id="die-haufigsten-schwachstellen"></a>

Die häufigsten Schwachstellen

• Risikobeurteilung: Sicherheitsfunktionen fehlen, weil Betriebsarten oder Instandhaltung nicht betrachtet wurden.
• PLr-Zuordnung: Der erforderliche Zielwert wurde aus einer Vorlage übernommen, statt ihn aus S, F und P abzuleiten.
• Diagnose: Die angenommene Diagnosedeckung wurde nicht durch Architektur und Test nachgewiesen.
• Normenstand: Konformitätserklärung, Berechnung und technische Akte verwenden unterschiedliche Ausgabestände.
• Software: Anwenderprogramm, Parameter und Firmware sind nicht versioniert oder nicht validiert.
• Retrofit: Änderungen an Hardware oder Logik wurden nicht auf ihre Auswirkungen auf die gesamte Sicherheitsfunktion geprüft.

<a id="projektcheckliste"></a>

Projektcheckliste

1. Normenbasis und Maschinenkategorie festlegen.
2. Gefährdungen und Betriebsarten nach EN ISO 12100 bewerten.
3. Jede Sicherheitsfunktion mit sicherem Zustand und PLr beschreiben.
4. Architektur und Komponenten begründen.
5. PL-Berechnung mit SISTEMA oder einem gleichwertig nachvollziehbaren Verfahren erstellen.
6. Softwareanforderungen, Version und Änderungsstand dokumentieren.
7. Diagnose- und Fehlerreaktionen prüfen.
8. Validierung für alle relevanten Betriebsarten protokollieren.
9. Betriebsanleitung und technische Dokumentation aktualisieren.
10. Konformitätsbewertungsverfahren nach Maschinenrichtlinie oder Maschinenverordnung prüfen.
11. Übergangs- und Normenstände bis zum Wechsel zur Maschinenverordnung am 20. Januar 2027 überwachen.
12. Konformitätserklärung erst nach Abschluss der Nachweise freigeben.

Für die Dokumentationserstellung, die Pflege von Normenständen und die Vorbereitung auf die Maschinenverordnung kann CE-Copilot Sicherheitsfunktionen erfassen, den PLr nach EN ISO 13849-1 dokumentieren, SISTEMA-Ergebnisse gegen den PLr plausibilisieren und technische Dokumentation, Betriebsanleitung sowie Konformitätserklärung in einem geführten Workflow vorbereiten. Das Werkzeug nimmt dem Hersteller die fachliche Verantwortung und die abschließende Bewertung nicht ab.

---

Wenn Sie Ihre Sicherheitsfunktionen, PLr-Nachweise und Retrofit-Dokumentation strukturiert zusammenführen möchten, können Sie CE-Copilot für die geführte CE-Dokumentation und die Vorbereitung auf die Maschinenverordnung nutzen. Prüfen Sie Ihr konkretes Projekt anschließend fachlich, insbesondere bei Änderungen an Sicherheitssoftware, Antrieben und vernetzten Steuerungen.