„Safety is a bitch“

Kai Binder: Der Claim auf dem Messestand von Neuron Automation lautet ‚Safety is a bitch‘. Was soll das heißen?

Michael Plankensteiner: Ich glaube, unsere Kunden könnten dies besser erklären. Wir haben dieses Jahr ein einschneidendes Jahr für die Safety in Europa, nachdem die Maschinenrichtlinie durch die Maschinenverordnung abgelöst wurde. Zudem kommen in Richtung Cyber Resilience Act eine ganze Menge neuer Regulative hinzu. Die funktionale Sicherheit beschäftigt Maschinenbauer und Komponentenhersteller seit Jahrzehnten, aber die Arbeit mit funktionaler Sicherheit ist für die meisten Komponentenhersteller eine Bitch – sprich: eine echte Herausforderung. Sie ist zeitaufwändig, sie ist teuer, die Erstprojekte gehen eigentlich immer schief. Ein Hersteller setzt sich ein Budgetziel für eine Sicherheitssteuerung von eineinhalb Millionen Euro und will dieses Projekt in drei Jahren umsetzen, und fünf Jahre später ist er vier Millionen Euro ärmer und im Zweifel auch nicht glücklich mit dem, was er entwickelt hat. Die Arbeit ist sehr prozess- und dokumentationslastig und nicht sehr standardisiert. Jeder versucht, das Rad immer wieder neu zu erfinden. Das macht es sehr mühsam.

Gleichzeitig führt kein Weg daran vorbei. Und es beschränkt sich nicht nur auf europäische Anbieter. Egal ob Amerikaner, Japaner und die anderen Asiaten: Jeder, der in Europa Geschäfte machen möchte, muss sich an die Maschinenverordnung halten. Wenn ein Hersteller in der Vergangenheit keine Safety-Steuerung hatte, braucht er spätestens jetzt eine. Bei vielen sind aber die Ressourcen nicht vorhanden und sie wissen nicht, wie sie es angehen sollen. Aber dafür gibt es dann Dienstleister wie uns. Wir haben bisher mehr als 70 Projekte durchgeführt und können dabei helfen, diese schneller und kostengünstiger zu realisieren.

Binder: Neuron Automation stellt also nicht in erster Linie Safety-Komponenten her, sondern ist Software-Anbieter für Unternehmen, die Saftey-Komponenten herstellen.

Wir bieten nicht nur Software, sondern auch Hardware. Das heißt, wenn heute ein Automatisierungsanbieter für seinen Kunden aus dem Maschinenbau Safety-Lösungen anbieten möchte und Unterstützung bei der Entwicklung benötigt oder komplett extern entwickeln lassen möchte, ist er bei uns genau richtig. Wir bieten einen Standardbaukasten. Unser Ansatz lautet: Nicht alles neu machen! Stattdessen bieten wir gewisse Basisdesigns in der Hardware, die relativ rasch verwendet und kundenspezifisch ausgelegt werden können. Ein Basisschaltplan, den ich im customized Layout für spezifische Bedürfnisse um bestimmte I/Os erweitern kann. Auf diesem Hardware-Baukasten können dann Firmware-Bibliotheken aufgesetzt und bei Bedarf auch gleich eine Runtime integriert und ein Saftey-zertifiziertes Detail-Engineering-Tool mitgeliefert werden. Wir unterstützen also von punktuell bis zu komplett – je nach Wunsch des Komponentenherstellers.

Jürgen Wirtz: In erster Linie sind also die Mitaussteller hier auf der SPS die Kunden von Neuron und nicht die Maschinenhersteller.

Letztere nur in den seltensten Fällen. Wir haben ein paar Maschinenhersteller, die ihre eigene Automatisierungslösung und Maschinensteuerung einbringen. Im Non-Safe-Bereich ist das dann oft die Runtime und das Engineering-Tool. Im Safety-Bereich gibt es auch den einen oder anderen, der seine eigene Safety-Steuerung entwickelt, weil die Stückzahlen groß genug sind. Aber das ist eher selten, und entsprechend sind die Aussteller der SPS eher unsere Kunden.

Wirtz: Inwieweit haben Maschinenhersteller überhaupt schon auf der Agenda, dass sie ab 2027 die neue Maschinenverordnung umsetzen müssen? Besteht schon ein gewisser Leidensdruck, oder wird das Thema eher noch verdrängt?

Ich denke, wenn man von der Maschinenrichtlinie auf die Maschinenverordnung blickt, hat sich in Sachen Safety, abgesehen von ein paar Klarstellungen, nicht so viel getan. Den großen Sprung betrifft das Thema Security, und hier glaube ich, es ist mittlerweile bei allen angekommen, dass man 2027 eine Lösung für die Cybersicherheit benötigt. Wir sind da im intensiven Dialog mit allen unseren Kunden. Wir haben unsere eigenen Lösungen und Prozesse und stehen natürlich auch vor der Herausforderung, dass wir einen Mittelweg zwischen unseren Prozessen und denen unserer Kunden finden müssen und hier eine Synchronisierung brauchen.

Aber zurück zur Frage: Ja, das Thema ist angekommen. Gleichzeitig hat die neue Maschinenverordnung das Thema funktionale Sicherheit grundsätzlich noch einmal in den Mittelpunkt gerückt, vor allem im Bereich Antriebstechnik. Wer sich in den letzten vier oder fünf Jahre mit der Integration einer STO-Funktion im Antrieb beschäftigt hat, will nun die anderen Safe-Motion-Funktionen implementieren. Hat man aber schlechte Erfahrungen mit der Erstintegration gemacht, sucht man jetzt vielleicht nach einem Partner, der ihm dabei hilft, diese negativen Erfahrungen nicht noch einmal machen zu müssen.

Binder: Welches Highlight gibt es bei Neuron Automation auf der Messe?

Unseren Baukasten. Das heißt, man kann bei uns spannende Hardware-Layouts sehen, mit denen ich sowohl kleine als auch große Performance-Anwendungen relativ unkompliziert für Safety umsetzen kann. Das Spannendste daran ist eine Ein-Prozessor-Lösung für Safety, die bis SIL3 gehen kann.

Wirtz: Abschließend noch ein Ausblick: Wo geht es hin bei Neuron Automation im Bereich der Safety?

Funktionale Sicherheit schneller und günstiger zu realisieren, ebenso wie eine flexiblere Programmier- und Parametrierbarkeit. Bei Standardisierung und Modularisierung hilft unser Baukasten. Die Ein-Prozessor-Lösung beschleunigt dies noch einmal auf der Hardware-Seite. Wir arbeiten gerade an den ersten Projekten. Im nächsten Schritt werden wir das Thema Hardware-Unabhängigkeit auf dem IPC realsieren. Wir haben jetzt schon ein klares Konzept, wo mit zwei Runtimes auf jedem IPC ohne besondere Anforderungen, auch in Verbindung mit Linux, Safety implementiert werden kann. Und wir arbeiten an einem ersten Basisprojekt zum Thema KI-Integration ins Applikations-Engineering, die dabei unterstützt, schneller in der Automatisierung unterwegs zu sein. Schneller in der Applikationserstellung, schneller im Testen, schneller in der Qualifikation eines Codes und in der Programmierung. KI wird uns dabei eine ganze Menge abnehmen. Wir haben zu wenige Ressourcen, alle unsere Kunden haben zu geringe Ressourcen. Wir müssen Automatisierung in die Erstellung der Automatisierung bringen.