Testbeds sind ein Ort der vorwettbewerblichen Zusammenarbeit auf einem praktischen Level und komplementieren somit die theoretische Kooperation bei der Standardisierung und die firmeninterne praktische Produktentwicklung. Der Fokus richtet sich dabei auf das entstehende Ökosystem, Standards werden als hierfür notwendiges Mittel zum Zweck gesehen. Ein Testbed verfolgt dabei typischerweise folgende Ziele:

• Etablierung des Ökosystems: Die Schaffung eines neuen Ökosystems erfordert einen ganzheitlichen Blick auf die Standards sowie das „Drumherum“. Wichtig ist es, hierfür die Standards anwendungsnah in den zukünftigen Kontext zu bringen. Dabei lassen sich sowohl Lücken in der Standardisierung, Verständnis für die Verwendung, Best-Practices und Themen wie die Nutzbarkeit voranbringen.
• Unterstützung der Standard-Entwicklung: Durch ein frühes Prototyping und Testing in der Standardisierung befindlicher Ansätze können diese früh validiert und optimiert werden.
• Sicherung der Interoperabilität: Eine herstellerübergreifende Interoperabilität ist entscheidend für den Erfolg von TSN insgesamt und somit auch für die individuellen Unternehmen. Ein frühzeitiges Testen und Kooperieren sichert diese Anforderung ab.
• Unterstützung der Produktentwicklung: Eine sehr pragmatische Motivation zum Einstieg ins frühe Prototyping ist der zu erwartende Vorsprung bei zukünftigen Produktionen.
• Ort für Innovation: Ein offener und früher Austausch zwischen Technologielieferanten und Anwendern sichert nicht nur den Erfolg zukünftiger Lösungen, er schafft durch den Austausch von Anforderungen und Technologiefortschritten auch den Raum für kreative neue Lösungen.

Arbeiten im Testbed

Genauso breit wie die Ziele eines Testbeds sind die Aktivitäten. Teilnehmer kommen aus verschiedenen Bereichen: Chip-Hersteller, Netzwerkinfrastrukturanbieter, Softwareentwickler und zunehmend auch Hersteller industrieller Steuerungen, Komponenten und Software sind dabei. Von zentraler Bedeutung sind gemeinsame Treffen vor Ort, die Plugfeste, welche bis zu sechsmal jährlich stattfinden. Selbstverständlich stehen die Teilnehmenden ebenfalls in regelmäßigem Austausch und auch ein kontinuierliches Testen ist zunehmend möglich. 

Bei den Plugfesten, typischerweise 3-tägige Veranstaltungen, kommen die Teilnehmer des Testbeds zum praktischen Arbeiten sowie zum Austausch und der Diskussion zusammen. Praktische Aktivitäten im Rahmen eines Plugfests umfassen typischerweise: 

• Ad-hoc-Testen: Insbesondere sehr frühe prototypische Implementierungen neuer Funktionen werden typischerweise zwischen zwei oder mehr Herstellern getestet, ohne hierfür spezielle Vorbereitungen zu treffen oder Testpläne zu erstellen. Ziel ist ein möglichst frühes Feedback für die Produktentwicklung, teilweise auch gezielt für die Rückmeldung in die Standardisierung. 
• Testen mit Test-Tool-Herstellern: Der systematische Weg zur Überprüfung der Standardkompatibilität erfolgt mittels spezieller Test-Tools und Testplänen. Die Hersteller dieser Tools sind typischerweise auf Plugfesten vertreten und nutzen die Interaktion zum besseren Verständnis der Marktbedürfnisse.
• Interoperabilitätstests: Das Testen der Interoperabilität erfolgt typischer Weise durch das herstellerübergreifende Vernetzen von Geräten. Dabei sollen möglichst viele verschiedene Kombinationen getestet, aber auch eine möglichst große Abdeckung potenzieller Testfälle erreicht werden. Diese sind jedoch im Vergleich zum Testen mit Tools oft schwerer zu stimulieren und zu überwachen.
• Proof-of-Concept: In frühen Stadien der Standardisierung können Proof-of-Concepts sehr wertvoll für die weitere Entwicklung sein. Insbesondere für herstellerübergreifende Ansätze bieten Testbeds den optimalen Rahmen.
• Gemeinsame Demonstratoren: Zur Validierung und öffentlichen Darstellung des Ökosystems werden gemeinsame Demonstratoren entwickelt. 

Themen im Testbed

Die im Rahmen des Testbeds diskutierten Themen sind so vielfältig wie das Ökosystem TSN und entwickeln sich mit der Zeit. Zu Beginn der Testbed-Aktivitäten lag der technische Fokus auf den grundlegenden Standards von TSN: Der Zeitsynchronisation mittels 802.1AS sowie dem zeitbasierten Scheduling im Rahmen von 802.1Qbv. Zusätzlich waren auch die Bekanntmachung der Technologie sowie erste herstellerübergreifende Proof-Of-Concepts im Fokus. Mit dem Erreichen eines gewissen Reifegrades sowie der steigenden Akzeptanz für TSN erweiterten sich die Themen zunehmend. Als zentrales Thema kam die Konfiguration hinzu - ein vielschichtiges und auch hochpolitisches Thema! Des Weiteren rückte eine Reihe von TSN-Standards ins Interesse, insbesondere bezüglich der Frame-Preemption und der Redundanz. Standardübergreifend ist zunehmend eine Verschiebung des Ziels von einem Proof-of-Concept der Interoperabilität hin zu einem Suchen potenzieller Interoperabilitätsprobleme zu beobachten. 
 

Bild 2: Die Übersicht der Arbeitsthemen im TSN Testbed

© ISW

Der zunehmende Fokus auf das Ökosystem TSN ist auch in der steigenden Bedeutung von Protokollen und Technologien unter und insbesondere oberhalb von TSN zu sehen. Da für viele Teilnehmer TSN insbesondere für die Nutzung von OPC UA bis hinunter zur Feldebene bedeutend ist, rückt auch das Zusammenspiel von OPC UA - insbesondere PubSub - und TSN weiter in den Fokus.

Entsprechend der sich weiterentwickelnden Themen, herrscht ein kontinuierlicher Bedarf an Abstimmung und Weiterentwicklung des Vorgehens beim Testen. Insbesondere die zunehmende Komplexität, die Reife der Produkte und die wachsende Anzahl an Teilnehmern erfordert eine zunehmende Systematisierung. Dies stand auch im Fokus der unfreiwilligen Zwangspause von vor-Ort-Aktivitäten, welche mittels virtueller Plugfeste versucht wurde abzudecken. Im Ergebnis wurde der Ansatz des Interoperabilitäts-Rack weiterentwickelt und optimiert.

Interoperabilität im Rack-Format

Interoperabilitätstests systematisch und effizient durchzuführen ist deutlich komplexer als klassische Tests zur Verifikation von Standards. Hierzu tragen mehrere Faktoren bei: Eine große Anzahl an Geräten führt zu nahezu beliebig vielen Topologien, welche sich potenziell auf die Funktion auswirken können. Gezielte Tests durchzuführen kann sehr komplex und die Abdeckung sehr limitiert sein, da die Geräte oft nur schwer zu einem bestimmten Verhalten angeregt werden können. Gleichermaßen stellen das Überwachen der Tests sowie eine detaillierte Analyse eine große Herausforderung dar. Andererseits wird an das Testen der Anspruch gestellt, mit möglichst geringem Overhead nutzbar zu sein, möglichst für Geräte mit unterschiedlichen Ausprägungen, vom Switch bis zum Endpunkt, zu funktionieren und reproduzierbare Ergebnisse zu liefern.
 

Bild 3: Die schematische Darstellung des Interoperability-Racks

© ISW

Die Entwicklung eines geeigneten Ansatzes ist seit langer Zeit im Fokus des Testbeds und Gegenstand kontinuierlicher Diskussionen. Im Zentrum der Lösung steht das Interoperability Rack, welches in vielen Iterationen umgesetzt und verbessert wurde. In der jüngeren Vergangenheit, in welcher das Durchführen realer Plugfeste nicht möglich war, lag der Fokus bei vielen virtuellen Meetings auf die Konsolidierung und Optimierung des Racks. Beim realen Plugfest um Herbst 2021 wurden die Ergebnisse vor Ort umgesetzt und stellen nun die Grundlage für weitere Aktivitäten dar.

Das Interoperability Rack, in welchem sämtliche für das Testing notwendigen Geräte untergebracht sind, lässt sich in folgende Bereiche gliedern:

• Basisinfrastruktur: Basis des Racks ist ein klassisches Server-Rack welches um Integrationsmöglichkeiten für verschiedenste Geräte ergänzt ist, von hutschienenbasierten Industriekomponenten bis zum Prototyping-Board. Das Rack versorgt die Geräte mit Energie und Konnektivität, inklusive einem VPN Zugriff.
• Kern-Topologie: Im Kern des Racks gibt es eine fixe Topologie aus Switches und Endpunkten, welche eine Vielzahl an Slots anbietet, mit welchen sich andere Geräte verbinden lassen.
• Devices-under-Test (DUT): Geräte, die getestet werden sollen, sind ebenfalls Bestandteil des Racks, lassen sich aber bei Bedarf, zum Beispiel bei einem Plugfest, auch extern verbinden.
• Topologie-Patch-Feld: Sowohl die verfügbaren Slots der Kern-Topologie als auch die Ports der DUTs sind auf ein Patch-Feld geführt. Mittels diesem können verschiedene Topologien sehr einfach gesteckt werden. Kombinationen aus DUTs und Kerntopologie werden als Szenarien bezeichnet. 
• Test-Tools: Das Rack ist mit einer Vielzahl an Test-Tools ausgestattet. Dazu gehören einerseits die Geräte einschlägiger Hersteller, andererseits auch weitere Systeme wie ein Pulse-Per-Second-Monitor. Als weiteres Tool wurde die so genannte Interoperability Application entwickelt, welche von den meisten Endpunkten ausgeführt wird und zum Testen und Monitoring dient.

Zur effizienten Nutzung des Racks existieren Testpläne, beispielsweise für spezifische Funktionen wie die Zeitsynchronisation oder Events wie den Ausfall eines Links. Zum systematischen Interoperabilitätstesten werden Testpläne in 
bestimmten Szenarien durchgeführt und die Ergebnisse analysiert. Während eines Plugfests werden möglichst viele Testpläne mit permutierenden Szenarien kombiniert, zwischen den Veranstaltungen läuft das Rack in einem kontinuierlichen Betrieb, welcher Langzeittests zulässt. Auch können Teilnehmer remote Firmware-Updates durchführen und deren Funktion testen.

Konfiguration – eine zentrale Herausforderung

Der Erfolg von TSN hängt entscheidend von der Nutzbarkeit ab und diese wiederum ist direkt mit der Konfiguration verwoben. Entsprechend 802.1Qcc gibt es drei grundlegende Ansätze bezüglich der Konfiguration - zentral, verteilt und hybrid - wobei sämtliche Varianten auf weitere, noch nicht vollständig verfügbare Standards aufsetzen. Der Fokus des Testbeds richtet sich auf den zentralen Ansatz.

Unabhängig vom Ansatz hat die Konfiguration mehrere Dimensionen: 

• Was soll konfiguriert werden? Es muss geklärt sein, welche Standards in welcher Konfiguration für welchen Anwendungsfall einzusetzen sind.
• Wie soll konfiguriert werden? Es muss geklärt sein, wie eine Konfiguration vom Ort der Entscheidung, zum Beispiel einem zentralen Netzwerkmanagement (CNC), zu den betroffenen Geräten kommt und wie diese damit umgehen, sowohl zeitlich als auch logisch.

Während die Beantwortung der ersten Frage grundsätzliche Entscheidungen hinsichtlich der Nutzung von TSN voraussetzt und dementsprechend eine hochpolitische ist, ist die zweite wesentlich technischer. Entsprechend wird über die erste zwar viel diskutiert und auch durchaus das ein oder andere Experiment oder gar Proof-of-Concept realisiert. Systematische Test fokussieren sich aber in erster Linie auf die technische Realisierung.

So fanden im Testbed bereits herstellerübergreifende Tests zur Konfiguration von Schedules auf Switches verschiedener Hersteller durch eine zentrale CNC mittels NETCONF und YANG statt. Auch Tests zur Kommunikation zwischen CUC und CNC sind erfolgreich gelaufen.

Im Laufe des Jahres ist eine deutliche Erweiterung der Aktivitäten hinsichtlich des Testens der Konfiguration geplant und es sollen insbesondere viele weitere YANG-Module in den Fokus rücken. Neben der reinen Logik und Daten sollen zunehmend auch Aspekte wie das Timing betrachtet werden. Als weiterer Aspekt ist die Endpunktkonfiguration zu nennen, welche dank großer Fortschritte bei den Standards ein wichtiges Thema für das Jahr 2022 ist.

Gemeinsam mehr erreichen

Der Autor: Florian Frick ist Gruppenleiter 'Echtzeitkommunikation' am ISW Stuttgart.

© Uni Stuttgart

Auch wenn in den vergangenen Jahren schon viel im Rahmen des Testbeds erreicht wurde, liegt vor dem Ökosystem TSN noch ein weiter Weg. Dieser wird hoffentlich in diesem Jahr wieder zunehmend mit persönlichen Treffen begleitet werden können. Neben vielen systematischen Interoperabilitätstests steht insbesondere die Konfiguration im Fokus der Arbeiten. Die positiven Erfahrungen der Teilnehmer zeigen, dass sich die Zusammenarbeit sowohl für diese selbst als auch für das Ökosystem TSN lohnt.