Funktioniert Offenheit in der Automatisierungstechnik?

Bild: Pragmatic Industries GmbH

Ursprünglich entstand die Open Source Bewegung aus Forschern und Idealisten, die durch die Offenlegung des Quellcodes eine Verbreitung und weitere Nutzung ihrer Programme erleichtern wollten. Seit einigen Jahren gibt es aber auch eine weitere Ausprägung, nämlich Open Source als Kooperationsmodell. Hier können (teilweise konkurrierende) Unternehmen gemeinsam an einer Problemstellung arbeiten, ohne dass komplexe rechtliche Rahmenbedingungen geprüft oder Verträge erstellt werden müssen. Dafür werden die Projekte oftmals von einer gemeinnützigen Organisation oder Stiftung verwaltet. Die bekanntesten Beispiele hierfür sind die Linux Foundation, die Apache Software Foundation oder die Eclipse Foundation. Diese Organisationen stellen üblicherweise die Infrastruktur und definieren die Spielregeln. Insbesondere haben diese Organisationen auch Prozesse und Erfahrung, um den Quellcode lizenzrechtlich zu prüfen und sicher zu stellen, dass eine Verwendung des bereitgestellten Codes keine rechtlichen Gefahren birgt.

Auch wenn dieses Vorgehen für viele mittelständische Unternehmen in der Automatisierungstechnik ungewohnt klingt, gibt es hier seit Jahren ähnliche Strukturen. Einige Unternehmen arbeiten bereits in Arbeitsgruppen bei entsprechenden Branchenverbänden wie dem VDMA oder den IHKs. Sie bieten Plattformen, um Spezifikationen und Standards zu erarbeiten oder unternehmensübergreifende Entwicklungsprojekte zu koordinieren. Ähnliche Kollaborationsmodelle gibt es also in der Automatisierungstechnik seit geraumer Zeit.

Apache PLC4X ist ein Open-Source-Projekt mit dem Ziel Treiber für die gängigen Steuerungs- und Feldbusprotokolle zu implementieren, wo dies technisch möglich und sinnvoll ist. Die wichtigsten Neuerungen hierdurch sind:

Alle drei Punkte sind aus Sicht des Zusammenwachsens von IT und Operation Technology (OT) sehr interessant. Zudem ist zu beobachten, dass die alleinige Dominanz von Windows im Produktionsumfeld an einigen Stellen zu schwinden scheint und somit der Bedarf an plattformunabhängigen Lösungen steigt. Weiterhin hilft die einheitliche Schnittstelle der Treiber dabei, Software einmal zu entwickeln und sehr einfach auf alle unterstützen Steuerungstypen zu portieren. Ein wichtiger Aspekt hierbei:

Empfehlungen der Redaktion

Auf den ersten Blick wirkt PLC4X genau wie OPC UA. Und in der Tat sind die Ziele der beiden Projekte nahezu identisch, allerdings unterscheiden sich die Lösungsansätze grundsätzlich. OPC UA vereinheitlicht die Kommunikation durch die Spezifikation eines neuen Kommunikationsformates, dass sich inzwischen etabliert hat und in fast allen neuen Steuerungen verfügbar ist. Bei PLC4X auf der anderen Seite liegt das Augenmerk darauf die existierenden oder nativen Protokolle zu implementieren und diese für die Kommunikation mit den Anlagen zu verwenden. Zur Verdeutlichung ist der Ablauf der Kommunikation mit mehreren Geräten für beide Ansätze im nachfolgenden Bild (oben rechts) dargestellt. Beide Ansätze haben Vor- und Nachteile, die im Folgenden kurz vorgestellt werden. Der Hauptvorteil von OPC UA ist neben der Vereinheitlichung der Kommunikation das Datenmodell, das Zugriff auf die verfügbaren Daten in einem Gerät und auf weitere Metadaten wie Typ-, Qualitäts- und Aktualitätsinformationen erlaubt. Zudem werden über sogenannte Companion Specifications herstellerübergreifend standardisierte Datenrepräsentationen erarbeitet. Nachteil ist jedoch eine gewisse Schwerfälligkeit des Protokolls, die es ungeeignet für Abfragen in kurzen Zeitintervallen macht. Der wichtigste Punkt ist aber, dass es schlicht auf dem Großteil der Bestandsanlagen im Feld nicht verfügbar ist, sondern erst seit zwei bis drei Jahren wesentlich in den Markt kommt. Damit ist OPC UA insbesondere für viele Brownfield-Projekte nicht geeignet, wenn die Steuerungen nicht ersetzt werden sollen. Apache PLC4X hat hier einen klaren Vorteil, da die Kommunikation mit den Steuerungen immer in den nativen Protokollen der Steuerungen stattfindet. Damit sind sowohl kurze Zykluszeiten für Abfragen möglich, als auch die Kommunikation mit älteren Geräten, sofern die Protokolle unterstützt werden. Der größte Nachteil von PLC4X ist, dass die Konfiguration für jedes Protokoll etwas anders aussieht. Die Portabilität ist daher nicht so komfortabel wie bei OPC UA. Weiterhin steht kein so reiches Datenmodell zur Verfügung wie bei OPC UA, sondern im Wesentlichen nur das, was die Steuerungen auch heute schon anbieten. Daher gibt es gute Gründe für beide Ansätze. Es gibt sogar einen Treiber für OPC-UA-Kommunikation über PLC4X, so dass sich auch neue und alte Anlagen gleichzeitig mit demselben Programm auslesen lassen.

Mit dem Projekt Apache PLC4X gibt es ein Open-Source-Projekt, das für Unternehmen in der Automatisierungstechnik interessante Möglichkeiten eröffnet. Insbesondere für das Auslesen von Maschinendaten aus Bestandsanlagen. Das Projekt hat zwar sehr ähnliche Ziele wie OPC UA, aber einen ganz anderen Ansatz, so dass es für beide eine Daseinsberechtigung gibt. Auch wenn es direkt aus dem Open-Source-Projekt heraus keinen kommerziellen Support oder Schulungen gibt, so gibt es doch Unternehmen wie Pragmatic Industries, die bei Bedarf entsprechende Dienstleistungen anbieten.

www.pragmaticindustries.com