Wer geantwortet hat, ist für die Einordnung nicht unerheblich, denn Gerätehersteller (37 Prozent der Teilnehmer), Maschinenbauer und Systemintegratoren (33 Prozent der Teilnehmer) sowie Endanwender und Betreiber (8 Prozent der Teilnehmer) blicken unterschiedlich auf das Thema Safety.
Stand heute und morgen
Bevor über die Zukunft gesprochen werden kann, lohnt der Blick auf den Status quo, denn er zeigt, wie tief klassische Ansätze verankert sind. Je 32 Prozent realisieren Functional Safety heute mit klassischer Hardware-Safety-SPS bzw. mit Safety-Funktionen, die direkt in Steuerungen, Antriebe oder Robotiksysteme integriert sind. 13 Prozent setzen auf Sicherheitsrelais oder dedizierte Safety-Controller, lediglich sieben Prozent auf softwarebasierte oder virtualisierte Lösungen, 16 Prozent kombinieren mehrere Ansätze. Virtuelle Safety ist damit heute die Ausnahme, nicht die Regel.
Die Frage nach der Entwicklung der nächsten drei bis fünf Jahre ist deshalb aufschlussreich, weil sie zeigt, ob dieser Zustand als Übergangsphase oder als Dauerzustand verstanden wird. Hier fällt die Antwort eindeutig aus: 59 Prozent gehen von einem kombinierten hard- und softwarebasierten Ansatz aus, nur fünf Prozent erwarten, dass Safety überwiegend hardwarebasiert bleibt, je 18 Prozent rechnen mit zunehmender Virtualisierung der Safety-Funktionen bzw. damit, dass Functional Safety künftig überwiegend softwarebasiert realisiert wird. Die Branche erwartet also keinen Bruch, sondern eine schrittweise Verschiebung, bei der Hardware nicht verschwindet, sondern ihre Rolle verändert.
Chancen und Herausforderungen für Virtual Safety
Wie sich diese Erwartung in konkretem Handeln niederschlägt, zeigt der Diffusionsgrad der virtuellen Safety-SPS selbst, einer Technologie, die Sicherheitsfunktionen als Softwareinstanz auf Standardhardware statt auf dedizierten Sicherheitscontrollern ausführt. Dem Thema steht der Großteil der Studien-Teilnehmer noch abwartend gegenüber: Nur bei 18 Prozent ist sie bereits im Einsatz oder in der Pilot- bzw. Evaluierungsphase, für 40 Prozent für zukünftige Produkte interessant, für 24 Prozent aktuell kein Thema, 18 Prozent machten keine Angabe. Das Muster entspricht einer frühen Adoptionsphase, in der die Mehrheit beobachtet, während eine kleine Gruppe bereits Erfahrungen sammelt.
Damit sich dieser Beobachterstatus in Investitionsentscheidungen übersetzt, braucht es einen belastbaren Business Case, weshalb die Frage nach den Treibern zentral ist. Größter Treiber ist die Reduktion von Kosten und Komplexität der Hardware mit 57 Prozent, gefolgt von der Skalierbarkeit über mehrere Produktlinien mit 49 Prozent, der flexibleren Plattformarchitektur mit 45 Prozent, der Integration in digitale Plattformen, Edge und Cloud mit 43 Prozent sowie der Verbindung zu KI- und datengetriebenen Systemen mit 31 Prozent. Die kürzere Time-to-Market sehen nur 28 Prozent als Treiber. Wirtschaftliche und architektonische Argumente stehen also vor Geschwindigkeit, Virtual Safety wird eher als strukturelle Vereinfachung denn als Beschleuniger verstanden.
Diesen Chancen stehen konkrete Hürden gegenüber, die erklären, warum die Umsetzung trotz breiter Zustimmung zögerlich bleibt. Als größte Herausforderungen nennen die Teilnehmer Cybersecurity mit 58 Prozent, Zertifizierung und Normenkonformität mit 55 Prozent sowie Vertrauen in softwarebasierte Safety mit 54 Prozent, gefolgt von interner Safety-Kompetenz mit 40 Prozent und Performance bzw. Determinismus mit 29 Prozent. Die Rangfolge ist nachvollziehbar: Auf Standardhardware und über offene Netzwerke vergrößert sich die Angriffsfläche gegenüber einer galvanisch getrennten Sicherheitssteuerung, und ob eine virtualisierte Laufzeitumgebung dieselbe zeitliche Vorhersagbarkeit liefert wie dedizierte Hardware, ist keineswegs trivial, zumal ein Hypervisor meist mehrere Prozesse parallel bedient.
Zertifizierung und Hardwareunabhängigkeit sind erfolgsentscheidend
Welche Eigenschaften eine Virtual-Safety-Lösung mitbringen muss, um diese Bedenken zu adressieren, beantwortet die nächste Frage, deren Ergebnis wenig überraschend die Zertifizierung an die Spitze stellt. Als entscheidend gelten vor allem die TÜV-Zertifizierung mit 66 Prozent und die Hardwareunabhängigkeit mit 63 Prozent, gefolgt von der Integration in bestehende Tool-Chains mit 38 Prozent, der Black-Channel-Kommunikation etwa nach FSoE mit 37 Prozent sowie der Unterstützung von Safe Motion mit 31 Prozent. Ein Lizenzmodell nannten 23 Prozent, die Cloud- oder Edge-Integration 18 Prozent. Black-Channel-Verfahren wie FSoE übertragen sicherheitsgerichtete Telegramme über ein nicht sicheres Netzwerk und prüfen Integrität und Aktualität der Daten auf Protokollebene, Voraussetzung dafür, dass Safety-Kommunikation auch über virtualisierte Netzwerkinfrastruktur laufen kann. KI-unterstützte SPS-Programmierung eröffnet neue Möglichkeiten. Über das Model Context Protocol (MCP) greifen Sprachmodelle direkt auf SPS-Projekte zu. So kann SPS-Code im Entwicklungsalltag automatisiert erstellt, analysiert und dokumentiert werden. ‣ weiterlesen
KI: Schneller zum SPS-Code
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.
4 Fragen an Michael Plankensteiner, CEO der Neuron GmbH
Sicherheit virtuell geregelt
Laut unserer Umfrage sehen lediglich 18 Prozent, dass sich Safety-Funktionen in den nächsten 3 bis 5 Jahren virtualisieren werden. Warum sehen Ihrer Meinung nach so viele die Virtualisierung im Bereich Safety eher skeptisch? Wie lassen sich Messdaten für effizientere Prozesse nutzen? ‣ weiterlesen
Die Zahl täuscht etwas: Zählt man Virtualisierung und softwaredefinierte Ansätze zusammen, rechnet die deutliche Mehrheit mit wachsendem Softwareanteil – nur eben schrittweise, nicht als Umbruch. Die Skepsis richtet sich weniger gegen Virtualisierung an sich als gegen die Frage, wie sich eine virtualisierte Safety-Instanz genauso belastbar zertifizieren lässt wie dedizierte Hardware. Das deckt sich mit den größten Hürden aus unserer Umfrage: Cybersecurity, Vertrauen und Normenkonformität. Der Kern dahinter ist der sogenannte Freedom-from-Interference-Nachweis – die Garantie, dass die Safety-Funktion von allem anderen auf dem System sauber getrennt bleibt. Technisch lösbar, aber in der Praxis noch nicht so etabliert wie bei klassischer Hardware. Das braucht Zeit und Referenzprojekte.
Endress+Hauser auf der SPS
Wie gehen Sie bei Neuron das Thema Virtual Safety an?
Für uns ist Virtual Safety kein entweder-oder zwischen Hardware und Software, sondern eine Frage der Wahlfreiheit. Unser Ansatz heißt Hardware Independent Safety, kurz HIS: Wir entwickeln eine Methodik, mit der sich funktionale Sicherheit auf beliebiger bestehender Hardware realisieren lässt, ohne dass für jede Variante eine komplett neue Zertifizierung nötig wird. Das ist keine Wette auf eine einzelne Technologie, sondern ein Werkzeugkasten. Kunden entscheiden selbst, wie viel Hardware und wie viel Software für ihre jeweilige Anwendung sinnvoll ist – und das spiegelt genau das wider, was auch unsere eigene Umfrage zeigt: Der Markt will Hybridlösungen, keinen Radikalwechsel.
Vor allem die Zertifizierung, das fehlende Vertrauen in Software sowie Cybersecurity werden als wesentliche Herausforderungen genannt. Wie wollen Sie diesen Herausforderungen begegnen?
Diese drei Punkte sind aus unserer Sicht keine drei getrennten Baustellen, sondern greifen bei Virtual Safety ineinander – deshalb gehen wir sie auch nicht einzeln, sondern strukturell an.
Bei der Zertifizierung ist unser Ansatz, den Aufwand nicht bei jedem Kundenprojekt neu entstehen zu lassen: Unsere Safety-Bausteine sind vorzertifiziert und wiederverwendbar, sodass ein Hersteller nicht für jede Hardware-Variante erneut durch den kompletten Zertifizierungsprozess muss. Das senkt sowohl Kosten als auch Zeit bis zur Marktreife.
Beim Vertrauen in Virtual Safety setzen wir auf Nachvollziehbarkeit statt Blackbox: Unser Safety Engineering Tool dokumentiert und testet automatisiert, sodass jeder Schritt im Entwicklungsprozess geprüft und nachvollzogen werden kann – genau das, was uns Ingenieure in Gesprächen immer wieder als größte Sorge bei virtualisierter Safety nennen.
Und Cybersecurity betrachten wir nicht als nachgelagerten Schritt, sondern als integralen Bestandteil unserer Architektur von Anfang an – von der Kommunikation zwischen Komponenten bis zur Firmware selbst.
Der gemeinsame Nenner hinter allen drei Punkten ist: Vertrauen entsteht nicht durch Behauptungen, sondern durch Nachweisbarkeit. Genau darauf ist unser gesamtes Toolkit ausgelegt.
Wie und wofür lässt sich Ihrer Meinung nach KI sinnvoll beim Safety-Engineering sowie -Programmieren einsetzen?
Unsere Umfrage zeigt es sehr klar, und das deckt sich mit unserer eigenen Erfahrung: Das größte Potenzial sehen die Befragten bei Dokumentation, Testautomatisierung sowie Validierung und Verifikation – also überall dort, wo viel Zeit in wiederkehrende Arbeit fließt. Wir gehen mit Transforma bewusst einen Schritt weiter und setzen KI auch für die Generierung von Code und Tests ein. Der entscheidende Hebel ist dabei die Zeitersparnis gegenüber der manuellen Code-Erstellung – und dass sich der Ingenieur dadurch stärker auf das konzentrieren kann, was seine Expertise wirklich braucht: Review, Systemtest und die sicherheitskritische Freigabe. Die Verantwortung wandert also nicht zur KI, sie verschiebt sich beim Menschen vom Schreiben zum Prüfen. Denn Nachvollziehbarkeit und Normenkonformität bleiben der Maßstab, und den kann derzeit kein Modell allein liefern. Kurz gesagt: KI entlastet den Ingenieur – funktionale Sicherheit schützt den Menschen.
