DSL für HART-Tests auf SQL und LabVIEW

Tabellenbasierte DSL für HART-Sensor-Tests in Produktionsanlagen

Die Entwicklung eines Systems zur Kalibrierung und zum Testen smarter Sensoren mit HART-Protokoll erfordert die Unterstützung vielfältiger Hardware: Signalgeneratoren, Klimakammern, Multimeter, HART-Modems und Schalter. Das HART-Protokoll arbeitet im Punkt-zu-Punkt-Modus über eine 4-20-mA-Stromschleife und ermöglicht Kalibrierung, Konfiguration und Datenaustausch. Tests umfassen charakteristische Linearisierungen, Druck- und Temperaturzyklen, Versorgungsspannungsschwankungen sowie HART-Sitzungen. Eine Client-Server-Architektur mit reinem SQL und einer tabellenbasierten Skriptsprache ermöglichte einem Zweier-Team, editierbare Tests auf mehreren Stationen umzusetzen.

Systemzerlegung in Teilsysteme

Das System gliedert sich in zentrale Komponenten:

• Hardwaresteuerung über LabVIEW.
• Testprogrammierung in tabellenbasierter DSL.
• Datenverarbeitung und Berechnungen in der Datenbank.
• Echtzeit-Überwachung der Stationen im SCADA-Stil.

LabVIEW wurde wegen seiner fertigen Treiber für USB-, GPIB-, TCP/IP- und RS232-Schnittstellen gewählt. Der Client an der Teststation agiert als Interpreter für Datenbankbefehle und verzichtet auf OOP-Abstraktionen. Die Testlogik wird an serverseitige Skripte ausgelagert, wodurch LabVIEW-Diagramme einfach bleiben.

Tabellenbasierte Skriptsprache: Struktur und Befehle

Die DSL wird als Datenbanktabellen mit linearer und zyklischer Ausführung realisiert. Jede Zeile ist eine Operation mit zwei Parametern, was die Bearbeitung vereinfacht. Indirekte Adressierung wird innerhalb von Schleifen unterstützt.

Wichtige DSL-Merkmale:

• Linearer Ablauf von Operationen.
• Schleifen über Reize (Druck, Temperatur, Kanäle).
• Timerbasierte Schleifen.
• Initialisierung statischer Reizmodelle.
• Über 100 Operationen für HART-Kommunikation, Messungen und Datenprotokollierung.

Schleifen werden durch SQL-Stored Procedures gesteuert: Separate Tabellen speichern Parameter (Start, Ende, Schritt, aktueller Wert, aktiver Sensorpool). Befehle wie INIT_LOOP und CHECK_END_LOOP regeln die Ausführung. Für Reizschleifen übernimmt eine Modifikator-Tabelle die Vor-/Nach-Inkrement-Logik.

Beispiel-Schleifenlogik:

• Laden des Reizmodells aus der Datenbank.
• Initialisieren der Schleife mit Parametern.
• Ausführen von Operationen bis zum Ausstiegsbedingung.
• Fortfahren zum nächsten Befehl nach der Schleife.

Schleifenimplementierung und Optimierung

Experimente mit SQL-Procedures zeigten, dass Schleifen in der Datenbank zuverlässig funktionieren. Schleifenparameter (Start/Endwert, Schritt) werden in Tabellen gespeichert, was dynamische Testgenerierung ermöglicht.

Schleifentypen:

• Allgemeine Schleife: Über eine Variable für einen Sensorpool an einer Station.
• Drucks Schleife: Mit Schritt und Reizgrenzen.
• Temperaturschleife: Kammerinitialisierung.
• Timer-Schleife: Wiederholung von Operationen bis Zeitablauf.

Das Hinzufügen von Schleifen halbierte die Testgrößen. Operationen werden angepasst: iterationsabhängig oder -unabhängig (für Timer).

Der tabellenbasierte Testeditor automatisiert Zeilennummerierung, Befehlsreferenzen, Kommentare und Schleifenanpassungen. Eine "Kompilations"-Stored Procedure ersetzt alte Tests durch neue. Copy-Paste-Unterstützung und interaktive Hinweise beschleunigen die Entwicklung. Über 100 Programme wurden für Produktions- und Periodentests von 4-20-mA/HART-Sensoren erstellt.

Hardware- und Datenbankintegration

Der LabVIEW-Client holt Skripte aus der Datenbank und interpretiert Befehle sequentiell. Lang laufende Operationen (Reizschleifen) erfordern keine hohe Geschwindigkeit. Rohdaten werden in die Datenbank gespeichert für Berechnungen und Berichtserstellung.

Vorteile des Ansatzes:

• Tests editieren ohne Client-Neukompilierung.
• Zentrale Speicherung von Skripten und Daten.
• Skalierbar auf Dutzende Stationen.
• Minimales Entwicklerteam.

Wichtige Erkenntnisse

• Tabellenbasierte SQL-DSL mit Schleifen halbiert Testcode bei voller Flexibilität.
• LabVIEW als Datenbank-Befehlsinterpreter vermeidet OOP-Komplexität.
• Zwei Parameter pro Operation für über 100 HART-Testbefehle.
• Automatische Referenz- und Nummerierungsanpassungen in Stored Procedures.
• Echtzeit-Stationenüberwachung über SCADA-ähnliche Oberfläche.

— Editorial Team