Hochsprachen werden seit Jahrzehnten eingesetzt, wobei die Softwaretools ständig weiterentwickelt wurden. Neben den Tools der Hochsprachen entstanden parallel auch spezialisierte Softwareentwicklungstools, die an die Entwicklung von logischen Steuerungsabläufen angepasst, und von denen einige im IEC61131-3- Standard aufgenommen wurden. Dieser setzt, im Gegensatz zu den Hochsprachentools, eine hardware- und betriebssystemabstrahierende Laufzeitumgebung voraus, in der bewusst Einschränkungen eingeführt wurden. In einer komplexer werdenden Automatisierungswelt sind jedoch genau diese Einschränkungen der IEC61131-3-basierten Systeme der Grund, warum die Integration von Hochsprachen immer öfter gewünscht wird. Die größte Hürde sind dabei die unterschiedlichen Anforderungen beider Systeme an die Laufzeitumgebung.
Thread-Umgebung & Integration
Beim kooperativen Scheduling von Threads in IEC61131-3-Targetsystemen können deren Threads nicht blockierend auf asynchrone Events warten, da sonst das komplette Laufzeitsystem, also alle anderen Threads, blockiert würden. Die Erkennung von Events kann nur im Rahmen eines SPS-Zyklusses erkannt werden. Deshalb können kleine Reaktionszeiten auf Events nur ineffizient durch kleinere SPS-Zykluszeiten erkauft werden. Der Einsatz von Hochsprachen setzt Prozesse voraus, die mehrere Threads enthalten, wobei diese unter der Kontrolle des Schedulers des Betriebssystems ablaufen. In den Threads kann suspendiert auf Events gewartet, und innerhalb von µsec erkannt und verarbeitet werden. Events können Hardwareinterrupts, der Empfang einer Nachricht, die Freigabe einer Semaphore bzw. Mutex-Variablen oder der Empfang eines Signals sein. Würde man C/C++ in bestehende IEC61131-3-Targetstrukturen integrieren, verliert C/C++ wesentliche Vorteile und würde zum objektorientierten \’Strukturierten Text\‘ reduziert. Weitere Aspekte beim Einsatz von Hochsprachen sind der freie Zugang zu physikalischem Speicher, Multicore-Konfigurationen, Geräteschnittstellen, und direkte Nutzung von C-Applikationen und Bibliotheken. Derartige Zugänge lassen sich nur eingeschränkt innerhalb von IEC61131-3-Targets realisieren. Letzten Endes muss man sich von den überkommenen Targetstrukturen verabschieden und zumindest Systemthreads als Threads in IEC61131-3-Targets zulassen. Das Targetsystem des Dachsview++ wurde daher modifiziert und unterstützt bis zu 15 Systemthreads, in denen jeweils eine einzelne Instanz der VM des Targets läuft.
- Diese Threads laufen unter der Kontrolle des Schedulers des RTOS QNX6/Linux.
- Die Abarbeitung von Steuerungscode kann frei und individuell implementiert werden.
- Eine Zeitüberwachung von Steuerungszyklen kann vorgesehen werden.
Die Darstellung der Funktionsblockapplikationen entspricht dem CFC-Standard.
Voller Multicore-Support
Es muss betont werden, dass nur mit Systemthreads eine vollständige Unterstützung von Multicore-CPUs möglich ist. Für Dachsview++ steht für Multicore-Applikationen die MTAPI-Library als Funktionsblockbibliothek zur Verfügung, und zwar so, wie sie von der Multicore Assoziation definiert wurde.
Schnittstellenimplementierung
Zur dynamischen Integration von Funktionen aus Bibliotheken wurden Servicefunktionsblöcke implementiert, die die jeweiligen Systemaufrufe aus der Hochsprachenwelt enthalten. Dies ist der einfachste Ansatz für die Nutzung von C/C++-Code innerhalb eines Steuerungstargets. Die Nutzung von textuellen Interpretersprachen wie Python oder Lua wurde über deren Interfaces zur C/C++Welt realisiert. Im Dachsview++ wurde dies für den objektorientierten Interpreter Lua implementiert. Die Integration von textuellem C- bzw. C++-Code als ausführbaren Code von Funktionsblöcken ist das am Schwierigsten zu implementierende, aber auch das interessanteste Feature.
