Innovationshemmend wirkt sich zudem aus, dass Technologietrends oft nur von wenigen Herstellern entwickelt und getragen werden. So gibt es beispielsweise bis heute kein Standardprotokoll zur Weiterleitung von Prozessdaten über das Netzwerk. Einige Hersteller treiben ihr eigenes Protokoll voran, andere Anbieter integrieren entsprechende Schnittstellen in ihre Geräte. Daraus resultieren verschiedene Protokolle, welche die gleichen Anforderungen umsetzen. Hat sich der Anwender also für ein Protokoll entschieden, ist er häufig an das Produktportfolio der jeweiligen Anbieter gebunden. Außerdem muss er mit dem Engineering-Werkzeug programmieren, das der Hersteller für seine Hardware anbietet. Möchte der Anwender den Hersteller wechseln, sind seine Mitarbeiter auf die neue Software zu schulen, obwohl die Programmiersprache an sich genormt ist. Allein die etwas andere Bedienphilosophie macht den Umstieg auf ein neues Tool unnötig schwer.
Einbindung von Open-Source-Funktionen
Da immer mehr typische IT-Anwendungen – wie die Kommunikation mit Datenbanken, Cloud Computing oder eine direkte Ankopplung an ERP-Systeme – Einzug in die klassische Steuerungstechnik halten, offenbart sich die eigentliche Schwäche der meisten Systeme: Die Einbindung von Funktionen, die oftmals als Open Source zur Verfügung stehen, gestaltet sich schwierig. Sie müssen häufig mit hohem Zeitaufwand in das entsprechende Engineering übertragen werden, wo die Abarbeitung in einer Echtzeitumgebung stattfindet. Aufgrund der nicht-deterministischen Ethernet-Kommunikation erweist sich das meist als problematisch. Vor diesem Hintergrund hat sich Phoenix Contact die Frage gestellt, wie eine zukunftsfähige Steuerungsplattform aussehen muss, deren Anwender von der Open-Source-Community profitieren, ihre Applikation schneller automatisieren und dabei nicht zur Verwendung des Engineering-Werkzeugs des jeweiligen Herstellers gezwungen sind. Falls die drei genannten Möglichkeiten für sie nicht relevant sind, wollen die Anwender zumindest so mit dem System agieren, als ob sie mit einer klassischen SPS arbeiten. Als Antwort auf diese Anforderungen ist die komplett neu entwickelte und in dieser Form einzigartige Technologieplattform PLCnext Technology entstanden. Was diese Plattform auszeichnet und besonders macht, soll nachfolgend anhand der Systemarchitektur erklärt werden.
Abarbeitung von Code in und außerhalb von Echtzeit
Neben der ARM- oder x86-basierten Hardware stellt das Betriebssystem den wesentlichen Bestandteil eines modernen Prozessorsystems dar. Um in einer Steuerung eingesetzt werden zu können, muss das Betriebssystem echtzeitfähig sein, weshalb nicht jede Lösung genutzt werden kann. Bei der Auswahl des Betriebssystems spielt zudem die Verfügbarkeit von Code, Bibliotheken oder ganzen Applikationen eine entscheidende Rolle. Aufgrund dieser Rahmenbedingungen hat sich Phoenix Contact bei der PLCnext Technology für Linux mit Echtzeiterweiterung entschieden. Auf diese Weise ist die Ausführung von Code in und außerhalb des Echtzeitkontextes möglich. Mit Linux können Programme zur Maschinensteuerung somit deterministisch abgearbeitet werden, während beispielsweise die Kommunikation mit Datenbanken außerhalb der Echtzeit läuft. Damit der Anwender in der gewohnten Umgebung gemäß IEC 61131-3 programmieren kann, muss die Laufzeitumgebung oberhalb des Betriebssystems angesiedelt sein, sodass sie mit dem Engineering-Werkzeug – bei Phoenix Contact mit PC Worx Engineer – kommunizieren kann. Die dort erstellten Programme werden auf die Steuerung geladen und in der Laufzeitumgebung ausgeführt. Die PLCnext Technology erscheint also bisher wie eine klassische SPS, nur das ein offenes Betriebssystem Anwendung findet. Zur Realisierung einer typischen modernen Applikation reicht ein solcher Ansatz jedoch nicht aus.
Weiterleitung von Datensätzen in einem festen Zeitabstand
In der Regel schreibt der Anwender das Programm zur Maschinensteuerung in IEC 61131-3. Nun möchte er einen mit Matlab Simulink oder C++ erstellten Regler in die Applikation einbinden, ohne ihn in IEC 61131-3 umschreiben zu müssen. Das Umschreiben ist oftmals notwendig, da die meisten Systeme den direkten Zugriff aus dem Hochsprachenprogramm auf Betriebssystemfunktionen nicht erlauben. Ferner sind viele Applikationen direkt an eine Datenbank angekoppelt – und das unter Umständen über eine VPN-Verbindung. Wegen der Netzwerkinfrastruktur sowie der Eigenschaften von TCP/IP und UDP/IP als Transportmechanismus erweist sich die Umsetzung der Kommunikationsaufgabe innerhalb der Echtzeitumgebung – wie bereits beschrieben – als problematisch. Dies, weil der Übertragungskanal – das Netzwerk oder das Internet – nicht deterministisch ist. Deterministisch bedeutet, dass die Applikation die Weiterleitung eines Datensatzes in einem festen Zeitabstand erwartet, was aufgrund der Netzwerkeigenschaften nicht unbedingt der Fall ist. Vielmehr täuscht die hohe Übertragungsgeschwindigkeit einen gewissen Determinismus vor: Bis ein neues Paket gesendet wird, ist das vorherige Paket sicher schon beim Empfänger eingetroffen. Der Anwender baut daher Wartezyklen in sein Programm ein oder reduziert das Datenvolumen so weit, dass selbst langsame Netzwerke einigermaßen funktionieren. Aus diesem Vorgehen resultieren unnötige Verzögerungen innerhalb der Applikation sowie ein erheblicher Programmieraufwand. Besser wäre es die Kommunikationsfunktionen außerhalb der Echtzeitumgebung des Geräts zu realisieren, denn dann ist die eigentliche Maschinenanwendung unabhängig von der Qualität des Übertragungskanals.
