LabVIEW: Messdatenquellen per LAN integrieren

Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
LabVIEW: Messdatenquellen per LAN integrieren
Der PC verdrängt in der Labor- und Prozessmesstechnik mehr und mehr das
klassische Messinstrument. PC-basierte Instrumente ermöglichen die Datenerfassung, Datenpräsentation und Auswertung auf Basis bekannter Benutzeroberflächen.
Typische Beispiele sind Messtechnikanwendungen für Windows-PCs wie
LabVIEW, VEE oder DASYLab. Diese Softwarepakete beinhalten umfangreiche
Funktionen für die PC-basierte Datenerfassung, -analyse und Datenpräsentation.
In der Regel gehört auch eine Entwicklungsumgebung zum Lieferumfang. Sie gestattet dem Anwender u.a. die Konstruktion eigener Instrumente auf Basis der
vorgefertigten Module.
Für die Anbindung der erforderlichen Messdatenquellen werden in erster Linie die
RS232- und USB-Schnittstellen eines PC genutzt. Teilweise werden auch sehr
spezielle Erweiterungs-Bussysteme als Datenquellen unterstützt. Zwei typische
Beispiele sind VXI (VME Bus for Instrumentation) und PXI (PCI Extensions for
Instrumentation). Sie ermöglichen die Integration sehr schneller Datenquellen.
Die Messdatenquellen müssen sich in der Regel in unmittelbarer Nähe des PCs
SSV EMBEDDED SYSTEMS
1
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
befinden, da die zuvor angesprochenen Schnittstellen primär für die Datenübertragung über kurze Distanzen geeignet sind.
Derzeit noch unzureichend genutzt wird die Ethernet-LAN-Schnittstelle eines
PCs. Dabei bietet gerade dieses Interface besonders vielfältige Möglichkeiten im
Hinblick auf dezentrale Messtechnikanwendungen mit PC-basierten Instrumenten.
Diese Applikationsschrift zu den beiden Linux Device Servern IGW/800 und
IGW/900 liefert zunächst einmal einen kurzen Überblick zu den Grundgedanken
der PC-basierten Messtechnik per LabVIEW – einer weit verbreiteten MSRSoftware der Firma National Instruments. Dann werden die wichtigsten Aspekte
eines Ethernet-LANs aus MSR-Sicht erläutert. Dabei kommt auch das von Haus
aus nicht vorhandene Ethernet-Echtzeitverhalten zur Sprache. In diesem Zusammenhang werden weiter hinten auch aktuelle Entwicklungen aus dem
Echtzeit-Ethernet-Bereich und die daraus resultierenden Probleme angesprochen.
Danach wird an Hand eines konkreten Beispiels eine dezentrale Temperaturmessung vorgestellt. Das PC-basierte Instrument und die Messdatenquelle sind
per Ethernet miteinander verbunden. Dieser Beitrag beschreibt auch den
Zusatznutzen einer solchen Lösung: durch die Eigenintelligenz eines netzwerkfähigen Temperatursensor-Subsystems werden nicht nur Messdaten an einen PC
geliefert. Es können auch Temperaturen hinsichtlich vorgegebener Grenzwerte
überwacht werden. Wird ein solcher Grenzwert überschritten, erfolgt der
automatische Versand einer E-Mail als Alarmmeldung.
LabVIEW für die PC-basierte Instrumentierung
National Instruments LabVIEW wird sowohl in klassischen MSR-Anwendungen
als auch für sehr komplexe Aufgaben im Bereich der Prozess- und Fertigungsautomatisierung eingesetzt.
LabVIEW ist eine relativ offene Software-Plattform. Es stehen von Haus aus zahlreiche Softwarekomponenten zur Unterstützung der in der Messtechnik geläufigen
I/O-Schnittstellen zur Verfügung. Besonders für RS232/RS422/RS485, VXI und
PXI werden leistungsfähige Integrationshilfen angeboten. Aber auch serielle Verbindungen zu Feldbussystemen wie CAN, Profibus, Interbus u.a. sind mittels
LabVIEW möglich.
LabVIEW ermöglicht die PC-basierte virtuelle Instrumentierung. Sie gestattet den
Ersatz konventioneller Messgeräte durch PC-zentrierte Lösungen. Dieser Wandel
vom herstellerdefinierten zum anwenderdefinierten Messsystem hat sich in den
letzten Jahren in verschiedenen Anwendungsbereichen mit einer beachtlichen
Geschwindigkeit verbreitet. Von großer Bedeutung für den Praxiseinsatz ist, dass
über die Benutzeroberfläche (MMI = Mensch-Maschine-Interface) einer PCMSR-Software auch sehr komplexe Anwendungen mit vielen einzelnen Messkomponenten als ein in sich geschlossenes Gesamtsystem erscheinen. Das
vereinfacht den Einsatz und die Handhabung sehr anspruchsvoller Ausgaben.
Der elementare LabVIEW-Grundbaustein ist das VI (virtuelles Instrument). Es
bildet aus der Sicht des Anwenders in erster Linie die Benutzerschnittstelle. Unter
SSV EMBEDDED SYSTEMS
2
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
der Oberfläche beinhaltet ein solches VI aber auch ein (mehr oder weniger
komplexes) ausführbares Programm, welches die eigentliche MSR-Anwendung
implementiert.
Ein typisches virtuelles Instrument (VI) erfüllt unter LabVIEW drei Teilaufgaben:
1. Datenerfassung, 2. Datenanalyse und 3. Datenpräsentation. Abbildung 1
liefert ein Beispiel für ein typisches LabVIEW-VI unter Microsoft-Windows.
Abbildung 1: Oberfläche eines LabVIEW-VI unter Microsoft-Windows
Die Datenerfassung sorgt dafür, dass die Rohdaten auf dem PC in digitalisierter
Form zur Verfügung stehen. Da es sich bei diesen Rohdaten häufig um analoge
Spannungen und Ströme sowie andere – nicht elektrische Größen (Sensordaten) in
analoger Form – handelt, sind in einem PC für den LabVIEW-Einsatz spezielle
A/D-Wandler-Karten erforderlich.
Die LabVIEW-Datenanalyse folgt in der Regel auf eine Datenerfassung. Sie
beinhaltet die Formatierung, Skalierung, Statistik sowie weitere anspruchsvolle
mathematische Analysealgorithmen. Aber auch eine eventuell erforderlich Signalverarbeitung ist im Rahmen der Datenanalyse möglich.
Die Datenpräsentation erfolgt in erster Linie durch die Benutzeroberfläche des
VIs. Das virtuelle Instrument selbst besteht bei detaillierter Betrachtung wiederum
aus einem Frontpanel als sichtbarem Anteil, sowie aus den – im normalen
Betrieb – unsichtbaren Bestandteilen Blockdiagramm und Anschlussblock.
Das VI-Frontpanel bildet die interaktive Benutzerschnittstelle (MMI) zwischen
der eigentlichen Anwendung und dem Bediener. Es besteht aus verschiedenen
grafischen Steuer- und Bedienelementen (Frontpanelobjekte) wie zum Beispiel
SSV EMBEDDED SYSTEMS
3
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
Drehknöpfen, unterschiedlichen Schaltern, Drucktasten, Eingabefeldern u.v.a.
Weitere wichtige Frontpanelobjekte sind Anzeigen (Graphen, LEDs usw.). Über
sie erfolgt die eigentliche Datenpräsentation auf der Benutzeroberfläche.
Ein LabVIEW-Blockdiagramm bildet das tatsächlich ausführbare (Steuer-) Programm hinter dem VI-Frontpanel. Blockdiagramme werden im Rahmen der
LabVIEW-Programmierung in einer speziellen grafischen Programmiersprache
erstellt. Die Art und Weise der symbolbasierten strukturierten LabVIEW-VIBlockdiagrammprogrammierung ermöglicht eine recht hohe Abstraktionsebene
mit großer Nähe zur eigentlichen MSR-Anwendung. Vereinfacht dargestellt
erfolgt das Erstellen bzw. Programmieren eines LabVIEW-Blockdiagramms per
interaktiver visueller Verdrahtung vorgefertigter Symbole. Durch die virtuellen
Drähte zwischen den einzelnen Blockdiagrammsymbolen fließen bei der
Ausführung des VIs die (Mess-) Daten, repräsentiert durch bestimmte Zahlenwerte. Die primären Bestandteile eines Blockdiagramms sind vordefinierte
Funktionen, Konstanten sowie unterschiedliche Ablaufstrukturen (Verzweigungen, Fallunterscheidungen, Schleifen). Auch andere untergeordnete VIs
können in ein Blockdiagramm eingefügt werden. Die Frontpanelobjekte besitzen
innerhalb eines Blockdiagramms korrespondierende Anschlüsse. Über diese
werden sie mit anderen Blockdiagramm-Bestandteilen verbunden. Die Ausführung eines LabVIEW-Blockdiagramms erfolgt Flow Driven, also nach den
Regeln der Datenflusstheorie.
Der Anschlussblock eines LabVIEW-VIs ermöglicht die Integration des VIs als
untergeordnete Funktion in das Blockdiagramm eines anderen VIs. Man spricht in
diesem Zusammenhang von einem SubVI, funktional vergleichbar mit dem
Unterprogramm in einer prozeduralen Programmiersprache. Jedem Anschlussblock ist in der Regel auch ein Symbol zugeordnet. Der VI-Anschlussblock
beschreibt weiterhin, wie die Daten aus anderen Blockdiagrammen eingespeist,
bzw. an andere VIs weitergeleitet werden.
LabVIEW gilt insgesamt als hochentwickelte 4GL (Fourth Generation Language),
also als Programmiersprache der vierten Generation. Solche Sprachen bieten eine
sehr hohe Abstraktionsebene für die Problemlösung. Sie ermöglichen weiterhin
eine sehr schnelle Anwendungsentwicklung.
Ethernet als Basis der dezentralen Messtechnik
Für die erforderlichen Verbindungen zu den I/O-Schnittstellen einer Messtechnikanwendung 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 unternehmensweite, 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.
SSV EMBEDDED SYSTEMS
4
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
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.
Abbildung 2: Ethernet-Ideenskizze von Dr. Metcalfe
Die innovative Idee von Dr. Metcalfe wurde von den Firmen DEC, Intel und
XEROX aufgegriffen und zu einem vermarktungsfähigen Produktkonzept weiterentwickelt. 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 EthernetSpezifikationen ü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
SSV EMBEDDED SYSTEMS
5
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
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.
Abbildung 3: Sternförmige Vernetzung in einem Ethernet-LAN
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 Koaxialverkabelung) 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.
TCP/IP für den Messdatentransport im Ethernet-LAN
Für die reibungslose Kommunikation und den betriebssystemunabhängigen
Datenaustausch zwischen verschiedenen Rechnersystemen in einem EthernetSSV EMBEDDED SYSTEMS
6
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
LAN werden sehr präzise Spezifikationen benötigt. Solche Regelwerke werden in
der Datenkommunikation als Protokolle bezeichnet. Eine Sammlung bestimmter
Protokolle wird als Protokollstack betitelt. Kennen zwei Rechner in einem
Netzwerk die gleichen Protokollregeln, so ist es sehr wahrscheinlich, dass auch
der Datenaustausch zwischen beiden möglich ist. Der Begriff Protokoll ist
eigentlich in der Diplomatie zu Hause. Dort legt ein Protokoll bei einem
Zusammentreffen von Personen aus völlig unterschiedlichen Kulturkreisen fest,
welche Handlungen in welcher Reihenfolge (wie) vorgenommen werden. Die
Beschreibung ist sinngemäß auf die Datenkommunikation übertragbar. Dort regelt
ein Kommunikationsprotokoll den Ablauf und die Details der „Handlungen“
zwischen den Kommunikationspartnern.
Insgesamt spezifiziert ein Protokoll in der Datenkommunikation bis ins letzte
Detail, wie die Daten übertragen werden (Datenformate, Zeichensätze usw.).
Dazu gehören auch die Steuerung des Verbindungsauf- und –abbaus, die
Flusskontrolle der gesamten Datenübertragung sowie die Fehlererkennung und
Fehlerkorrektur. In Netzwerken wird auch die Adressierung der Kommunikationspartner durch ein Protokoll geregelt.
Abbildung 4: IP transportiert TCP- oder UDP-Pakete im Ethernet-LAN
Jedes Protokoll definiert in der Regel auch ein Datenpaket mit einem bestimmten
Format. Solche Pakete bestehen im Allgemeinen aus einem Nutzdaten- und einem
Kopfdatenbereich (Header). Im Header werden die erforderlichen Steuer- und
Adressinformationen des jeweiligen Protokolls übertragen [2].
Ein TCP/IP-Protokollstack ist eine Sammlung ganz bestimmter Kommunikationsprotokolle. Im Grossen und Ganzen besteht dieser Stack aus drei Transportprotokollen, einigen Hilfsprotokollen sowie einer inzwischen nahezu unübersichtlichen Vielfalt von Anwendungsprotokollen. Zwei Protokolle (TCP und IP) bilden
die Basis für den Namen des gesamten Protokollstacks. Die Protokolle TCP
(Transmission Control Protocol), UDP (User Datagram Protocol) sowie IP
(Internet Protocol) können im Zusammenhang mit LabVIEW für die
Kommunikation zwischen PC-basierten Instrumenten und weit entfernten
dezentralen MSR-Datenquellen über ein Ethernet-LAN eingesetzt werden.
Abbildung 4 illustriert das Zusammenspiel der Protokolle TCP, UDP und IP per
Ethernet. Die eigentlichen MSR-Daten werden in ein TCP- oder UDP-Paket
eingebettet. Dieses wiederum wird im Nutzdatenbereich eines IP-Pakets abgelegt.
SSV EMBEDDED SYSTEMS
7
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
Die tatsächliche physikalische Datenübertragung über ein Ethernet-LAN-Kabel
erfolgt allerdings durch das Ethernet-Paket selbst.
Funktion
Aufgabe
accept
Nimmt eine neue Verbindung auf der Serverseite entgegen.
Verknüpft einen Socket mit einer IP-Adresse und einer
bind
Portnummer.
close
Schließt einen Socket.
connect
Erzeugt eine Verbindung zwischen zwei Sockets.
Name für einen Rechner ermitteln, von dem die IP-Adresse
gethostbyaddr
vorliegt.
IP-Adresse für einen Rechner ermitteln, von dem der Name
gethostbyname
vorliegt.
getservbyname Portnummer für einen bestimmten Dienst ermitteln.
Konvertiere 32-Bit-Wert (Long) von Host to Network Byte
htonl
Order.
Konvertiere 16-Bit-Wert (Short) von Host to Network Byte
htons
Order.
inet_addr
Konvertiere IP-Adresse von Zeichenfolge nach 32-Bit-Wert.
inet_ntoa
Konvertiere IP-Adresse von 32-Bit-Wert nach Zeichenfolge.
listen
Warte auf einen Verbindungsaufbau.
Konvertiere 32-Bit-Wert (Long) von Network to Host Byte
ntohl
Order.
Konvertiere 16-Bit-Wert (Short) von Network to Host Byte
ntohs
Order.
recv
Daten über eine bestehende Verbindung empfangen.
recvfrom
Daten von einer bestimmten IP-Adresse empfangen.
select
Statusprüfung.
send
Daten über eine bestehende Verbindung senden.
sendto
Daten an eine bestimmte IP-Adresse senden.
shutdown
Verbindung zum Kommunikationspartner beenden.
socket
Erzeugt einen neuen Socket.
Tabelle 1: Übersicht der wichtigsten Funktionen des Socketinterface
TCP/IP-Protokollstacks besitzen eine mehr oder weniger komplexe Programmierschnittstelle. Diese Schnittstelle wird als Socketinterface bezeichnet. Tabelle 1
liefert eine Übersicht der wichtigsten Funktionen. Das Socketinterface ermöglicht
den direkten Zugriff auf die Protokolle TCP und UDP. Bei einigen TCP/IPImplementierungen kann auch direkt auf IP zugegriffen werden. Über das
Socketinterface können beliebige Daten zwischen zwei Kommunikationspartnern
per Ethernet und TCP/IP übertragen werden. Dabei ist allerdings zu beachten,
dass die einzelnen Funktionen des Socketinterface ein Client/Server-Verhalten
voraussetzen. Das bedeutet, ein Kommunikationspartner arbeitet als Server, der
SSV EMBEDDED SYSTEMS
8
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
andere als Client. Der Server ist in der Regel der passive Partner in einer
Beziehung. Er wartet auf den Verbindungsaufbau durch einen Client, um dann
den Datenübertragungswünschen des Clients zu entsprechen.
Innerhalb eines LabVIEW-Blockdiagramms besteht die Möglichkeit auf das
Socketinterface des PC-Betriebssystems zuzugreifen. Dadurch können Daten aus
einem TCP- oder UDP-Paket in das jeweilige VI importiert werden. Das Ausnutzen dieser LabVIEW-Eigenschaft gestattet verteilte MSR-Anwendungen auf
Basis von Ethernet und TCP/IP.
Temperaturmessung per Ethernet und TCP/IP
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-Anwendung 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.
Abbildung 5: Kopplung einer Messdatenquelle mit einem VI
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 Socketfunktionen socket, bind und listen (siehe Tabelle 1) ein TCP-Serversocket erzeugt.
Das LabVIEW-VI benutzt für den eigentlichen Verbindungsaufbau die Socketfunktion connect (linker Teil der Abbildung 6). Der Server bestätigt die Verbindung mittels accept. Danach besteht eine vollständig transparente Übertragungsstrecke zwischen TCP-Server (Linux Device Server IGW/800 oder
SSV EMBEDDED SYSTEMS
9
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
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.
Abbildung 6: Client/Server-Kommunikation per TCP und Socketinterface
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.
Dezentrale Datenquellen automatisch überwachen
Der Rechnerkern der Linux Device Server IGW/800 und IGW/900 wird durch
einen Freescale (früher Motorola) 32-bit-MCF5282 gebildet. Diese MCU
(MicroController Unit) basiert auf einem ColdFire-CPU-Core der Version 2 (V2),
der im Laufe der Jahre über verschiedene Zwischenschritte aus der M68000Architektur desselben Herstellers entstanden. Der ColdFire-V2-CPU-Core des
MCF5282 wird in den IGW/800 und IGW/900 mit einem Prozessortakt von 66
MHz betrieben. Dabei ergibt sich eine Rechenleistung von ungefähr 63 Dhrystone
2.1 MIPS – also im Idealfall bis zu 63 Millionen Befehle je Sekunde. Der CPUSSV EMBEDDED SYSTEMS
10
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
Core (Prozessorkern) des MCF5282 verfügt über einen internen 2K-Cache für
Befehle (I-Cache) und Daten (D-Cache) zur Leistungssteigerung. Die Aufteilung
der Speichertiefe von insgesamt 2K in die I- und D-Cache-Bereiche ist über
spezielle Register konfigurierbar.
Um ein Linux als Betriebssystem ablaufen zu lassen, ist neben dem 32-bitMikrocontroller auch der entsprechende Speicher erforderlich. Dieser wird im
IGW/800 und IGW/900 durch zwei hochintegrierte Schaltkreise gebildet. Einer
davon ist ein 16-MByte-SDRAM (Synchrones Dynamisches RAM =
Speicherbaustein, der laufend aufgefrischt werden muss, damit die gespeicherten
Informationen nicht verloren gehen). Er dient als Arbeitsspeicher. Der andere
Baustein ist ein sogenannter Flash, also ein nichtflüchtiger Halbleiterspeicher, der
sektorweise gelöscht und neu programmiert werden kann – vergleichbar mit der
Speicherkarte einer digitalen Kamera. Dieser Flash besitzt eine Speicherkapazität
von 8 MBytes.
Im Flash-Speicherbaustein eines IGW/800 und IGW/900 Linux Device Server ist
der Hardware-Initialisierungscode, ein Linux-Bootloader zum Start des
Betriebssystems, der Linux-Kernel (Betriebssystemkern) selbst, sowie das für
Linux obligatorische Root-Dateisystem abgelegt. Weiterhin ist noch ein
sogenannter Flash-Loader vorhanden, der den Austausch des Bootloaders, des
Linux-Kernels und des Root-Dateisystems über eine serielle RS232-Schnittstelle
oder per Ethernet ermöglicht. Insgesamt werden im Flash noch nicht einmal 2
MByte Speicherkapazität vom Betriebssystem nebst Zubehör benötigt. Linux ist
sehr kompakt, ursächlich dafür ist seine Skalierbarkeit. Der restliche FlashSpeicherplatz steht zur Laufzeit als nicht flüchtiges Schreib/Lese-Laufwerk (SSD
= Solid-State Disk) zur Verfügung. Das SDRAM dient als Arbeitsspeicher und als
RAM-Disk für das Root-Dateisystem.
Durch den leistungsfähigen 32-bit-Mikrocontroller und das Linux-Betriebssystem
kann ein IGW/800 bzw. IGW/900 Linux Device Server deutlich mehr Aufgaben
übernehmen, als die Daten aus einem Temperatursensor auszulesen und per
Ethernet-basierter TCP/IP-Verbindung an ein LabVIEW-VI zu liefern. So kann –
neben dem TCP-Server für die LabVIEW-Kommunikation – zusätzlich auch noch
ein SMTP-Client laufen. Linux ist schließlich ein Multitasking-Betriebssystem.
Über SMTP (Simple Mail Transfer Protocol = TCP/IP-Protokoll für den E-MailVersand) ist dann der automatische E-Mail-Versand möglich. Erreicht zum
Beispiel die Temperatur einen gewissen Grenzwert, könnte über diese Eigenschaft
ein Systembetreuer alarmiert werden.
Selbstverständlich ist auch eine Langzeit-Datenaufzeichnung (Data Logging)
möglich. Diese Daten können auf Wunsch als E-Mail-Anhang ebenfalls mit Hilfe
der TCP/IP-Protokolle verschickt werden.
Ausblick auf weitere Einsatzmöglichkeiten
Ein großes Handikap für den Ethernet-Einsatz in LabVIEW-basierten MSRAnwendungen ist zur Zeit sicherlich die fehlende Echtzeitfähigkeit. Zahlreiche
Aufgabenstellungen in der MSR-Welt erfordern aber ein echtzeitfähiges VerSSV EMBEDDED SYSTEMS
11
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
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 LANTeilnehmer 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.
Abbildung 7: Deterministisches Zeitverhalten
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
SSV EMBEDDED SYSTEMS
12
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
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.
Fazit
Die direkte Übernahme von TCP/IP-Daten in ein LabVIEW-VI-Blockdiagramm
ermöglicht verteilte MSR-Anwendung mit großer räumlicher Ausdehnung. Die
für den Datentransport benutzten TCP/IP-Protokolle sind grundsätzlich nicht an
das Ethernet gebunden. Sie kommen auch im weltweiten Internet zum Einsatz.
Dadurch ist die hier beschriebene Lösung nicht nur in einem lokalen EthernetLAN, sondern – ohne jede Änderung – auch im weltweiten Internet einsetzbar.
Der LabVIEW Integration Kit LAN (LIK-LAN) benutzt als Messgröße die Umgebungstemperatur. Die Bausteine dieses Kits lassen sich aber sehr leicht an
andere elektrische oder nicht elektrische Größen (Sensordaten) anpassen. Die
Kommunikation per TCP/IP bleibt dabei unverändert.
Die TCP/IP-Kommunikations- und Multitaskingfähigkeit des IGW/800- bzw.
IGW/900-Linux-Betriebssystems eröffnet zahlreiche weitere Anwendungsmöglichkeiten. Über die Grenzwertüberwachung mit E-Mail-Alarmierung sowie ein
optionales Data Logging wurden zwei Beispiele vorgestellt.
SSV EMBEDDED SYSTEMS
13
Linux Device Server IGW/800 und IGW/900: Anwendungshinweise
Abbildungen
Abbildung 1: Oberfläche eines LabVIEW-VI unter Microsoft-Windows
Abbildung 2: Ethernet-Ideenskizze von Dr. Metcalfe
Abbildung 3: Sternförmige Vernetzung in einem Ethernet-LAN
Abbildung 4: IP transportiert TCP- oder UDP-Pakete im Ethernet-LAN
Abbildung 5: Kopplung einer Messdatenquelle mit einem VI
Abbildung 6: Client/Server-Kommunikation per TCP und Socketinterface
Abbildung 7: Deterministisches Zeitverhalten
Quellenangaben
[1] Walter: MSR mit ARM- Mikrocontrollern. Franzis-Verlag 2004.
[2] Walter: Embedded Internet in der Industrieautomation. Hüthig-Verlag 2004.
[3] Website zu den Linux Device Servern: www.ssv-comm.de
Kontakt
SSV Embedded Systems
Heisterbergallee 72
D-30453 Hannover
Tel. +49-(0)511-40000-0
Fax. +49-(0)511-40000-40
Email: [email protected]
Web: www.ssv-embedded.de
Web: www.ssv-comm.de
Web: www.dilnetpc.com
Hinweise zu diesem Dokument (LabVIEW-AN1.Doc)
Revision
Date
1.00
28.01.2005
Name
Erste Version erstellt
KDW
Dieses Dokument ist nur für die interne Verwendung bestimmt. Der Inhalt
dieses Dokuments kann sich jederzeit ohne Ankündigung ändern. Es wird
keine Garantie für die Richtigkeit der Angaben übernommen. Copyright ©
SSV EMBEDDED SYSTEMS 2005. Alle Rechte vorbehalten.
Einige in der dieser Beschreibung erwähnte Produkt- und Firmennamen
sind möglicherweise die Warenzeichen der jeweiligen Besitzer.
SSV EMBEDDED SYSTEMS
14