Erschienen am: 06.10.2017, Ausgabe SPS-MAGAZIN 10 2017

Die industrielle Kommunikation der Zukunft - Teil 1/4

Babylon ist überall

Steht die industrielle Kommunikation vor einer babylonischen Sprachverwirrung? Der Eindruck könnte entstehen, wenn man die zahlreichen Feldbustechnologien und Protokolle betrachtet, die derzeit weltweit auch im Zusammenhang mit Industrie 4.0 diskutiert werden. Doch wohin geht die Reise der Ethernet-Kommunikation? Ist die künftig echtzeitfähige, aber noch sehr junge Technologie von OPC UA mit Publish/Subscriber-Protokoll und TSN schon die finale Lösung?


Bild: Wikimedia Commons, gemeinfrei

Laut der biblischen Überlieferung geht die babylonische Sprachverwirrung auf das Vorhaben eines Turmbaus in einem Land namens Schinar zurück. Dort will ein Volk in der Stadt Babylon einen Turm mit einer Spitze bis zum Himmel bauen. Der Herr stieg herab, betrachtete den Turm und erkannte, dass den Menschen nach der Fertigstellung nichts mehr unerreichbar sein würde - egal, was sie sich auch vornehmen. Um zu vermeiden, dass das Volk dadurch übermütig werden könnte und vor nichts zurückschreckt, was ihm in den Sinn kommt, rief er eine Sprachverwirrung hervor. Diese führte zu unüberwindbaren Verständigungsschwierigkeiten der am Bau Beteiligten und damit zur Aufgabe des Projektes. Zudem wurden alle am Bau Beteiligten über die ganze Erde verstreut. Die Analogie ist nicht beliebig belastbar, aber die Parallele zum heutigen Stand der sprachlichen Einheit in der Ethernet-Kommunikation ist frappierend. Die beteiligten Unternehmen, die verschiedenen Standardisierungs- und Feldbusorganisationen sind über den Globus verteilt und fokussieren sich aus verschiedenen Gründen auf verschiedene Ethernet-Sprachen als industrielle Kommunikationsprotokolle. Egal, wie die vielen humanen Sprachen dieser Welt entstanden sind - wir Menschen haben dennoch gelernt, uns zu verständigen. Und in der industriellen Kommunikation zeichnet sich ganz schwach schon die eine oder andere Konsolidierung ab.

Relevante Eigenschaften für technische Sprachen

Die industrielle Automatisierungstechnik stellt an Kommunikationsprotokolle zunächst eine Reihe von wirtschaftlichen Anforderungen. Unter die Total Cost of Ownership fallen neben möglichen Lizenzgebühren die Entwicklungs-, Test- und Hardwarekosten. Das entscheidende Unterscheidungsmerkmal findet man aber vornehmlich in den technischen Eigenschaften der Protokolle. So gibt es heute sehr einfache Protokolle nur mit Lese- und Schreibfunktionen, aber auch Protokolle mit zahlreichen Zusatzfunktionen wie Registrieren bestimmter Nachrichtentypen, Informationskonzentration in Brokern oder mit Versionstoleranz. Je nach Applikation und persönlichen Präferenzen spielen zudem weitere Eigenschaften eine wichtige Rolle bei der Auswahl eines Protokolls.

Frage/Antwort - Request/Response

Die übersichtlichste und einfachste Form der Kommunikation ist: einer fragt und ein anderer antwortet. In der industriellen Kommunikation sind dabei die Rollen klar verteilt: der Master (Steuerung) stellt eine Frage und der Slave (Feldgerät) beantwortet sie. Diese Form der Kommunikationstechnik ist gerade auf Geräteseite besonders einfach zu implementieren. Da der Kommandointerpreter eines Servers nur auf hereinkommende Nachrichten vom Slave - also dem Feldgerät - wartet und sie als Antwort, Fehlernachricht oder Ignorierung sofort vollständig bearbeitet, können Implementierungen solcher Protokolle mitunter in weniger als 100 Zeilen Code realisiert werden. Ferner erfreut sich das Paradigma an Beliebtheit aus einem fundamentalen Vorteil aus vergangenen halbduplex Zeiten: Die Regelung der Leitungsbelegung ist auf einfache Weise durch das Protokoll gelöst: Es redet außer dem Master - dem Client - nur, wer gefragt wurde. Mancher Ethernet-Feldbus nutzt diese Eigenschaft zur Erreichung einer Echtzeitfähigkeit. Doch dazu darf kein fremder Teilnehmer im Netz sichtbar werden.

Long-Polling

Das Kommunikationsparadigma Request/Response ist beliebt und einfach. Möchte man auf einem Server (Slave) aber ein relativ seltenes Ereignis sehr zeitnah - also mit nur kurzer Latenz - erfahren, so muss man die Information hochfrequent abfragen. Wenn es das Protokoll zulässt, kann man die Implementierung auf der Server-Seite dahingehend optimieren, dass seltener gefragt werden muss und dennoch sehr zeitnah geantwortet wird: der Slave wartet mit der Antwort eine 'sehr lange' Zeit bis das gewünschte Ereignis eintritt und antwortet dann. Berühmt wurde die Technologie im Web, wo man sich meist dem Client/Server-Prinzip unterwirft - Stichwort HTTP Long-Polling.

Publish / Subscribe

Betrachten wir die Kommunikation zwischen Teilnehmern nicht abstrakt als Austauschen von Nachrichten, sondern konkreter als auszutauschende Datenwerte wie Variablen, Parameter oder Topics, so lassen sich bequemere Mechanismen zur Synchronisation definieren. Ein solcher Datenwert kann ein sich stetig ändernder Messwert oder ein Stellwert sein. Das Kommunikationsparadigma Publish/Subscribe basiert auf einem solchen Datenmodell. Dabei wird ein eigener Datenpunkt veröffentlicht (publish). Das Netzwerk ist damit in der Lage zu suchen, welche Datenpunkte existieren. Der Netzwerkteilnehmer, welcher Datenwerte veröffentlicht, wird Publisher (Talker) genannt. Ein Subscriber (Listener) kann nun einzelne Datenwerte aus dem Netzwerk für sich registrieren. Dieser Vorgang geschieht meist durch ein einmaliges Anmelden gemäß dem Frage-Antwort-Prinzip. Spätestens ab diesem Zeitpunkt sendet der Publisher seinen Datenpunkt gemäß Bedarf, beispielsweise bei einer Änderung, an den Subscriber.

Serie Industrielle Kommunikation

Teil 1: Eigenschaften technischer Sprachen (SPS-MAGAZIN 10/2017)

Teil 2: Performanz & Echtzeitfähigkeit (SPS-MAGAZIN 11/2017)

Teil 3: Neue Protokolle für Paradigmenwechsel

(Messe-Special SPS IPC Drives 2017)

Teil 4: Ersetzt OPC UA die Feldbusse? (SPS-MAGAZIN 12/2017)