Ein Angebot von

Time-Sensitive Networking (TSN): Was ist das und wie geht das?

| Autor / Redakteur: Dr. Carsten Emde* / Sebastian Gerstl

Die Hauptbausteine von Time-Sensitive Network (TSN)

1. VLAN
Ähnlich wie beim oben beschriebenen UDP-Verfahren, bei dem zwei Rechner exklusiv in Echtzeit miteinander kommunizieren können, verwendet TSN zur Aufspaltung des physikalischen Netzwerks in logische unterschiedlich priorisierte Teilnetze virtuelles Netzwerk VLAN, das als IEEE 802.1Q im Frameformat nach IEEE 802.3 standardisiert ist. Bei Verwendung des Linuxkernels wird üblicherweise die Punktnotation verwendet, bei welcher der Interface-Name von einem Punkt und dann der jeweiligen VLAN-Nummer gefolgt wird. Betrachten wir folgendes Shell-Skript:

mkvlan.sh
for i in `seq 1 8`
do
    vconfig add $1 $i
    ifconfig $1.$i 192.168.$i.$2 up
    p=`expr $i - 1`
    for j in `seq 0 7`
    do
       vconfig set_egress_map $1.$i $j $p
    done
done

ifconfig $1 192.168.10.$2 up

Das Shell-Skript mkvlan.sh richtet acht VLAN-Interfaces mit den Adressen 192.168.1.x bis 192.168.8.x ein und vergibt die entsprechende Priorität, wobei das erste Argument den Namen des Netzwerk-Device und das zweite Argument die Rechner-Komponente der IP-Adresse angibt, z.B. Ausführung auf Rechner Nr. 1

mkvlan.sh enp1s0 1


und Ausführung auf Rechner Nr. 2

mkvlan.sh enp1s0 2

Wenn die Devices enp1s0 der beiden Rechner miteinander verbunden sind, können diese über die VLAN-Netzwerke 192.168.1.x bis 192.168.8.x sowie über das Standard-Netzwerk 192.168.10.x kommunizieren, wobei x bei Rechner Nr. 1 für 1 und bei Rechner Nr. 2 für 2 steht. Durch die logische Partitionierung der physikalischen Netzwerkverbindung und die Zuordnung unterschiedlicher VLAN-Prioritäten zu den jeweiligen Netzwerken kann der Anwender durch die Wahl eines bestimmten Netzwerks die Priorität der Paketverarbeitung festlegen.

2. Hochgenaue Zeit-Synchronisation der beteiligten Systeme
Für die hochgenaue Zeitsynchronisation nach IEEE 1588 bzw. IEEE 802.1QAS-rev wird ein Netzwerkadapter benötigt, der dieses Verfahren unterstützt. Für Rechner mit Standard Intel-PC-Architektur und PCI-Expressbus steht der Intel-Netzwerkkontroller I210 zur Verfügung, der für alle folgenden Beispiele und Messungen eingesetzt wurde. Dieser wird seit einiger Zeit vom Linuxkernel unterstützt, und die meisten Linuxdistributionen enthalten Anwenderprogramme zur Konfiguration und Diagnostik wie z.B. das Debian-Paket linuxptp. Grundsätzlich unterscheidet man bei der Konfiguration einerseits zwischen dem – in der Regel nur einmal im System vorhandenen – PTP-Server, der sogenannten „Grandmaster Clock“, und andererseits den PTP-Clients.

Unter Linux wird mit dem Programm ptp4l die Netzwerkkarte entweder als Grandmaster oder als Client konfiguriert. Darüber hinaus kann das Programm ptp4l die Qualität der Zeitsynchronisation überwachen und regelmäßig z.B. die Zeitabweichung ausgeben. Eine typische Aufzeichnung dieser Ausgabe der minimalen, maximalen und mittleren Zeitabweichung ist in Bild 5 wiedergegeben; die Dauer der Aufzeichnung beträgt eine Woche.

Man erkennt in Bild 5 die über einen relativ langen Zeitraum gehende fast perfekte Synchronisation mit einem maximalen Jitter von unter 20 ns. Allerdings kommt es zweimal zu erheblichen Ausreißern von 65 und sogar 374 ns. Die Ursache dieser Ausreißer ist nicht bekannt und wird noch untersucht. Zum jetzigen Zeitpunkt hat aber selbst der relativ hohe Jitter, der bei den beiden Ausreißern gemessen wurde, keinerlei Bedeutung, da selbst diese Werte immer noch im Submikrosekundenbereich und damit weit unter den Anforderungen an heute übliche Echtzeitsysteme liegen.

Die alleinige Synchronisation der Rechner untereinander genügt aber noch nicht; denn es muss auch noch die Uhrzeit des Systems und damit die von Anwenderprogrammen verwendbare Uhrzeit mit der Netzwerkuhrzeit synchronisiert werden. Dafür dient das Programm phc2sys, das ebenfalls in den PTP-Paketen der üblichen Linuxdistributionen enthalten ist. Normalerweise werden sowohl PTP-Server als auch die PTP-Clients so konfiguriert, dass sie die Uhrzeit von der Netzwerkkarte beziehen.

Auch das Programm phc2sys kann die Qualität der Synchronisation überwachen und regelmäßig die Zeitabweichung ausgeben. Eine typische Aufzeichnung dieser Ausgabe der minimalen, maximalen und mittleren Zeitabweichung ist in Bild 6 wiedergegeben; die Dauer der Aufzeichnung beträgt wie in Bild 5 eine Woche. Die mittlere Gangabweichung liegt bei etwa 200 ns, während der maximale Ausschlag nach oben und unten etwa 650 ns beträgt und damit ebenfalls – wie die PTPSynchronisation – im Submikrosekundenbereich liegt.

3. Zeitstempelgenaue Versendung von Netzwerkpaketen
Um die hochgenaue Synchronisation der Rechner für Echtzeit-Ethernet praktisch ausnutzen zu können, muss ein Mechanismus bereitgestellt werden, der es erlaubt, einem Netzwerkpaket einen Zeitstempel mitzugeben, der festlegt, zu welchem Zeitpunkt das Paket versandt werden soll. Um diesen Mechanismus einzuschalten, wurde die Socket-Option SO_TXTIME vereinbart sowie eine Struktur definiert, in welcher der Netzwerkkarte der Betriebsmode dieser Option mitgeteilt wird. Der jeweilige aktuelle Zeitstempel wird im CMSG-Bereich eines jeden Netzwerkpakets abgelegt und das SCM_TXTIME-Feld entsprechend gesetzt.

4. Bandbreitenreservation
Die Organisation und Vergabe von Bandbreiten für das Versenden und Empfangen von Netzwerkpaketen geschieht mit dem sogenannten Polycing und Shaping, wobei verschiedene Klassen von Netzwerkdiensten (Quality of Service = QoS) differenziert werden. Realisiert wird dies z.B. im Linuxkernel mit Queue-Disciplines, die mit dem Traffic-Control-Programm tc konfiguriert werden. Es genügt nämlich nicht, dass dem Netzwerkadapter mit dem oben genannten Verfahren ein Paket mit einem Zeitstempel geschickt wird, sondern zum geplanten Zeitpunkt muss eine genügende Sendebandbreite zur Verfügung stehen, damit das Paket unmittelbar nach Erreichen der programmierten Sendezeit auch tatsächlich versandt werden kann.

Die für Echtzeit-Ethernet mit TSN neu geschaffene relevante Queue-Discipline heißt Earliest TxTime First (ETF). Diese sorgt dafür, dass Pakete, welche über die SO_TXTIME Socket-Option und die entsprechende SCM_TXTIME-Einstellung in den jeweiligen Paketfeldern verfügen, zum entsprechenden Zeitpunkt in den Netzwerkadapter ausgekoppelt werden.

Gegenüber dem früheren TBS-Verfahren (Time Based Scheduler) bietet ETF die zusätzliche Möglichkeit, eine Zeitdifferenz anzugeben, damit die Pakete früher als nötig gesendet werden können. Dies betrifft zum Beispiel Audio- und Video-Frames, die selbst eigene Timing-Information beinhalten, so dass deren Verwendung zum korrekten Zeitpunkt erfolgen kann, obwohl die Pakete früher als nötig eintreffen. Dies ermöglicht eine bessere Bandbreitenausnutzung.

OPC UA PubSub: Beispiel einer Realisierung von Echtzeit-Ethernet mit Hilfe von TSN

Die ursprünglich „OLE for Process Control“ genannte Software-Schnitttstelle war geschaffen worden, um Daten unterschiedlicher Hersteller speziell in der Automatisierungsbranche austauschen zu können, ohne vorher spezielle Protokollregelungen vornehmen zu müssen. Im Laufe der Weiterentwicklung der Schnittstelle nahm die Bedeutung des von Microsoft entwickelten Systems mit dem Namen „Object Linking and Embedding“ (OLE) ab, so dass im Jahre 2011 das Akronym OPC mit der neuen Bedeutung „Open Platform Communications“ belegt wurde. Außerdem wurde mit der zusätzlichen Bezeichnung UA (Unified Architecture) darauf abgehoben, dass es sich um ein universell verwendbares Protokoll handelt, das nicht an Produkte eines bestimmten Herstellers oder an ein bestimmtes Betriebssystem gebunden ist.

Zunächst war OPC UA ausschließlich an Kommunikationsverfahren gebunden, die auf einer dedizierten Verbindung zwischen zwei Netzwerkpartnern beruhen. Im Hinblick auf zukünftige Anforderungen durch das Internet der Dinge, bei denen viele tausend Geräte mit geringen Ressourcen an CPU-Leistung und Speicher miteinander kommunizieren sollen, wird aber anstelle der genannten paarweisen Kommunikation eine Mehrpunktkommunikation benötigt. Diese sollte idealerweise ohne den Ressourcenbedarf üblicher statischer Netzwerkverbindungen auskommen. Das Ergebnis war die Entwicklung der sogenannten Publish/Subscribe-Erweiterungen (PubSub).

Es wird zur Zeit davon ausgegangen, dass OPC UA PubSub der zukünftige universelle Standard für die Echtzeitkommunikation im Internet der Dinge sein wird. Und es besteht die Hoffnung, dass TSN dann auch die vielen proprietären und untereinander nicht kompatiblen Verfahren für Echtzeit-Ethernet ablöst. Um zu testen, inwieweit sich bereits heute mit aktuell erhältlicher Hardware und Software, eine echtzeitfähige Kommunikation mit OPC UA PubSub über TSN realisieren lässt und welche Kennwerte dabei erreicht werden können, wurden die folgenden Tests durchgeführt.

  • Hardware: Intel i5-Prozessor, I210-Netzwerkkarte
  • Betriebssystem: Linux 4.18.7-rt5, Realtime- und ETF-Patch
  • Software: OPC UA mit PubSub von open62541.org
  • TSN-Konfiguration: Mit VLAN, ptp4l, phc2sys und ETF wie beschrieben
  • Messungen: Maximale Roundtripdauer von OPC UA Paketen, die über einen Loopback-Server an den Sender zurückgesandt werden.
  • Messbedingungen: Parallele konkurrierende Netzwerklast, künstliche Systemlast

Bild 7 zeigt die Verteilung des Messwerte bei fehlender Echtzeit-Konfiguration: Maximale Roundtripdauer hier 362 ms. Die gleichen Daten und die gleichen Messbedingungen, allerdings bei optimaler Echtzeit-Konfiguration, sind in Bild 8 wiedergegeben: Hier ergibt sich eine maximale Roundtripdauer von 1,28 ms.

Fazit

Bereits die aktuell erhältlichen Hardware- und Software-Komponenten für OPC UA PubSub über TSN erlauben es, ein funktionsfähiges Netzwerk mit Echtzeit-Ethernet aufzubauen und ein für viele Anwendungsfälle ausreichendes Echtzeitverhalten zu erreichen. Dabei kommen ausschließlich Softwarekomponenten zum Einsatz, die unter einer Open Source-Lizenz weitergegeben werden können. Bis dieses Verfahren allerdings allgemein anwendbar sein und sich nennenswerte Marktanteile verschaffen wird, dürften allerdings noch mindestens ein bis zwei Jahre vergehen. Voraussetzungen sind:

  • Deutlich weiter fortgeschrittener Standardisierungsprozess
  • Mehr on-chip Netzwerkkontroller mit TSN
  • Sicherungsschicht in OPC UA
  • Weitgehend automatische Konfiguration
  • Besseres Echtzeitverhalten

Wenn dies der Fall ist, stehen die Chancen gut, dass TSN und OPC UA PubSub in nicht zu ferner Zukunft der Normalfall für Echtzeit-Ethernet werden.

Der Autor

Dr. Carsten Emde, Geschäftsführer der Open Source Automation Development Lab eG
Dr. Carsten Emde, Geschäftsführer der Open Source Automation Development Lab eG (Bild: OSADL)

* Dr. Carsten Emde blickt auf eine mehr als 25-jährige Tätigkeit als Software-Entwickler, System-Integrator und Trainer zurück. Seine Spezialgebiete sind graphische Bedienoberflächen, maschinelle Bilderkennung und Echtzeit-Betriebssysteme. Seit der Gründung der Open Source Automation Development Lab (OSADL) eG im Jahre 2005 ist er deren Geschäftsführer.

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

So gelingt der Einstieg mit OPC UA

So gelingt der Einstieg mit OPC UA

13.08.18 - Eine herstellerunabhängige Vernetzung von Geräten und Anlagen ist mit dem Kommunikationsprotokoll OPC UA möglich – doch der Einstieg ist nicht immer einfach. Auf was Anweder achten müssen. lesen

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben
CLOCK_MONOTONIC ? Ha-ha. Ich stelle mir gerade das Gegenteil vor, also rückwärtslaufend-getaktete...  lesen
posted am 20.03.2019 um 17:41 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45747486 / Echtzeit)