Verwenden des richtigen Netzwerkprotokolls

Jede Art der Kommunikation umfasst Zielsysteme (üblicherweise Datenerfassungssysteme oder Controller) und Hosts (üblicherweise die Anzeige des HMIs), die in mehreren möglichen Konfigurationen angeordnet werden können. Sie können zwischen einem einzelnen Zielsystem und einem einzelnen Host kommunizieren (1:1), zwischen mehreren Zielsystemen und einem einzelnen Host (N:1) oder zwischen einem einzelnen Zielsystem und mehreren Hosts (1:N). Im folgenden Abschnitt werden die verschiedenen Kommunikationsarten beschrieben, die in Maschinensteuerungsanwendungen verwendet werden, die gängigen Systemkonfigurationen sowie die Netzwerk- und Datenübertragungsanforderungen.

Befehls- oder nachrichtenbasierte Kommunikation

Befehls- oder nachrichtenbasierte Kommunikation ist eine seltene Informationsübertragung, die durch ein bestimmtes Ereignis ausgelöst wird. Dabei kann es sich um einen Schaltflächendruck oder einen Alarm handeln, der dann eine bestimmte Reaktion auslöst. Bei einer befehlsbasierten Architektur gibt es zwei Arten von Systemen: ein Commander-System (Host) und ein Worker-System (Zielsystem). Der Commander sendet Anweisungen, die der Worker ausführen muss. Befehle müssen verlustfrei ausgegeben werden und sollten eine minimale Latenz haben. Wenn ein Bediener beispielsweise eine Schaltfläche drückt, erwartet er, dass die zugehörige Aktion ausgeführt wird, ohne die Schaltfläche erneut drücken zu müssen. Er erwartet außerdem, dass das System innerhalb eines angemessenen Zeitrahmens reagiert. Die gängigste Konfiguration ist 1:1, aber es sind auch N:1 und 1:N möglich.

Prozessdatenkommunikation

Die Prozessdatenkommunikation besteht aus der periodischen Übertragung der neuesten Werte von Prozessvariablen. Diese Art der Kommunikation ist am häufigsten und nützlich für Steueranwendungen und für MMS, die zur Anzeige aktueller Systemzustände verwendet werden.  Sie wird z. B. für regelmäßige Updates eingesetzt, die von einem oder mehreren Embedded-Controllern an eine MMS gesendet werden, der den Zustand des/der Rechner(s) überwacht.  Der Bediener muss den aktuellen Zustand der Maschinen sehen, so dass eine verlustfreie Übertragung nicht erforderlich ist, da der Real-Time-Controller oder HMI nur auf den neuesten Wert reagiert.

Diese Art der Datenübertragung kann zwischen Embedded-Controllern verwendet werden und muss möglicherweise mit hoher Geschwindigkeit ausgeführt werden.  Am häufigsten wird die Prozessdatenkommunikation jedoch zum Aktualisieren einer MMS verwendet.  Diese Art der Kommunikation bringt langsame Aktualisierungsraten mit sich, da die Daten von Menschen betrachtet werden. Aktualisierungsraten von 1 bis 30 Hz sind in der Regel ausreichend. Alles, was schneller ist, belastet CPU- und Speicherressourcen und stellt mehr Informationen dar, als der menschliche Bediener visuell verarbeiten kann. Eine gute Regel ist, dass numerische Anzeigen nicht schneller als mit 1–2 Hz aktualisiert werden sollten. Bei grafischen Anzeigen sorgen 30 Hz für reibungslose Aktualisierungen.

Streaming/gepufferte Kommunikation

Beim Daten-Streaming werden große Mengen an Informationen kontinuierlich, aber nicht unbedingt in Echtzeit gesendet. Diese Art der Kommunikation ist nützlich, wenn viele Daten gesendet werden sollen und Sie jeden Datenpunkt erfassen müssen. Oft, aber nicht immer, ist das Streaming unidirektional und hat eine 1:1-Konfiguration. Dabei werden die Daten kontinuierlich gepuffert, so dass keine Daten verloren gehen. Streaming-Kommunikation wird häufig verwendet, wenn ein Zielgerät eine Datenerfassung mit hoher Geschwindigkeit durchführt und die Daten zur Protokollierung oder Nachbearbeitung an den Host übertragen werden müssen.

Tabelle 1.1. Zusammenfassung der Kommunikationsarten der Maschinensteuerung

Bei der Auswahl eines Netzwerkprotokolls für Ihre Anwendung sollten Sie folgende Faktoren berücksichtigen:

• Kommunikationstyp
• Systemkonfiguration
• Leistung
• Benutzerfreundlichkeit
• Unterstützte APIs von Drittanbietern

Die oben beschriebenen Kommunikationsarten und Systemkonfigurationen sind der entscheidende Faktor bei der Auswahl des Netzwerkprotokolls für Ihre Anwendung. Die Anforderungen an Leistung und Benutzerfreundlichkeit richten sich nach Ihrer spezifischen Anwendungs- und Programmiererfahrung. Wenn Sie Ihre Anwendung entwickeln möchten, um mit Anwendungen von Drittanbietern wie z. B. mit C oder VB zu kommunizieren, müssen Sie Netzwerkprotokolle verwenden, die mit APIs von Drittanbietern arbeiten können. Durch die Untersuchung dieser Faktoren sind Sie in der Lage, die richtige Entscheidung für Ihre Anwendung zu treffen. Eine Zusammenfassung der einzelnen Netzwerkprotokolle in Bezug auf die oben genannten Faktoren finden Sie in Tabelle 1.2.

Tabelle 1.2. Zusammenfassung der Netzwerkprotokolle ( = Am besten,  = Besser,  = Gut, * = hängt davon ab, welche Aktion im Webdienst abgeschlossen wird)

TCP und UDP

TCP- und UDP-Internetprotokolle sind Bausteine auf grundlegender Ebene, die von allen in diesem Dokument behandelten Netzwerkprotokollen verwendet werden. Alle anderen Protokolle bieten zusätzlich zu diesen Protokollen eine benutzerfreundliche Abstraktion. Aufgrund dieser Abstraktion bieten TCP und UDP die höchste Leistung und bieten eine grundlegende Steuerung, die größtmögliche Flexibilität ermöglicht. TCP und UDP können verwendet werden, um ein eigenes benutzerdefiniertes Protokoll (z. B. STM) zu erstellen.

TCP

TCP ist ein zuverlässiges Punkt-zu-Punkt-Kommunikationsprotokoll; Daten werden ordnungsgemäß und verlustfrei ausgetauscht. Da es sich um ein verbindungsbasiertes Protokoll handelt, muss vor der Datenübertragung eine Verbindung zwischen dem Client und dem Server hergestellt werden. Um die Zustellung der Daten sicherzustellen, überträgt TCP die Daten so lange, bis eine Bestätigung eingeht. Der TCP-Client und der TCP-Server kommunizieren über einen angegebenen Port.

UDP

UDP unterscheidet sich von TCP dadurch, dass es Daten an einen angegebenen Port veröffentlicht, aber keine Verbindung mit einem Client erfordert, bevor die Daten gesendet werden. Wenn es keine Verbindung zum Empfang der Daten am Zielort gibt, werden die Daten einfach verworfen; es gibt keine Überprüfung auf erfolgreiche Auslieferung. Daher sollte UDP nicht in Anwendungen verwendet werden, in denen die verlustfreie Datenübertragung von entscheidender Bedeutung ist.

UDP-Funktionen können verwendet werden, um mit einem einzelnen Client zu kommunizieren, oder Daten können an mehrere Clients übertragen werden. UDP-Multicast ist ein Modus zur effizienten Kommunikation zwischen einem einzelnen Sender und mehreren Clients in einem Netzwerk, ohne dass der Sender eine Liste von Clients führen muss. UDP hat die höchsten Übertragungsraten von allen hier behandelten Protokollen, gewährleistet aber nicht die verlustfreie Datenübertragung.

TCP und UDP sind Netzwerkprotokolle mit hohem Durchsatz, jedoch auf Kosten der Einfachheit der Implementierung. Die Netzwerkverbindung muss manuell verwaltet werden. Jede Verbindung beansprucht einen Port. TCP und UDP erfordern, dass alle Daten im String-Format gesendet werden. Das heißt, der Sender muss alle Daten in einen String verwandeln und der Empfänger muss die Daten aus einem String wieder zurückverwandeln. Dadurch wird die Übertragung von Daten, die nicht in String-Form vorliegen, noch komplexer.

TCP und UDP sind gute Werkzeuge für die nachrichtenbasierte Kommunikation und benutzerdefinierte Streaming-Anwendungen. Sie unterstützen alle Arten von Konfigurationen und können, da es sich um Branchenstandards handelt, mit Anwendungen von Drittanbietern verwendet werden.

Netzwerk-Umgebungsvariablen

Netzwerk-Umgebungsvariablen sind ein benutzerfreundliches LabVIEW-Tool zum Austauschen von Daten. Sie sind einfach zu implementieren und unterstützen die meisten LabVIEW-Datentypen und benutzerdefinierten Typdefinitionen.

Die Netzwerkvariable in LabVIEW besteht aus drei Teilen: Netzwerkvariablenknoten, der Engine für Umgebungsvariablen und dem NI-Publish-Subscribe-Protokoll (NI-PSP). Die Netzwerkvariablenknoten werden im Blockdiagramm platziert, um die Lese- und Schreiboperationen der Variablen durchzuführen. Die Engine für Umgebungsvariablen ist die Softwarekomponente, mit der die veröffentlichten Daten gehostet werden. Sie kann auf Real-Time-Zielsystemen oder Windows-PCs gehostet werden, muss aber auf mindestens einem Netzwerkcomputer ausgeführt werden.  NI-PSP ist ein proprietäres Netzwerkprotokoll, das den Transport von Netzwerk-Umgebungsvariablen optimiert. Dieses Protokoll basiert auf TCP/IP, wodurch Daten effizient und zuverlässig über das Netzwerk übertragen werden können.

Sie können die Pufferung für Netzwerk-Umgebungsvariablen aktivieren. Dies eignet sich, wenn Sie eine einfache Möglichkeit benötigen, pseudo-verlustlose N:1- und 1:N-Kommunikation zu implementieren. Das Puffern von Umgebungsvariablen kann Datenverlust aufgrund vorübergehender Netzwerkverzögerungen verhindern, garantiert jedoch keine verlustfreie Datenübertragung. Wenn ein Client Daten schneller schreibt, als ein anderer Client Daten liest, tritt letztlich ein Überlauf auf und Daten gehen verloren. Der Datenfluss wird nicht verwaltet, um einen Überlauf zu verhindern. Selbst wenn alle Clients schnell genug lesen, können Daten trotzdem verloren gehen, wenn Daten übertragen werden, während die zugrunde liegende TCP-Verbindung aufgrund von Netzwerkunterbrechungen unterbrochen ist. Netzwerk-Streams werden empfohlen, wenn eine verlustfreie Datenübertragung von Punkt zu Punkt gewünscht ist. Netzwerk-Umgebungsvariablen eignen sich am besten für die Kommunikation von Prozessdaten, wenn der aktuellste Wert einer Prozessvariablen wichtig ist.

Netzwerk-Streams

Netzwerk-Streams sind eine in LabVIEW 2010 veröffentlichte LabVIEW-Funktion, die für ein effizientes Daten-Streaming entwickelt wurde.  Sie bieten einfach zu verwendende Abstraktionen auf höherer Ebene für die Handhabung von Verbindungen, Trennungen und die Kontrolle des Datenflusses, während gleichzeitig ein ähnlicher Durchsatz von rohem TCP/UDP beibehalten wird. Es handelt sich bei jedem Netzwerk-Stream um einen verlustlosen, unidirektionalen Kommunikationskanal zwischen jeweils einem Endpunkt zum Senden und Empfangen. Aufgrund seines verlustfreien Charakters kann er auch als Grundlage für die Nachrichtenkommunikation dienen.

Netzwerk-Streams können die meisten LabVIEW-Datentypen, einschließlich Clustern und Arrays, über das Netzwerk übertragen. Streams sind jedoch am effizientesten mit den folgenden Datentypen:

• Numerische Skalare
• Boolesche Werte
• 1D-Arrays aus numerischen Skalaren
• 1D-Arrays aus booleschen Werten

Sie können Netzwerk-Streams verwenden, um Daten von einem Computer an einen anderen Computer, von einem Computer an ein Real-Time-Remote-System oder von einem Real-Time-Remote-System an ein Real-Time-Remote-System zu übertragen. Da Netzwerk-Streams unidirektional sind, müssen Sie zwei Streams öffnen, wenn Sie Daten auf beide Arten zwischen Ihren Endpunkten weiterleiten möchten. Wenn Sie Daten an mehrere Zielsysteme weiterleiten müssen, müssen Sie auch mehrere Streams öffnen.

Webdienste

Mit Webdiensten können Sie Webanwendungen erstellen, die über das Netzwerk mit jedem HTTP-fähigen Web-Client, einschließlich Standard-Webbrowser, kommunizieren. Mit LabVIEW können Sie ein VI als serverseitigen Webdienst veröffentlichen. Dieses VI wird als Webmethoden-VI bezeichnet. Dieser Webdienst wird auf einen eigenen Webserver von ausführbaren Dateien oder auf den Webserver von Anwendungen übertragen und kann auf Windows-PCs und NI-Real-Time-Computing-Plattformen gehostet werden. Diese LabVIEW-Funktion hat den Vorteil, dass sie mit zahlreichen HTTP-fähigen Geräten und Anwendungen arbeitet, die sich nicht auf Produkte von National Instruments beschränken. Viele Benutzer können eine oder mehrere Anwendungen von verschiedenen Plattformen und Standorten aus überwachen. Die Benutzerfreundlichkeit und Effizienz hängt vom Web-Client und Ihrer Kenntnisse in der Programmierung von Webanwendungen ab.

Der Datenaustausch mit dem Webmethoden-VI erfolgt über eine URL und Standard-HTTP-Methoden. So können Sie beispielsweise von einem Web-Client mit Hilfe von Standard-HTTP-Methoden (z. B. POST) Eingangsdaten für die Elemente des Web-Methoden-VIs bereitstellen. Die Daten werden entweder über die Ausgangsanschlüsse des VIs oder durch Streaming über den Webserver an den HTTP-Client ausgegeben.  Bei der Anschlussmethode gibt der Webserver beim Empfang einer Anfrage alle mit einem Ausgangsanschluss verbundenen Daten als XML-String (Extensible Markup Language) an den Web-Client zurück. Der Webdienst kann auch so konfiguriert werden, dass Daten in Hypertext-Markup-Sprache (HTML), JavaScript-Objektnotation (JSON) oder im Textformat ausgegeben werden. Ein Webmethoden-VI kann auch für den Stream-Ausgangsmodus konfiguriert werden. Mit diesem Ausgangsmodus können Sie Daten in einem benutzerdefinierten Format ausgeben. Sie können eine Pufferung implementieren und benutzerdefinierte HTML-Header verwenden. Mit diesen beiden verfügbaren Ausgangsmodi eignen sich Webdienste zur Überwachung oder zum Streaming von Anwendungen.

Im Folgenden finden Sie eine Zusammenfassung des Netzwerkprotokolls, das sich für jede Art der Kommunikation in maschinellen Steueranwendungen am besten eignet.

Befehls- oder nachrichtenbasierte Kommunikation

Die Nachrichtenkommunikation erfordert eine zuverlässige Übertragung und schnelle Übertragungsraten. In Tabelle 1.3 sind alle Optionen für die Nachrichtenkommunikation aufgeführt. Diese Anwendung wird am besten durch Netzwerk-Streams bedient. Sie sind zuverlässig, einfach zu bedienen und bieten schnelle Übertragungsraten. Wenn Sie jedoch eine 1:N- oder N:1-Systemkonfiguration benötigen oder Daten mit Anwendungen von Drittanbietern übertragen müssen, eignen sich TCP/UDP besser. Aus Gründen der Benutzerfreundlichkeit können auch mehrere Netzwerk-Streams verwendet werden, wenn hinter N eine kleine Zahl Geräte steckt. Webdienste können mit ähnlicher Leistung wie TCP mit Formelanalyse verwendet werden, sind aber auch einfacher zu bedienen.

Tabelle 1.3 Für die nachrichtenbasierte Kommunikation geeignete Netzwerkprotokolle

Prozessdatenkommunikation

Die Prozessdatenkommunikation interessiert sich nur für den neuesten Wert. Garantierte Zustellungs- und Übertragungsraten sind daher weniger wichtig. In Tabelle 1.4 sind alle Optionen für die Prozessdatenkommunikation aufgeführt. Umgebungsvariablen sind die empfohlene LabVIEW-Funktion für diese Anwendung. Sie sind einfach zu bedienen und ermöglichen zahlreiche Systemkonfigurationen. Sie verwalten auch automatisch die Netzwerkverbindung. Webdienste sollten verwendet werden, wenn die Daten von mehreren Standorten auf Computern ohne LabVIEW überwacht werden müssen. Ebenso sollte TCP/UDP verwendet werden, wenn die Daten von Anwendungen von Drittanbietern überwacht werden sollen.

Tabelle 1.4 Netzwerkprotokolle für die Prozessdatenkommunikation

Streaming/gepufferte Kommunikation

Die Streaming-Kommunikation erfordert hohe Übertragungsraten und eine zuverlässige Übertragung. In Tabelle 1.5 sind alle Optionen für die Streaming-/Pufferkommunikation aufgeführt. Für diese Anwendung werden Netzwerk-Streams empfohlen. TCP/UDP sollte für N:1- oder 1:N-Konfigurationen und für das Streaming von Daten an eine Anwendung von Drittanbietern verwendet werden.

Tabelle 1.5 Für die Streaming-/Pufferkommunikation geeignete Netzwerkprotokolle