Was verstehen Sie unter einer „Plattform“?
Kotlarski: Eine Plattform oder konkreter eine Plattform für die industrielle Automatisierung ist eine Hardware-agnostische Software, die die Entwicklung von Automatisierungsprozessen standardisiert und effizienzsteigernd modernisiert sowie gleichzeitig eine (Echtzeit-)Ausführung und Orchestrierung der Prozesse und damit sämtlicher Prozessteilnehmer ermöglicht. Idealerweise ist eine solche Plattform offen – besitzt gepflegte und dokumentierte APIs – und ist ohne Vendor-Lock erweiterbar. Eigene IPs und eigenes (Prozess-)Wissen können sicher und selbstständig unter Verwendung einer gängigen Hochsprache ohne spezifisches (Technologie-)Wissen integriert werden. Dabei werden stets Anforderungen der industriellen Automatisierung und an einen Produktivbetrieb berücksichtigt und sichergestellt.
Mit offenen Plattformen auf dem Weg zum Android der Automation
Wie heißt Ihre Plattform und können Sie diese mit ihren wesentlichen Eigenschaften kurz vorstellen? (Wie funktioniert sie technisch? Welche Technologien, Standards etc. nutzen Sie?)
Kotlarski: Voraus Robotik bietet mit der Software voraus.core einen Hardware-agnostisches Middleware-Layer für Industrieroboter und darüber hinaus eine offene Plattform für die Entwicklung, Ausführung und das Monitoring von automatisierten Produktionsanlagen. Integration und Inbetriebnahme sowie Prozessveränderungen werden standardisiert und ohne Vendor-Lock drastisch vereinfacht. Roboter, Greifer, Kamera und weitere Peripheriegeräte sowie Technologien können in einer Python-basierten Entwicklungsumgebung integriert und innerhalb einer Applikation orchestriert werden. Eine grafische Bedienoberfläche ermöglicht, den Prozess direkt im Shopfloor anzupassen und zu optimieren. Änderungen können ohne spezifisches Vorwissen eigenständig vorgenommen werden – so bleibt die Anlage immer auf dem neuesten Stand und Betreiber unabhängig.
Was unterscheidet ihren Ansatz von anderen Ansätzen (USP)? Und wo gibt es Gemeinsamkeiten?
Kotlarski: Unser Ursprung ist die Robotik – ein wesentlicher Teil der industriellen Automatisierung. Entsprechend sind wir in der Lage sehr tief in die Echtzeitebene (Embedded Runtime) zu gehen und damit neben der Entwicklung insbesondere auch die (Echtzeit-)Ausführung und Koordination eines Automatisierungsprozesses sicherzustellen. Wir verfolgen einen einzigartigen „Bottom-Up“-Ansatz: mit unserem agnostischen Middleware-Layer, der auf einem eigens entwickelten Echtzeit-Betriebssystem aufsetzt, unterstützen wir durch kontinuierliche Ergänzung von Feldbussen und Netzwerkprotokollen markt- und anwendungsnah praktisch die gesamte Ökosystemlandschaft der Automatisierung. Gleichzeitig ermöglichen wir die Einbindung von Micro-Services und koppeln Technologie- und Clouddienste dank offener APIs an.
Wo sehen Sie die Vorteile von offenen Plattformen (OT/IT-Integration? Realisierung von App-Konzepten? Hardware-Unabhängigkeit/Flexibilität?)?
Kotlarski: Die wesentlichen Vorteile ergeben sich aus den Anforderungen einer offenen Plattform:
- Offene Schnittstellen egalisieren den Vendor-Lock und garantieren eine Einbindung heutiger und vor allem zukünftiger, smarter Technologien, um Prozesse zur Laufzeit zu analysieren und bei erhöhtem Prozessoutput bezüglich Ressourcenschonung zu optimieren.
- Die Standardisierung und Modernisierung der Programmierung, die faktisch jeden befähigt, Automatisierungslösungen zu erstellen und auszuführen, erlaubt die Einbindung moderner Entwicklungstools (DevOps), die neben Effizienz auch die Wiederverwendung von Code und damit von Applikationen sicherstellt.
- Ressourceneffiziente, containerisierte Softwarelösung, die auf vorhandener Hardware installiert werden kann. Ein zusätzlicher IPC oder generell zusätzliche Hardware sind nicht erforderlich – das reduziert Komplexität, spart Kosten und senkt den Energieverbrauch.
- Bestehende Anlagen und Applikationen können auf den neuesten Stand der Technik gebracht und gleichzeitig optimiert werden – das verlängert die Einsatzdauer, ohne eine Neuanschaffung von Komponenten.
Wie lassen sich die teilweise hohen Anforderungen der Automatisierungstechnik (OT) mit der IT-Welt verbinden – OT-Echtzeit und IT-Echtzeit sind ja nicht deckungsgleich? Kann eine OT-IT-Plattform wirklich beide Welten verbinden?
Kotlarski: Alles eine Frage der richtigen Herangehensweise und Konzipierung. Architektur, Modularität und Schnittstellen sind entscheidend. Natürlich darf kein „langsamer“ IT-Prozess die Echtzeit der OT beeinflussen. Beide „Welten“ haben andere Anforderungen an Takt und Determinismus. Konzepte und Ansätze für die Kommunikation und Synchronisation zwischen OT und IT bestehen allerdings und lassen sich anwenden. Schauen wir uns diesbezüglich den Linux-Kernel an. Echtzeit-Funktionen sind zunehmend integriert. Darüber hinaus zeigen Netzwerkerweiterungen wie z. B. TSN einen ähnlichen Trend. Natürlich lösen diese Technologien nicht alle Probleme, jedoch wird auf diversen Ebenen vieles dafür getan, dass sich OT und IT annähern.
Lässt sich diese Verbindung technisch über „offene Steuerungen“ realisieren oder eher über eine Zusatz-Schicht („offene Middleware“), die zwischen OT und IT sowie zwischen verschiedenen Systemen vermittelt?
Kotlarski: Eine Plattform muss Entwicklung, Ausführung und Monitoring sicherstellen. Die richtigen Schnittstellen garantieren dabei Offenheit bei gleichzeitigem „Schutz“ der Steuerungs/Echtzeitebenen. Meinen Eindruck nach gehen die Begriffe einer offenen Steuerung und einer offenen Middleware durcheinander. Technisch betrachtet, macht bei dieser Frage der Begriff einer offenen Middleware mehr Sinn. Allerdings lassen sich nicht alle Herausforderungen der industriellen Automatisierung in Perfektion, d. h. nicht ohne zusätzlichen Overhead, in der Middleware lösen. Entsprechend braucht es eine Echtzeitebene bzw. eine Embedded Runtime.
Was bedeutet das für das Engineering? Wie können Produkt- und Produktionsentwicklung profitieren?
Kotlarski: Aufgrund der Verwendung verbreiteter und moderner Hochsprachen sind weder herstellerspezifisches Wissen noch speziell geschulte Experten, deren Verfügbarkeit häufig der limitierende Faktor bei der Automatisierung ist, erforderlich. Produkt- und Produktionsentwicklung profitieren explizit, da der Fokus ganz klar auf das adressierte bzw. zu lösende Problem und nicht auf das Verstehen proprietärer Software gelegt werden kann, die nur Mittel zum Zweck ist.
Die Verwendung von Hochsprachen erlaubt es, viele Praktiken moderner Softwareentwicklung einzusetzen. So können bspw. Applikationen besser gekapselt, Teile in Bibliotheken ausgelagert und wiederverwendet werden. Die in der modernen SW-Entwicklung etablierten DevOps-Ansätze finden Einzug in die industrielle Automatisierung: Tests, statische Code Analyse, saubere Versionierung und einfaches Deployment ohne manuellen Aufwand. Das verändert die Entwicklung von Automatisierungslösungen nachhaltig und verlagert den Fokus hin zu schnellen Entwicklungs- und Optimierungszyklen.
Darüber hinaus erlauben die offenen Schnittstellen des voraus.core die Einbindung von KI-basierten Co-Pilot-Funktionalitäten, die eine Entwicklung zunehmend unterstützt und Effizienz gewährleistet. Auch heutige und insbesondere zukünftige KI-Assistenten für die Analyse und Optimierung von Produktionsprozessen sind integrierbar – weniger Ressourcen bei höheren Stückzahlen, also ein besseres Produkt.
Wird der Automatisierer auf Dauer von IT-Spezialisten „ersetzt“ und wird mit den offenen Plattformen die Steuerungsprogrammierung entsprechend IEC 61131–3 auf Dauer hinfällig – oder nur entsprechend von der IT-Seite kommend „übersetzt“?
Kotlarski: Man sollte nicht von Ersetzen sprechen, sondern vielmehr von einer Transition. Man wird feststellen, dass die klassische Steuerungsprogrammierung ineffizient und teuer ist (auch weil die Möglichkeiten der modernen Software-Entwicklung derzeit nicht anwendbar und die Anzahl an Experten limitiert sind) und sich mehr und mehr auf moderne Plattformen konzentrieren – über die Vorteile haben wir bereits ausgiebig gesprochen.
Deren Verwendung erfordert nicht einmal IT-Spezialisten, sodass auch Automatisierer in der Lage sind, bzw. unter Verwendung der Python-basierten Entwicklungsumgebung des voraus.core in die Lage versetzt werden, komplette Automatisierungslösungen inklusive Roboter, Greifer, Kamera und weiterer Peripheriegeräte sowie Technologien zu entwickeln und auszuführen.
Unabhängig davon ist die Einbindung und damit die proprietäre Kapselung klassischer Steuerungsprogrammierung entsprechend IEC 61131–3 problemlos möglich. Markt/Kundenanforderungen erfordern vereinzelt eine Brown-Field-Unterstützung – alles eine Frage der richtigen API.
Welche Rolle spielt bei dem Plattform-Gedanken die Offenheit nicht nur gegenüber OT- bzw. IT-Systemen Dritter, sondern auch gegenüber vergleichbaren Plattformansätzen von Marktbegleitern? Entsteht auf Dauer eine gemeinsame offene interoperable Plattform über Standardisierung oder über Kooperationen oder durch Marktdominanz („the Winner takes it all“)?
Kotlarski: Aufgrund offener Schnittstellen ist eine Kombination verschiedener Plattformen durchaus möglich. Bei angenommen identischer Abdeckung ist dies allerdings nur bedingt sinnvoll. Vielmehr profitieren alle und insbesondere der (End-)Anwender von den offenen Schnittstellen, sodass Funktionen, Technologien und ganze Lösungen theoretisch in beliebigen Plattformen lauffähig sind. Unterm Strich ist auch dies nur eine standardisierte API. Entscheidend ist allerdings, wer eine robuste, ressourceneffiziente Ausführung im Produktivbetrieb sicherstellen kann und entsprechend bereit ist, Verfügbarkeit und Aktualisierung zu garantieren.
Auf der technischen Ebene: Welche Rolle spielen im Zusammenhang mit dem Thema Offenheit speziell Open-Source-Lösungen bzw. Betriebssysteme wie Linux sowie der Datenaustausch via OPC UA – das OPC steht dabei ja bereits für „Open Platform Communications“?
Kotlarski: Linux hat sich eindrucksvoll etabliert und zeigt damit, wie ein offener Ansatz die Entwicklung und Verbreitung beschleunigen/unterstützen kann. Bei OPC UA ist es ähnlich: freie Implementierungen, wie bspw. des open62541, vereinfachen die Verwendung von OPC UA massiv und unterstützen die einfache und schnelle Kommunikation/Interaktion weiterführend.
Eine offene Plattform für die industrielle Automatisierung muss – wie der Name schon sagt – Open-Source-Lösungen bzw. allgemein jegliche Individuallösungen ankoppeln/integrieren können (kein Vendor-Lock) und die Entwicklung in diesem Bereich kontinuierlich unterstützen. Gleichzeitig darf eine Plattform – übertrieben formuliert – allerdings durch ein unkontrolliertes Überangebot an industriefernen Lösungsansätzen nicht „zugemüllt“ werden. Andersherum genauso: konkret werden wir bspw. Teile unsere Testinfrastruktur open-source stellen und damit einen Beitrag zu einer garantiert hochqualitativen Automatisierungssoftware für den Produktivbetrieb leisten.
Kann bzw. wird sich über offene Plattformen eine Art „Android der Automation“ entwickeln, das auf verschiedenen Hardwareplattformen (Maschinen, Robotern) läuft?
Kotlarski: Die klare Antwort ist: Ja. Technologisch ist ein Android der Automatisierung nicht mehr fern bzw. schon heute möglich. Was es allerdings braucht, ist ein partnerschaftliches Umdenken: Fokus auf die eigenen Stärken beschneidet beispielsweise nicht das Geschäft, sondern führt vielmehr zu einer Produkt/Technologieverbesserung bei gleichzeitiger Kostenreduktion für den Anwender. Das vorausgesetzt wird die Robotik und die Automatisierung einen nie dagewesenen Boom in vielen Bereichen unseres Lebens erleben.
Mehr zum Thema Industrie 4.0
