PLCnext: Offene Plattform für simultanes Engineering

Anbieter zum Thema

Phoenix Contact GmbH & Co. KG

FAULHABER Antriebssysteme

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

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

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).

(ID:45729728)