So funktioniert OPC/UA over TSN

Echtzeit-Ethernet mit Time-Sensitive Networking

| Autor / Redakteur: Dr. Carsten Emde [Red.:Sebastian Gerstl / Andreas Donner

Elemente des Standards IEEE 802.1: OPC/UA over TSN verspricht, der neue Kommunikationsstandard in der Automatisierung zu werden. Aber wie genau geht TSN?
Elemente des Standards IEEE 802.1: OPC/UA over TSN verspricht, der neue Kommunikationsstandard in der Automatisierung zu werden. Aber wie genau geht TSN? (Bild: Bosch Rexroth)

Ob sie nun Profibus, Profinet oder EtherCat heißen: Wen es um vernetzte Echtzeit-Lösungen geht, stehen in der Industrie zahlreiche unterschiedliche Standards in Konkurrenz. OPC/UA over TSN könnte nun erstmals eine einheitliche Lösung bieten. Was steckt dahinter?

Im Vergleich zum weltweit enormen Erfolg von Standard-Ethernet und dessen allgegenwärtiger Verbreitung und Verfügbarkeit sieht es bei Echtzeit-Ethernet völlig anders aus: Hier haben sich in erster Linie proprietäre und untereinander nicht kompatible Verfahren durchgesetzt. Mit der Standardisierung von TSN, der benötigten ebenfalls standardisierten Erweiterung des schon lange vorhandenen Protokolls OPC UA und dessen Verfügbarkeit unter einer Open Source-Lizenz könnte sich dies nun ändern.

Dieser Beitrag erläutert die technische Basis von TSN und OPC UA mit Publish- und Subscribe-Erweiterungen und zeigt einen Weg auf, wie ein alter Traum Wahrheit werden könnte: Uneingeschränktes Echtzeit-Ethernet für jedermann.

Was ist Echtzeit, wie sollten derartige Systeme bezeichnet werden?

Der Begriff „Echtzeit“ wurde vor langer Zeit eingeführt, obwohl der Wortsinn dieses Begriffs eigentlich nicht korrekt dessen übliche Verwendung beschreibt. Denn basierend auf dem Wortsinn müsste „Echtzeit“ die „richtige Uhrzeit“ bedeuten, also die zu einem bestimmten Zeitpunkt an einem bestimmten Ort gültige Zeit. Diese „richtige Uhrzeit“ hat den Nachteil, dass sie nicht notwendigerweise monoton ansteigt, sondern mitunter automatisch oder manuell nachgeführt werden muss. Eine solche Notwendigkeit zur Nachführung entsteht z.B. durch Einfügung von Korrektursekunden wegen mechanischer Unregelmäßigkeiten von Himmelskörpern, durch willkürliche Zeitsprünge wie bei Umschaltung von Normalzeit auf Sommerzeit oder durch Verbringung von mobilen Systemen in eine andere Zeitzone.

Aber der etablierte Begriff „Echtzeit“ bedeutet dies gerade nicht, sondern bezeichnet Systeme, die in der Lage sind, in einem typischen maximalen Zeitraum auf nicht vorhersagbare externe Ereignisse zu reagieren und daher eine Uhr benötigen, die ohne Zeitsprünge kontinuierlich weiterläuft. Solche Systeme sollten besser als „deterministische Systeme“ bezeichnet werden; darüber hinaus ist es wünschenswert, dass zusätzlich noch angegeben wird, wie lange es maximal dauern kann, bis ein System reagiert.

In Anlehnung an die Klassifizierung von feuerfesten Türen, die nach DIN 4102-5 mit dem Buchstaben „T“ und einer Zahl bezeichnet werden, wobei die Zahl die Dauer in Minuten angibt, wie lange die Tür das Feuer abhalten und sich noch öffnen lassen muss (z.B. T30-, T60-, T90-Tür), könnte man Systeme, die üblicher-, aber fälschlicherweise Echtzeit-Systeme genannt werden, mit dem Buchstaben „D“ gefolgt von einer Zahl bezeichnen. Die Zahl würde dann die maximale Reaktionszeit in Mikrosekunden angeben. So weist ein üblicher in industriellen Steuerungen eingesetzter 1-GHz-Prozessor typischerweise eine maximale Reaktionszeit von 100 μs auf und könnte dementsprechend als D100-System bezeichnet werden. Aber auch Anforderungen könnten entsprechend klassifiziert werden: Wird z.B. eine industrielle Steuerung benötigt, die nach spätestens 500 μs reagieren muss, würde es sich um eine „D500-Anforderung“ handeln.

Übrigens hat die genannte Unschärfe des Begriffs „Echtzeit“ bzw. „Realtime“ speziell im Zusammenhang mit Linux-Echtzeitprogrammierung bereits zu erheblicher Verwirrung geführt. Denn die Präprozessor-Definitionen für die verschiedenen Uhren des Linuxkernels verwenden den Begriff „Realtime“ im Wortsinn und bezeichnen die Uhr, welche die aktuelle Uhrzeit wiedergibt, aber durchaus Sprünge aufweisen kann, als CLOCK_REALTIME und die monoton stetig fortschreitende Uhr, die in Echtzeitanwendungen zwingend verwendet werden muss, als CLOCK_MONOTONIC. Da es aber bisher übliche und unveränderte Praxis ist, die Anforderung an Determinismus als „Echtzeit“-Anforderung zu bezeichnen, wird dies auch in diesem Beitrag weiterhin so gehandhabt.

Was ist Echtzeit-Ethernet?

In der gleichen Weise wie von einem Echtzeit-System deterministisches Antwortverhalten erwartet wird, muss Echtzeit-Ethernet ein deterministisches Transportverhalten aufweisen. Dies bedeutet, dass beim Absenden eines Netzwerkpakets dieses so konfiguriert werden kann, dass es zu einem bestimmten Zeitpunkt zuverlässig auf dem Zielrechner ankommt. Und zwangsläufig bedeutet dies dann auch, dass das Netzwerkpaket zu einem vorhersagbaren Zeitpunkt von einem Anwenderprogramm empfangen und bearbeitet wird. Insofern ist es aus praktischen Gründen unabdingbare Voraussetzung für Echtzeit-Ethernet, dass auch das jeweilige Betriebssystem von Sender und Empfänger echtzeitfähig ist. Man könnte zwar theoretisch eine echtzeitfähige Transportschicht auf einem nicht-echtzeitfähigen Computer installieren, aber dies hätte wohl kaum jemals praktischen Nutzen.

Zwei verschiedene Ansätze, um Echtzeit-Ethernet zu realisieren

1. Exklusive Verbindung zweier Rechner mit UDP
Um Echtzeit-Ethernet zu realisieren, kann man die gesamte Strecke vom 1. Versenden eines Pakets durch ein Anwenderprogramm, 2. Versenden dieses Pakets durch den Netzwerkadapter des Senders über 3. die physikalische Verbindung zum Netzwerkadapter des Empfängers und 4. bis zur Programmfortsetzung eines auf eine Netzwerknachricht wartenden Anwenderprogramms so gestalten, dass diese Sequenz vorrangig abläuft. Wenn auf Sender- und Empfängerrechner jeweils ein echtzeitfähiges Betriebssystem installiert ist, die beiden Rechner exklusiv und bidirektional miteinander verbunden sind, zunächst kein anderer Netzwerkverkehr gleichzeitig über diese Netzwerkverbindung gesandt wird und das besonders anspruchslose Protokoll UDP verwendet wird, dann lässt sich damit im Prinzip eine Echtzeit-Ethernet-Verbindung realisieren. Das Ergebnis einer Messung der kombinierten Sende- und Empfangsdauer einer Netzwerkverbindung mit diesen Bedingungen ist in Bild 1 gezeigt.

Zweimal am Tag wurde für jeweils knapp drei Stunden eine Messung durchgeführt, wobei Netzwerkpakete mit einem Zyklusintervall von 500 μs versandt, vom Empfänger unmittelbar an den Sender zurückgesandt und deren Zeiten registriert wurden. Die in Bild 1 über die Zeit aufgetragenen Werte repräsentieren jeweils die maximale Dauer eines kompletten Sende- und Empfangsvorgangs während aufeinanderfolgender 5-Minuten-Intervalle. Es ist erkennbar, dass die Dauer zu keinem Zeitpunkt 343 μs überschreitet und sich damit dieses Verfahren vermutlich für eine echtzeitfähige Ethernet-Verbindung eignet.

Das beschriebene Verfahren lässt sich dahingehend optimieren, dass auch anderer nicht-echtzeitfähiger Netzwerkverkehr zugelassen werden kann. Dies erfolgt durch Aufspaltung des physikalischen Netzwerks in logische Teilnetze mit Hilfe von Virtual Local Area Network (VLAN) und Zuordnung von Bearbeitungsprioritäten. Im vorliegenden

Fall wurden die echtzeitpflichtigen UDP-Netzwerkpakete über das hochpriorisierte VLAN eth1.2 versandt (Bild 2), während gleichzeitig anderer Netzwerkverkehr zwar mit hoher Bandbreitennutzung bis 20 Mb/s, aber niedriger VLAN-Priorität über eth1.3 versandt wurde (Bild 3).

Da Netzwerk-Switches erhältlich sind, die über VLAN verfügen, kann das beschriebene Verfahren, das sich ausschließlich mit Open Source-lizenzierter Software realisieren lässt, durchaus auch in einer entsprechend erweiterten Topologie eingesetzt werden, was beim Messaufbau für die Gewinnung der Daten in den Bilden 1 bis 3 der Fall war. Aber die Hinzunahme weiterer Rechner ist nicht möglich, und als darüber hinaus relevanter Nachteil des Verfahrens muss angemerkt werden, dass sich alle Zeitangaben dieser Echtzeit-Netzwerkverbindung immer auf die Uhrzeit des Senders beziehen. Insofern kann der Empfänger Antwortpakete oder auch eigenständige neue Pakete immer nur relativ zur Uhrzeit des Senders versenden. Da es aber in vielen Fällen durchaus wünschenswert ist, dass alle beteiligten Rechner relativ zur gleichen Uhrzeit Netzwerkpakete senden und empfangen können und aktuelle Anforderungen wie zum Beispiel für das Internet der Dinge von einer großen Anzahl angeschlossener Rechner ausgehen, ist dieses Verfahren zur Realisierung von universell verwendbarem Echtzeit-Ethernet nicht zukunftsfähig.

2. Time-Sensitive Network (TSN)
Ein zweiter grundsätzlich unterschiedlicher Ansatz für Echtzeit-Ethernet geht davon aus, dass alle im Netzwerk zusammengeschalteten Rechner hochgenau zeitlich synchronisiert sind. Die dabei geforderte Gangabweichung liegt um Dimensionen niedriger als üblicherweise im Internet mit dem Network Time Protocol (NTP) erreichbar ist. Während sich mit dem NTP-Verfahren maximale Abweichungen im Millisekundenbereich erreichen lassen (Bild 4), wird für ein universell verwendbares Echtzeit-Ethernet eine Rechnersynchronisation im Submikrosekundenbereich gefordert. Wenn Rechner mit einer derartig hohen Präzision mit definierter maximaler Gangabweichung synchronisiert werden und ein Sendeverfahren bereitgestellt wird, das es erlaubt, Netzwerkpakete zu einem bestimmten Zeitpunkt und mit bekannter Übertragungsgeschwindigkeit absenden zu lassen, dann kann man den spätestmöglichen Empfangszeitpunkt eines Netzwerkpakets präzise vorhersagen und auf diese Weise Echtzeit-Ethernet realisieren.

Genau dies – und noch vieles mehr – verbirgt sich hinter den verschiedenen Methoden, die unter dem gemeinsamen Begriff Time-Sensitive Network (TSN) zusammengefasst werden. Diese Methoden sind mit einer Ausnahme in der Gruppe IEEE 802.1Qxx standardisiert. Bei der Ausnahme handelt es sich um das Verfahren zur hochgenauen Rechnersynchronisation, das ein spezielles Profil des bereits vor längerer Zeit als IEEE 1588 standardisierten Precision Time Protocol (PTP) verwendet und voraussichtlich in naher Zukunft unter dem Standard IEEE 802.1AS-rev veröffentlicht werden wird. Insgesamt werden wohl mehr als zehn unterschiedliche Standards die verschiedenen Komponenten von TSN beschreiben; allerdings sind erst ein kleiner Teil davon verabschiedet, und aktuell stehen unter Linux bzw. bei unter Linux lauffähiger Netzwerk-Hardware zunächst die ersten drei in Tabelle 1 genannten Verfahren zur Verfügung.

Während alle genannten in IEEE 802.1Q zusammengefassten Standards und selbstverständlich auch VLAN ausschließlich die Link-Layer-Schicht (Schicht 2) der im Open Systems Interconnection (OSI) Referenz-Modell definierten Schichten betrifft, sind für die komplette Realisierung von Echtzeit-Ethernet mit Hilfe von TSN zusätzliche Komponenten in fast allen Schichten erforderlich (Tabelle 2).

Dies bedeutet, dass Spezialisten aus verschiedenen Bereichen zusammenarbeiten müssen, um die erfolgreiche Einführung von auf TSN basierendem Echtzeit-Ethernet zu ermöglichen. Benötigt werden

  • Netzwerk-Hardware mit TSN-Unterstützung: Netzwerkadapter, Switche, Router
  • Linuxtreiber für die Netzwerkadapter
  • Bibliotheken für Anwenderprogramme
  • Anwenderprogramme zum Konfigurieren von TSN-Komponenten

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.

Dr. Carsten Emde.
Dr. Carsten Emde. (Bild: OSADL)

Über den Autor

Dr. Carsten Emde ist Geschäftsführer der Open Source Automation Development Lab eG und 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.

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

Dieser Beitrag stammt von unserem Schwesterportal Embedded Software Engineering.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

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