zurück zur Themenseite

Schwerpunkt

Teil 4 der TSN-Serie

Florian Frick & Meinrad Happacher | Meinrad Happacher,

Die Protokolle der oberen Schichten

TSN deckt lediglich die unteren OSI-Schichten ab. Für die oberen Schichten gibt es verschiedene Protokoll-Ansätze. Aufgrund der deterministischen Anforderungen haben diese – anders als in der Vergangenheit – auch Auswirkungen auf TSN selbst.

© WEKA Fachmedien

Florian Frick ist Gruppenleiter Echtzeit­kommunikation und Steuerungs-hardware am ISW Stuttgart.

© ISW

Ethernet und somit auch TSN deckt die OSI-Schichten 1 und 2 ab, weshalb auf den oberen Schichten stets weitere Protokolle nötig sind, welche typischerweise mit steigendem Layer zunehmend applikationsspezifisch werden. Häufig kommen aus der IT bewährte Protokolle zum Einsatz, zum Beispiel TCP/IP auf den Schichten 3 und 4. Auf der Applikationsschicht hingegen werden aber oft branchenspezifische Protokolle genutzt, beispielsweise für Automotive oder Professional Audio Video. Im in­dustriellen Umfeld gibt es momentan mehrere Ansätze: Grundsätzlich muss unterschieden werden, inwieweit TSN zum Einsatz kommen soll – lediglich bis zur Anlagenebene oder bis zur 
Feldebene. Bei der Nutzung bis runter zur Feldebene gibt es zwei grundlegende Fraktionen: Auf der einen die Vertreter der Philosophie ‚Feldbusse-over-TSN‘ und auf der anderen jene, die eine Standardisierung durch alle Ebenen erreichen möchten und sich im Rahmen der OPC Foundation unter dem Akronym OPC UA FLC (Field Level Communication) zusammengefunden haben.

Meinrad Happacher, Editor at Large Computer&AUTOMATION 

© Computer&AUTOMATION

Anders als dies in der Vergangenheit der Fall war, lässt sich bei der determi-nistischen Echtzeit-Kommunikation mit TSN keine saubere Entkopplung zwischen den unteren und oberen Schichten mehr vornehmen – die Abhängigkeiten der Funktionen auf den unteren Ebenen und der Applikationen sind einfach zu stark verwoben. Um TSN interoperabel nutzen zu können, haben sich deswegen ver­schiedene Gruppen für die unterschiedlichen Branchen gebildet, welche jeweils eine gemeinsame Basis für die unterschiedlichen Protokolle über TSN spezifizieren: Für Automotive entsteht das Profil 802.1DG, für Professional Audio Video wird die Milan-Spezifikation erarbeitet und für die industrielle Kommunikation hat sich die Arbeitsgruppe IEC/IEEE 60802 gebildet.
Inwieweit die Profile dafür ausreichen werden, dass verschiedene Protokolle 
interoperabel koexistieren können, wird noch sehr kontrovers diskutiert, genauso wie das Thema der branchenübergreifenden Interoperabilität. In dieser Ausgabe der Artikelserie beziehen auf den folgenden Seiten wichtige Fraktionen der industriellen Kommunikation zu diesem Thema Stellung: die OPC Foundation, die Profibus Nutzerorganisation, die Ethercat Technology Group und die CC-Link Partner Association.

Anzeige

Peter Lutz, Director Field Level Communications bei der OPC Foundation

© OPC Foundation

Der TSN-Ansatz der OPC Foundation

Welchen Ansatz verfolgt die OPC Foundation in puncto TSN?

Peter Lutz: OPC UA ist kein Transport-protokoll im herkömmlichen Sinne. Es handelt sich vielmehr um ein industrielles Framework, das Mechanismen für einen sicheren, zuverlässigen, hersteller- und plattformunabhängigen Informationsaustausch sowie Möglichkeiten zur semantischen Informationsmodellierung und Selbstbeschreibung von Geräten beinhaltet. Im Gegensatz zu anderen reinen Feldbus-Protokollen skaliert OPC UA vom Sensor über alle Ebenen bis hin zu den MES- und ERP-Systemen, aber auch in die Cloud – auch die von Beginn an eingeplante IT-Security ist ein wesentliches Differenzierungsmerkmal. Mit Hilfe eines universellen QoS-Modellierungskonzeptes können modellierte Informationen und Dienste mit ihren jeweiligen QoS-Mechanismen einfach auf verschiedene unterlagerte Kommunikationsprotokolle und Übertragungsphysiken abgebildet werden. 
Die Kombination von OPC UA mit anderen unterlagerten Infrastrukturen ermöglicht neue erweiterte Einsatzgebiete: Mit TSN wird OPC UA echtzeitfähig, und in Kombination mit Ethernet-APL beziehungsweise SPE erschließt OPC UA neue Anwendungsfelder in der Prozessindustrie, der diskreten Fertigung und auch darüber hinaus.

Die OPC Foundation hat bereits im Juni 2015 eine Arbeitsgruppe eingesetzt, um entsprechende PubSub-Erweiterungen für TSN zu spezifizieren. Im November 2018 wurde zusätzlich die Field-Level-Communications-Initiative ins Leben gerufen, um alle notwendigen Anforderungen für Anwendungen in der Steuerungs- und Feldebene für die Prozess- und Fabrikautomation erforderlichen Erweiterungen für OPC UA zu spezifizieren – inklusive dem Mapping auf TSN zu. 
OPC-UA-FLC-Endgeräte werden über OPC UA – online oder offline – und Netzwerk-Infrastruktur-Geräte über gängige Netzwerk-Management-Protokolle konfiguriert. Dabei wird sowohl eine zentrale, wie auch eine dezentrale Konfiguration unterstützt. Die für die TSN-Konfiguration zu unterstützenden Protokolle werden im TSN IA Profile IEC/IEEE 60802 zusammengestellt beziehungsweise selektiert.

Wie wirkt sich TSN auf Ihre Geräte und das Ökosystem aus?

Mit TSN wird das Anwendungsspektrum von OPC UA auf Bereiche erweitert, die eine deterministische Kommunikation erfordern. Neben einem direkten Layer 2 Mapping von OPC UA auf TSN für Anwendungen mit entsprechenden Anforderungen in Bezug auf Echtzeit-Fähigkeit und Protokoll-Effizienz wird ein Layer 3 Mapping über UDP spezifiziert, damit ein flexibler Einsatz von OPC UA in der Prozessindustrie und auch in der Fabrikautomatisierung gewährleistet ist.   
Durch das Baukastenprinzip von OPC UA bleiben alle Basisdienste, die Informationsmodelle, die semantische Selbstbeschreibung und die Security-Mechanismen unverändert und rückwärtskompatibel bestehen. Somit können auch bestehende Toolkits weiterhin verwendet und konventionelle OPC-UA-Geräte mit in die Kommunikation eingebunden werden. 

Inwieweit ist Ihr Ansatz interoperabel im Sinne konvergenter Netzwerke?

Es gibt ein klares Bekenntnis der OPC Foundation zum IEC/IEEE-60802-Profil, um sicherzustellen, dass verschiedene Protokolle eine einheitliche Netzwerk-infrastruktur nutzen können. Dies sehen wir nicht nur als wichtig in Bezug auf die Konvergenz von IT und OT an, sondern auch, um die Migration herkömmlicher Feldbus- und Echtzeit-Ethernetprotokolle zu einer einheitlichen Kommunikationslösung zu unterstützen. Klare Zielsetzung der FLC-Initiative ist es, auch die höheren Protokollschichten, sowie die Semantik der verschiedenartigen Steuerungs- und Feldgeräte in der Fabrik- und Prozessautomatisierung zu vereinheitlichen, um einen Beitrag zur Vereinheitlichung der aktuell heterogenen Protokoll- und Profillandschaft zu leisten. 

Das Schichtenmodell von OPC UA/FLC über TSN.

© OPC Foundation

Gibt es schon existierende Lösungen oder wann ist damit zu rechnen?

OPC-UA-Lösungen sind heute bereits von einer Vielzahl verschiedener Anbieter im Markt verfügbar und werden in unterschiedlichsten Anwendungsfeldern eingesetzt. Erste OPC-UA-Geräte mit TSN wurden bereits als prototypische Implementierungen vorgestellt. 
Die Spezifikationen, die eine herstellerübergreifende Interoperabilität zwischen Steuerungen und Feldgeräten verschiedener Hersteller ermöglichen, sind aktuell noch in Arbeit. Eine erste Spezifikationsversion soll noch in diesem Jahr released werden. Wir erwarten, dass diese dann auch zeitnah in entsprechenden OPC-UA-Produkten umgesetzt wird.
 
Warum ist OPC UA für die Digitalisierung der Produktion geeignet?

Im ersten Schritt ermöglicht die FLC-Initiative der OPC Foundation, Geräte aus verschiedenen Ökosystemen horizontal (und mit TSN auch deterministisch) miteinander zu verbinden. Mit der vertikalen Erweiterung von OPC UA in die Feldebene steht eine einheitliche Lösung zur Verfügung, die alle relevanten Anwendungen – inklusive Motion, Safety, Echtzeit – in der industriellen Automatisierung abdeckt und gleichzeitig eine komplette Durchgängigkeit vom Sensor zur Cloud und vice versa sicherstellt. 
Der große Vorteil einer durchgängigen OPC-UA-basierten Lösung ist, dass keine Protokollumsetzungen oder Datenkonvertierungen notwendig sind, um auf prozess- und produktionsrelevante Informationen zugreifen zu können, die für die Umsetzung von Industrie-4.0-Konzepten benötigt werden. Stattdessen kann über einen einheitlichen Kommunikationsstandard direkt auf die modellierten Informationen in den entsprechenden Geräten – etwa Steuerungen, Feldgeräte – zugegriffen werden – und dies sicher, herstellerübergreifend und zukunftssicher.
    
*) kurz: FLC

Der TSN-Ansatz der Profibus Nutzerorganisation

Dr. Peter Wenzel, Geschäftsführer der Profibus Nutzerorganisation

© PNO

Welchen Ansatz verfolgt die Profibus Nutzerorganisation in Kombination mit TSN?

Dr. Peter Wenzel: Bei den Spezifikationsarbeiten zu Profinet wurde darauf geachtet, dass geeignete internationale Standards – IEEE und IEC – in die Architektur von Profinet Einzug finden. Nur für Kommunikationsmechanismen, für die keine geeigneten Standards verfügbar waren, wurden Profinet-spezifische Mechanismen definiert. 
Zum Beispiel erfolgte in Bezug auf harte Echtzeit die Entwicklung des IRT Protokolls1). Profibus InternationaI – kurz PI – hat mit der Integration 
relevanter TSN-Funktionen in die Profinet-Architektur Mehrwerte für den Kunden generiert und darüber hinaus Profinet auf ein zukunftsfähiges Fundament für Industrie 4.0 gesetzt. Die grundlegende Idee dabei ist, auf Schicht 2 neben RT und IRT jetzt auch TSN als dritte Option anzubieten. 
Bei der Integration von TSN in Profinet wurde auf Parameter zurückgegriffen, welche in den relevanten IEEE-802.1-Standards bezüglich Synchronisation2), TAS3) und Preemption4) spezifiziert sind. 
Eine einfache Konfiguration von Netzwerk-Parametern ist ausschlaggebend für die Akzeptanz beim Anwender. Zur Vereinfachung und Vereinheitlichung dieses Vorgangs entstand das Konzept einer Network Management Engine – kurz NME. Sie soll im Profinet Controller angesiedelt sein. Der Umgang mit den bekannten Engineering Tools bleibt gleich, die Planung wird aber erheblich erleichtert, da die Erstellung einer Netzwerk-Konfiguration in TSN nicht mehr Teil des Engineering, sondern Bestandteil der Runtime-Funktionen im Controller beziehungsweise im Device sein wird. Die NME soll eine Umplanung von Netzwerken während der Laufzeit ermöglichen.

Wie wirkt sich TSN auf Ihre Geräte und das Ökosystem aus?

Ein Eckpfeiler der Strategie von PI ist, dass in der Feldebene Profinet auch mit unterlagertem TSN betrieben werden kann. Die Anwendersicht mit den standardisierten Zugängen zu Daten aus der Produktion, zu Diagnose-Informationen aber auch zu Profil-relevanten Parametern wie PA Devices beziehungsweise Profisafe bleibt dabei unverändert. TSN bietet neben RT/IRT ‚lediglich‘ einen zusätzlichen Layer-2-Zugang zu einem konvergenten TSN-Netzwerk. Der Aufbau von Mischsystemen ist bei Einhaltung von definierten Regeln möglich, was flexible Übergänge und Erweiterungen von RT/IRT zu TSN in Brownfield-Anlagen ermöglicht.
Als weiteren Eckpfeiler setzt PI auf OPC UA als ‚Middelware‘ in der Anlagenebene, das heißt zum herstellerunabhängigen Daten- und Informationsaustausch zwischen verschiedenen Steuerungen und Maschinen. Das funktioniert in den meisten Fällen bereits schon auf Basis des TCP/IP Unterbaus und bekommt mit den neuen Mechanismen Pub/Sub zusätzliche gewünschte Eigenschaften. All dies ermöglicht in Verbindung mit TSN den Einsatz von Standard-Hardware, was sich ausgesprochen positiv auf die Kosten sowohl der Anbieter als auch Anwender auswirkt.

Die Profinet-Architektur mit TSN und APL.

© PNO

Inwieweit ist Ihr Ansatz interoperabel im Sinne konvergenter Netzwerke?

Notwendige Voraussetzung für ein hohes Maß an Interoperabilität ist die Existenz einer offenen Schnittstellen-spezifikation. Sichergestellt wird dies bei PI durch weltweit einheitliche Teststandards für die Zertifizierung von Produktschnittstellen. Mit TSN kann die Interoperabilität auf eine höhere Ebene gehoben werden, sodass unterschiedliche Ethernet-Systeme, die TSN nutzen, interoperieren können. Profinet ist so konzipiert, dass Koexistenz zu anderen Kommunikationssystemen, wie TCP/IP, gegeben ist. Lediglich die Bandbreiten müssen bei einem Parallelbetrieb geregelt sein. Damit ist die Koexistenz von Profinet mit beispielsweise AVB oder den unterschiedlichen IT-Protokollen grundsätzlich gegeben.
Das Ziel des TSN Industrial Automation Profile5) der IEC/IEEE 6080 ist, einen einheitlichen TSN-Standard für industrielle Anwendungen so zu definieren, dass Geräte, die unterschiedliche Kommunikationssysteme ‚sprechen‘ im Sinne eines konvergentes TSN-Netzwerks interoperieren können. Der Zeitplan sieht vor, das Profil 2021/22 bereitzustellen.

Gibt es schon existierende Lösungen oder wann ist damit zu rechnen?

TSN steht mit der Profinet-Spezifikation V2.4 zur Verfügung. Bereits vor Abschluss der Spezifikationsarbeiten sind sowohl erste Implementierungen bei mehreren Basistechnologieanbietern entstanden als auch die Konzepte für die Zertifizierung erarbeitet worden. Die frühzeitig gestartete Erstellung von Test Cases ermöglichten einen entsprechenden frühen Start von Tests schon während der Entwicklungsphase von Produkten. 

Warum ist Ihr Ansatz für die Digitalisierung der Produktion geeignet?

Um Profinet für den Einsatz in Produktionssystemen der Generation Industrie 4.0 zu ertüchtigen, haben die zuständigen Arbeitskreise offene Semantik- und Informationsmodelle für die Gerätebeschreibung und zu übertragende anwendungsbezogene Daten spezifiziert. Als Grundlage für die Realisierung wurde OPC UA als vertikaler Kommunikationskanal und die Verwendung des OPC UA Information Models für die Übergänge von Profinet zu OPC UA festgelegt.
Die Realisierung einer digitalen Fabrik benötigt als Basis ein hohes Maß an firmen- und branchenübergreifend verfügbarer maschinell verarbeitbarer, standardisierter Informationen. PI hat hierbei im ersten Schritt Features für die Bereitstellung von Geräte-Know-how etwa in Form von Parametern in Geräteprofilen und durch Festlegungen auf der Applikationsschicht, wie für ein Asset Management Record, bereitgestellt. Damit diese aber als Basis für einen maschinen-verarbeitbaren Datenfluss über die verschiedenen Systeme hinweg vom Sensor bis zur Cloud genutzt werden können, müssen die Daten mit Hilfe von semantischen Standards in nutzbare Informationen gewandelt werden. Hierbei werden in Kooperation mit eCl@ss e.V. die von PI definierten Parameter um Semantik-Identifier erweitert. 

1) Isochronous Real Time
2) 802.1 ASrev
3) time aware shaper, 802.1Qbv
4) 802.1Qbu
5) TSN IA-Profil

Der TSN-Ansatz der Ethercat Technology Group

Martin Rostan, Executive Director, Ethercat Technology Group

© ETG

Welchen Ansatz verfolgt die Ethercat Technology Group in Kombination mit TSN? 

Martin Rostan: Der prägende Anwendungsfall für Ethercat ist die Steuerung, die ‚nach unten‘ maschinenintern über Ethercat hoch performant und hart echtzeitfähig mit E/As, Antrieben und Sensoren kommuniziert, und ‚nach oben‘ maschinenübergreifend über Ethernet Daten austauscht: mit überlagerten und benachbarten Steuerungen sowie mit lokalen und Cloud-basierten Systemen wie SCADA, ERP und MES.
TSN-Technologien werden auch das ‚obere‘ Ethernet-Netzwerk deterministisch machen – das begrüßen wir und werden wir entsprechend nutzen. Ethercat unterhalb der Steuerung benötigt keine TSN-Technologien: Ethercat ist schon immer hart echtzeitfähig.
Nur wenn beide Netzwerke getrennt bleiben, gelingt die saubere und für den stabilen Betrieb notwendige Strukturierung des Gesamtsystems: Wenn sich sowohl die ‚unteren‘ als auch die ‚oberen‘ Netzwerk-Knoten Bandbreite und Adressraum teilen und deshalb in der Konfiguration aufeinander abgestimmt werden müssen, dann kann auch der eigentlich maschineninterne Netzwerkteil erst dann in Betrieb genommen werden, wenn das komplette Netzwerk beim Kunden aufgebaut ist – und jede zukünftige Erweiterung der Anlage hat dann potenziell Rückwirkungen auf die Funktion jedes Teilsystems.

Mit unserem TSN-Ansatz eröffnen wir die Möglichkeit, ganze Ethercat-Segmente echtzeitfähig an ein heterogenes Ethernet-Netzwerk an-zubinden: Hierfür werden wir Ethercat-Frames über TSN-Streams tunneln, wobei innerhalb des Ethercat-Segments keine TSN-Features mehr erforderlich oder vorhanden sind. Das erweitert die Topologie-Optionen. Die Strukturierung bleibt fast vollständig erhalten: da je Ethercat-Segment nur ein Frame und nur eine Adresse erforderlich sind, wird das TSN-Netzwerk kaum belastet und die Konfiguration ist beinahe unabhängig vom restlichen Netzwerk.
Bei der TSN-Konfiguration verfechten wir übrigens bewusst keine eigenständige Lösung: Ethercat selbst wird ja nicht auf TSN-Technologien basieren, sondern an zukünftige heterogene TSN-basierte Netzwerke angekoppelt. 

 

Das Zusammenspiel von TSN und Ethercat.

© ETG

Wie wirkt sich TSN auf Ihre Geräte und das Ökosystem aus? 

Praktisch gar nicht: Ethercat selbst bleibt stabil und unterliegt auch in Zukunft keinen Versionierungsproblemen. Ethercat-Slave-Geräte müssen überhaupt nicht verändert werden, weil TSN innerhalb des Segments keine Rolle spielt. Die Anpassung an den TSN-Stream*) wird noch im TSN-Switch oder aber im ersten Gerät stattfinden, die dann hierfür ertüchtigt sein müssen – führende Switch-Hersteller haben hierfür ihre Unterstützung zugesagt. Steuerungen, die via TSN-Netzwerk mit Ethercat-Segmenten kommunizieren wollen, benötigen lediglich eine Software-Erweiterung: Hier werden die Ethercat-Frames in den TSN-Stream eingefügt.

Inwieweit ist Ihr ‚Ethercat-and-TSN‘ interoperabel im Sinne konvergenter Netzwerke? 

Interoperabilität – oder besser Koexistenz – mit anderen Protokollen ist genau das Ziel unseres Ansatzes. Deshalb arbeiten wir auch aktiv am IEC/IEEE-Profil 60802 mit.

Gibt es schon existierende Lösungen oder wann ist damit zu rechnen?

Der Einsatz von TSN macht erst Sinn, wenn die TSN-Technologien ihre Versprechen einlösen können: mit Hilfe von Standard-Ethernet-Hardware unterschiedliche Protokolle deterministisch und parallel betreiben, und das Netzwerk herstellerunabhängig konfigurieren. Wenn ich die Verfügbarkeit der Chips und die Fortschritte gerade bei der Standardisierung der TSN-Konfiguration betrachte: Das wird noch dauern. 

Warum ist Ethercat für die Digitalisierung der Produktion geeignet? 

Weil Ethercat schon heute die Anforderungen erfüllt: extrem schnelle Kommunikation ohne aufwendige IT-Konfiguration da, wo es darauf ankommt. Und IT-Konnektivität – gerne auch über OPC UA – da, wo sie gebraucht wird. Und das mit stabiler Technologie, der größten Gerätevielfalt im Markt und ohne Security-Sorgen.

1) Stream Adaptation

Der TSN-Ansatz der CC-Link Partner Association

Christoph Behler, Business Development Manager, CC-Link Partner Association Europe

© CLPA

Welchen Ansatz verfolgt die CLPA in Kombination mit TSN?

Christoph Behler: Die CC-Link Partner Association – kurz CLPA – ist als Nutzerorganisation Ansprechpartner für CC-Link IE TSN. CC-Link IE TSN kombiniert erstmalig die Gigabit-Bandbreite des Ethernet mit der Time-Sensitive-Networking-Technologie. TSN steht für eine neue Ära von Datenaustausch und schafft die Voraussetzungen, um die Herausforderungen des Zusammenwachsen der IT- und OT-Welten zu meistern. 
Es ist die erste offene Ethernet-Technologie, die die Gigabit-Bandbreite mit wichtigen TSN-Funktionalitäten, Zeitsynchronisation und Datenfluss-Priorisierung kombiniert. Des Weiteren wird die Einbindung und Nutzung der bestehenden CLPA-Netzwerke ermöglicht. Die CLPA schafft hierbei Schnittstellen zwischen OSI Layer 2 und 3. CC-Link IE TSN wird durch eine Software-Konfigurationsplattform aufgesetzt, die den IE TSN Master konfiguriert. Hierbei werden alle Merkmale der teilnehmenden Devices parametriert und verwaltet. 

Wie wirkt sich TSN auf Ihre Geräte und das Ökosystem aus?

Die Datentransparenz und -durchgängigkeit wird mit CC-link IE TSN erweitert. Es sind jetzt nicht nur ASIC-gestützte Entwicklungen möglich, sondern auch Software-Entwicklungen die auf standardisierte TSN Hardware aufsetzen. Somit reduzieren sich die Entwicklungsaufwendungen für schnelle Umsetzung der Adaptionen.
CC-Link IE TSN ist abwärtskompatibel und bestehende CC-Link Systeme können eingebunden werden, da CC-Link-Netzwerke von Haus aus deterministischen Datenverkehr unterstützen. Dies bietet getätigten Entwicklungen und Installationen Investitionsschutz. 
Je nach Anforderung reichen Software-Lösungen implementiert auf IEEE 802.1AS und IEEE 1588 kompatibler standardisierter TSN-Ethernet Hardware bei zeitkritischen Anwendungen. Darüber hinaus besteht die Möglichkeit für hoch performante Applikationen, Chips in den Master, Slave oder Remote-Stationen zu implementieren. 
Der Master übernimmt einerseits die Netzwerk-Konfiguration und anderseits die Steuerung des Datenverkehrs von und zu den Slaves. Die Slaves geben ihre Informationen an den Master zur weiteren Verarbeitung. Eine Querkommunikation zwischen den Slaves  ist möglich.  

Die TSN-Protokoll-Implementierung in CC-Link IE TSN.

© CLPA

Inwieweit ist CC-Link IE TSN interoperabel im Sinne konvergenter Netzwerke?

Die CLPA hat bereits in der Vergangenheit mit anderen Nutzerorganisationen eng zusammengearbeitet und eine Spezifikation zur Netzwerk-Kopplung von CC-link IE mit Profinet erarbeitet. Diese Entwicklung und deren Nutzen werden auch bei CC-Link IE TSN weiter vorangetrieben, zumal die Daten beider Systeme auf der gleichen TSN Netzwerkinfrastruktur koexistent und verfügbar sind. Die Koexistenz, also der Parallelbetrieb, verschiedener Netzwerke ist bereits vorhanden. Die Interoperabilität wird auf den höheren Layern, etwa dem Applikations-Layer, geschaffen. 
Der in dem Gemeinschaftsprojekt IEC/IEEE 60802 entwickelte Standard ‚IEC/IEEE 60802 TSN Profile for Industrial Automation‘ wird die künftige Basis für industrielles Internet in der Automation werden.
Wir haben bereits die Teile des Standards IEEE802.1 in CC-Link IE TSN implementiert, die bereits ver­öffentlicht – also ‚published‘ – sind. Besonders sind hierbei die Standards 802.1Qbv, Time aware shaping, und 802.1AS, Zeitsynchronisierung, zu nennen. Die noch nicht freigegebene IEEE 802.1AS-2020 wird in der zukünftigen Entwicklung berücksichtigt. Darüber hinaus ist die CLPA involviert, einheitliche CA*)-Test-Spezifikationen mit zu erarbeiten und Partnern anzubieten. Somit wird die Qualität, Koexistenz sowie die Interoperabilität von Entwicklungslösungen verschiedenster Anbieter gewährleistet werden. Synergien sind gewollt und können genutzt werden.

Gibt es schon existierende Lösungen?

Seit 2018 ist das CC-Link IE TSN Protokoll veröffentlicht und bereits in viele verschiedenste Geräte, Komponenten und Software Stacks  implementiert. Unterstützt wird dieses durch das große Angebot von weltweiten Technologie-Partnern mit Hardware und Software-Lösungen – etwa ASICs, Embedded Board, Software Protocol Stacks. Außerdem werden CC-Link-IE-TSN-basierte Safety-Lösungen im nächsten Schritt entwickelt. 

Warum ist CC-Link IE TSN für die Digitalisierung der Produktion geeignet?

CC-Link IE TSN ist ein ganzheitliches transparentes Kommunikationskonzept für den Datenverkehr von der Geschäftsebene mit Cloud-Anbindung bis hin zur Feldebene mit einzelnem Sensor und umgekehrt. Außerdem ermöglicht es ein Zusammenwachsen von IT und OT Welten. Damit wird eine Barrierefreiheit im Datenaustausch von deterministischen mit nicht deterministischen Systemen
sowie zwischen Systemen unterschiedlicher Übertragungsgeschwindigkeiten beispielsweise 1 Gigabit und 100 Mbit realisiert, wie es das Konzept von Industrie 4.0 es fordert. Einer Erfüllung dieses Konzeptes kommen wir somit näher.
Durch die Kombination von Gigabit-Bandbreite und TSN-Technologie sind wir in der Lage, als erste Nutzerorganisation ein höchst performantes Netzwerk für die Industrie anzubieten. Mit CC-Link IE TSN ist es möglich, Informationen transparent und bidirektional über alle Ebenen auszutauschen und beispielsweise aus den Produktionsprozessen Daten in Echtzeit zu sammeln, über Edge-Computing zu verarbeiten und dann nahtlos an IT-Systeme oder auch Cloud-Server zu über­tragen. Auch arbeiten die Partner der CLPA bereits an der OPC-UA-Implementierung über CC-Link IE TSN oberhalb der Controller-Ebene.

*) Conformance Assessment

 

  • Xing Icon
  • LinkedIn Icon
Anzeige
zurück zur Themenseite
Anzeige

Das könnte Sie auch interessieren

Anzeige

OPC Foundation

Ein Zwischenziel ist erreicht!

Zwei Jahre nach dem Startschuss im November 2018 hat die Field Level Communications Initiative der OPC Foundation den initialen Release Candidate für den Use Case ‚Controller- to-Controller‘ fertiggestellt. Was steckt hinter diesem Release und was...

mehr...
Anzeige
Anzeige
Anzeige

PNO

Vorstand turnusgemäß neu gewählt

Am 14. September 2020 fand die Mitgliederversammlung der Profibus Nutzerorganisation (PNO) statt - aufgrund der Corona-Pandemie erstmals virtuell. Auf der Tagesordnung stand unter anderem die turnusgemäße Wahl des Vorstands.

mehr...
Anzeige
Anzeige
Anzeige

Ethernet-TSN

Internationale TSN-Konferenz 2020

Ethernet erhält mit TSN eine Echtzeit-Erweiterung – und mit 5G gar ein neues Übertragungsmedium! Die Auswirkungen auf alle Branchen stehen im Zentrum der TSN/A Conference am 7. und 8. Oktober 2020, die in diesem Jahr als virtuelle Veranstaltung...

mehr...

Was denken Sie?

TSN allein ist nichts!

Ja, TSN ist die neue Basistechnologie für konvergente Echtzeit-Kommunikation. Aber welche Protokolle dann tatsächlich auf den TSN-Layern aufsetzen und sich am Markt durchsetzen werden, ist noch nicht entschieden. In diesem Beitrag kommen vier...

mehr...

Teil 3 der TSN-Serie

Prototyping und Testing von TSN

An TSN werden sehr hohe Anforderungen in puncto Interopera­bilität gestellt. Welchen Beitrag leisten hierbei herstellerüber­greifende Testbeds? Wie können die Implemen­tierungen von TSN-­Standards, aber auch die Interoperabilität getestet werden?

mehr...
Jetzt Newsletter abonnieren