Suchen

Automatisierungssuite Twincat 3.1 Wenn mehrere User online auf einer Steuerung arbeiten

| Autor / Redakteur: Dr. Josef Papenfort* / Dipl. -Ing. Ines Stotz

Inbetriebnahmen werden immer teurer. Zudem lässt sich häufig das entsprechende Personal nur schwer für eine aufwendige Inbetriebnahme gewinnen. Entsprechend naheliegend ist der Wunsch nach einer möglichst schnellen und einfachen Inbetriebnahme auch von komplexen Maschinen oder Anlagen.

Firmen zum Thema

Beckhoff realisiert offene Automatisierungssysteme auf Basis PC-basierter Steuerungstechnik.
Beckhoff realisiert offene Automatisierungssysteme auf Basis PC-basierter Steuerungstechnik.
(Bild: ©putilov_denis - stock.adobe.com)

Alle zwei Jahre bringt Beckhoff ein neues Build von Twincat auf den Markt – mit dem Ziel, das Arbeiten mit seinem Softwaresystem effizienter und schneller zu gestalten. Ein Build oder Erstellungsprozess ist in der Softwareentwicklung ein Vorgang, durch den ein fertiges Anwendungsprogramm automatisiert erzeugt wird. Komplexe Maschinen oder Anlagen lassen sich nur dann schnell und einfach in Betrieb nehmen, wenn parallel mit mehreren Programmierern gearbeitet werden kann. Mit der neuen Multi-User-Fähigkeit bietet Twincat jetzt die passende Lösung hierfür. Beckhoff hat sich für diese neue Funktion eines Prinzips bedient, welches auch schon für die Offline-Entwicklung in Teams verwendet wird. Offline ist klar, dass man eine Softwareentwicklung in einem Team nur mithilfe eines Source-Code-Kontrollsystems realisieren kann. Diese Möglichkeit ist nun in Twincat ebenfalls vorhanden und hier auch für den Online-Betrieb so umgesetzt, dass kein zusätzliches Know-how vorhanden sein muss.

Multi-User-Zugriff auf die SPS

Und wie gestaltet sich das Arbeiten im Team online auf einer Steuerung? Angenommen, dass Programmierer 1 sich auf der Steuerung einloggt und eine Änderung am Code vornimmt. Parallel sind noch Programmierer 2 und 3 eingeloggt. Da Programmierer 2 und 3 den Quellcode der Änderung nicht auf ihren Programmiergeräten haben, muss das Entwicklungssystem den Quellcode von Programmierer 1 so ablegen, dass auch Programmierer 2 und 3 darauf Zugriff haben.

Twincat nutzt dazu Git – die häufig verwendete Open-Source-Lösung für Sourcecodecontrol – mit einem Repository, das z. B. direkt auf der Steuerung liegen kann. Sobald Programmierer 2 sich einloggt, wird ein Fenster angezeigt, das die Änderungen gegenüber dem Source-Code-Stand auf dem Entwicklungsrechner von Programmierer 2 darstellt. Programmierer 2 kann dann die Änderungen von Programmierer 1 übernehmen oder auch beide Stände zusammenführen.

Dazu dient das bekannte Twincat Comparetool. Programmierer 2 erkennt genau die Unterschiede zwischen den Quellcodeständen und muss dann entscheiden, welcher Stand übernommen werden soll. Ein weiterer Vorteil der Verwendung von Git auf der Steuerung liegt darin, dass sich zu jeder Zeit ablesen lässt, wer welche Änderungen durchgeführt hat. Damit ist eine lückenlose Nachverfolgung während der Inbetriebnahme oder auch während des gesamten Lebenszyklus einer Maschine gegeben.

Variantenmanagement vermeidet Fehler

Sollen mehrere Varianten einer Maschine in Software abgebildet werden, wurden bislang entweder unterschiedliche Source-Code-Stände für verschiedene Varianten verwendet oder es wurde eine Meta-Software entwickelt, die alle Varianten abdeckt. Über eine Parametrierung wurden dann die Spezifika einer Variante erzeugt. Beides ist umständlich und fehlerbehaftet:

  • Unterschiedliche Software lässt sich nur schwer warten. Außerdem müssen Fehlerbehebungen in allen Softwarevarianten durchgeführt werden.
  • Die Meta-Software hat den Nachteil, dass unnötig viel Code zu sehen ist und die Konfiguration natürlich den maximalen Ausbau zeigt. Das meiste davon wird in einer bestimmten Variante aber gar nicht genutzt. Auch hier ist die Wartbarkeit der Software schwierig.

Die bessere Lösung stellt hingegen eine Software dar, die über eine einfache Einstellung in verschiedenen Varianten generiert wird. In der klassischen Hochsprachenprogrammierung nutzt man dazu die bedingte Kompilierung. In einem Twincat-Projekt gibt es aber neben der SPS-Programmierung auch Varianten mit unterschiedlicher I/O-Ausstattung. Dementsprechend ist ein Teilnehmer nicht immer vorhanden oder er hat jeweils unterschiedliche Parameter. Gleiches gilt im Bereich Motion Control für eine Bewegungsachse.

Aus diesem Grund stehen im neuen Twincat Build die sogenannten Projektvarianten sowie Gruppen davon für das gesamte Twincat-Projekt zur Verfügung. Auf diese Weise können zusätzlich variantenspezifische Einstellungen in Bereichen wie z. B. der I/O- oder Motion-Konfiguration vorgenommen werden. Die Pflege der Software ist nun wesentlich leichter. Es gibt nur noch eine Software für alle Maschinenvarianten. Beim Erzeugen einer spezifischen Variante muss lediglich die gewünschte Variante ausgewählt werden und schon wird automatisch die korrekte Software erzeugt. Versionierung und Wartung der Software sind somit einfach.

Verbesserungen bei der SPS

Im Bereich der SPS wurden zahlreiche Verbesserungen eingepflegt, um schneller und effektiver SPS-Code entwickeln und testen zu können. Gerade bei der objektorientierten Programmierung ist das Ziel eine bessere und einfachere Wartbarkeit und Wiederverwendung von Code. Die Nutzung von Interfaces ist hierbei eine Grundeigenschaft. Bisher konnte bei der Verwendung von Interface-Pointern zwar die Adresse angezeigt werden, eine Pointer-Dereferenzierung wurde aber nicht durchgeführt. Das ist jetzt mit Build 4024 möglich und führt ebenfalls zu einem verbesserten Engineering.

In den Hochsprachen C++ und C# ist die Programmierung von abstrakten Klassen mit abstrakten Methoden und Eigenschaften weit verbreitet. Diese Möglichkeit steht jetzt auch dem SPS-Programmierer zur Verfügung: Mit abstrakten Klassen lassen sich einfach Muster für Bausteine oder Klassen erzeugen. Diese Muster können dann beim Ableiten der abstrakten Klasse mit Code gefüllt werden. Damit nähern sich die SPS-Programmierer wieder einen Schritt an die Möglichkeiten von C++ und C# an.

Ähnlich verhält es sich mit der Ausnahmebehandlung. Kommt es zu einer Ausnahme (Exception), möchte auch der SPS-Programmierer darauf reagieren. Im Fall einer Division durch Null kann es sinnvoll sein, eine bestimmte Routine auszuführen, um die Maschine in einen sicheren Zustand zu bringen und so Maschinenschäden zu verhindern.

Der Mapping-Dialog wurde dahingehend optimiert, dass nicht alle Knotenebenen aufgeklappt sind. Dies führt zu einem kleineren Scroll-Bereich und damit zu einer besseren Übersicht während des Anlegens einer Verknüpfung, z. B. von der SPS zum I/O. So können die gesuchten Teilnehmer in diesem Dialog einfacher gefunden werden. Eine Option ermöglicht das Umschalten zwischen der alten, der neuen und einer automatisch angepassten Ansicht. Mit dem „Go To Link Variable“ konnte der Nutzer schon immer einfach von einem I/O-Teilnehmer zum Prozessabbild und zurückspringen. Bisher gab es aber keine Möglichkeit, vom Prozessabbild in den Code zu wechseln. Das ist jetzt mithilfe des Befehls „Go To Definition“ möglich, was die Fehlersuche erleichtert. Zudem wird das Programm übersichtlicher, da mit dieser Funktionalität auf die noch häufig verwendeten globalen Variablenlisten verzichtet werden kann.

Ein weiterer Vorteil liegt darin, dass der Programmcode von Bausteinen in grafischen Sprachen jetzt auch im Binärformat Base64 gespeichert werden kann. Auf diese Weise lässt sich das Laden und Speichern von Programmen mit einem hohen Anteil an grafischen Sprachen beschleunigen.

Online-Change von C++- oder Matlab/Simulink-Code

Bisher war es nur dem SPS-Programmierer möglich, im laufenden Betrieb der Maschine den Steuerungscode zu ändern. Da im praktischen Einsatz viele Maschinen oder Anlagen sich entweder nicht oder nur selten anhalten lassen, ist das auch ein notwendiges Feature. Wird hingegen C++ oder Matlab/Simulink für die Maschinensteuerung verwendet, konnte man diesen Code bisher nur in Verbindung mit einem Maschinenneustart ändern. Ein entsprechender Neustart ist allerdings in manchen Applikationen nicht zulässig. So dürfen insbesondere bei Prüfmaschinen Prozesse in der Regel nicht unterbrochen werden. Trotzdem sind immer wieder Programmänderungen erforderlich.

Als Lösung für diese Anforderung hat Beckhoff im neuen Twincat Build die Möglichkeit implementiert, auch C++- und Matlab/Simulink-Code im laufenden Betrieb auszutauschen. Hierzu wird der entsprechende Code speziell versioniert. Im laufenden Betrieb kann dann eine Version durch eine neue Version unter Erhalt der Daten ersetzt werden.

Zeitsynchronisierte Datensätze in verteilten Anlagen

In größeren Anlagen mit mehreren Steuerungen sind häufig bestimmte Daten auf einem zentralen Server zu speichern, um diese aggregierten Daten anschließend auswerten zu können. Die Schwierigkeit dabei ist, dass die Zeitstempel auf den unterschiedlichen Geräten sich nicht einheitlich generieren lassen. Werden dann Daten für eine zentrale Anwendung wie z. B. Twincat Scope aggregiert, ist auf dem zentralen System kein genauer zeitlicher Bezug möglich. Die Systemzeiten auf den einzelnen Steuerungen können dabei für eine Synchronisierung nicht ohne weiteres nachgestellt werden, da dies die gesamte Anwendung beeinträchtigen würde. Es bleibt nur die Möglichkeit, mithilfe einer Referenzuhr die Offsets zu den lokalen Uhrzeiten zu ermitteln, wenn Zeitstempel für zu aggregierende Daten erzeugt werden.

Aber welche Referenzuhr sollte man einsetzen? Um auf eine einfache Weise bereits eine mittlere Genauigkeit zu erreichen, eignet sich der kostenlose und auf allen Beckhoff-Geräten installierte (S)NTP-Service. Dieses Verfahren reicht bei verteilten Anlagen häufig aus, wenn es nur um den Vergleich von Daten geht.

Für eine noch höhere Genauigkeit bietet sich das Verfahren nach IEEE 1588 an. Diese auch PTP (Precision Time Protocol) genannte Methode kann sehr genau unterschiedliche SPSen zeitlich miteinander abgleichen, bedingt jedoch eine spezielle Hardware wie die Ethercat-Klemme EL6688. Eine weitere Steigerung der Genauigkeit ist dann nur noch durch explizite Verkabelung – also einem Ethercat-Kabel zwischen den Geräten – möglich.

Durch die im neuen Twincat Build eingeführte Schnittstelle für eines dieser Verfahren lassen sich nun korrigierte Zeitstempel für unterschiedliche Daten verwenden und in aggregierten Datenbanken somit auch vergleichbare Zeitstempel erreichen.

Sichere Kommunikation mit Secure ADS

Das Beckhoff-Protokoll ADS wurde schon mit der ersten Twincat-Version eingeführt und im Kern nie geändert – aber immer wieder um Features erweitert. Eine neue Eigenschaft im Twincat Build 4024 ist, dass sicher per ADS kommuniziert werden kann. Hierbei wird eine verschlüsselte Verbindung zwischen zwei Teilnehmern aufgebaut, die dann wie gewohnt ADS-Telegramme austauschen können.

Beim Anlegen einer neuen Verbindung zwischen zwei ADS-Geräten kann die Authentifizierung über Zertifikate sichergestellt werden. Dabei werden alle Telegramme automatisch verschlüsselt.

Mit TLS hat sich Beckhoff entschieden, das bekannteste Verfahren für Authentifizierung und Verschlüsselung zu nutzen. Um die Zertifikate und deren Verwaltung muss sich der Programmierer nicht kümmern. Das erledigt das Twincat-System selbstständig im Hintergrund. Durch die Integration in die zentrale Twincat-Kommunikationskomponente (Twincat Router) ergeben sich auch für ADS nutzende Bestandsanwendungen die Möglichkeit, durch Rekonfiguration der Verbindung eine verschlüsselte Verbindung zu nutzen, ohne dass die eigentliche Anwendung neu geschrieben oder auch nur neu kompiliert werden muss.

* Dr. Josef Papenfort, Senior Produktmanager Twincat, Beckhoff Automation

(ID:46710353)