Einsatz von LabVIEW zur Erfassung und zum Monitoring von Messdaten der Peripherie des Forschungs- und Entwicklungsprüffelds der Deutz AG

Dipl.-Inf. Torsten Althoff, DEUTZ AG

"Die starren Strukturen aus unserem ersten Leitsystem haben wir erfolgreich durch ein flexibles System ersetzt. National Instruments zeigt auch hier, dass LabVIEW ein stabiles Grundgerüst für den Dauereinsatz ist. LabVIEW ist ein perfekter Partner für die Kommunikation über Netzwerke und die Zusammenarbeit mit diversen Datenbanken."

- Dipl.-Inf. Torsten Althoff, DEUTZ AG

Die Aufgabe:

Um einen reibungslosen Betrieb unserer Entwicklungsprüfstände zu gewährleisten, ist viel Peripherie zu überwachen, um vorzeitig Ausfällen des Prüffelds vorzubeugen.

Die Lösung:

An dieser Stelle wird gezeigt, wie einfach ein relativ komplexes System mit Hilfe von LabVIEW und Datenbanken frei konfigurierbar gestaltet werden kann. Es wird auch verdeutlicht, welche Probleme (Porthandling durch Windows) beim Zugriff auf die externe Peripherie (SPS, OPC-Server) auftreten und wie diese umgangen werden können.

Autor(en):

Dipl.-Inf. Torsten Althoff - DEUTZ AG

Diese Kundenlösung wurde im Tagungsband 2016 des Technologie- und Anwenderkongresses „Virtuelle Instrumente in der Praxis“ veröffentlicht.

Eingesetzte Produkte: LabVIEW, NI-OPC-Server

Kurzfassung

Um einen reibungslosen Betrieb unserer Entwicklungsprüfstände zu gewährleisten und vorzeitig Ausfällen des Prüffelds vorzubeugen, ist es erforderlich, viel Peripherie zu überwachen. An dieser Stelle wird gezeigt, wie einfach ein relativ komplexes System mithilfe von LabVIEW und Datenbanken frei konfigurierbar gestaltet werden kann. Es wird auch verdeutlicht, welche Probleme (Porthandling durch Windows) beim Zugriff auf die externe Peripherie (SPS, OPC-Server) auftreten und wie diese umgangen werden können.

 

Einleitung

Aufgrund eines wachsenden Prüffelds und immer komplexerer Systeme, die teils durch neue Gesetzgebungen getrieben wurden, musste nun auch unser Leitsystem an diesen Fortschritt angepasst werden. Das „alte“ Leitsystem beruhte ebenfalls auf LabVIEW. Allerdings waren dort alle Signaleingänge im LabVIEW-Code „fest“ einprogrammiert. Der Aufwand, dieses System zu pflegen, war sehr hoch. Zwar handelte es sich „nur“ um 150 abgefragte Sensoren, allerdings musste für jede Änderung der Code neu kompiliert werden und auf die anzuzeigenden Systeme verteilt werden. Das Grundsystem bestand aus einem Windows-XP-Rechner, auf dem ein OPC-Server lief. Dieser OPC-Server stellte den Zugang zu den Prozessdaten der SPS her. Auf diesem Rechner lief auch die Hauptanwendung, die die erste Visualisierung ermöglichte und die Daten für weitere Visualisierungen aufbereitete. Der Bedarf an weiterer Visualisierung stieg. Es sollte an vielen dezentralen Stellen eine Visualisierung ermöglicht werden. Damit vermehrten sich auch die Probleme, die eine Umsetzung mit dem alten Leitsystem verhinderten:

• Verwaltungsaufwand bei der Verteilung des Leitsystems
• Jede Änderung bedeutete eine Neukomplilierung des Codes.
• Windows lässt nur zehn gleichzeitige Verbindungen zu.
• Werte konnten über längere Zeit nicht vom OPC-Server abgefragt werden.
• Die grafischen Möglichkeiten erwiesen sich als sehr einschränkend und unübersichtlich zu programmieren.

 

 

Dies war der Zeitpunkt, über ein „neues“ Leitsystem nachzudenken, welches die augenscheinlichen Einschränkungen nicht aufwies.

 

Zudem war zu diesem Zeitpunkt auch noch nicht klar, warum es in LabVIEW Messstellen gab, die längere Zeit keine Werte vom OPC-Server erhielten. Eine weitere Einschränkung bestand darin, dass zur Abfrage von Werten des OPC-Servers die LabVIEW-Anwendung auf demselben Rechner wie der OPC-Server laufen musste. Das bedeutete aber auch, dass während der Programmentwicklung die Werte des OPC-Servers nicht zur Verfügung standen und zumindest an dieser Stelle erst getestet werden konnte, wenn die kompilierte Anwendung auf dem Rechner des OPC-Servers lief. Dieser Sachverhalt hätte eingeschränkt umgangen werden können, wenn die DCOM-Schnittstelle zur Verwendung gekommen wäre. Leider ist dieses Thema an dieser Stelle zu komplex. Da der verwendete OPC-Server aus lizenzrechtlicher Sicht problematisch war, fiel es nicht schwer, sich für ein neues Produkt zu entscheiden.

 

Mit dem neuen OPC-Server waren die Lizenzprobleme gelöst und es gab von dieser Seite keine Ausfälle mehr. Aber auch hier muss die LabVIEW-Anwendung auf demselben Rechner wie der OPC-Server ausgeführt werden. Auch hier gibt es die Möglichkeit, einen dezentralen Zugriff über DCOM zu realisieren. Der Hersteller des OPC-Servers hat uns hiervon aus diversen Gründen abgeraten und sah sich selbst nicht in der Lage, uns das System nach unseren Vorstellungen einzurichten. Als Lösung ohne DCOM existiert zumindest bei diesem Hersteller eine Art Tunnel, der einen dezentralen Zugriff zulässt. Jedoch haben alle Methoden des Zugriffs eines gemeinsam: Der Zugriffspfad unterscheidet sich bei zentralem und dezentralem Zugriff. So müssen in der Anwendungsentwicklung andere Pfade verwendet werden als im späteren Betrieb. An dieser Stelle stand für uns fest, dass wir unseren eigenen Tunnel entwickeln.

 

Problem erkannt

Im „alten“ Leitsystem erfolgte der Zugriff auf den OPC-Server mittels Bedienelement, welches über die Einstellungen „Datenbindung“ an ein DataSocket gebunden wurde. Das bedeutet aber, dass für jeden zu verarbeitenden Wert solch ein Bedienelement anzulegen ist. So wurde der Weg gewählt, das Einlesen von Werten in einer Schleife mit direktem Socket-Zugriff abzuhandeln und über die Eigenschaften bei jedem Schleifendurchlauf die Socket-Verbindung zu ändern. Das hat mit zwei, drei Werten funktioniert. Bei einer größeren Anzahl einzulesender Werte zeigte sich das alte Problem, dass es Werte gab, die über einen längeren Zeitraum nicht aktualisiert wurden.

 

Nach dem Einfügen einer Verzögerungszeit zwischen neuem Socket-Pfad und dem Auslesen des Wertes konnte das Problem behoben werden. Es zeigt sich allerdings auch, dass der Weg über das Bedienelement und die Datenbindung auf die gleiche Problematik hinausläuft. Woher dieses Problem rührte, konnte nicht festgestellt werden. Nun war es möglich, mit relativ wenig Code viele Werte in LabVIEW einzulesen, wobei die oben angesprochene Verzögerungszeit den Prozess sehr langsam macht. Mit einer Testanwendung wurde dieser Prozess mit diversen Änderungen über Wochen hinweg auf Stabilität überprüft. Nach einer Laufzeit von mehreren Tagen zeigte sich, dass der Prozess des Einlesens nicht mehr lief und Windows ein äußerst unstabiles

 

Erscheinungsbild zeigte. Jeder Zugriff auf den OPC-Server öffnet eine Verbindung, der Wert wird abgefragt und die Verbindung wird wieder geschlossen. Zumindest erscheint es so aus der Sicht von LabVIEW. Die Realität zeigt nun aber ein anderes Verhalten.

 

LabVIEW öffnet eine Socket-Verbindung, stellt hierzu bei Windows eine Anfrage auf einen freien Port, Windows reserviert den Port und übermittelt LabVIEW die Portnummer. LabVIEW erzeugt ein Socket-Handle, mit dem nun der Wert vom OPC-Server abgefragt wird. Nun soll mit dem Socket-Handle der Port geschlossen werden. LabVIEW stellt die Anfrage nach Schließung des Ports an Windows. Windows vermerkt sich diese Anfrage und gibt ein OK an LabVIEW zurück. LabVIEW betrachtet den Port nun als geschlossen und vernichtet das Socket-Handle.

 

Lösung

Es wurde eine Anwendung entwickelt, die wie ein Tunnel zwischen OPC-Server und Leitsystem fungiert. Die Kommunikation zwischen dem Leitsystem und dem Tunnel basiert auf einem TCP/IP-Protokoll und kann auf dieser Basis dezentral verwendet werden. Das Leitsystem fragt eine Messstelle per Socket-String beim Tunnel an und erhält sofort den gewünschten Wert als Antwort, wenn er sich bereits im zyklischen Ablauf befindet.

 

Der Tunnel nimmt den Socket-String vom Leitsystem entgegen und prüft in einer internen SQLite-Datenbank, ob der String schon vorhanden ist. Nicht vorhanden bedeutet, es wird ein Eintrag in der Datenbank erstellt. Eine Socket-Verbindung wird geöffnet, Windows reserviert einen Port und das Socket-Handle wird zu dem Socket-String in die Datenbank geschrieben. Wenn innerhalb von zehn Minuten keine Anfragen mehr an den Messwert gestellt werden, werden die Verbindung abgebaut, der Port geschlossen und die entsprechenden Einträge aus der Datenbank gelöscht. Werden regelmäßig Anfragen an den Messwert gestellt, holt der Tunnel zyklisch die benötigten Messwerte vom OPC-Server ab und schreibt sie zum passenden Socket-String in die SQLite-Datenbank.

 

Durch dieses Vorgehen entfallen folgende Probleme:
• dass keine Werte vom OPC-Server mehr zu erhalten sind,
• dass keine Wartezeiten durch eine zusätzliche Verzögerungszeit entstehen,
• dass Windows keine freien Ports mehr zur Verfügung hat,
• dass kein dezentraler Zugriff auf Prozesswerte möglich ist.

 

Leitsystem

Da die eigentliche Problematik zum Einlesen der Prozessdaten in den Tunnel ausgelagert wurde, verbleiben dem Leitsystem nur noch die Funktionen der Überwachung, der Alarmierung, der Visualisierung und der Histogramme. Die eingelesenen Werte werden im „Intelligenz-Modul“ mit einem Offset/Multiplikator versehen und auf Grenzwertverletzungen überprüft. Mittelwerte können gebildet  und selbst komplexere Formeln hinterlegt werden.

 

Die Einrichtung eines solchen Wertes zur Erfassung erfolgt als Konfigurationseintrag in einer Microsoft-SQL-Datenbank. Dort werden auch die Überwachungsgrenzen, Formeln, die Anzahl der Historieneinträge usw. hinterlegt. Nach der Verarbeitung im „Intelligenz-Modul“ werden alle anzuzeigenden Daten (Messwert, Alarme, Warnungen …) in einer Visualisierungsdatenbank hinterlegt.Durch LabVIEW werden die Daten soweit aufbereitet, dass die Visualisierungsdatenbank exakt die Einträge enthält, die dem Nutzer grafisch gezeigt werden sollen.

 

Die eigentliche Visualisierung erfolgt nun in einem Browser. Per PHP werden die Datenbankinhalte der Visualisierungsdatenbank abgefragt und visuell aufbereitet. Da durch LabVIEW die Visualisierung als Datenbasis bereits erledigt wurde, beschränkt sich die Arbeit in PHP auf die Anzeige der Messwerte und das Anzeigen entsprechender Grafiken zu den digitalen Signalen.Durch die Anzeige im Browser ist ein dezentraler Zugriff gewährleistet und der Verwaltungsaufwand für eine Verteilung des Leitsystems im Entwicklungswerk reduziert sich auf ein Minimum.

 

Derzeit werden mit dem Leitsystem 1.000 Prozesswerte verarbeitet und überwacht. Soll ein neuer Messwert hinzugefügt werden, bedeutet das im ersten Schritt einen neuen Eintrag in die Konfigurationsdatenbank. Ab diesem Zeitpunkt werden sofort Meldungen generiert und Historiendaten mitgeschrieben. Der Verantwortliche für dieses Gewerk erhält ab diesem Zeitpunkt E-Mails, die auf Abweichungen der Norm hinweisen. Ebenfalls ist es möglich, wichtige Meldungen per SMS auf ein Mobiltelefon zu erhalten. Durch die Festlegung von Prioritäten bei den einzelnen Warn-/Alarmmeldungen können unterschiedliche Benachrichtigungsgruppen angelegt und ggf. der Werkschutz benachrichtigt werden. In einem zweiten Schritt kann in eine vorhandene Visualisierung der neue Wert mittels weniger PHP-Befehl eingefügt werden. Aber auch eine komplett neue Seite für ein neues Gewerk ist mit relativ geringem Aufwand erledigt.

 

Zusammenfassung

Mit dem „neuen“ Leitsystem haben wir ein Tool erhalten, was in hohem Maße flexibel ist und sich auf unsere Bedürfnisse durch kleine Änderungen anpassen lässt. Die starren Strukturen aus unserem ersten Leitsystem haben wir erfolgreich durch ein flexibles System ersetzt. National Instruments zeigt auch hier, dass LabVIEW ein stabiles Grundgerüst für den Dauereinsatz ist. LabVIEW ist ein perfekter Partner für die Kommunikation über Netzwerke und die Zusammenarbeit mit diversen Datenbanken.

 

Informationen zum Autor:

Dipl.-Inf. Torsten Althoff
DEUTZ AG
Ottostraße 1
Köln 51149
Germany
Tel: +49 (0)221 822-4317
althoff.t@deutz.com

Bild 2: Data-Socket-Anbindung an numerisches Bedienfeld
Bild 3: Schematische Darstellung des „neuen“ Leitsystems
Bild 4: Folgende Daten werden dem Leitsystem per Konfigurationseintrag mitgegeben
Bild 5: Übersicht über die Betriebs- und Kalibriergase für die Abgasmessanlagen
Bild 6: Die Historiendaten zeigen hier den Druckverlauf von Kalibriergas HC(100).
Bild 1: Übersicht der einzelnen Gewerke im „neuen“ Leitsystem