Für die erforderlichen Verbindungen zu den I/O-Schnittstellen einer Messtechnik-anwendung werden in erster Linie USB, RS232/RS422/RS485, VXI und PXI benutzt. Dadurch entstehen MSR-Applikationen, in welchen der LabVIEW-PC und die MSR-Datenquellen in unmittelbarer Nähe zueinander angeordnet sind.

Grundsätzlich unterstützt LabVIEW aber auch Feldbussysteme mit mittlerer Ausdehnung sowie LAN-Integrationen. Über die fortschreitende unternehmens-weite, durchgängige Vernetzung auf Basis von Ethernet und TCP/IP eröffnen sich aber auch für den LabVIEW-Einsatz vielfältige neue Anwendungsmöglichkeiten mit vollständig dezentraler Struktur. Leider erfordern solche MSR-Applikationen ein umfangreiches Detailwissen über Netzwerk- und Protokolltechnologien. Weiterhin reicht die 4GL-Programmierung für LabVIEW alleine nicht aus, um eine dezentrale Anwendung per Ethernet und TCP/IP zu erstellen. Diese Lücke versucht der LabVIEW Integration Kit LAN (LIK-LAN) für die beiden Linux Device Server IGW/800 und IGW/900 zu schließen.

Ethernet wurde ursprünglich für lokale Netzwerke (LANs = Local Area Networks) in der Büroumgebung entwickelt. Die Idee für diese Form der Vernetzung über ein gemeinsam benutztes Übertragungsmedium hatte im Jahre 1973 Dr. Robert Metcalfe, damals ein Mitarbeiter der US-Firma XEROX. Abbildung 2 zeigt die ursprüngliche Ideenskizze von Dr. Metcalfe. Bereits 1976 veröffentlicht Dr. Metcalfe die erste Beschreibung zu Ethernet. Der Name Ethernet basiert im Übrigen auf der völlig falschen Annahme der Physiker von 1887, dass der gesamte Weltraum mit einem „Lichtäther" gefüllt sei, in welchem sich elektromagnetische Wellen problemlos ausbreiten können.

Die innovative Idee von Dr. Metcalfe wurde von den Firmen DEC, Intel und XEROX aufgegriffen und zu einem vermarktungsfähigen Produktkonzept weiter-entwickelt. Die Arbeitsgemeinschaft aus diesen drei Firmen nannte sich DIX (DEC, Intel, XEROX). 1980 wurden die ersten DIX-Ethernet-Spezifikationen veröffentlicht. Kurz danach kamen in den USA die ersten IBM-PCs auf den Markt. Der Rest der Geschichte ist bekannt. Heute kann man praktisch keinen PC mehr kaufen, der nicht bereits ab Werk mit einem Ethernet-LAN-Interface ausgestattet ist. Ethernet wurde durch den PC zu einem etablierten Standard.

In der Zwischenzeit hat das US-Standardinstitute IEEE (Institute of Electrical and Electronics Engineers) die Pflege und Weiterentwicklung der gesamten Ethernet-Spezifikationen übernommen. Aus den DIX-Arbeiten ist der Standard IEEE 802.3 geworden. Diese Ursprungsform des Ethernet-Standards war für lokale Netzwerke (LANs) mit 10 Mbps gedacht. Zahlreiche weitere Arbeiten, wie IEEE 802.3u für das 100-Mbps-Fast-Ethernet, 802.3z/802.3ab für 1.000-Mbps-Gigabit-Ethernet und 802.3ae für zukünftige 10-Gigabit-Ethernet-Netzwerke dokumentieren die kontinuierliche Weiterentwicklung [1].

Ethernet ist von Haus aus ein logischer Bus. Die Daten des jeweils sendenden Rechners in einem Netzwerk werden von allen anderen Rechnern gleichzeitig empfangen. Der logische Bus war in der Urform des Ethernets auch als physikalischer Bus implementiert. Dabei wurde ein Koaxialkabel an allen Rechnern vorbeigeführt. Über ein spezielles Verbindungsstück (zum Beispiel das BNC-T-Stück bei der 10Base2-Verkabelung) war der jeweilige Rechner mit dem Koaxialkabel verbunden.

Das busförmige Kabel diente als gemeinsam benutztes Übertragungsmedium gemäß der Idee von Dr. Metcalfe. Um den gleichzeitigen Zugriff mehrerer Rechner auf das Medium zu koordinieren, ist ein Verfahren zur Zugriffssteuerung notwendig (siehe hierzu: CSMA/CD-Zugriffsverfahren). Dieses muss auch die Bandbreite unter den einzelnen Teilnehmern eines Netzwerks aufteilen.

Die Vorteile der busförmigen Verkabelung waren die geringen Kosten und die einfache Erweiterbarkeit. Die Nachteile waren die sehr große Fehleranfälligkeit (zum Beispiel wegen fehlender Abschlusswiderstände bei der Koaxial-verkabelung) und die kaum mögliche Fehlerdiagnose im Problemfall. Auf Grund der Nachteile hat die busförmige Ethernet-Verkabelung mittlerweile ausgedient und wird für neue Installationen kaum noch verwendet. Gängig sind inzwischen sternförmige Topologien wie in der Abbildung 3.

Der Stern ist eine Punkt-zu-Punkt-Verbindung zwischen einem Rechner (R) und einem speziellen Sternkoppler bzw. Sternverteiler (S). Somit steht praktisch jedem Rechner die volle Bandbreite zum Sternkoppler zur Verfügung. Sogar die Vollduplexübertragung ist bei sternförmiger Vernetzung mit einem Sternkoppler grundsätzlich möglich, wenn – wie beim 10- und 100-Mbps-Ethernet – zwei Adernpaare benutzt werden. Alle Rechner können in einem solchen Netzwerk praktisch gleichzeitig senden. Lediglich die Übertragung von Echtzeitdaten ist auf Grund des Ethernet-Übertragungsverfahrens von Haus aus nicht möglich.

Der LabVIEW Integration Kit LAN (LIK-LAN) überträgt die Möglichkeiten von Ethernet, TCP/IP und dem zuvor vorgestellten Socketinterface, auf eine in der Praxis einsetzbare LabVIEW-Anwendung. In dieser dezentralen MSR-An-wendung ist ein Linux Device Server IGW/800 oder IGW/900 [3] mit bis zu vier verschiedenen Temperatursensoren verbunden. Die Sensordaten werden vom Linux Device Server per Ethernet periodisch an ein VI weitergeleitet und dort grafisch dargestellt. Die Abbildung 5 illustriert den Zusammenhang.

LabVIEW arbeitet in diesem Beispiel als TCP-Client, der Linux Device Server IGW/800 oder IGW/900 mit dem Temperatursensor als TCP-Server. Nach dem Start des VIs erzeugt dieses über das PC-Socketinterface eine TCP-Verbindung zum Linux Device Server. Dieser liefert dann die aktuellen Temperaturwerte an das VI auf dem PC.

Der rechte Teil in der Abbildung 6 illustriert das Kommunikationsverhalten des TCP-Serverprogramms auf dem Linux Device Server. Sofort nach dem Anlegen der IGW/800- bzw. IGW/900-Versorgungsspannung wird mit Hilfe der Socket-funktionen socket, bind und listen (siehe Tabelle 1) ein TCP-Serversocket erzeugt.

Das LabVIEW-VI benutzt für den eigentlichen Verbindungsaufbau die Socket-funktion connect (linker Teil der Abbildung 6). Der Server bestätigt die Ver-bindung mittels accept. Danach besteht eine vollständig transparente Über-tragungsstrecke zwischen TCP-Server (Linux Device Server IGW/800 oder IGW/900) und TCP-Client (LabVIEW-VI auf dem PC). Über diese können beide Kommunikationspartner mit Hilfe der Funktionen send und recv beliebige Daten übertragen. Wird das VI beendet, kann es über die Funktion close die Verbindung beenden.

Beim praktischen Einsatz dieser Lösung in einem Firmennetzwerk ist zu beachten, dass für die Datenübertragung per TCP eine bestimmte Portnummer (Adresselement der TCP- und UDP-Protokolle eines TCP/IP-Protokollstacks) benutzt wird. Typischerweise findet man in einem Firmen-LAN verschiedene Firewalls, die den gesamten Datenverkehr filtern und überwachen. Sämtlichen Ethernet-LAN-Firewalls zwischen PC mit dem LabVIEW-VI und Linux Device Server muss die zum Einsatz kommende TCP-Portnummer bekannt sein. Die zu benutzende Portnummer kann für das VI und den TCP-Server innerhalb bestimmter Grenzen nach Bedarf konfiguriert werden. Unter Umständen muss der zuständige LAN-Administrator kontaktiert werden.

Ein großes Handikap für den Ethernet-Einsatz in LabVIEW-basierten MSR-Anwendungen ist zur Zeit sicherlich die fehlende Echtzeitfähigkeit. Zahlreiche Aufgabenstellungen in der MSR-Welt erfordern aber ein echtzeitfähiges Ver-halten. Aus diesem Grund ist Ethernet als Übertragungsmedium zur Lösung vieler MSR-Probleme gegenwärtig nur bedingt geeignet. Die Ursache hierfür ist das Ethernet-CSMA/CD-Zugriffsverfahren (CSMA/CD = Carrier Sense Multiple Access / Collision Detection). Bei diesem Verfahren sind alle Teilnehmer in einem Ethernet-LAN gleichberechtigt. Es gibt keinen Bus-Master, der den anderen Teilnehmern eine Zugriffserlaubnis für die Datenübertragung erteilt und so den Zugriff auf das gemeinsame Medium kontrolliert. Hat ein LAN-Teilnehmer Daten die er versenden möchte, so prüft er zunächst, ob das Übertragungsmedium (das Ethernet-LAN-Kabel) frei ist (Carrier Sense-Phase). Ist das nicht der Fall, wird gewartet, bis der andere Teilnehmer seine Datenübertragung abgeschlossen hat. Erkennt der prüfende – und ggf. wartende – Teilnehmer das unbenutzte Übertragungsmedium, beginnt er die jeweiligen Daten zu versenden. Dabei wird sofort nach dem Sendebeginn für eine bestimmte Zeit (Collision Window) überprüft, ob es zu einer Kollision kommt, weil gleichzeitig eine weitere Station mit der Datenübertragung begonnen hat. Im Fall einer solchen Kollision wird die Übertragung sofort abgebrochen, um eine zufällige Wartezeit verstreichen zu lassen. Dann wiederholt sich der Übertragungsvorgang mit dem Einleiten einer neuen Carrier Sense-Phase.

Durch den CSMA/CD-Buszugriff ist nicht vorhersehbar, wann genau ein Ethernet-Datenpaket verschickt wird. Ethernet besitzt durch das standardmäßige CSMA/CD-Buszugriffsverfahren kein deterministisches Zeitverhalten, wie es aber für viele dezentrale MSR-Aufgaben unbedingt erforderlich wäre. Die Abbildung 7 illustriert die Zusammenhänge bezüglich eines deterministischen Zeitverhaltens: wenn zum Zeitpunkt t1 ein Ereignis eintritt, muss unter allen Umständen nach dem Verstreichen einer Latenzzeit spätestens zum Zeitpunkt t2 die Reaktion erfolgen. Die Latenzzeit eines echtzeitfähigen Systems ist stets eine bekannte Größe. Sie wird in jedem Fall – unabhängig von der Systemauslastung – eingehalten. In der Praxis ist jedoch jede Latenzzeit mit einem Jitter (Varianz) behaftet. Je geringer ein solcher Jitter ist, desto hochwertiger ist ein Echtzeitsystem.

Es gibt in der MSR-Welt in der letzten Zeit zahlreiche Bestrebungen, das Ethernet als Ersatz für echtzeitfähige Feldbussysteme zu benutzen. Die Ursachen hierfür sind die relativ geringen Übertragungsgeschwindigkeiten der vorhandenen Feldbusse – im Vergleich zum 100 Mbps-Ethernet – und die Tatsache, dass Ethernet-Verkabelung in vielen industriellen Umgebungen bereits vorhanden ist (ein Kabel für verschiedene Aufgaben). Das einzige zu lösende Problem ist das fehlende Echtzeitverhalten in Ethernet-LANs. Verschiedene Anbieter und Forschungseinrichtungen haben zwei völlig unterschiedliche Ansätze als Lösung erarbeitet: 1. die Uhrensynchronisation für Zeitstempel im Zusammenhang mit der Priorisierung bei der Übertragung von Ethernet-Datenpakten und 2. den Ersatz des klassischen CSMA/CD-Buszugriffsverfahren durch ein Zeitschlitzverfahren (TDMA). Beide Verfahren werden in Zukunft sicherlich sogar die Integration von Echtzeitdatenquellen in LabVIEW-VIs per Ethernet und TCP/IP ermöglichen.