Die Maschinenverordnung (EU) 2023/1230 macht Software als Sicherheitsbauteil ausdrücklich zum Thema. Sie definiert ein Sicherheitsbauteil als physisches oder digitales Bauteil, einschließlich Software, und führt in Anhang II als eigene Position Software, die Sicherheitsfunktionen wahrnimmt. Für Maschinenbauer heißt das nicht, dass jedes Sicherheitsprogramm künftig von einer benannten Stelle geprüft werden muss. Es heißt aber, dass Spezifikation, Programmierung, Validierung und Änderungen der Sicherheitssoftware lückenlos nachvollziehbar sein müssen.
Software als Sicherheitsbauteil: was genau gemeint ist
Der Verordnungstext auf EUR-Lex unterscheidet zwei Fälle. Erstens Software, die Sicherheitsfunktionen wahrnimmt und gesondert in Verkehr gebracht wird, etwa als Bibliothek oder Funktionsbaustein für mehrere Maschinen. Zweitens Sicherheitsbauteile mit vollständig oder teilweise selbstentwickelndem Verhalten auf Basis von maschinellem Lernen. Nur diese zweite Gruppe steht in Anhang I Teil A und erfordert eine benannte Stelle.
| Fall | Einordnung | Konsequenz |
|---|---|---|
| Sicherheitsprogramm als Teil der Maschine | Teil der Maschine | Konformität über die Maschine |
| Sicherheitssoftware separat in Verkehr gebracht | Sicherheitsbauteil, Anhang II Nr. 18 | eigene Konformitätsbewertung |
| Sicherheitsbauteil mit maschinellem Lernen | Anhang I Teil A | benannte Stelle erforderlich |
Für die große Mehrheit der Maschinenbauer bleibt das Sicherheitsprogramm Teil der Maschine. Die Anforderungen an seine Qualität ergeben sich dann aus den grundlegenden Sicherheits- und Gesundheitsschutzanforderungen in Anhang III und aus den harmonisierten Normen, allen voran der DIN EN ISO 13849-1.
Was die DIN EN ISO 13849-1:2023 an Software verlangt
Die vierte Ausgabe der Norm ist 2023 erschienen. Eine DGUV-Information des IFA fasst die Neuerungen zusammen. Für die Softwareseite sind diese Punkte wichtig:
- Die Anforderungen an Software stehen jetzt in einem eigenen Abschnitt 7, ergänzt durch die Anhänge J und N.
- Für sicherheitsbezogene Anwendersoftware (SRASW) gilt ein zweistufiges V-Modell.
- Programmiersprachen nach IEC 61131-3 gelten als Sprachen mit eingeschränktem Sprachumfang (LVL).
- Anhang N ordnet die Maßnahmen zur Fehlervermeidung nach erforderlichem Performance Level.
- Die Validierung ist in Abschnitt 10 neu strukturiert.
- KI-spezifische Anforderungen enthält die Norm ausdrücklich nicht.
Laut DGUV gilt eine Übergangsfrist von drei Jahren. Wer heute neue Maschinen auslegt, sollte direkt nach der Ausgabe 2023 arbeiten.

Das V-Modell in der Praxis
Das V-Modell klingt nach Bürokratie, ist im Kern aber eine einfache Disziplin: Jede Anforderung bekommt einen Test, jeder Test verweist auf eine Anforderung. Für ein typisches Sicherheitsprogramm einer Verpackungsmaschine mit Schutztüren, Lichtgitter und Not-Halt sieht das so aus:
- Spezifikation der Sicherheitsfunktionen: Aus der Risikobeurteilung jede Funktion mit Auslöser, Reaktion, Reaktionszeit und erforderlichem Performance Level beschreiben.
- Softwarespezifikation: Festlegen, welche Bausteine die Funktion umsetzen, welche Signale beteiligt sind und wie Fehler erkannt werden.
- Programmierung: Zertifizierte Bausteine des Steuerungsherstellers verwenden, einfache Struktur, keine unnötige Logik im Sicherheitsprogramm.
- Codeprüfung: Vier-Augen-Prinzip, Abgleich mit der Spezifikation.
- Funktionstest: Jede Sicherheitsfunktion einzeln, einschließlich Fehlerfällen wie Querschluss oder Diskrepanz.
- Validierung: Nachweis an der Maschine, dass die Funktionen die Anforderungen erfüllen, mit Protokoll.
EN ISO 13849: SISTEMA SOFTEMA
Grollmus | TIA Portal & Automatisierung
Dieses Video wird von YouTube bereitgestellt. Beim Abspielen werden Inhalte von Google geladen, und es können Cookies gesetzt werden.
Auf YouTube ansehenWerkzeuge: SISTEMA und SOFTEMA
Das IFA stellt zwei kostenlose Werkzeuge bereit. SISTEMA berechnet den erreichten Performance Level der Hardwarearchitektur. Die Version 3.x unterstützt laut IFA die Ausgabe 2023 der Norm. SOFTEMA unterstützt die Projektierung und Dokumentation sicherheitsbezogener Anwendersoftware nach der IFA-Matrixmethode. Beide Werkzeuge ersetzen keine Fachkenntnis, sie strukturieren aber die Nachweise so, dass ein CE-Partner oder Prüfer sie nachvollziehen kann.
Wie viel Struktur das Sicherheitsprogramm braucht
Ein gutes Sicherheitsprogramm ist langweilig. Es enthält nur die Logik, die für die Sicherheitsfunktionen nötig ist, nutzt zertifizierte Bausteine des Steuerungsherstellers und ist so aufgebaut, dass jede Sicherheitsfunktion einem klar abgegrenzten Programmteil entspricht. Komfortfunktionen, Diagnosemeldungen und Verknüpfungen mit dem Standardprogramm gehören in den Standardteil, der Sicherheitsteil liefert nur Freigaben und Zustände.
In der Praxis sehen wir häufig das Gegenteil: Sicherheitsprogramme, in die über Jahre Betriebsartenlogik, Rückmeldungen für die Visualisierung und Sonderfälle für einzelne Kunden eingewandert sind. Jede dieser Ergänzungen erschwert die Validierung und erhöht das Risiko, dass eine Änderung unbeabsichtigte Folgen hat. Eine Migration oder eine neue Maschinengeneration ist die Gelegenheit, den Sicherheitsteil wieder auf das Wesentliche zu reduzieren.
Für Maschinenbauer mit vielen ähnlichen Maschinen lohnt sich zudem eine geprüfte Bibliothek von Sicherheitsbausteinen für wiederkehrende Funktionen wie Schutztürüberwachung oder Zweihandbedienung. Achten Sie darauf, dass eine solche Bibliothek versioniert ist und ihre Validierung dokumentiert. Wird sie getrennt von der Maschine an Dritte weitergegeben, kann sie selbst als Sicherheitsbauteil gelten.
Änderungen und Updates nach der Auslieferung
Die Maschinenverordnung verlangt, dass Eingriffe in die Sicherheitssoftware und hochgeladene Versionen nachvollziehbar sind. Für Ihre Serviceprozesse heißt das: Jede Änderung am Sicherheitsprogramm braucht eine Bewertung, ob sie sicherheitsrelevant ist, eine erneute Prüfung der betroffenen Funktionen und eine Dokumentation mit neuer Prüfsumme. Ein Servicetechniker, der beim Kunden schnell eine Zeit im Sicherheitsprogramm ändert, darf es nicht mehr geben, wenn er es je durfte.
Praktisch hilft ein einfaches Änderungsformular: Was wurde geändert, warum, welche Sicherheitsfunktionen sind betroffen, welche Tests wurden durchgeführt, wer hat freigegeben, welche Prüfsumme hat die neue Version. Fünf Minuten Dokumentation ersparen im Ernstfall lange Diskussionen.
Ein sauberer Update-Prozess ist zugleich eine Anforderung des Cyber Resilience Act. Wer beides gemeinsam aufbaut, spart doppelte Arbeit. Den Rahmen erklären die Beiträge Maschinenverordnung 2027 und Cyber Resilience Act im Maschinenbau.
Unsere Rolle
Wartens programmiert Sicherheitssoftware in TIA Portal und TwinCAT nach Ihrer Spezifikation, erstellt die Softwaredokumentation einschließlich Testspezifikation und unterstützt bei der Validierung. Die CE-Kennzeichnung und die Verantwortung für die Konformität der Maschine bleiben beim Hersteller und seinem CE-Partner, mit dem wir zusammenarbeiten. Mehr unter Automatisierungs-Engineering.
Nächster Schritt: Schicken Sie uns die Liste der Sicherheitsfunktionen einer Maschine. Wir zeigen, wie eine Dokumentation nach DIN EN ISO 13849-1:2023 dafür aussieht, und nennen Umfang und Festpreis. Kontakt.



