(openPR) An die Steuerungstechnik von hochwertigen Maschinen und Anlagen werden immer höhere Anforderungen gestellt. Laut VDMA werden im aktuellen Techniktrend immer stärker verteilte Systeme gefragt, bei denen Steuerungs-, I/O- und Grafikfunktionen in einem System integriert sind und in harter Echtzeit arbeiten.
STEINHOFF Automation- & Fieldbus Systems unterstützt mit der neuen Version 1.3 von DACHSview neben QNX 6.4 auch PREEMPT_RT LINUX. Beide neuen Versionen decken die oben genannten Forderungen ab, wobei die Minimierung der Systemkomplexität ein wesentliches Entwurfsziel war. Welche Probleme existierten und wie diese bei der Implementierung von DACHSview gelöst wurden, wird im folgenden Text aufgezeigt.
1. Die Mainstream SPS-Technologie ist in der IEC61131-3-Sackgasse
Aufgrund der Tatsache, dass der heute in den meisten SPS-Systemen verwendete IEC61131-3-Standard keine verteilten Systeme oder ereignisorientierte Echtzeitverarbeitung zulässt, können die aktuellen und zukünftigen Anforderungen mit IEC61131-3 basierten Steuerungssystemen nicht realisiert werden. An neuen Wegen führt also nichts vorbei, will man auch aktuelle und zukünftige Anforderungen erfüllen können.
2. Sind PC-basierte Real-Time-Betriebssysteme die Lösung?
Bei Real-Time-Betriebssystemen (RTOS) denkt man zuerst an den Einsatz von komplexe Entwicklungsumgebungen mit textuellen Sprachen, für die in der Regel Real-Time-Experten als Entwickler benötigt werden. Ein solcher Ansatz ist sehr kostenintensiv, wobei wegen der hohen Anfangsinvestitionen auch noch eine starke Abhängigkeit zum RTOS-Hersteller entstehen würde. Ein weiterer kritischer Punkt von PC-basierten Systemen, auch Programmable-Automation-Controller (PAC) genannt, ist die Komplexität des gesamten Systems mit Handlings-, Installations- und Programmier-Aufwand. Die vielen internen Schnittstellen, mit denen der Softwareentwickler konfrontiert wird, sollten auch nicht unterschätzt werden.
Ein alternativer Ansatz ist der Ersatz der textuellen Sprachen durch eine universelle grafische Programmiersprache als Entwicklungssprache für RTOS-Applikationen.
3. Grafische Programmiersprachen für Real-Time-Applikationen
Textuelle Sprachen, wie C und C++, können in die Steuerungswelt nicht ohne Akzeptanzverluste übertragen werden. Nach den positiven Erfahrungen mit den grafischen Sprachen des IEC61131-3-Standards liegt es nahe eine zu den textuellen Sprachen äquivalente grafische Sprache einzusetzen. Hier bietet sich die bekannte Funktionsblockdarstellung (FBD) an, da sie als formale Sprache im Vergleich zu den Textsprachen gleichmächtig ist.
Mit dem SPS-Standard IEC-61131-3 wurden jedoch in der FBD Restriktionen eingeführt, die erst beseitigt werden müssen sind, um funktional mit den Textsprachen gleichzuziehen. Es müssen beispielsweise FBD-Programme vom RTOS als normale RTOS-Prozesse behandelt werden, d.h. sie müssen unter der Kontrolle des RTOS-Schedulers ausgeführt werden. Dies ermöglicht, dass blockierende Funktionen unterstützt werden können, die auf RTOS-Ereignisse suspendiert warten und nicht aktiv zur Ereigniserkennung pollen müssen. Nur so können Reaktionszeiten im Bereich von Mikrosekunden erreicht werden, womit eine wesentliche Grundlage für die Echtzeitverarbeitung gegeben ist.
3.1 FBD als „general purpose“ Entwicklungssprache
Mit Funktionsblöcken sind unterschiedlichste Systemdetails kapselbar, womit der erste Schritt zur Minimierung der Komplexität getan werden kann. Funktionen von Teilsystemen, wie Grafik-, Feldbus-, Hardware- und Kommunikationsfunktionen können einheitlich über FBD-Bibliotheken implementiert werden. Damit kann der Entwickler Funktionen dieser Teilsysteme ohne Schnittstellenprobleme nutzen. Durch die Möglichkeit eigene, hierarchische Funktionsblöcke zu definieren und diese zu instanziieren, können intuitiv objektorientierte Konzepte auch von Mitarbeitern realisiert werden, die nicht unbedingt Informatiker sein müssen. Die FBD wird so als objektorientierte „general purpose“ Entwicklungssprache für Real-Time-Applikationen und -Steuerungen eingesetzt. Mit dieser erweiterten Implementierung der FBD ist es möglich die Komplexität der Softwareentwicklung auf ein Minimum zu bringen.
Im Gegensatz zur IEC61131-3 basierten Soft-SPS kann eine Real-Time-Soft-SPS für modulare Applikationen mehrfach auf einem Zielsystem gestartet werden. Jede Real-Time-Soft-SPS kann mehrere RTOS-Threads als Systemthreads starten. Wichtig ist, daß der Entwickler der Steuerungsapplikation keinen direkten Kontakt mit dem RTOS des Zielsystems benötigt.
Die FBD-Programmierung geschieht bei DACHSview unter MS-Windows auf einer PC-Workbench, die über eine UDP-Verbindung den Upload der Real-Time-Applikation zur remoten Real-Time-SoftSPS DACHSview-RT und den Online-Test unterstützt.
3.2 FBD-Bibliotheken für Hardware-,Feldbus-, Grafik-, Datenbank- und Mathematikschnittstellen
DACHSview stellt dem Steuerungsprogrammierer FBD-Bibliotheken zur Verfügung mit denen er Betriebssystemfunktionen bis runter zum Durchgriff auf Hardware nutzen kann. So können z.B. für den QNX-Target Interrupt-Service-Routinen in FBD geschrieben und auf I/O-Ports und PCI-Interfaces zugegriffen werden. Des Weiteren existieren FDB-Bibliotheken für statische und animierte 2D- und 3D-OpenGL-Grafiken. Diese Grafikfunktionen erlauben die Programmierung einzelner Pixel bis hin zur Nutzung komplexer Widgets. Des Weiteren werden FBD-Bibliotheken angeboten für Ethernet basierte Feldbusse wie PROFINET (RT/IRT), EtherCAT, Ethernet Powerlink und Modbus. Auch die klassischen Feldbusse PROFIBUS, INTERBUS, CAN und CANopen werden unterstützt. Speziell für die Real-Time-Linux basierte Version können mathematische Funktionen aus dem ROOT/CINT-System vom CERN2 genutzt werden. Dieses System stellt den Forschern vom CERN interessante Datenvisualisierungen und mächtige mathematische Bibliotheken für Datenauswertungen und Statistiken zur Verfügung.
3.3 Lokale und verteilte Systeme kommuniziren über Message-Passing-Middelware
Lokale und verteilte PC-Systeme werden mit DACHSview über die Message-Passing-Middelware ZeroMQ unterstützt, die eine sichere und mikrosekundenschnelle Kommunikation zwischen Linux, QNX Neutrino, MS-Windows und anderen Betriebssystemen bietet. Dies geschieht natürlich über eine FBD-Bibliothek.
4. Embedded PC-Hardware als Steuerungsplattform
Als Hardwarebasis steht heute PC-Hardware mit sehr leistungsfähigen Low-Power-CPUs zur Verfügung, die fallweise mehreren CPU-Cores besitzen. Diese leistungsfähigen, lüfterlosen embedded PC-Systeme bieten die ideale Basis für die heute geforderte Systemintegration. Da man die unterschiedlichen Systemfunktionen einzelnen CPU-Cores zuordnen kann, sorgen Multi-Core-CPUs dafür, dass sicherheitskritische Funktionen die geforderte Rechenzeit bekommen können. Zusammen mit diesen Hardwarevoraussetzungen bieten heute ausgereifte PC-basierte Real-Time-Betriebssysteme, wie das preemptive Real-Time Linux oder QNX Neutrino, alle Eigenschaften, um die geforderte Systemintegration und das erforderliche Echtzeitverhalten zu leisten.
5. Komplettlösungen
Um dem Endbenutzer den Handlings-, Installationsaufwand für die Integration aller Hardware- und Softwarekomponenten zu ersparen, wird ein komplettes System samt vorinstalliertem RTOS, der Real-Time-SoftSPS-, Feldbus-Hard- und Software und konfigurationsspezifischer Module angeboten. Das System kann wahlweise unter dem preemptiven Real-Time-Linux oder QNX Neutrino (ab Vers. 6.4.1) betrieben werden. Passend dazu wird die DACHSview-Entwicklungsumgebung für MS-Windows kundenspezifisch mit den optionalen RTOS-, Feldbus- und Grafikbiliotheken usw. angeboten.
6. Schlussbetrachtung
Die freie Verwendung der Funktionsblockdarstellung für alle Systemaspekte führt zu einer echten Innovation die Kompliziertes einfacher macht. Das Resultat ist eine durchgängige System- und Entwicklungsumgebung, die durch die Integration von Grafik-, SPS-, Feldbus-IO-, Datenbank- und Kommunikationsfunktionen das effiziente Entwickeln von umfassenden Steuerungsapplikation kostengünstig möglich macht. DACHSview wird eingesetzt in Materailflußsystemen, wie z.B. automatische Parkhäuser. Seine grafischen Fähigkeiten hat DACHSview bei der Entwicklung von ICE-Lokführerdisplays, basierend auf dem ETCS-Standard, bewiesen.
