In dem speziellen Fall, bei dem es in diesem Buch geht, kann eine Schnittstelle als Oberfläche zur Kommunikation mit einem Test- oder Messgerät aufgefasst werden.
Ganz allgemein kann so ein Gerät mehrere Schnittstellen besitzen. Die klassischste Variante ist dabei sicherlich die sogenannte Benutzerschnittstelle. Sie dient der Mensch-Maschine-Kommunikation. Bei einem Mess- oder Testgerät sind das Anzeigeelemente wie Lampen, Skalen oder Displays oder auch Bedienelemente wie Schalter, Tasten oder Potenziometer. Geräte können auch Maschine-Maschine-Schnittstellen besitzen, über die sie zu einem System verbunden sind, oder über die ein Gerät modular erweitert wird. Ein Beispiel dafür sind die alten Tektronix-Oszil-loskope, die mit unterschiedlichen Einschüben wie Messverstärkern oder Zeitbasen bestückt werden konnten, je nach geforderter Konfiguration. Eine weitere Variante sind Schnittstellen, mit denen Test- und Messgeräte Daten austauschen. Diese Daten können sowohl Messergebnisse als auch Steuerbefehle sein. Wenn solche Datenschnittstellen genutzt werden, um die Geräte in ein Netzwerk einzubinden, kann man sie zu Recht als Netzwerkschnittstellen bezeichnen. Alle genannten Vari-anten kommen in der Praxis vor, und nicht wenige Geräte besitzen mehrere dieser Schnittstellen gleichzeitig. Die Maschine-Maschine-Schnittstellen dienen grund-sätzlich dazu, verschiedene Geräte zu einem System zusammenzufassen, mit dem eine komplexe Test- oder Messaufgabe gelöst werden soll. Werden diverse Test- und Messgeräte zu einem System zusammengeschlossen, gibt es in vielen Anwendungen ein grundlegendes Problem, und zwar die Zeit. Es kommt häufig vor, dass mehrere Ereignisse in einem festen, kontrollierbaren Zeitintervall aufeinanderfolgen sollen, oder dass sie womöglich isochron ablaufen oder zumindest gestartet werden sollen.
Nicht selten sollen auch verschiedene Messwerte eines Testobjekts gleichzeitig erfasst werden. Für derartige Aufgaben sind Daten- oder Netzwerkschnittstellen all-gemein schlecht geeignet, besonders wenn ein Messgerät das Triggersignal für andere Geräte des Systems erzeugen soll. Dazu ein Beispiel: Ein schnelles Voltmeter erkennt die Nulldurchgänge einer Wechselspannung und will einem Amperemeter diese Zeitpunkte als Startsignale für Strommessungen liefern, weil der Anwender wissen möchte, mit welcher Art von Reaktanz er es bei einem Messobjekt zu tun hat. Wenn die einzelnen Geräte von einem PC als Kontrollinstanz verwaltet werden, auf dem ein Steuerprogramm unter der Herrschaft eines Multitasking-Betriebssys-tems läuft, ist an kontrollierte Echtzeitsteuerung ohnehin nicht zu denken,
unab-27
hängig davon, ob die Systemhardware Echtzeit ermöglicht. Als Anwender sollte man z. B. immer an Folgendes denken: „Windows war nie als Echtzeit-Betriebssystem konzipiert, das bestimmte Transferraten für Peripheriegeräte garantieren kann“
[USB2.0 Handbuch: 3.5.4]. Für Echtzeitanforderungen gibt es nur die Lösung, Bus-Schnittstellen zu verwenden, die neben Mess- und Steuerinformationen auch Nach-richten zur Echtzeitsteuerung transportieren, und diese unter die Verwaltung eines Real-Time-Betriebssystems zu stellen. Es soll nun ein kurzer, zum Teil auch geschichtlicher Überblick folgen.
2.1 CAMAC
Computer Automated Measurement and Control ist der Name eines Urvaters der Messtechnik-Bussysteme, die Echtzeitsteuerung erlauben. Die einzelnen Messgeräte sind als Steckkarten ausgeführt, die in einem Grundrahmen, dem sogenannten Crate stecken. In diesem Grundrahmen befindet sich ein Crate-Controller, der bis zu 24 einzelne Geräte innerhalb des Crate verwalten kann. In diesem Rahmen kön-nen Echtzeitinformatiokön-nen übertragen werden. Nach außen kann der Controller über ein Interface mit übergeordneten Systemen verbunden werden. CAMAC wird primär in der Kern- oder Teilchenphysik eingesetzt.
2.2 VME
Der Versa Module Eurocard Bus wurde ursprünglich für die Prozesssteuerung ent-wickelt und ist bedingt echtzeittauglich. Das Prinzip ist ähnlich wie beim CAMAC-Bus. Echtzeit kann bedingt durch priorisierbare Interruptanforderungen der einzel-nen Steckkarten erzwungen werden. Der VME Bus wird z. B. in der Luft- und Raumfahrt und in schnellen Produktionsmaschinensteuerungen eingesetzt.
2.3 VXI
Versa Module Eurocard Bus Extensions for Instrumentation ist der VME-Bus mit Erweiterungen für Messinstrumente. Auf diesem Bus gegründete Messsysteme besitzen eine standardisierte Software-Schnittstelle zum Steuercomputer. Dieser Standard nennt sich VISA für Virtual Instrument Software Architecture. Die Schreibweise „XI“ als Abkürzung für die Formulierung „Extensions for Instrumen-tation“ wurde im Zusammenhang mit VXI eingeführt und wird für andere Bussys-teme ebenfalls angewandt, wenn diese für Messzwecke verwendet werden.
2.3 VXI
28
2.4 PXI
Dieses Kürzel steht für den PCI-Bus, wie er auf Computer-Mainboards vorhanden ist, wenn er für Messsysteme erweitert wird. Peripheral Component Interconnect ist der allgemeine Standard für Erweiterungskarten in zeitgenössischen PCs. PXI ist analog zu VXI also Peripheral Component Interconnect Extensions for Instrumen-tation. Diese Schnittstelle wird insbesondere von der Firma National Instruments favorisiert, die in PXI eine hinreichend gute Lösung sieht, um echtzeittaugliche Messsysteme zu realisieren. Auch bei PXI gilt das Prinzip, dass Einsteckkarten in einem Grundrahmen von einem Steuercomputer in Echtzeit verwaltet werden. Die-ser Steuercomputer verfügt über eine Datenschnittstelle zu einem übergeordneten System.
Alle bisher vorgestellten Schnittstellen haben gemeinsam, dass die damit ausgerüs-teten Test- und Messgeräte keine Geräte im landläufigen Sinne sind, sondern Ein-steckkarten, die einen gemeinsamen Grundrahmen verwenden. Über diesen Grund-rahmen erfolgen die Ablaufsteuerung und auch die Energieversorgung der jeweili-gen Karten. Eine einzelne Karte solcher Bussysteme ist allein nicht lebensfähig und verwendbar. Eine andere Art von Schnittstellen wird in eigenständigen Geräten ver-wendet und verbindet diese zu Mess- und Testsystemen. Solche Geräte funktionieren im Allgemeinen „stand alone“. Sie haben ihre eigene Stromversorgung und häufig eine Benutzerschnittstelle. Wenn sie nicht in einem System eingesetzt werden, kann man sie meistens als eigenständiges Messgerät per Handbedienung nutzen.
2.5 LXI
Diese Schnittstelle wird hier, historisch betrachtet, viel zu früh aufgeführt, weil es sich um die jüngste Schnittstelle für Test- und Messgeräte handelt, aber wegen „XI“
passt sie schön hierher. „XI“ steht auch hier wieder für „Extensions for Instrumen-tation“. Das „L“ steht für Local Area Network. LXI soll antreten, um den im Fol-genden noch zu besprechenden, in die Jahre gekommenen GPIB abzulösen. Die Freigabe des LXI-Standards erfolgte im Jahre 2005, und es stehen wirklich viele bedeutende Messtechnik-Unternehmen hinter diesem Standard. Die Ansprüche an LXI sind so hoch, dass der Standard in Unterklassen aufgeteilt wurde, damit auch
„ein wenig LXI“ für simple Anwendungen übrig bleiben kann. LXI der Klasse C bedeutet, dass das Test- oder Messgerät über eine Ethernet-Schnittstelle verfügt und softwareseitig das Protokoll TCP/IP beherrscht. Man kann ein solches Gerät also per CAT-5 Kabel an den PC stecken und über den Standard-Webbrowser fernbedie-nen. Das Gerät hat also gewissermaßen eine eigene Website. Im Idealfall bietet es
2 Schnittstellen für Test- und Messgeräte im Überblick
29
Hyperlinks zu Hilfe- und Serviceportalen des Herstellers und hält eine komplette Bedienungsanleitung bereit. Eine LXI Instrument Homepage sollte in etwa folgen-dermaßen aussehen:
Geräte der LXI Klasse B verfügen über ein Synchronisierungskonzept, das auf dem Standard IEEE 1588 aufbaut. Jedes Gerät hat dabei eine eigene „innere Uhr“, also einen recht präzisen Taktgenerator. Die Uhren aller Geräte können synchronisiert werden, indem ihnen allen gleichzeitig ein Zeitstempel übertragen wird. Das funk-tioniert, weil das Konzept des Ethernet es zulässt, alle Netzteilnehmer gleichzeitig mit sogenannten Broadcast Messages zu erreichen. Die unten dargestellte histori-sche Grafik von Dr. Robert M. Metcalfe verdeutlicht, dass alle teilnehmenden Geräte ein gemeinsames Medium, „The Ether“ genannt, zur Datenübertragung ver-wenden. Wenn ein Teilnehmer Daten in dieses Medium sendet, können alle ande-ren diese Daten gleichzeitig empfangen. Dadurch können isochrone Zeitstempel übertragen werden.
Ein derartiger Zeitstempel wird in definierten Intervallen erneut übertragen, sodass die einzelnen Geräte nahezu synchron arbeiten. Bestimmte Ereignisse können in den einzelnen Geräten zeitgleich ausgelöst werden, indem ihnen über das LAN ein gemeinsamer Starttermin mitgeteilt wird.
Wenn diese Methoden der Synchronisation und Triggerung von Ereignissen nicht präzise genug ist, kommt LXI der Klasse A zum Einsatz. Bei dieser Erweiterung gibt es zusätzlich zum Ethernet und IEEE 1588 eine weitere Verbindung zwischen den teilnehmenden Geräten, den sogenannten LXI Trigger Bus. Über diesen Bus werden Echtzeit-Triggersignale übertragen, die präzises Timing ermöglichen. Die mit
die-2.5 LXI
30
sem Trigger Bus verbundenen Geräte müssen im Unterschied zu Klasse B- und C-Geräten räumlich dicht beieinanderstehen. Deswegen kann die Klasse A nur in lokalen Systemen eingesetzt werden.
2.6 GPIB
Der General Purpose Interface Bus wurde von der Firma Hewlett Packard in den 1960er-Jahren als Schnittstelle zwischen Messgeräten oder Computern und Peri-pheriegeräten entwickelt. Er stammt also aus einer Zeit, in der es noch keine Mikro-controller und PCs gab. Im Laufe seines Lebens hat der GPIB diverse Namen erhal-ten, wie HPIB, IEC 625 oder IEEE 488. Der GPIB ermöglicht die Vernetzung von maximal 15 Geräten und ist echtzeitfähig. Alle Busteilnehmer können vom Bus-Controller prinzipiell gleichzeitig mit Nachrichten erreicht werden, sodass auch eine Triggernachricht gesendet werden kann, die den Namen Group Execute Trig-ger (GET) trägt. Wie ein Gerät die GET-Nachricht interpretiert, hängt entweder von festgelegten Geräteeigenschaften ab oder ist in bestimmten Grenzen über den Bus konfigurierbar. Ein Unsicherheitsfaktor ist, dass es jedem Gerät freisteht, wie lange es zum Empfang der GET-Nachricht braucht. Ein bestimmtes Handshake-Verfahren des GPIB erzwingt nämlich, dass sich alle Busteilnehmer nach dem jeweils langsamsten Gerät richten. Allerdings gibt es noch einen Vorteil für diese Triggermöglichkeit. GPIB ist so ausgelegt, dass jeder Busteilnehmer prinzipiell die Rolle des Controllers übernehmen kann (natürlich immer nur einer zur selben Zeit). Somit könnte ein Gerät in Abhängigkeit von den Messergebnissen also andere Geräte im System triggern, wenn ihm die Kontrolle übergeben würde. Diese Methode wird in der Praxis jedoch kaum angewandt, weil die wenigsten Messgeräte mit GPIB-Schnittstelle über die Controllerfähigkeit verfügen. Die Urversion des GPIB-Standards beschrieb nur die Anforderungen an die Hardware sowie die
2 Schnittstellen für Test- und Messgeräte im Überblick
31
Codierung der Gerätenachrichten. Erst sehr viel später wurde der Standard durch Regeln für die Syntax und den Stil des Informationsaustauschs ergänzt. Aus dem ursprünglichen Standard für Hardware und Codierung der Gerätenachrichten wurde der Standard IEEE 488.1, die ergänzenden Regeln für Syntax und Stil erhiel-ten die Bezeichnung IEEE 488.2. Diese beiden Standards sind für dieses Buch von großer Bedeutung, weil einige grundlegende Anforderungen aus diesen Standards in das Protokoll USB488 eingeflossen sind, das hier ausführlich abgehandelt wird.
Auch der Standard SCPI, von dem hier noch viel berichtet werden wird, hat seine Wurzeln in IEEE 488.2. Der GPIB ist über die vergangenen vier Jahrzehnte der Standard-Messtechnik-Bus gewesen. Der Fortschritt in der Elektronik und in der Informationstechnik lässt ihm jedoch keine großen Überlebenschancen mehr.
Dafür gibt es diverse Gründe: Es ist eine spezielle Controller-Hardware für den GPIB erforderlich, die entweder als PCI-Karte in den Hostcomputer eingebaut, oder als externes Gerät daran angeschlossen werden muss. Der GPIB ist nicht feh-lertolerant, Busteilnehmer können fehlerhafte Nachrichten nicht verwerfen und neu anfordern. Ein einzelnes defektes Gerät kann das gesamte Bussystem zum Still-stand bringen, es ist nicht möglich, Redundanz einzubauen. Es gibt keinen einheit-lichen Mindeststandard für das Protokoll-Management, weil die Geräteentwickler nicht gezwungen sind, IEEE 488.2 verbindlich einzuhalten. Die Buskabel sind teuer und schwer zu beschaffen. Die einzelnen Busteilnehmer sind nur mit erheblichem Aufwand untereinander elektrisch isolierbar, um z. B. Masseschleifen zu vermeiden oder Geräte in einem gemeinsamen System auf unterschiedlichen Massepotenzialen zu betreiben.
2.7 USB
Der Universal Serial Bus wird in diesem Buch noch oft angesprochen, sodass er an dieser Stelle nicht detailliert beschrieben werden muss. Seine Berechtigung in der Messtechnik zeigt die Tatsache, dass führende Unternehmen die USB-Geräteklasse USBTMC mit dem Protokoll USB488 definiert haben und zahlreiche Messgeräte mit USB-Schnittstelle angeboten werden. Er hat jedoch im Messtechnik-Umfeld eine deutliche Schwäche: Es ist nicht möglich, Echtzeitanwendungen mit ihm zu realisieren. Die Bus-Topologie lässt es nicht zu, mehrere Teilnehmer zeitgleich zu benachrichtigen. Der Bus ist in jeder Hinsicht seriell, sowohl in der Datenübertra-gung als auch in der Kommunikation mit den einzelnen Busteilnehmern. Es geht immer schön der Reihe nach, daher können keine Zeitstempel versandt werden, wie beim LXI der Klassen A und B (obwohl es technisch möglich ist, wie im Folgenden noch gezeigt wird). Falls man jedoch nicht auf synchrone Triggermöglichkeiten angewiesen ist, hat der USB gravierende Vorteile gegenüber anderen
Messtechnik-2.7 USB
32
Schnittstellen. USB-Komponenten sind unschlagbar preiswert, weil sie in der Kon-sumgüterindustrie verwurzelt sind. Für den Preis eines einzigen GPIB-Anschluss-kabels bekommt man gegenwärtig das gesamte Kabelmaterial, einschließlich USB-Hub mit Stromversorgungsgerät, für mindestens vier Messgeräte. Und diese Komponenten führt nicht nur der Messgeräte-Fachhändler, sondern gelegentlich sogar der Lebensmittelmarkt um die Ecke. Zeitgemäße PCs besitzen ohnehin meis-tens genug USB-Ports für mindesmeis-tens vier Geräte, sodass für kleine Messsysteme nur noch USB-Kabel beschafft werden müssen, sofern diese nicht ohnehin zum Lie-ferumfang der Geräte gehören. Der USB stellt jedem Busteilnehmer eine Versor-gungsspannung zur Verfügung, wodurch etliche USB-Messgeräte auf eine eigene Spannungsversorgung verzichten können. Das reduziert wiederum Kosten und schafft die Möglichkeit, einfach aufgebaute Sensorsysteme am USB zu betreiben. Es ist außerdem relativ unproblematisch, die einzelnen Messgeräte elektrisch vonein-ander zu isolieren, indem Übertrager eingesetzt werden.
2.8 UXI?
Die Frage, ob es Sinn machen würde, eine spezielle Messtechnik-Erweiterung des USB-Standards zu schaffen, also „Universal Serial Bus Extensions for Instrumenta-tion“, kann prinzipiell verneint werden. Die Erweiterungen würden letztlich in LXI gipfeln, das um die Fähigkeit erweitert wäre, Geräte über die Schnittstelle mit Ener-gie zu versorgen. Und das gibt es bereits mit „Power over Ethernet“ (PoE). Die ein-zig sinnvolle Möglichkeit wäre, auch USB-Geräte über einen Webbrowser zu steu-ern, aber das wird wohl ohnehin noch kommen. Prinzipiell könnte allerdings eine Art LXI der Klasse B auch mit USB erreicht werden, denn einen Zeitstempel gibt es dort schon. Der Packet Identifier (PID) „Start of Frame“ (SOF) wird vom Host gleichzeitig an alle USB-Geräte versandt, wenn sie nicht mit der Übertragungsrate Low-Speed arbeiten. SOF tritt brav einmal pro Millisekunde in Aktion und könnte im Prinzip wie eine Broadcast Message zur Synchronisation benutzt werden. Mit SOF wird auch eine Frame-Nummer versandt, mit der gewisse Triggerinformatio-nen übertragen werden könnten. Diese Möglichkeit besteht technisch, wird aber praktisch nicht umgesetzt oder gar standardisiert. Das legt die Vermutung nahe, dass es künftig zwei Messtechnik-Schnittstellen geben wird, nämlich LXI für echt-zeitfähige Systeme und USB für kostengünstige Messsysteme mit unkritischem Zeitverhalten. Daher ist es nicht weiter verwunderlich, dass bereits Messgeräte ange-boten werden, die gleichzeitig über beide Schnittstellen verfügen. Und als Dritte im Bunde ist manchmal noch GPIB dabei, vermutlich um die Komponente als Aus-tauschgerät in existierenden GPIB-Systemen einsetzen zu können.
2 Schnittstellen für Test- und Messgeräte im Überblick