Software-Entwicklung
Die Vorteile der grafischen Modellierung
Die modellbasierte Software-Entwicklung findet im Automatisierungsumfeld immer mehr Anhänger. Bei der automatischen Code-Generierung in eine textuelle Programmiersprache geht allerdings die Ähnlichkeit zum Quellmodell verloren und eine Code-Rückübersetzung ist nicht mehr möglich. Eine grafische Übersetzung kann hier Abhilfe schaffen.
Der Einsatz einer modellbasierten Entwicklung von Reglern stellt eine Brücke zwischen Modell und Code dar. Mit ihr lässt sich der Zeitaufwand für die Programmerstellung reduzieren und damit letztendlich Kosten sparen. Insbesondere Fehler, die bei einer manuellen Übersetzung auftreten, sind so vermeidbar. Viele Entwicklungsumgebungen unterstützen die automatische Code-Generierung für die Programmiersprache C, wie beispielsweise Matlab/Simulink. Mittels des so genannten Real Time Workshop (RTW) von Mathworks generiert diese Entwicklungsumgebung automatisch einen lauffähigen C-Code. Zudem unterstützt Matlab die Übersetzung eines Simulink-Modells in die textuelle Programmiersprache Structured Text (ST) der IEC 61131-3.
Für die Verständlichkeit des generierten Codes ist die Vergleichbarkeit zum Quellmodell erforderlich. Die Vergleichbarkeit zum Quellmodell ist bei Code-Generatoren, die das Simulink-Modell in eine textuelle Programmiersprache übersetzen, allerdings nur durch die Übernahme der Namensbezeichner aus dem Simulink-Modell gewährleistet. Dadurch kann zwar die Fehlersuche im Code ermöglicht werden; im Gegensatz zu einer grafischen Darstellung ist diese jedoch mühsam und zeitaufwendig. Auch eine automatische Rücktransformation bei Änderungen im Programmcode ist nicht möglich, da eine textuelle Programmiersprache nicht in ein grafisches Modell zurück übersetzt werden kann. Um Modell und Code beispielsweise zur Fehlerbehebung oder Code-Anpassung konsistent zu halten, ist es daher notwendig, nach den Namensbezeichnern im Modell zu suchen und die Änderungen manuell nachzuziehen.
Im Gegensatz zu einer textuellen Transformation wurde bei dem vom Lehrstuhl für Automatisierung und Informationssysteme (AIS) der Technischen Universität München in Zusammenarbeit mit Beckhoff Automation entwickelten Code-Generator eine grafische, strukturähnliche Übersetzung gewählt. Dafür wird das Simulink-Modell in die Programmiersprache Continuous Function Chart (CFC) transformiert, welche zwar keine der genormten IEC-61131-3-Programmiersprachen ist, jedoch von nahezu allen Herstellern unterstützt wird. Im CFC-Editor von Codesys beispielsweise, der Programmier- und Entwicklungsumgebung von 3S, auf welcher auch die Software-Umgebung von Beckhoff basiert, lassen sich die Funktionsbausteine frei platzieren. Auf diese Weise können selbst Rückkopplungen einfach realisiert und die Simulink-Struktur in CFC 1:1 nachgebildet werden. Ein Block in Simulink entspricht dabei genau einem Funktionsbaustein in CFC. Des Weiteren bietet CFC so genannte Makros an, mit denen mehrere Funktionsbausteine grafisch zusammengefasst werden können. Dadurch ist ebenso eine Subsystem-Struktur, wie sie in Simulink möglich ist, mittels CFC-Makros abbildbar.
Die Twincat-Bibliothek in Simulink: Die kategorisierten Blöcke können per Drag & Drop in das Modell eingefügt und simuliert werden. Durch die Eingabemaske ist die Parametrierung der Blöcke direkt in Simulink möglich.
© TU München (AIS)Zusammengefasst hat eine grafische Darstellung folgende Vorteile: Zum einen ermöglicht die grafische Programmiersprache CFC eine einfache und schnelle Fehlersuche im Code. Zum anderen lassen sich Fehler, die erst in der realen Umgebung auftreten, direkt beheben und das Modell durch eine automatische Rücktransformation dementsprechend anpassen. Zudem ist eine adaptive Wartung möglich, die es erlaubt, den Programmcode unkompliziert an veränderte technische Bedingungen der Umgebung anzupassen und das Modell dementsprechend ebenfalls mittels Rücktransformation zu synchronisieren. Kurzum: Ein Round Trip Engineering wird möglich.
Um das untersuchte Zeitverhalten eines Reglers in Simulink auch in der Zielumgebung zu gewährleisten, ist es notwendig, bei der automatischen Code-Generierung die Eigenschaften der Zielumgebung zu berücksichtigen. Diese sind bei einer SPS unter anderem die Zykluszeit und die Abarbeitungsreihenfolge des Programmcodes. Des Weiteren müssen kontinuierliche Blöcke in Simulink für die Code-Generierung vorab für die digitale Regelung diskretisiert werden. Damit werden die kontinuierlichen Blöcke in Simulink vom SPS-Code-Generator zwar nicht vollständig unterstützt; jedoch gilt diese Einschränkung für alle marktüblichen Code-Generatoren wie Real Time Workshop (RTW) von Mathworks oder TargetLink von dSpace. RTW empfiehlt zum Beispiel zunächst die kontinuierlichen Blöcke durch ein „Model Discretizer Tool“ von Matlab zu diskretisieren und weist darauf hin, dass kontinuierliche Blöcke nicht für eine Code-Generierung geeignet sind. Auch für einige diskrete Blöcke gibt es Einschränkungen: Bestimmte Eingänge – zum Beispiel Vektoreingänge – werden von den Code-Generatoren nicht unterstützt.
Die genannten Einschränkungen gelten auch für den SPS-Code-Generator. Der SPS-Code-Generator benutzt das übliche Speicherformat von Matlab/Simulink – die Model-Datei (MDL) –, um das Modell in eine für Codesys schnittstellenkonforme Datei (EXP-File) zu übersetzen. Die Übersetzung ist allerdings auch in andere Formate wie XML möglich. Auf diese Weise kann der Anwender das Simulink-Modell in Steuerungssoftware anderer SPS-Hersteller transformieren.
Mit einem Klick übersetzt
Durch Tests untermauert: Das Bestimmtheitsmaß des generierten Codes liegt nachweislich bei 99,9 %.
© TU München (AIS)Ein Regler wird in Simulink als Blockdiagramm modelliert, welches aus den Blöcken der Simulink-Bibliothek besteht. Ein Klick im SPS-Code-Generator übersetzt das komplette Simulink-Modell anschließend in die Programmiersprache CFC. Die Code-Generierung beginnt damit, dass für das gesamte Modell ein CFC-Funktionsbaustein angelegt wird. Blöcke aus der Simulink-Bibliothek, welche bereits eine Entsprechung in der Zielumgebung besitzen (zum Beispiel die Bausteine aus der Twincat-PLC-Standard-Bibliothek oder aus der Twincat-Controller-Bibliothek), werden nicht neu übersetzt, sondern direkt eingebunden. Die Zuordnung der einzelnen Blöcke in die entsprechenden Bausteine ist im Code-Generator definiert. Falls die Definitionen zwischen den Bibliotheken unterschiedlich sind beziehungsweise voneinander abweichen, findet im Code-Generator eine entsprechende Umformung statt. Ansonsten werden die Parameter direkt ohne Umrechnung an den entsprechenden Funktionsbaustein übergeben. Durch dieses Prinzip der 1:1-Bibliotheksübersetzung ist nicht nur die modellbasierte Entwicklung von Reglern möglich, sondern auch das Zurückführen des generierten Codes in das Simulink-Modell.
Bei Rückkopplungen zwischen Blöcken müssen in Simulink Verzögerungsblöcke eingefügt werden, um den Eingangswert des Blocks mit der Rückführung für die nächste Zykluszeit zur Verfügung zu stellen. Werden diese Verzögerungsblöcke nicht eingefügt, kommt es während der Simulation zur Ausgabe eines Fehlers, da sonst der Eingang des Blocks mit der Rückführung einen Wert erwartet, der noch nicht vorhanden ist. Durch die zyklische Abarbeitung des Programmcodes in einer SPS ist ein Verzögerungsglied dagegen nicht notwendig, weil ein Wert erst in der nächsten Zykluszeit zur Verfügung steht. Die Verzögerungsbausteine in Simulink werden daher während der Code-Generierung erkannt und automatisch eliminiert.
Twincat unterstützt eine Vielzahl von mathematischen und regelungstechnischen Funktionsbausteinen. Etliche davon finden sich auch in der Simulink-Bibliothek wie beispielsweise die Lookup-, Saturate- und DiscreteTransferFcn-Blöcke. Zusätzlich hat der Lehrstuhl AIS gemeinsam mit Beckhoff eine Twincat-Controller-Bibliothek in Simulink erstellt, um dem Anwender die Möglichkeit zu geben, mit diesen Bausteinen einen Regler in Simulink zu entwerfen. Die Twincat-Funktionsbausteine wie beispielsweise Notch- oder gleitendes Mittelwert-Filter oder auch 2- und 3-Punkt-Regler können somit direkt in Simulink für den Reglerentwurf verwendet werden. Dadurch lässt sich zusätzlich das Zeitverhalten der Funktionsbausteine sowie des Reglers untersuchen und mittels Code-Generierung automatisch ein lauffähiger CFC-Code generieren. Ebenso erlaubt ist die Kombination von Blöcken aus Simulink und der Twincat-Bibliothek; dies wird vom SPS-Code-Generator unterstützt.
Zeitverhalten zu 99,9 % identisch
Der Technologie-Editor: Dargestellt ist die Integration des Reglers in den UML-Editor.
© TU München (AIS)Für die Evaluation des SPS-Code-Generators wurden unterschiedlich komplexe Simulink-Modelle – einmal aus einer realen Papiermaschine und einmal aus einer realen Pitchregelung einer Windkraftanlage stammend – automatisch in CFC übersetzt. Der Blattwinkelregler der Windkraftanlage bestand aus mehreren unterschiedlichen Simulink-Blöcken und enthielt auch einige Reglerbausteine aus der Twincat-Controller-Bibliothek. Der Regler der Papiermaschine bestand aus mehreren Übertragungsfunktionen und Rückkopplungen.
Beide Modelle wurden zunächst in Simulink simuliert und das Zeitverhalten mittels Scope aufgezeichnet. Danach erfolgten eine Übersetzung mittels Code-Generator und anschließend der Import in die Steuerungssoftware Twincat. Der importierte Code konnte fehlerfrei übersetzt und der Online-Modus direkt gestartet werden. Mit Hilfe der Scope-View-Aufzeichnung von Twincat ließen sich zudem beide Aufzeichnungen des Zeitverhaltens übereinander legen und zusätzlich das Bestimmtheitsmaß berechnen. Das Ergebnis: Bei beiden Modellen lag das Bestimmtheitsmaß bei 99,9 %. Mit anderen Worten: Der in Simulink simulierte Regler weist zu 99,9 % das gleiche Zeitverhalten auch in der Zielumgebung auf.
In Summe lässt sich festhalten: Vor allem bei komplexen Reglern ist eine grafische Programmiersprache vorteilhaft, denn mit CFC ist der Quellcode strukturähnlich und damit intuitiv verständlich. Darüber hinaus kann der CFC-Code in das Simulink-Modell zurück überführt werden, die Wiederverwendbarkeit ist durch das Bibliotheksprinzip gegeben und die Regler lassen sich optimal an die Umgebung anpassen. Die Konsistenz von Modell und Code bleibt dabei immer erhalten.
Zurzeit wird der Code-Generator in den vom Lehrstuhl AIS entwickelten Unified Modeling Language-Editor eingebettet, welcher direkt in Codesys V3 integriert ist. Die objektorientierte Steuerungssoftware nach IEC 61131-3 ermöglicht die Ausführung der ausgewählten UML-Modelle auf der Steuerung. Durch die zusätzliche Einbettung von Reglern mittels des SPS-Code-Generators in ein Verhaltensdiagramm der UML können hybride Systeme unterstützt werden. Wegen der großen Bandbreite ist diese Unterstützung zunächst auf thermomechanische Prozesse beschränkt. Dadurch haben die Technologen aus diesem Bereich erstmals die Möglichkeit, mittels einer thermomechanischen Reglerbibliothek an Versuchsanlagen mehrere Versuchsreihen ohne Programmieraufwand durchzuführen.
Autor: Gülden Bayrak ist wissenschaftliche Mitarbeiterin am Lehrstuhl für Automatisierung und Informationssysteme (AIS) an der Technischen Universität München.













