PLCnext: Offene Plattform für simultanes Engineering

Autor / Redakteur: Michael Gulsch * / Gerd Kucera

Als offene Steuerungsplattform ist PLCnext Technology die Basis für das simultane Engineering. Auch Hochsprachen- und modellbasierter Code wird konsistent sowie in Echtzeit abgearbeitet.

Firmen zum Thema

Bild 1: Klassische SPS-Architektur mit herstellerspezifischer Laufzeitumgebung sowie ohne Zugriff auf die API des Operating Systems.
Bild 1: Klassische SPS-Architektur mit herstellerspezifischer Laufzeitumgebung sowie ohne Zugriff auf die API des Operating Systems.
(Bild: Phoenix Contact Electronics)

Worum es geht: Die hier skizzierte Steuerungsplattform PLCnext Technology vereinfacht das Engineering von Automatisierungsprojekten, an denen weit verteilte Entwickler gemeinsam arbeiten. Jeder dieser Entwickler kann dazu seine favorisierten Programmierwerkzeuge ohne Einschränkung einsetzten. Das Zusammenführen und Abarbeiten aller Programmteile übernimmt PLCnext in Echtzeit. Die neuen Steuerungen dazu heißen PCLnext Control und haben ein Linux-Betriebssystem.

In einer sich schnell verändernden Welt, in der immer mehr Dinge miteinander vernetzt sind, vollzieht sich auch in der industriellen Automation ein grundlegender Wandel. Klassische Systemstrukturen entwickeln sich zu Cyber-physikalischen Systemen. Zukunftsfähige Automatisierungslösungen müssen daher flexibel, offen und vernetzt sein. Mit der PLCnext Technology steht jetzt eine Plattform zur Verfügung, die völlig neue Freiheitsgrade eröffnet.

Bildergalerie
Bildergalerie mit 5 Bildern

Um zu erklären, was die Plattform so flexibel macht, bedarf es eines Rückblicks auf die Architektur klassischer SPS-Systeme. Diese sind durch proprietäre Laufzeitsysteme geprägt. Aufgesetzt auf ein Betriebssystem übernehmen die herstellerspezifischen Laufzeitsysteme die Aufgabe der Programmausführung in Echtzeit, also des Scheduling. Darüber hinaus sind sie für den konsistenten Prozessdatenaustausch verantwortlich. Eine solche Systemarchitektur hat den Vorteil, dass der Anwender keine Berührungspunkte mit dem Betriebssystem hat.

Kommt es dort aufgrund eines Updates zu Änderungen, hat das keine Auswirkungen auf seine Applikation. Die Änderungen im Betriebssystem werden vielmehr durch entsprechende Anpassungen des jeweiligen Herstellers in seiner Laufzeitumgebung abgefangen. Dieser Pluspunkt der klassischen SPS-Systeme führt in der Welt moderner Automatisierungstechnik jedoch vermehrt zu einigen Nachteilen (Bild 1).

Mit der beschriebenen Systemarchitektur lassen sich Anforderungen an zukunftgerichtete Applikationen nicht oder nur mit großem Aufwand umsetzen. Als Beispiel sei die Integration eines neuen Protokoll-Stacks wie MQTT, die Anbindung einer Datenbank oder der Betrieb der Plattform Node.js auf der Steuerung genannt. Dies, weil vorhandene Bibliotheken in Form von DLL (Dynamic Link Library) für Windows-basierte Systeme oder Shared Objects (.so) in Linux-Lösungen nicht ohne weiteres in ein klassisches System eingebunden werden können. Sie benötigen oftmals den Zugriff auf Funktionen aus der Betriebssystem-API, die allerdings aus den anfangs angeführten Gründen durch die Laufzeitumgebung gekapselt werden. Der Steuerungshersteller müsste die Funktionen folglich in der Laufzeit bereitstellen. Außerdem müsste das System in der Lage sein, eine DLL oder ein .so zu integrieren.

Bisherige Optimierungen lösen nicht alle Herausforderungen

Vor diesem Hintergrund werden verschiedene Lösungen für das oben erläuterte klassische SPS-System angeboten. Der einfachste und zugleich aufwändigste Ansatz besteht darin, die klassische Systemarchitektur in der bestehenden Form zu belassen. Der Anwender erhält ergänzend in seinen Engineering-Tools – wie Visual Studio oder Eclipse – einen entsprechenden Cross-Compiler für die herstellerspezifische Laufzeitumgebung. So hat er die Möglichkeit in Hochsprache zu programmieren und erzeugt ausführbaren Code, der meist als Baustein in das eigentliche IEC-61131-Programm eingebettet wird.

Der Nachteil, dass er lediglich zu den Funktionen des Betriebssystems Zugang hat, die ihm der Hersteller des SPS-Systems in der Laufzeitumgebung zur Verfügung stellt, bleibt jedoch bestehen. Es kann somit sein, dass der Anwender auf ein Update des Steuerungssystems warten muss, um eine bestimmte Funktion zu implementieren (Bild 2).

Als zweite Alternative bekommt der Anwender eine komplett offene, häufig auf dem Linux- oder Windows-Betriebssystem basierende Hardware – sozusagen einen Industrie-PC im Formfaktor einer Steuerung. Mit dieser Lösung kann er bis in die Tiefen des Betriebssystems vordringen, muss sich allerdings selbst um die Echtzeitausführung der Programme und den konsistenten Datenaustausch zwischen ihnen kümmern. Denn in klassischen SPS-Systemen handelt es sich hierbei um Funktionen, die in der nun nicht mehr mitgelieferten Laufzeitumgebung enthalten waren. Dieser Ansatz unterstützt den Anwender also nur bedingt bei der Umsetzung seiner Anforderungen (Bild 3).

Als drittes Konzept lassen sich die beiden vorher beschriebenen Ansätze in einem Gerät kombinieren. Die Laufzeitumgebung erlaubt folglich die Einbindung von Hochsprachenprogrammen als Bausteine, gewährt aber keinen Zugriff auf die Betriebssystem-API. Ferner wird ein offenes Betriebssystem wie Windows oder Linux bereitgestellt, jedoch nicht für die Abarbeitung der Programme in Echtzeit gesorgt. Obwohl mit dieser Lösung alle Anwendungsfälle abgedeckt sein sollten, ist das in der Praxis nicht der Fall. Insbesondere dann, wenn der Anwender einen Protokoll-Stack einbauen möchte, der die API des Betriebssystems bedienen und in Echtzeit ausgeführt werden muss, stößt der dritte Ansatz ebenfalls an seine Grenzen (Bild 4).

Unabhängig voneinander in das System integriert

Die drei erläuterten Konzepte zur Realisierung der steigenden Anforderungen mit klassischen SPS-Systemen sowie die Analyse der jeweiligen Nachteile verdeutlichen, worin das eigentliche Problem besteht: in der monolithischen Ausprägung der herstellerspezifischen Laufzeitsysteme. Diese umfassen sowohl die Ausführungsschicht, die den IEC-Programmen bestimmte Funktionen zur Abarbeitung zur Verfügung stellt, als auch den Scheduler, der die Echtzeitausführung, also das zeitsynchrone Starten von Threads verantwortet.

Bildergalerie
Bildergalerie mit 5 Bildern

Darüber hinaus beinhalten die Laufzeitsysteme Komponenten, die sich um den konsistenten Prozessdatenaustausch der Programme untereinander sowie mit den angeschlossenen Feldbussen kümmern. Deshalb integriert die PLCnext Technology die drei für die Entwicklung von Automatisierungsapplikationen wichtigen Komponenten unabhängig voneinander in ein System. Das bedeutet, dass die IEC-Laufzeit zur Abarbeitung von Programmen, die im Engineering-Tool PLCnext Engineer gemäß IEC 61131-3 geschrieben worden sind, ein Programm neben anderen ist, welche in Hochsprache oder Matlab Simulink erstellt sein können.

Auf diese Weise kann jedes Hochsprachenprogramm die API des Betriebssystems direkt nutzen und trotzdem in Echtzeit ausgeführt werden. Dies, weil das Scheduling betriebssystemweit von einer separaten Komponente erledigt wird, dem Execution and Synchronisation Manager (ESM). Der ESM ermöglicht somit das betriebssystemweite Scheduling von beliebigen Programmen – egal, ob sie durch C++-Tools, Matlab Simulink oder innerhalb der Laufzeit aus dem eigenen IEC-61131-Engineering generiert worden sind (Bild 5).

Ähnlich verhält es sich mit dem konsistenten Datenaustausch zwischen Programmen, Tasks und den angebundenen Feldbussen. Diese Funktion, Global Data Space (GDS) genannt, ist ebenfalls als separate Komponente in die PLCnext Technology implementiert.

Die Lösung bietet dem Programmierer die Möglichkeit, die relevanten Daten über In- und Out-Ports am GDS anzumelden, auf den dann weitere Programme zugreifen können. Der Global Data Space bildet gewissermaßen ein Shared Memory, das dem Programmierer viele Aufgaben abnimmt. Setzt er den GDS ein, muss sich der Programmierer keine Gedanken über das Blockieren von Speicherbereichen machen und keine eigenen Buffer-Mechanismen mehr einbauen. Sie sind in der GDS-Komponente enthalten.

Neben der Kombination verschiedener Programme aus unterschiedlichen Engineering-Tools zu einer Applikation lassen sich Programme auch ohne Verwendung des ESM direkt durch das Betriebssystem verwalten. Das freilaufende, eventgesteuerte Programm kann durch Nutzung des GDS aber auf die Prozessdaten der in Echtzeit ausgeführten Programme zugreifen.

Damit eröffnet die PLCnext Technology die größtmögliche Flexibilität in den Bereichen, in denen jede andere Systemarchitektur an ihre Grenzen stößt. Aufgrund der unzähligen Konstellationen könnte beispielsweise ein Programm außerhalb der Echtzeitumgebung eine kontinuierliche Videostream- oder Bildanalyse durchführen. Die ermittelten Daten werden über den GDS an ein in IEC 61131 erstelltes Programm weitergeleitet, um etwa einen XY-Positioniertisch zu steuern.

Rund um die PLCnext Technology ist bei Phoenix Contact ein ganzes Ökosystem entstanden, über das der Anwender seine Geräte auf einfache Weise mit der Cloud verbinden kann. Dazu gehört die Steuerung AXC F 2152 mit dem Dual Core-Prozessor ARM9 und einer Taktfrequenz von 800 MHz für den mittleren Leistungsbereich. Ende 2018 ist zudem der PLCnext Store eingeführt worden. Er stellt Software-Applikationen (Apps) zur Verfügung, mit denen Anwender die PLCnext Controller um technische Funktionen erweitern können. Je nach App werden keine tiefen Programmierkenntnisse benötigt, um mit den Lösungen eigene Anwendungen umzusetzen.

Wegen der Offenheit des Stores können auch Drittanbieter die von ihnen entwickelten Apps hier zum Verkauf anbieten. Damit ist der PLCnext Store nicht nur für die Nutzer der Steuerungstechnik interessant, sondern auch für Software-Anbieter. Durch den einfachen Zugang zu den Software-Applikationen sowie den verringerten Programmieraufwand wird die Anwendungsentwicklung beschleunigt. Neue Apps fördern Vielseitigkeit und Nutzungsmöglichkeit. Als weitere leistungsfähige Steuerung wurde Ende 2018 darüber hinaus die Sicherheits-SPS RFC 4072S vorgestellt.

* Michael Gulsch arbeitet im Business Development bei der Phoenix Contact Electronics, Bad Pyrmont.

(ID:45729728)