Warum fehlersichere Software für die CE-Kennzeichnung unverzichtbar ist
Fehlersichere Software ist ein zentraler Bestandteil der Maschinensicherheit. In diesem Beitrag zeige ich, wie Hersteller normgerecht und prüfbar sichere Softwarelösungen entwickeln können und welche fatalen Folgen Fehler in der Software haben können.
Ihr Experte für die CE-Kennzeichnung von Maschinen und Produktionsanlagen.
"Gerne können wir Sie bei der CE-Kennzeichnung Ihrer Maschine oder Produktionsanlage unterstützen."
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen1. Softwarefehler als unterschätztes Risiko in der Maschinenwelt
Fehlerfreie Software gibt es nicht, das ist leider die Realität. Selbst einfache Programme enthalten durchschnittlich etwa 25 Fehler pro 1.000 Codezeilen. Bei gut getesteter Software sinkt diese Quote auf etwa zwei bis drei Fehler, bei intensiv kontrollierter Software, wie jene der NASA, auf weniger als einen Fehler pro 10.000 Zeilen.
Zur Einordnung: Ein Smartphone enthält rund 200.000 Programmzeilen, statistisch also etwa 600 Fehler. Ein PC-Betriebssystem mit etwa 27 Millionen Zeilen bringt es auf mehr als 50.000 Fehler. Auch Verteidigungssysteme oder industrielle Steuerungen sind mit potenziell fatalen Folgen betroffen.
1.1 Beispiele für reale Softwarefehler mit katastrophalen Folgen
Beispiel 1: Beinahe-Atomkrieg durch Softwarefehler im sowjetischen Frühwarnsystem
1983 registrierte das sowjetische Frühwarnsystem den Start von fünf US-Raketen. Die Auslösung des Großalarms wurde nur durch die Einschätzung eines einzelnen Menschen verhindert, der die Situation besonnen beurteilte. Später stellte sich heraus, dass es sich um eine fehlerhafte Interpretation von Sonnenreflexionen handelte. Dieser Vorfall zeigt, wie gefährlich Softwarefehler sein können, nicht nur technisch, sondern auch geopolitisch.
Quelle: Wikipedia – Nuklear-Fehlalarm von 1983
https://de.wikipedia.org/wiki/Nuklear-Fehlalarm_von_1983
Beispiel 2: Ariane 5: Selbstzerstörung durch wiederverwendete Software
Beim Erstflug der Ariane 5 im Jahr 1996 wurde Software aus dem Vorgängermodell Ariane 4 übernommen, ohne die geänderten Flugbedingungen zu berücksichtigen. Die Rakete zerstörte sich 37 Sekunden nach dem Start selbst. Ursache war ein Gleitkomma-Überlauf in einem Konvertierungsprozess, ausgelöst durch die höheren Beschleunigungen der neuen Trägerrakete.
Quelle: ESA – Ariane 501 Inquiry Board Reporthttps://esamultimedia.esa.int/docs/esa-x-1819eng.pdf
Beispiel 3: Therac-25: Tödliche Fehlbestrahlung durch Race Condition
Die Bestrahlungsmaschine Therac-25 verursachte in den 1980er Jahren mehrere Todesfälle. Bediener konnten Eingaben schneller vornehmen, als die Software verarbeiten konnte. Es kam zu inkonsistenten Zuständen (Race Conditions), die zu unkontrollierten Bestrahlungen mit tödlicher Dosis führten. Die Fehler blieben lange unentdeckt, da mechanische Sicherheitsvorkehrungen durch die fehlerhafte Software ersetzt worden waren.
Quelle: University of Chicago – Investigation of the Therac-25 Accidents
https://klasses.cs.uchicago.edu/archive/2020/winter/33100-1/papers/therac25.pdf
Quelle: Wikipedia Therac-25
https://de.wikipedia.org/wiki/Therac-25
1.2 Warum Fehler nicht immer beim Bediener liegen
In der Maschinenpraxis wird oft vorschnell der Bediener als Fehlerquelle genannt. Doch viele Störungen lassen sich auf Schwächen in der Software zurückführen. Auch wenn menschliche Bedienfehler eine Rolle spielen können, entstehen die entscheidenden Sicherheitsrisiken häufig durch fehlerhafte oder unvollständig getestete Software. Dieses Verständnis ist entscheidend für eine korrekte Risikobeurteilung und eine zuverlässige CE-Kennzeichnung.
2. Verantwortung des Herstellers für fehlersichere Software
Hersteller von Maschinen tragen die volle Verantwortung für die Sicherheit ihrer Produkte, dazu gehört auch die eingesetzte Software. Auch wenn Softwarefehler statistisch gesehen unvermeidbar sind, verlangt der Gesetzgeber, dass Software in sicherheitsrelevanten Funktionen fehlersicher ausgelegt, entwickelt und geprüft wird.
2.1 Was der Gesetzgeber fordert
Die Maschinenrichtlinie 2006/42/EG und künftig die Maschinenverordnung (ab Jan. 2027 in Kraft) fordern, dass Maschinen so konstruiert und gebaut sein müssen, dass sie sicher betrieben werden können. Diese Anforderung gilt ausdrücklich auch für die in der Maschine enthaltene Software. Das bedeutet, dass die Software so gestaltet sein muss, dass sie keine unzulässigen Risiken verursacht, selbst im Falle eines internen Fehlers.
Die Verantwortung liegt klar beim Hersteller. Er muss dafür sorgen, dass die Software den allgemeinen Grundsätzen der Sicherheitstechnik folgt, nachvollziehbar dokumentiert ist und im Rahmen der Konformitätsbewertung nachgewiesen werden kann.
2.2 Rolle der harmonisierten Normen, insbesondere EN ISO 13849
Ein zentrales Hilfsmittel zur Umsetzung dieser Anforderungen sind harmonisierte Normen. Für softwarebasierte Sicherheitsfunktionen ist insbesondere die EN ISO 13849-1 relevant. Diese regelt unter anderem
• wie sicherheitsbezogene Steuerungssysteme auszulegen sind,
• wie der Performance Level (PL) bestimmt wird,
• wie sowohl Hardware als auch Software zu validieren sind.
Teil 2 der Norm EN ISO 13849-2 beschreibt konkret die notwendigen Verifizierungs- und Validierungsmethoden, einschließlich der Prüfung von Softwarearchitekturen, Teststrategien und systematischer Fehlerquellen. Die Einhaltung dieser Normen ist zwar formal freiwillig, bietet aber im Haftungsfall und bei der Bewertung durch Behörden einen belastbaren Nachweis für den Stand der Technik.
2.3 CE-Kennzeichnung und maschinenspezifische Anforderungen
Im Rahmen der CE-Kennzeichnung muss der Hersteller alle relevanten Risiken identifizieren, bewerten und geeignete Maßnahmen ergreifen. Wenn eine Sicherheitsfunktion softwarebasiert umgesetzt wird, muss diese Risikominimierung nachvollziehbar dokumentiert und validiert werden. Die technische Dokumentation muss dabei unter anderem enthalten:
• eine Beschreibung der sicherheitsbezogenen Softwarefunktionen
• die eingesetzten Tools und Entwicklungsumgebungen
• die Ergebnisse der Prüfungen und Bewertungen
• die Verantwortlichkeiten im Entwicklungsprozess
Fehlersichere Software ist daher nicht nur ein technisches Thema, sondern ein zentraler Bestandteil der rechtlichen Konformität einer Maschine.
3. Technische Umsetzung sicherer Softwarelösungen
Die Umsetzung sicherheitsrelevanter Funktionen mit Software ist technisch anspruchsvoll, insbesondere wenn sie zuverlässig und normgerecht erfolgen soll. Eine fehlersichere Lösung erfordert stets das Zusammenspiel mehrerer Komponenten:
• Sensorik
• Logik (einschließlich Software)
• Aktorik
Entscheidend ist dabei nicht nur die Auswahl geeigneter Hardware, sondern auch die Architektur der Software und deren Verifikation.
3.1 Zusammenspiel von Sensorik, Logik und Aktorik
Eine funktionierende Sicherheitskette besteht typischerweise aus drei Elementen:
• Sensoren, die Gefahren erkennen (z. B. Lichtgitter, Näherungsschalter),
• Logikeinheiten, in denen die Auswertung erfolgt (z. B. SPS, Sicherheitsrelais),
• Aktorik, die auf das erkannte Risiko reagiert (z. B. Abschaltung von Motoren, Verriegelung)
Fehler in einem dieser Glieder, insbesondere in der Softwarelogik, können zu gefährlichen Situationen führen. Selbst bei bewährter Hardware führt eine fehlerhafte Programmierung schnell zu Funktionsausfällen oder unerwünschten Zuständen.
3.2 Klassische Hardwarelösungen versus programmierbare Systeme
In der Praxis bieten sich drei Lösungswege an, abhängig vom Sicherheitsbedarf und der Komplexität der Funktion:
1. Klassische Hardwarelösung mit Sicherheitsrelais:
Diese Lösungen sind besonders robust, da sie keine frei programmierbare Software benötigen. Die Konfiguration erfolgt durch Verdrahtung und Parametrierung.
Vorteil: Der Hersteller der Sicherheitskomponenten übernimmt die Verantwortung für die Fehlerfreiheit, was die CE-Kennzeichnung erleichtert.
2. Programmierbare Systeme mit zertifizierten Bausteinen:
Hierbei wird eine programmierbare Steuerung eingesetzt, die zertifizierte Funktionsbausteine verwendet. Die Programmierung erfolgt durch Auswahl und Kombination dieser geprüften Elemente.
Vorteil: Mehr Flexibilität bei moderatem Prüfaufwand bei gleichzeitig hoher Sicherheit, sofern nur zugelassene Bausteine verwendet werden.
3. Trennung von Prozess- und Sicherheitssteuerung:
Eine häufig eingesetzte Praxis ist die Trennung in zwei Systeme:
• Prozesssteuerung, die nicht sicherheitsrelevante Funktionen übernimmt
• Sicherheitssteuerung, die ausschließlich sicherheitsrelevante Aufgaben verarbeitet
Wichtig: Die Prozesssteuerung darf keinen Einfluss auf die Sicherheitssteuerung nehmen. Eine Kommunikation ist möglich, aber strikt zu trennen. Diese Struktur erhöht die Robustheit und erleichtert die Validierung.
3.3 Königsdisziplin: Eigene Hardware und Sicherheitssoftware entwickeln
Für Hersteller mit hohen Stückzahlen oder speziellen Anforderungen kann es sinnvoll sein, eine eigene Hardwareplattform mit spezifischer Sicherheitssoftware zu entwickeln, z.B. in C oder C++. Dies ermöglicht maximale Flexibilität und Performance, erfordert jedoch erheblichen Entwicklungsaufwand sowie tiefgehende Kenntnisse in funktionaler Sicherheit, Softwareverifikation und regulatorischen Anforderungen. Diese Option rechnet sich nur bei Serienmaschinen mit größeren Losgrößen.
4. Validierung, Verifizierung und Haftungsvermeidung
Fehlersichere Software ist nur dann tatsächlich sicher, wenn sie konsequent validiert und verifiziert wird. Diese Prozesse sind unverzichtbar, um die Konformität mit der Maschinenrichtlinie bzw. Maschinenverordnung nachzuweisen und um die eigene Haftung als Hersteller rechtssicher zu begrenzen.
4.1 Warum klare Verantwortlichkeiten entscheidend sind
Ein wesentliches Element für die Qualität der Softwareentwicklung ist die klare Zuweisung von Aufgaben und Prüfverantwortung. Wer eine sicherheitsrelevante Funktion programmiert, darf nicht gleichzeitig die finale Prüfung übernehmen. Es braucht
• nachvollziehbare Arbeitsanweisungen für Programmierer,
• interne Prüfschritte und technische Reviews durch unabhängige Personen,
• definierte Kriterien für die Abnahme jeder Softwareversion.
Diese organisatorischen Maßnahmen helfen nicht nur systematische Fehler zu vermeiden, sondern bieten im Streitfall auch belastbare Nachweise zur ordnungsgemäßen Durchführung der Entwicklung.
4.2 Kontrollprozesse und Dokumentation
Die Validierung (Nachweis der Eignung zur Erfüllung der Sicherheitsfunktion) und Verifizierung (Überprüfung der Einhaltung der festgelegten Anforderungen) sind Pflichtaufgaben im Entwicklungsprozess. Sie beinhalten
• Prüfberichte für alle sicherheitsrelevanten Funktionen,
• Simulations- oder Testprotokolle,
• Tools zur automatisierten Prüfung,
• lückenlose Versionsverwaltung und Änderungsnachweise.
Besonders vorteilhaft sind vorgefertigte, geprüfte Softwarebausteine, da deren Validierung in der Regel durch den Komponentenhersteller erfolgt, ein erheblicher Vorteil in der CE-Dokumentation.
4.3 Ab wann sich eigene Lösungen wirtschaftlich lohnen
Eigene Sicherheitssoft- und -hardware zu entwickeln lohnt sich in der Regel nur ab einer bestimmten Stückzahl, typischerweise bei Serienmaschinen. Erst dann amortisieren sich die hohen Aufwände für Entwicklung, Prüfung, Zertifizierung und Dokumentation. Für Einzelanlagen oder kleine Serien empfiehlt es sich, auf bewährte, zertifizierte Komponenten zurückzugreifen und diese projektspezifisch anzupassen.
Wir unterstützen Sie bei der Konformitätsbewertung, von der Risikobeurteilung über die Festlegung der Sicherheitsfunktionen inklusive Vorgaben für die Software bis zur CE-Kennzeichnung. Fragen Sie jetzt ein kostenloses Erstgespräch an, um die gesetzlichen Anforderungen Ihrer Sicherheitstechnik und der zugehörigen Software zu besprechen.
"Lassen Sie uns prüfen, ob Sie die Herstellerhaftung übernommen haben und leiten Sie die notwendigen Schritte ein, um Ihre Sorgfaltspflicht zu erfüllen."
Ihr Experte für CE-Kennzeichnung von Maschinen und Anlagen.
