Wann diese Anforderungen tatsächlich in produktiven Anlagen ankommen, lässt sich aus dem erwarteten Zeithorizont ablesen, der als Realitätscheck für die zuvor geäußerte Zuversicht dient. Die ersten produktiven Einsätze virtualisierter Safety-Architekturen erwarten 34 Prozent in den nächsten zwei Jahren, weitere 29 Prozent in drei bis fünf Jahren, elf Prozent erst in mehr als fünf Jahren. Bereits heute setzen nur acht Prozent diese Technik ein, fünf Prozent halten einen Einsatz generell für unwahrscheinlich.

KI kommt ins Spiel

Da Safety-Programmierung traditionell einen hohen manuellen Aufwand bei Dokumentation und Verifikation verursacht, liegt die Frage nahe, wo künstliche Intelligenz diesen Aufwand senken könnte. Ein großes Potenzial sehen 41 Prozent, immerhin mittel 38 Prozent, nur fünf Prozent sind skeptisch. Danach gefragt, in welchen Bereichen der Einsatz sinnvoll erscheint, nannten 77 Prozent die Dokumentationserstellung, 69 Prozent die Testautomatisierung sowie 63 Prozent Validierung und Verifikation, gefolgt von Fehleranalyse mit 55 Prozent, Normen-Compliance-Check mit 54 Prozent sowie automatischer Safety-Code-Generierung mit 45 Prozent. Die Reihenfolge zeigt ein klares Muster: KI wird zunächst dort akzeptiert, wo sie unterstützend und nachvollziehbar bleibt, deutlich zurückhaltender dort, wo sie selbst sicherheitsgerichteten Code erzeugen würde.

Diese Zurückhaltung spiegelt sich in den offenen Kommentaren wider. Mehrfach wurde die Gefahr der Halluzination benannt, ebenso die Sorge, dass Modelle Gefährdungen aus dem Zusammenspiel verschiedener Gewerke nicht zuverlässig erfassen und jeder Schritt weiterhin genau geprüft werden muss. Wiederholt kam die Haftungsfrage auf, wer im Ernstfall verantwortlich ist, die KI selbst, deren Anbieter oder der Anwender, und wie sich das Ergebnis überhaupt zuverlässig prüfen lässt. Ein Teilnehmer brachte es auf den Punkt: Die Zukunft der Safety liege weniger in künstlicher Intelligenz als in klaren Regelwerken und Codegeneratoren, die reproduzierbare, lesbare Anwenderprogramme nach festen Regeln erzeugen.

Eine Zukunftsfrage

Gefragt, wie Functional Safety idealerweise 2030 in den eigenen Produkten umgesetzt sein wird, zeichnet sich trotz aller offenen Fragen ein relativ konkretes Bild ab. Am häufigsten genannt wurde eine hybride, hard- und softwarebasierte Lösung, konkretisiert u.a. durch eine hardwareunabhängige vPLC-Runtime, die nicht in einem Rechenzentrum, sondern auf beliebiger Hardware im Subnetz der Anlage läuft, um auf zusätzliche vLANs, Switches und virtuelle Switches verzichten zu können, durch eine Integration, die untrennbar mit den zentralen und dezentralen Steuerungseinheiten zu einem Gesamtsystem verschmilzt, sowie durch eine eigenständige Virtual-Safety-App. Zwischen dem heutigen, noch klar hardwaredominierten Stand und diesem Zielbild liegt vor allem eines: die Zeit, in der Zertifizierung, Cybersecurity und Vertrauen in softwarebasierte Safety so weit reifen, dass aus einer Option ein Standard wird.

Seiten: 1 2