Startseite > Messen + Testen > Testsysteme > An der Applikationskante

Systemdesign / Praxistest TSN

An der Applikationskante

12. April 2019, 10:26 Uhr | Dr. Constantin Tomaras, Ressortredakteur für Systemdesign, DESIGN&ELEKTRONIK

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Werkzeuge zur Implementierung

Die Motivation für ein TSN-TestBed ist im allgemeinen nicht die funktionale Validierung der Hardware: tatsächlich ist die Frage, ob eine Anwendung über der jeweiligen TSN-Hardware implementiert werden kann, unabhängig von ihrer Spezifikationskonformität. Ein einfaches Beispiel stellen - durch in der Planung unberücksichtigte Überhangdaten - zu hohe deterministische Datenraten, die der priorisierte Puffer nicht mehr handeln kann. Fortgeschrittene Härtefälle sind spezifische Netzwerktopologien, die eine gesonderte applikationsabhängige Konfiguration benötigen.

Jobangebote+ passend zum Thema

Ingenieur/Elektroingenieur/Elektrotechniker als Field Application Engineer

GEYER Electronic GmbH, Planegg

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Darüber hinaus ist zu betrachten, wie eine bestimmte physikalische Schicht (phy) auf Störungen aus der Umgebung reagiert: an der geöffneten und damit ungeschirmten Leitung bewirkt beispielsweise die Verbindung der KBox mit dem AES-USB-Dongle, einen sporadischen Verbindungsabbruch der nach wenigen Sekunden kompensiert wird (Bild 2).

Uhrenvergleich

Das Aufsynchronisieren der Netzwerkteilnehmer erfolgt bereits vollautomatisch. Das linuxptp-Paket beinhaltet dazu die ptp4l- und phc2sys-Programme, für eine Zeitstempelung von phy-zu-Master auf Hardware-Basis und System-zu-Master auf Softwarebasis.

Verkehrsplanung

Auf Terminalebene werden die Zyklen und Schaltzustände jeder Schnittstelle eines Netzwerkschalters in drei Schritten vom Anwender konfiguriert [4]: der Definition des Kommunikationsschemas, die Tourenplanung der deterministischen Anteile, und das Schreiben der Konfiguration auf den jeweiligen Port.

In der behaupteten Konvergenz von OT und IT muss ein Schalter simultan unterschiedlich kritische Datenanteile handeln. Die Dringlichkeitsstufe wird vom Anwender mit dem VLAN-Code eines Telegramms parametriert. Das Starterkit-Handbuch [4] referenziert hier eine Tabelle des IIC, mit der die Verkehrsklasse nach Parametern des Datenstroms bewertet werden kann. Diese sind die Übertragungsfrequenz, Länge, Synchronisierung, Datenvolumen, Empfangssicherheit, Robustheit gegen Störer, Robustheit gegen Datenverlust und die Verlässlichkeit. Die Konfiguration des Schalters erfolgt auf der gegenwärtigen Entwicklungsstufe des Starterkits noch händisch. Den aktiven Entwicklungsschritt stellt die automatisierte, protokollbasierte Konfiguration nach IEEE802.1Qcc: hier wird von einer zentralen Konfiguration auf Anwendungsebene (CUC), automatisiert das gesamte Netzwerk (CNC) konfiguriert. Aber auch an dieser Stelle ist die Frage zulässig, ob das bei allgemeiner Netzwerktopologie immer gelingen kann, oder ob sehr spezielle Topologien noch händisch nachjustiert werden müssen.

Die Konfiguration eines TSN-Schalters wird dabei vom Anwender in einer Liste mit den Zeilen

sgs <intervall> <gsv>

hinterlegt. Die Ziffer <gsv> gibt dabei an, welche Prioritäten der Schalter gerade weiterleitet, die Dezimalzahl <intervall> misst das Zeitintervall für diesen Schaltzustand in Nanosekunden. Mit dem <gsv> gibt der Anwender die aktiven Verkehrsklassen [0,...,7] als 8-Bit-Information an: zulässig ist die Darstellung als hex-, Oktal- oder Binärformat. Der Schalter arbeitet allerdings nur mit vier Schlangen, durch die Paarbildung 0/1 → 0, 2/3→1, 4/5→2, 6/7→3. Schlange 3 handelt dabei den kritischen Verkehr. Die Konfiguration wird dann mit

tsntool st wrcl <config_filename> <interface>

auf die Admin-Liste der jeweiligen TSN-fähigen Schnittstelle geschrieben.

Das Kommando

tsntool st configure <basetime> <cycletime> <cycletime-extension>
<interface>

führt die Konfiguration zur oben genannten Systemzeit mit dem parametrierten Zyklus aus.

Erzeugung von Netzwerkverkehr

Layer-2-Daten werden im Starter-Kit mit Ostinatos drone erzeugt. Die Softwareschnittstelle zum laufenden '>drone &' ist das Python2.7-Skript gen-traffic. Damit werden 1230 bytes lange Frames mit den Nutzdaten 0x00 verschickt, der Parameter -b variiert dabei die Bandbreite der Übertragung.

Benchmark

Die effektive Latenz und Bandbreite der Übertragung kann mit zwei weiteren Softwarewerkzeugen bestimmt werden.

Das netlatency-rx/tx-Werkzeug evaluiert Latenz und Jitter der Übertragung, sofern der Controller Hardware-Zeitstempel zulässt. Das netreceive-Werkzeug, kann die Bandbreiten in den jeweiligen Verkehrsklassen mit sogenannten PCAP-Filtern auflösen [5].

Skript

Das Handbuch für das TSN-Starterkit gibt keinen quantitativen Überblick in die oben genannten Werkzeuge: es bespricht jene elementare Funktionen, die im ausgelieferten Zustand eine vollständige TSN-Strecke bis zur Evaluation mit, im Verzeichnis /opt/Kontron/ hinterlegten, Skripten parametrieren.

Letztendlich wird nach Verbindung der Netzwerkkabel drone gestartet, die RX/TX-Konfiguration ausgeführt, die Daten verschickt und die Analyse-PNGs gehoben (Bild 3). Unsere Teststrecke im Redaktionslabor zeigt eine Abweichung von der im Handbuch gezeigten Evaluation (Bild 3; inset). Für einen Proof-of-Concept stellt die Modifikation dieser Skripten vermutlich den schnellsten Weg.