Während klassische Industrieroboter in abgeschirmten Bereichen betrieben werden, erfordert kollaborierende Robotik eine kontinuierliche Überwachung von Bewegung, Geschwindigkeit und Kraft. Safety wird damit zur zentralen Systemfunktion. Doch hier stößt die klassische Trennung von funktionaler Steuerung und Safety zunehmend an ihre Grenzen.
Status-quo: Zwei getrennte Welten
Der aktuelle Stand in Robotersystemen ist klar: Funktionale Steuerung und Safety sind strikt voneinander getrennt – sowohl architektonisch als auch organisatorisch. Die non-safe-Steuerung berechnet Bewegungen und gibt Sollwerte an lokale Controller weiter, während eine separate Safety-SPS sicherheitsrelevante Parameter wie Position, Geschwindigkeit und Drehmoment überwacht. Daraus wird der Zustand des Tool Center Points bestimmt. Bei Grenzwertüberschreitungen oder beim Verlassen des Arbeitsraums greift die Safety ein und überführt das System in einen sicheren Zustand. Beide Bereiche sind als eigenständige Systeme mit jeweils eigener Hardware, Logik und oft eigener Engineering-Umgebung realisiert.
Safety als limitierender Faktor
Die Trennung von funktionaler Steuerung und Safety hat unmittelbare Auswirkungen auf Aufwand, Kosten und Time-to-Market. Auf Hardwareebene führt sie zu einer doppelten Auslegung: separate Controller, redundante Strukturen und zusätzliche Kommunikationsschnittstellen erhöhen nicht nur die Materialkosten, sondern auch die Systemkomplexität. Parallel dazu entstehen zwei Applikationswelten, die unabhängig voneinander entwickelt, getestet und zertifiziert werden müssen – mit entsprechendem Mehraufwand über den gesamten Entwicklungszyklus hinweg. Automatisierungstechnik von Beckhoff ermöglicht die effiziente Entwicklung ressourcenschonender Verpackungsmaschinen, verkürzt Konstruktionszeiten und senkt Kosten – für innovative Lösungen und nachhaltige Produktionsprozesse. ‣ weiterlesen
Vorsprung im Packaging
Der Integrationsaufwand steigt zusätzlich, da Daten zwischen funktionaler Steuerung und Safety konsistent gehalten werden müssen. Schnittstellen, Synchronisation und Validierung werden zu kritischen Faktoren, die einen erheblichen Abstimmungsbedarf verursachen – sowohl im Engineering als auch später im Betrieb und bei Änderungen. Jede Anpassung zieht potenziell Auswirkungen auf beide Systeme nach sich und erhöht den Aufwand für Tests und Re-Zertifizierung.
Besonders kritisch ist dabei die mangelnde Skalierbarkeit dieser Architektur: Mit zunehmender Funktionalität steigt der Aufwand überproportional. Genau dort, wo moderne Robotiksysteme immer komplexer werden – etwa durch kollaborierende Anwendungen, dynamische Umgebungen oder erweiterte Sicherheitsfunktionen – stößt das klassische Konzept an seine strukturellen Grenzen. Der wachsende Funktionsumfang sicherheitsgerichteter Systeme trifft auf eine Architektur, die ursprünglich für klar getrennte Zuständigkeiten ausgelegt war und diese Komplexität nur unzureichend abbilden kann.
„Zwei vollständig getrennte Systeme, die parallel entwickelt und betrieben werden müssen, sind ein strukturelles Hindernis für moderne Roboterapplikationen“, erklärt Robert Mühlfellner, CTO bei Neuron Automation. „Die klassische Architektur erhöht Kosten, verlängert Entwicklungszeiten und erschwert die Skalierung – genau in dem Moment, in dem Flexibilität und Geschwindigkeit entscheidend sind. Das bremst Innovation.“
Architekturwechsel hin zur Virtual Safety
Mit seinem Safety-Toolkit verfolgt Neuron Automation einen konsequent integrierten und standardisierten Ansatz. Dabei wird Safety nicht mehr als separates Hardware-Subsystem realisiert, sondern als integrierte, softwaredefinierte Funktion innerhalb der Systemarchitektur. Kern dieses Ansatzes ist Virtual Safety beziehungsweise Hardware Independent Safety (HIS). Dabei werden funktionale und sicherheitsgerichtete Funktionen auf derselben Hardware ausgeführt. Die notwendige Trennung erfolgt nicht mehr physisch über separate Systeme, sondern logisch innerhalb einer Runtime-Umgebung.
