Um zu erklären, was die PLCnext-Plattform 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.
Integration neuer Protokolle nur schwer möglich
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. Denn vorhandene Bibliotheken in Form von DLL (Dynamic Link Library) für Windows-basierte Systeme oder Shared Objects (.so) in Linux-Lösungen können nicht ohne Weiteres in ein klassisches System eingebunden werden. 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.
Optimierungsansätze für klassische SPS-Systeme
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. Als Ergänzung erhält der Anwender in seinen Engineering-Tools – wie Visual Studio oder Eclipse – einen Cross-Compiler für die herstellerspezifische Laufzeitumgebung. Damit 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. Es bleibt jedoch der Nachteil bestehen, dass er lediglich zu den Funktionen des Betriebssystems Zugang hat, die ihm der Hersteller des SPS-Systems in der Laufzeitumgebung zur Verfügung stellt. 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 Linux oder Windows 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.
Die drei erläuterten Konzepte und ihre jeweiligen Nachteile verdeutlichen somit: 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.
Kombination dreier Komponenten
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. Das ist möglich, weil das Scheduling betriebssystemweit von einer separaten Komponente erledigt wird, dem Execution and Synchronisation Manager (ESM). Der ESM erlaubt 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.
Konsistenter Datenaustausch
Ä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. Die ermittelten Daten werden dann über den GDS an ein in IEC 61131 erstelltes Programm weitergeleitet, um einen XY-Positioniertisch zu steuern.
PLCnext Store für neue Geschäftsmodelle
Rund um die PLCnext-Plattform 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 sowie das Modell RFC 4072S mit leistungsfähigem Core i5 mit 2,4 GHz Dual-Core. Über den PLCnext Store kann jeder Programmierer seine Bibliotheken, Programme oder ganze Applikationen vertreiben. Die offene Plattform trägt also zur Generierung neuer Geschäftsmodelle bei. Ferner können Anwender noch schneller eine Lösung für ihre jeweilige Automatisierungsanforderung finden. Über die offene und leistungsfähige Steuerungsplattform sind Anwender auch offen und vorbereitet für neue Technologien wie Augmented Reality und Künstliche Intelligenz.
