Phoenix Contact PLCnext: Automatisierung ohne Grenzen

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 eine Plattform zur Verfügung, die umfassende Freiheitsgrade eröffnet.

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.

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.

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.

Mit der beschriebenen Systemarchitektur lassen sich Anforderungen an zukunftsgerichtete 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. Vor diesem Hintergrund werden verschiedene Optimierungslösungen für das klassische SPS-System angeboten.

Architektur der PLCnext Technology: Der API-Zugriff des Operation Systems in Echtzeitapplikationen ist möglich, was eine hohe Offenheit und Flexibilität erlaubt.

Architektur der PLCnext Technology: Der API-Zugriff des Operation Systems in Echtzeitapplikationen ist möglich, was eine hohe Offenheit und Flexibilität erlaubt.

Optimierungsansätze für klassische SPS-Systeme

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.

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.

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.

Klassische SPS-Architektur mit herstellerspezifischer Laufzeitumgebung sowie ohne Zugriff auf die API des Operating Systems.

Klassische SPS-Architektur mit herstellerspezifischer Laufzeitumgebung sowie ohne Zugriff auf die API des Operating Systems.

Erweiterung der Engineering-Werkzeuge von Drittherstellern um Cross Compiler, wobei dennoch kein Zugriff auf die API des Operating Systems möglich ist.

Erweiterung der Engineering-Werkzeuge von Drittherstellern um Cross Compiler, wobei dennoch kein Zugriff auf die API des Operating Systems möglich ist.

Betriebssystemweites Scheduling beliebiger Programme

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. 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 PC Worx 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.

Offenes System mit direktem Zugriff auf die API des Operating Systems; dadurch ist allerdings kein Scheduling und kein konsistenter Prozessdatenaustausch möglich.

Offenes System mit direktem Zugriff auf die API des Operating Systems; dadurch ist allerdings kein Scheduling und kein konsistenter Prozessdatenaustausch möglich.

Kombination eines offenes Systems mit API-Zugriff des Operation Systems, jedoch ohne Echtzeit und eines Echtzeitsystems ohne API-Zugriff des Operation Systems.

Kombination eines offenes Systems mit API-Zugriff des Operation Systems, jedoch ohne Echtzeit und eines Echtzeitsystems ohne API-Zugriff des Operation Systems.

Konsistenter Datenaustausch von Programmen, Tasks und Feldbussen

Ä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 bereits in der GDS-Komponente enthalten.

Neben der Kombination verschiedener Programme aus unterschiedlichen Engineering-Tools zu einer Automatisierungsapplikation lassen sich Programme auch ohne Verwendung des ESM direkt durch das Betriebssystem verwalten. Das frei laufende, durch Events gesteuerte 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.

Filtern

Suchbegriff

Unterkategorie

Firmen

Inhaltstyp

Firmentyp

Land