Patentiertes Task-Handling, offenes Betriebssystem, die Kombination unterschiedlicher Programmiersprachen sowie der deterministische Datenaustauch – das sind die Zutaten für eine zukunftsgerichtete Automatisierungslösung

Patentiertes Task-Handling, offenes Betriebssystem, die Kombination unterschiedlicher Programmiersprachen sowie der deterministische Datenaustauch – das sind die Zutaten für eine zukunftsgerichtete Automatisierungslösung Phoenix Contact

Als Basis der Steuerungsplattform von Phoenix Contact steht die PLCnext Technology den Anwendern seit November 2017 zur Verfügung. Erste Interessenten hatten schon seit 2016 die Gelegenheit, die Plattform im Rahmen eines Early Adopter-Programms in einem frühen Stadium zu begleiten. Aus dieser Aktivität sind interessante Ideen und Anwendungen entstanden.

Auf die Schnelle

  • SPS-typische Echtzeit-Performance und Datenkonsistenz auch für Hochsprachen und modellbasierten Code
  • grenzenlose Anpassungsfähigkeit durch die schnelle, einfache Integration von Open-Source-Software, Apps und Zukunftstechnologien
  • intelligente Vernetzung durch eine Cloud-Anbindung sowie die Integration aktueller und zukünftiger Kommunikationsstandards
  • schnelle Anwendungsentwicklung, denn mehrere Entwickler arbeiten unabhängig voneinander auch in unterschiedlichen Programmiersprachen an einem Steuerungsprogramm
  • komfortables Engineering mit dem jeweils präferierten Programmier-Tool

Welche Möglichkeiten die Steuerungsplattform bietet, zeigt ein Vergleich mit etablierten Lösungen: Die klassische SPS-Architektur beruht darauf, dass ein Laufzeitsystem auf einem mehr oder weniger bekannten Betriebssystem implementiert ist. Im Laufzeitsystem wird dann mit einem herstellerspezifischen Engineering-Tool programmiert. Dabei übernimmt das System sowohl die Ausführung und das Scheduling, als auch den konsistenten Datenaustausch zwischen den in der Laufzeitumgebung definierten Tasks und Programmen. In den letzten Jahren haben sich die Bedürfnisse der Anwender erheblich gewandelt. Beispielsweise ist die Programmierung in Hochsprache Pflicht. Die SPS-Hersteller haben diese Anforderung mit zwei unterschiedlichen Strategien erfüllt: Anbindung externer Tools und offene Entwicklungs-Plattform.

Der erste Ansatz ist dadurch gekennzeichnet, dass Steuerungsanbieter das Engineering mit den Tools Microsoft Visual Studio, Eclipse sowie Matlab Simulink ermöglichen. Die damit erstellten Programme werden anschließend gegen die auf der SPS vorhandene Laufzeit kompiliert und so innerhalb der Runtime zur Ausführung gebracht. Der Vorteil dieses getrennten Ansatzes: Die Programme lassen sich wie gewohnt vom Steuerungsprogrammierer als Funktionsblock erstellen. Bei dem System sind die Hochsprachenprogramme durch eine Laufzeitumgebung vom Betriebssystem gekapselt. Das wird zum Problem, wenn der Anwender bereits existierende Open-Source-Komponenten nutzen möchte. Sie nutzen nämlich oft Funktionen des Betriebssystems. Sofern diese vom SPS-Hersteller nicht in der Laufzeitumgebung bereitgestellt wurden, begibt sich der Anwender in die gleiche Abhängigkeit wie bei klassischen Steuerungssystemen: Er kann nicht einfach eine Java-Runtime oder einen Python-Interpreter in sein Engineering integrieren.

Spezifische Vorteile bisherige Ansätze beibehalten

Ein weiteres Konzept, mit dem Steuerungsanbieter auf die Anforderungen reagieren, ist das Angebot eines Linux-PCs in einem IP20-Hutschienengehäuse. Hier kann der Anwender frei hinsichtlich der Handhabung, Programmierung und Verwendung bestehender Open-Source-Bibliotheken entscheiden. Derartige Plattformen sprechen jedoch die klassischen SPS-Programmierer nur bedingt an, denn sie können das Engineering nicht in den ihnen bekannten IEC 61131-Programmiersprachen umsetzen.

Symbiose gelungen

PLCnext-Steuerung AXC F 2152 für das Axioline-I/O-System; weitere Controller sind in Vorbereitung.

PLCnext-Steuerung AXC F 2152 für das Axioline-I/O-System; weitere Controller sind in Vorbereitung. Phoenix Contact

Vor diesem Hintergrund hat Phoenix Contact die Vorteile beider Ansätze in der PLCnext Technology kombiniert und die entsprechenden Nachteile eliminiert. Basierend auf einem Realtime-Linux-Betriebssystem hat jede PLCnext-Steuerung eine IEC 61131-Laufzeitumgebung. Der klassische SPS-Programmierer kann das Gerät somit auspacken, anschließen und wie gewohnt programmieren – ohne sich in die Feinheiten von Linux einarbeiten zu müssen. Gleichzeitig erhält er eine Plattform, die künftigen Anforderungen flexibel begegnet. Dem Hochsprachenprogrammierer sagt die PLCnext Technology zu, weil er seine Anwendung in jeder bekannten Engineering-Umgebung erstellen kann: Für Microsoft Visual Studio, Eclipse und Matlab Simulink gibt es Plug-ins, die die Konfiguration der Compiler vornehmen (ARM- oder x86-Architektur) und verschiedene Exportfilter installieren.

Und trotzdem stimmt das Timing

Bei der PLCnext Technology wurde das Scheduling komplett aus der Laufzeitumgebung herausgelöst und als Linux-Komponente organisiert. Auf diese Weise können beliebige Programme in Tasks gegliedert und in einen zeitlichen Kontext gesetzt werden. Das ist einer der wesentlichen Unterschiede zu anderen Steuerungslösungen, welche für die Abarbeitung einer IEC 61131-Task sowie für den Hochsprachenteil getrennte Laufzeitsysteme in einem Gerät zur Verfügung stellen. Der Anwender kann dann zwar neben IEC 61131 auch in Hochsprache programmieren, doch seine Flexibilität ist begrenzt. Denn er ist wieder von der Laufzeitumgebung des jeweiligen Herstellers abhängig.

Im Gegensatz dazu kann der Programmierer bei PLCnext seine Programme aus beliebigen Tools in einen zeitlichen Kontext bringen und beispielsweise die Zykluszeit und Abarbeitungsreihenfolge eines IEC61131-, C++- und Matlab Simulink-Programms in einer Task ausführen. Er kann aber auch auf den Scheduler komplett verzichten, wenn die Programme nicht in Echtzeit abgearbeitet werden müssen. Das betrifft zum Beispiel nicht-echtzeitfähige Protokolle wie MQTT oder Modbus/TCP sowie die Abarbeitung von Datenbank-Clients wie Redis oder SQL.

Daten zwischen Tasks und Programmen einfach austauschen

Systemarchitektur der PLCnext Technology mit ESM (Execution and Synchronization Manager) und GDS (Global Data Space)

Systemarchitektur der PLCnext Technology mit ESM (Execution and Synchronization Manager) und GDS (Global Data Space) Phoenix Contact

Für eine weitere Vereinfachung sorgt der Global Data Space (GDS). Er ermöglicht dem Programmierer, Prozessdaten über im GDS definierte Ports zwischen den Tasks (Threads) und Programmen auszutauschen. Das erspart ihm das lästige Hantieren mit Semaphoren, Resource Blocking oder anderen Programmiertechniken, um Daten konsistent von einem in den nächsten Prozess zu übertragen.

Darüber hinaus beinhaltet der Global Data Space eine Schnittstelle, über die außerhalb der Echtzeitumgebung laufende Anwendungen Daten in den GDS schreiben oder lesen können. Damit lässt sich die Realtime- und Non-Realtime-Welt einfach koppeln.

Die Konfiguration aller Komponenten basiert auf XML-Files. Wie unter Linux gewohnt, kann der Programmierer also das Scheduling sowie die Prozessdatenzuordnung über das Editieren einer Textdatei erstellen und ändern. Mehr Komfort bietet das Konfigurations- und Programmierwerkzeug PC Worx Engineer, das eine grafische Schnittstelle zur Einrichtung des Execution and Synchronization Manager (ESM) und des Global Data Space umfasst. Auf diese Weise können Programme den Tasks zugeordnet und per Drag&Drop in der Abarbeitungsreihenfolge angepasst werden. Außerdem lassen sich die Ein- und Ausgangs-Ports des GDSs den In- und Out-Ports der Programme zuweisen. Ebenso umfasst PC Worx Engineer die IEC 61131-Programmierumgebung.

Welches Tool oder Funktionsbibliothek darf es denn sein?

Seite 1 von 212