Remote über Ethernet Mess- und Testgeräte über HiSLIP aus der Ferne steuern

Anbieter zum Thema

PFLITSCH GmbH & Co. KG

Syslogic GmbH

NetModule AG

TSEP Technical Software Engineering Plazotta

Mit Poseidon steht ein Mess- und Testsystem bereit, um Remote aus der Ferne über eine Ethernet-Verbindung zu kommunizieren. Zum Einsatz kommt das HiSLIP-Protokoll in der Version 2.0.

In der Testautomation wird von Seiten der Anwender eine schnelle Command- und Queryausführung von Messgeräten gefordert. Hier bietet sich Poseidon an, der über einen SCPI-konformen Parser verfügt. Der nach SCPI 488- konforme Parser übersetzt entsprechende Befehle und leitet diese an die Geräte-Firmware weiter. Die Modularität von Poseidon spiegelt sich in der Architektur wider.

Zu den drei Schlüsselkomponenten gehören die Kanäle, die Parser und ein Core-Modul. Der Kommunikationskanal implementiert die Hardware Kommunikationsschnittstelle. Das Multi-Instanz-Kanal-Konzept kann mehrere aktive Verbindungen gleichzeitig abarbeiten. Kunden können außerdem unabhängige Kanäle definieren und implementieren.

Der Parser definiert einzelne SCPI-Befehle, deren Syntax und Verarbeitung. Poseidon unterstützt mehrere Parser zur gleichen Zeit. Damit sind Kunden in der Lage, die SCPI-Kommandostruktur modular aufzubauen und innerhalb anderer Gerätevarianten wiederzuverwenden. Alle Kanäle übertragen ihre Daten an den Kern von Poseidon und werden dann vorverarbeitet und an den entsprechenden Parser weitergeleitet. Die Ergebnisse des Parsers werden dann über den Core an die Geräte-Firmware kommuniziert.

Das TCP/IP-basierte Protokoll HiSLIP

Derzeit unterstützt Poseidon die Standardschnittstellen TCP/IP, HiSLIP und RS232. HiSLIP steht für High-Speed LAN Instrument Protocol. Dabei handelt es sich um ein TCP/IP-basiertes Protokoll. Über das Protokoll lassen sich ein Gerät mit einem Client verbinden. Die zunehmende Anforderung nach einer schnellen und zugleich sicheren Kommunikation zwischen Gerät und Client wurde im HiSLIP 2.0 implementiert. Betrachtet man eine HiSLIP-Verbindung, so besteht diese aus zwei Verbindungen. Kommuniziert wird sowohl synchron als auch asynchron.

Die synchrone Verbindung wird hauptsächlich als Datenkanal verwendet. Über den asynchronen Kanal erfolgt die Kontrollverbindung, um Service Requests mitzuteilen.

Dabei sollte die asynchrone Verbindung höher priorisiert sein als die synchrone Verbindung. Das System sollte zunächst auf Befehle der asynchronen Verbindung reagieren, bevor die Befehle der synchronen Verbindung abgehandelt werden. Außerdem instanziiert das HiSLIP-Protokoll mehrere Verbindungen auf einem Port. Spezielle Verbindungen werden lediglich durch eine Subadresse angegeben.

Das Protokoll unterstützt für jede HiSLIP-Verbindung, ein Instrument gegenüber anderen HiSLIP-Verbindungen zu sperren oder den Befehlszustand aus der Ferne (Remote) oder lokal zurückzugeben. Außerdem spezifiziert HiSLIP ein End- Message-Element. Damit wird signalisiert, dass die Nachricht vollständig ist und ein Status-Reporting wird nach der Message-Available-Kalkulation nach IEEE4888.2 ebenfalls unterstützt.

HiSLIP-Verbindung ist verschlüsselt und authentifiziert

HiSLIP2.0 kann als eine Erweiterung des HiSLIP-Protokolls angesehen werden, welcher alle bereits beschriebenen Aspekte weiterhin unverändert unterstützt. Anhand der Initialize-Transaction des Protokolls wird bereits früh vereinbart, welche HiSLIP-Version von Server und Client unterstützt werden. Sollten beide Geräte HiSLIP2.0 unterstützen, können die Anwender die neuen Features des Standards verwenden. Der wesentliche Unterschied zwischen der Version 1.1 und 2.0 liegt darin, dass die Verbindung sowohl verschlüsselt und authentifiziert werden kann.

Sowohl Server als auch Client sind in der Lage, sich untereinander gegenseitig zu authentifizieren. Damit stellen beide Seiten sicher, mit dem richtigen Adressaten zu sprechen. Die Verbindung wird über TLS-Sockets verschlüsselt. Eine sichere Verbindung ist nicht durch HiSLIP2.0 vorgegeben. Von Seiten des HiSLIP-Servers wird das über den Befehl InitializeResponse gesteuert. Dieser Befehl gibt im Control Code an, ob eine Verschlüsselung notwendig ist und ob mit einer sicheren Verbindung fortgefahren werden soll. Der Grund hierfür liegt darin, dass HiSLIP2.0 das Konzept der Server-Fähigkeiten eingeführt hat.

Ein HiSLIP-Server wird unterstützt, das ist allerdings nicht zwingend. Diese Eigenschaft des Servers muss beim Aufbau einer Verbindung zwischen Server und Client von Seiten des Clients ermittelt und entsprechend behandelt werden. Dabei wurde bisher nur definiert, eine sichere Verbindung des Servers aufzubauen.

Wenn sich Client und Server austauschen

Wird eine sichere Verbindung aufgebaut, so wird zunächst der Prozess für die asynchrone Verbindung vom Client angestoßen und bei erfolgreicher Antwort der TLS-Handshake ausgeführt. Danach erfolgt das gleiche Prinzip für die synchrone Verbindung. Für den Client ergeben sich zwei Pfade. Denn der Client muss ermitteln, welche Authentifizierungsmöglichkeiten der Server unterstützt. Der Client authentifiziert sich, indem er dem Server mitteilt, mit welchem Mechanismus dieser sich authentifizieren möchte und anschließend die notwendigen Daten zuschickt. Kann der Server die Daten validieren, gibt es eine positive Antwort.

Bei erfolgreichem Ablauf besteht eine sichere Verbindung zwischen Client und Server. Je nach Konfiguration des Servers und der Anwendung des Clients lässt sich die verschlüsselte Verbindung im laufenden Betrieb beenden. Das spart Datenrate. Eine Man-in-the-Middle-Attacke ist ausgeschlossen, da die Authentifizierung bereits über eine verschlüsselte Verbindung stattgefunden hat.

Authentifizierung mit HiSLIP2.0

Für die Authentifizierung verwendet HiSLIP2.0 die Mechanismen von Simple Authentication and Security Layer (SASL). Trotzdem muss sich der HiSLIP-Client an die unterstützten Authentifizierungsarten des Servers anpassen. Die IVI-Foundation macht keine Vorgaben, welche Authentifizierungen unterstützt werden. Einzig das LXI Consortium schreibt bestimmte Mechanismen vor. Alle LXI-konformen Geräte lassen sich mit den gleichen Mechanismen authentifizieren. Die LXI-Security-Extended-Funktion ist noch Draft. Hier muss man abwarten, ob die enthaltenen Mechanismen Anonymous, Plain, External und Scram bis zur Veröffentlichung bestehen bleiben und sich in HiSLIP2.0 zu Standard-Authentifizierungsmöglichkeiten entwickeln.

Das HiSLIP2.0-Protokoll erweitert das bislang bestehende HiSLIP-Protokoll mit dem Zusatz der verschlüsselten und authentifizierenden Verbindung für eine sichere Kommunikation zwischen zwei Parteien. Poseidon von TSEP hat dieses Protokoll in den HiSLIP-Kanal mit aufgenommen, um Anwendungen und Geräte sichere Verbindungen zu gewähren.

* David Courtney ist Junior Director bei TSEP. Er ist unter anderem verantwortlich für die Referenz-Implementierung des LXI-Standards für das LXI Konsortium.

(ID:47763681)