In einigen Industriezweigen gewinnt die modellbasierte Entwicklung ständig an Popularität, denn sie erlaubt eine Verifizierung des Gesamtmodells mittels der Simulation von Anlagen und Anlagenregelungen. In diesem Kontext kommt Matlab/Simulink eine führende Rolle zu. Trotzdem erfolgt die Implementierung in ein Automatisierungssystem weiterhin meist durch eine manuelle Umwandlung der Regelalgorithmen in einen IEC61131-3-basierten Code, der auf dem Controller abgearbeitet werden kann. Neben dem zusätzlichen Zeitaufwand wegen der manuellen Transformation von Modellen erweist sich das beschriebene Verfahren gerade bei komplexen Regelalgorithmen als fehleranfällig und zieht einen hohen Testaufwand nach sich. Fehler im Modell lassen sich nicht vor Ort, sondern über eine umständliche Suche im IEC-Code detektieren. Besser wäre ein natives Zusammenspiel zwischen Modell und SPS-Programm.
Determinismus und Echtzeitfähigkeit kein Thema
Mit PLCnext Target for Simulink hat Phoenix Contact genau für diesen Anwendungsfall eine Lösung erarbeitet. Über die Schnittstelle wird das Modell aus Matlab/Simulink automatisch in die offene Steuerungsarchitektur PLCnext Technology integriert und so auf eine neue Art verwendet. Bei PLCnext Technology handelt es sich um ein offenes Ecosystem für aktuelle und zukünftige Automatisierungsanforderungen, das auf Linux aufsetzt und die Vorteile dieses Betriebssystems einfach nutzbar macht. Als Grundlage dient eine intelligente Schicht zwischen dem Anwenderprogramm und dem Betriebssystem, über die sämtliche Systemkomponenten Daten synchron und in Echtzeit austauschen. Aufgrund dieser offenen Schnittstelle lässt sich jede Projektaufgabe mit dem passenden Tool realisieren.
Im Ecosystem fungiert PLCnext Engineer als Engineering-Oberfläche für die Steuerungen von Phoenix Contact. Die in den unterschiedlichen Disziplinen erzeugten Projektteile werden in diesem Tool zusammengeführt, ohne dass sich der Entwickler Gedanken über Determinismus und Echtzeitfähigkeit machen muss. Dazu laufen die Hochsprachenprogramme und Modelle im Echtzeitkontext und sind deterministisch sequenziell oder parallel zu den in IEC 61131-3 erstellten Programmen ausführbar.
Automatische Code-Generierung
Mit PLCnext Target for Simulink stellt Phoenix Contact die Schnittstelle im Ecosystem zur Entwicklungsumgebung Matlab/Simulink bereit. Das Add-on ermöglicht, dass der Code des zu implementierenden Modells für alle gängigen Industriesteuerungen der Produktfamilien Remote Field Controller (RFC) und Axioline Controller (AXC) automatisch generiert wird. Zu diesem Zweck erzeugt es die Schnittstelle zwischen dem im Simulink Coder erstellten Programm und dem PLCnext-Framework. Das Add-on bietet dem Simulink-Anwender zudem erweiterte Einstellungsoptionen. Auf diese Weise lassen sich zum Beispiel spezielle Änderungen am Code oder anderen Konfigurationsmöglichkeiten vornehmen, bevor sie mit nur einem Mausklick generiert und kompiliert werden.
Die Integration des Modells ist einfach und intuitiv gehalten. Der aus Simulink erzeugte gerätespezifische Code des implementierten Modells kann als Programm in ein Projekt eingebunden und als Task mit einer beliebigen Taskzeit auf einer PLCnext-fähigen Steuerung ausgeführt werden. Dadurch ist ein Zugriff auf sämtliche Funktionen des offenen Ecosystems PLCnext Technology möglich. Erstellte Modelle lassen sich beispielsweise in Kombination mit PLCnext-Steuerungen ganzheitlich simulieren, was anspruchsvolle Fehleranalysen wesentlich vereinfacht. Anwender erhalten mit dem PLCnext Target for Simulink eine Vielzahl von Optionen, die deutlich über den üblichen Funktionen einer Engineering-Umgebung für Steuerungssysteme liegen.
Direkte Nutzung der Test-Harnische
Im Rahmen der anforderungsgerechten Modellentwicklung kann ein Modell während der Konzeptionsphase ständig durch Tests verifiziert werden. Das geschieht auf Basis von Simulationen des Modells in Simulink, wobei oftmals die Toolbox-Erweiterung Simulink Tests zum Einsatz kommt. Nachdem die SIL-Tests (Software-in-the-Loop) abgeschlossen sind, erfolgt der HIL-Test (Hardware-in-the-Loop) auf der eigentlichen Zielhardware. Dazu verfügt das Add-on PLCnext Target for Simulink über die PLCN.Testmanager-Klasse, über die sich die HIL-Tests auf den PLCnext-Steuerungen schnell aufsetzen und durchführen lassen.
Dabei wird das Modell zuerst lokal simuliert sowie die Inputs und Outputs aufgezeichnet. Anschließend lädt der Entwickler das Modell auf die PLCnext-Steuerung, füttert es mit den in Simulink protokollierten Inputs und simuliert es in der Hardware. Danach lädt er die Output-Daten von der Steuerung herunter und vergleicht sie mit den Output-Daten der lokalen Simulation. Diese Tests lassen sich zusammen mit der Simulink Testbox verwenden und dort einfach in bestehende Test-Cases integrieren. Darüber hinaus können die Test-Harnische von Simulink direkt für die HIL-Tests genutzt werden.
Lizenzfreie Alternative zum External-Mode
Wenn ein Modell schon auf der Steuerung läuft und alle Tests absolviert hat, erweist es sich häufig als nützlich, sich einen Überblick über die Modellsignale und -ausführung zu verschaffen. Zu diesem Zweck lässt sich entweder der in Simulink vorhandene External-Mode oder das Add-in „Viewer for Simulink“ für PLCnext Engineer einsetzen. Beim External-Mode kann der notwendige Interface-Code optional in die Modell-Binaries hinein generiert und der External-Mode-Server zur Laufzeit für jedes PLCnext-Programm mit konfigurierbarem Port an- oder ausgeschaltet werden. Der External-Mode läuft also nur bei Bedarf und es lassen sich Modellsignale anzeigen sowie Parameter anpassen.
Der External-Mode hat aber auch Nachteile: Zunächst wird für die Verwendung eine Matlab-Lizenz benötigt. Außerdem sind viele Signale lediglich sichtbar, sofern sie vorher konfiguriert wurden. Signale in Referenzmodellen sind gar nicht sichtbar. Viewer for Simulink stellt eine Alternative zur Verfügung. Über das Add-in für die PLCnext-Steuerungen lässt sich der gesamte Modellinhalt gemeinsam mit den bestehenden Signalen visualisieren. Limitierungen kann der Entwickler konfigurieren. Gleiches gilt für den Inhalt von Referenzmodellen. Ferner können sämtliche Signale verändert oder auf einen bestimmten Wert gezwungen werden. Bisher funktionierte der Viewer for Simulink nur für PLCnext-Programme. Nun ist eine Erweiterung auf Funktionsbausteine für die PLCnext-Modelle geplant.
Keine Probleme bei Division-durch-Null
Während der Modellentwicklung stellt der Umgang mit Division-durch-Null-Fehlern und anderen FPU-Exceptions (Floating Point Unit) ein meist zeitraubendes Thema dar. Für den Modellentwickler ist der Unterschied zwischen einem kleinen meist Double-Wert und einer Null, der oft durch unerwartete Input-Daten verursacht wird, häufig marginal. Der Prozessor, der durch diese Null dividieren soll, kann damit ein schwerwiegendes Problem haben. Selbst wenn dies nicht zutrifft und als Ergebnis NaN (not a number) durch das Modell weiterpropagiert wird, zeigt sich das als kritisch für die Funktionalität des Modells an sich.
In PLCnext Target for Simulink lässt sich das Verhalten in solchen Fällen frei einstellen. Entweder kann die Division ignoriert werden, was zur beschriebenen Propagation von NaN führt. Oder der Fehler wird detektiert und bringt lediglich das Modell/PLCnext-Programm in den Fehlerzustand. In diesem Fall zeigen die Diagnose-Ports des Programms die Fehlerart an und der Entwickler kann eine genauere Beschreibung im Handbuch nachschlagen.
Automatische Erzeugung eines Eclipse-Projekts
Zur detaillierten Untersuchung des Modellverhaltens oder der Fehler ist es sinnvoll, die C/C++-Ebene zu betrachten. Beim Erstellen der PLCnext Library wird automatisch ein Eclipse-Projekt miterzeugt, mit dessen Hilfe sich der generierte Code anpassen und neu bauen lässt – etwa um Log-Nachrichten einzufügen oder Fehler zu debuggen.
In den erstellten Eclipse-Projekten ist zudem eine Gdb-Server-Remote-Debugging-Konfiguration voreingestellt. Sie unterstützt dabei, ein auf der Steuerung laufendes Modell in wenigen Schritten zu debuggen. Das Linux-Programm Gdb steht dem Entwickler mit seinen Werkzeugen in vollem Umfang zur Verfügung. Er kann zum Beispiel Breakpoints setzen, um sich das Verhalten und die Variablen an bestimmten Stellen im Detail anzuschauen. Während der Verbindung über den dgbserver lassen sich auch Exceptions und Signals schnell lokalisieren. Im Fall eines Division-durch-Null-Fehlers hält der Debugger an und markiert die Stelle im C/C++-Code, sodass der entsprechende Fehlerblock und die Ursache bestimmt werden können. Statt den Umweg über Gdb-Server zu nehmen, lässt sich Gdb ebenfalls auf der Steuerung nutzen – ein weiterer Vorteil des Linux-Betriebssystems.
