Bei Industrie 4.0 (I4.0) geht es im Grunde um eine einfache Frage: Wie können wir die Beschreibung von realen Gegenständen (Dingen) und den damit verbundenen Prozessen über deren ganzen Lebenszyklus in ­einer einheitlichen und interoperablen Weise digital formulieren? Es geht ­dabei aber nicht darum, noch mehr PDF-Dokumente zu erstellen, die erst ein Mensch lesen muss, um dann da­raus Schlüsse zu ziehen. Ziel ist ­vielmehr, so viele Daten wie möglich ohne Konvertierung – und die fehleranfälligste Art der Konvertierung ist nun einmal das ‚Abtippen‘ – direkt weiterverarbeiten zu können. Ein di­gital beschriebenes ‚Ding‘ erschließt sich also in erster Linie nicht dem menschlichen Betrachter, sondern es wird für Software beziehungsweise für Algorithmen verständlich. Dinge, die andere Dinge ohne menschliches Zutun ‚verstehen‘, sind dann die allseits zitierten ‚Cyber Physical Systems‘.

Das ‚Reference ­Architectural Model Industrie 4.0‘ – kurz RAMI – erlaubt es, ‚I4.0-Dinge‘ aus verschiedenen Perspektiven zu betrachten: Welche Daten eines Dinges werden gebraucht, zu welchen Zeitpunkten und mit welchen Verfügbarkeiten?

© ZVEI

Sind die Dinge digital beschrieben, so folgen daraus eine Reihe von Möglichkeiten und Veränderungen: Jeder Datenpunkt, der mit einem Ding verknüpft ist, hat einen Ort in der Hierarchie und kann in verschiedenen funktionalen Ebenen wichtig werden. Das Referenzmodel RAMI der Industrie 4.0 versucht alle diese Aspekte in einem Schichtenmodell abzubilden. Am Anfang scheinbar komplex, hilft es, die Daten nach der jeweiligen Gemengelage zu verorten und zu strukturieren. Parktisch ergeben sich darüber hinaus Fragen nach der zeitlichen und räumlichen Verfügbarkeit der Daten bei vernetzten Dingen.

Einen Aspekt, den RAMI nicht darstellt, ist die sehr unterschiedliche ­zeitliche Verfügbarkeit von Daten. So ­müssen die Daten für das Lebenszyklus-Management sicherlich nicht jede Minute, wahrscheinlich nicht einmal jeden Tag ausgelesen werden. Hingegen sind die für die eigentliche Anwendung wichtigen Prozess-Daten im Bereich von wenigen Millisekunden in der Antriebstechnik deutlich unter einer Millisekunde zur Verfügung zu stellen. Meist sind die Prozessdaten allerdings nur im direkten Regelkreis in dieser hohen Qualität notwendig. Wie aber können die Daten aus verschieden zeitlichen und räumlich Quellen zusammengeführt werden?

Die Rolle der Cloud

Die Cloud ist in aller Munde. Früher waren das die hübschen Wolken in IT-Grafiken, die eine nicht näher bezeichnete Kommunikation oder eine sonstige In­frastruktur darstellten, von der niemand so genau zu wissen brauchte, wie sie funktioniert. Dies wurde schlicht als ‚gegeben‘ angenommen. Der Begriff Cloud – genau genommen Cloud-Computing – hat sich gehalten; jedoch versteht man darunter neuerdings eine Technik, bei der neben den Daten die zugehörigen Programme auf einem Server oder einer Serverfarm laufen. Die Cloud kann im öffentlichen Internet angelegt sein und als Dienstleistung zur Verfügung stehen – wie zum ­Beispiel Microsoft Azure – oder auch völlig ­privat innerhalb eines Unternehmens sowie in allen denkbaren Hybridlösungen.

Die Cloud ermöglicht es, den Dingen eine digitale Repräsentanz zu geben, beziehungsweise alle Daten aus sämtlichen räumlichen und zeitlichen Bezügen zusammenzufassen. In dieser Cloud können Daten aus verschiedenen Quellen hinterlegt werden: Daten vom Hersteller/Lieferanten (3D-Modell, Typenbezeichnung, Katalogeintrag), vom Integrator (Einbauort, Konfiguration) oder vom Benutzer/Bediener (Einstellungen, Service-Logbuch) und nicht zuletzt die Daten, die vom Gerät selbst kommen (Gerätestatus, aktuelle Daten). – Das ‚Ding‘ existiert somit als digitale Kopie in der Cloud.

Der entscheidende Vorteil dieses Konzeptes liegt darin, dass die Daten innerhalb der Cloud geteilt und mit fast beliebigen anderen Daten korreliert werden können. Somit sind auch neue Geschäftsmodelle denkbar, die in bis­herigen Architekturen nur schwer inte­grierbar waren. Man denke nur an das immer wieder genannte Beispiel der ‚Big-Data-Analyse‘ zur Prozessoptimierung durch dritte Dienstleister. Damit das alles gelingt, müssen aber alle Daten, die für eine Analyse oder Weiterverarbeitung interessant sind, auch in der Cloud verfügbar sein. Was bedeutet dies nun letztlich für die industrielle Kommunikation?

Knausern mit Bytes macht keinen Sinn mehr

Die Repräsentanz eines Dinges im digitalen Raum führt zu einer Reihe von Implikationen für die Kommunikation von Feldgeräten, Sensoren und Aktoren. Zuerst einmal sollten die Daten durchgängig nutzbar sein. In der Automatisierungswelt gibt es auch im Jahre 2016 immer noch ein gewisse Liebe zu Bytes und Byte-Feldern sowie kryp­tischen Datentypen. Dies ist verständlich, musste doch viele Jahre mit Bytes gespart und geknausert werden, da die klassischen Feldbusse hinsichtlich der Datenmenge doch recht begrenzt waren.

Bei Ethernet-basierter Kommunikation macht das keinen Sinn mehr: Hier beträgt die Mindestlänge einer Nachricht 64 Byte. Abzüglich des Overhead (14 Byte Header + 2 Byte VLAN + 4 Byte CRC) bleiben 44 Byte. Davon werden je nach verwendetem Protokoll nochmal ein paar Byte abgezogen – zum Beispiel 20 + 8 für UDP/IP, 20 + 20 für TCP/IP oder etwa 8 für Profinet RT. Ist eine Nachricht zu kurz – sprich kürzer als 64 Byte –, muss diese vor dem Senden aufgefüllt werden (üblicherweise mit dem Wert ‚0‘). Es macht also bei kleinen Feld­geräten und Sensoren keinen Sinn, kryptische Datentypen zu verwenden, nur um ein paar Bytes oder gar Bits zu sparen. Ein Analogwert ist in einem 32-bit-Float üblicherweise ganz gut untergebracht.

Ebenfalls muss ein zeitlicher Zugriff auf alle relevanten Daten möglich sein. In der Vergangenheit waren in der Regel nur einige wenige Parameter über den Feldbus verfügbar. Für eher selten genutzte Parameter gab es häufig nur den Weg über ein Tool des Herstellers. Auch das wird sich nicht halten können; der Nutzer muss vielmehr über alle relevanten Daten über die eigentliche Schnittstelle, das Industrial Ethernet, verfügen können. Nur so lässt sich die Repräsentanz in der Cloud vollständig halten und nur auf diese Wiese sind neue Analysemethoden über Herstellergrenzen hinweg denkbar.

Elektronische Datenblätter, wie etwa die GSDML bei Profinet oder das EDS bei Ethernet/IP, erlauben heute schon eine vernünftige Beschreibung von Gerätedaten. Das sollte auf jeden Fall ­genutzt werden, denn eine gute Gerätebeschreibung ist ein guter Start ins I4.0-Zeitalter.

Wie kommen die Daten in die Cloud?

Heute sind sich viele einig, dass OPC UA der beste Weg ist, Daten in die Cloud zu schicken. OPC UA ist ein relativ einfaches, auf TCP/IP basierendes Protokoll zum Austausch von Daten. Der große Vorteil gegenüber den viel schnelleren Echtzeit-Protokollen ist, dass OPC UA auch in einer Version mit verschlüsselter Kommunikation definiert ist. Somit kann OPC UA durchaus über öffentliche Netze betrieben werden. OPC UA selbst eignet sich allerdings nicht für harte Echtzeit-Anwendungen.

Die Frage wird also sein: Muss sich jeder Sensor und jedes Feldgerät selbst in der Cloud anmelden und dort seine Daten aktuell halten, oder wird diese Funktion von der Steuerung oder von entsprechenden Gateways bereitgestellt? Dieses Thema steht derzeit im Fokus der Diskussionen und das bis hin zu der Forderung, OPC UA möge in jedem Ding implementiert werden – im Zweifel auch parallel zu weiteren Industrial-Ethernet-Lösungen.

Und damit kommen wir zu einem ­anderen Trend in der industriellen Kommunikation: dem Time Sensitive Networking – kurz TSN. Dabei han-delt es sich um einen Standard der IEEE (802.1Q) und eine Weiter­entwicklung des AVB-Standards (Audio-Video-Bridging). In diesem Standard werden für Ethernet Methoden der Bandbreiten-Reservierung, der ­genauen zeitlichen Synchronisation und der redundanten Kommunikation definiert.

TSN ist dementsprechend eine reine Erweiterung des Ethernet-Layers, also der Schicht 2. Trotzdem wird es oft als das ‚Industrial Ethernet der Zukunft‘ beschrieben. Zwar kann TSN tatsächlich zu mehr Vereinheitlichung führen und wird gerade für Halbleiter-Anbieter einen großen Markt eröffnen; ein vollständiges Protokoll – vergleichbar mit HTTP/TCP/IP, Profinet oder Ethercat – ist TSN alleine allerdings nicht. Mit anderen Worten: TSN macht erst in Kombination mit anderen Protokollen Sinn.

Diesem Fakt Rechnung tragend, gibt es derzeit Bestrebungen, OPC UA mit TSN zu verheiraten, um aus diesen zwei Protokollen ein Neues zu schaffen oder genauer: Um OPC UA mittels TSN Echtzeit-Fähigkeiten zu eröffnen. Dabei sollte aber nicht vergessen werden, dass dies ein langer Weg ist, denn OPC UA muss dazu noch viel lernen: Wie sind die Datenpakete auf TSN-Streams abzubilden? Wie wird das Engineering erfolgen? Das sind nur einige der zu lösenden Fragen. Von größter Bedeutung wird es in diesem Zusammenhang sein, dass OPC UA durch eine solche Entwicklung nicht seine eigentlichen Stärken verliert – nämlich die Cloud und das Feld sicher zu verbinden.

Daneben ist TSN mit fast jedem anderen Protokoll nutzbar. Vor kurzem hat zum Beispiel die Profibus-Nutzerorganisation angekündigt, TSN und Profinet zu verbinden. Das ist zukunftsweisend, denn es gibt viele offensichtliche Parallelen zwischen den Mechanismen von TSN und Profinet, besonders in Hinsicht auf Profinet-IRT. Profinet-IRT auf TSN-Hardware würde die Reichweite dieses bereits sehr erfolgreichen Protokolls sicher noch einmal deutlich erweitern. Zudem wäre das Engineering aus Anwendersicht nicht wesentlich anders als heute bei IRT. Somit könnte auf viel vorhandenes Wissen und auf vorhandene Erfahrung zurückgegriffen werden. Der bereits bekannte ‚FIDO5000REM 3-Port Switch‘ von Innovasic, der heute beispielsweise Profinet IRT, Ethercat und OPC UA unterstützt, ist ebenfalls für TSN geeignet und ein entsprechendes Evaluation-Kit steht seit September zur Verfügung.

Wann kommt Gigabit ­Ethernet?

Vergleich des Ethernet-Kabels mit einem Rohr: In Relation zu GigB, 100 Mbit/s und auch zu 10 Mbit/s ist die Datenmenge, die ein Sensor bei 64 Byte alle 1 ms erzeugt, verschwindend klein – der grüne Punkt ist schon fast zu groß gezeichnet!

© Innovasic

Mit Gigabit Ethernet (1000Base-T, GigB) hat die Automatisierungsindus­trie es bisher nicht eilig. Dafür gibt es gute Gründe:

1. Bei den typischen kurzen Nachrichten in der Automatisierung wirken sich die Latenzen der Phy-Schnittstelle (GMII) negativ aus. Diese sind bei GigB und 100Base-T etwa gleich groß. Eine Latenz von typisch 250 ns angenommen, entspricht das drei Zeichen bei 100 Mbit, aber eben 31 Zeichen bei 1 Gbit. Das kann in Applikationen mit sehr vielen kurzen Nachrichten dazu führen, das GigB seine Vorteile nicht recht ausspielen kann. Allerdings werden die Phys immer besser und damit wird dieses Problem tendenziell kleiner.
2. Ein GigB Phy hat eine deutlich größere Leistungsaufnahme als ein 100Base-T Phy. Während ein ‚100-Base-T Phy‘ mit unter 200 mW auskommt, sind es bei GigB eher 500 mW. Durch bessere Phys lässt sich dieses Problem letztlich nicht beseitigen, da die elektrischen Parameter der Norm zu erfüllen sind.
3. Ein erhöhter Verdrahtungsaufwand: 1000Base-T benutzt vier Adern-Paare statt zwei wie bei 100BaseTX.
4. Die Befürchtung, dass mit dem höheren Verkehrsaufkommen ein bereits gelöstes Problem wieder Bedeutung erlangen könnte: das Thema Netzlast. Kann ein Mikrocontroller überhaupt der Belastung durch eine GigB-Schnittstelle standhalten?

Ungeachtet dieser Argumente wird GigB langfristig dennoch eine größere Rolle spielen, insbesondere dort wo Automatisierung und IT das gleiche Kabel nutzen. Denn die Vorteile beim Datendurchsatz sind offensichtlich. Und das ist besonders für datenintensive Anwendungen im Bereich Vision und Überwachung interessant (Monitoring, Kameras, Scanner). Gleichzeitig soll die Einfachheit der Infrastrukturplanung, die bis heute mit den Zwei-Port-Geräten erreicht wurde, nicht aufgeben werden. Deshalb wird der Embedded-2-Port-Switch in Zukunft auch GigB unterstützen müssen.

Nur zwei Drähte?

Eine andere Ethernet-Technologie steht noch ganz am Anfang: 100Base-T1. Mit 100Base-T1 ist eine 100-Mbit-Full-Duplex-Übertragung auf nur einem verdrillten Adernpaar definiert. Diese Norm wurde insbesondere von der Automobilindustrie gefördert. Laut Norm sind damit allerdings nur 15 m mit ungeschirmtem Kabel überbrückbar. Für das Auto ist das sicher ausreichend. Aber auch für viele Anwendungen des Maschinenbaus wäre eine solche Technik interessant, da hiermit kleinere Steckverbinder denkbar wären und sich damit die Miniaturisierung weiter vorantreiben ließe. Übrigens wird gerade hier durch die Embedded-2-Port-Switches ein Nachteil von 100Base-T1 – und zwar die kurzen Leitungslängen – sinnvoll kompensiert.

So könnte in Zukunft eine Steuerungs­architektur aussehen: Alle Sensoren und Aktoren sind direkt durchgängig mit Ethernet an die Steuerung angeschlossen. Das heute übliche Remote-IO könnte die Ausnahme statt die Regel werden.

© Innovasic

Wenn Zwei-Draht-Ethernet auch über längere Strecken funktionieren würde, wäre dies gerade für die Prozessindus­trie interessant. Im Gegensatz zur Automobilindustrie sind die Stückzahlen in der Automatisierung allerdings vergleichsweise klein. Eine spezielle Ethernet-Physik für die Prozessindus­trie könnte daher einen aus Kostensicht nicht optimalen Sonderweg bedeuten. Allerdings gibt es vergleichbare Forderungen auch in anderen Industrien, zum Beispiel der Gebäudeautomatisierung. Ob eine solche Technik (single-twisted pair, mindestens 10 Mbit, 1000 bis 1200 m) also irgendwann kosteneffi­zient zur Verfügung stehen wird, hängt sicher mit davon ab, ob über Industrie­grenzen hinweg genug Nachfrage existiert und sich die Beteiligten auf eine Spezifikation einigen können.

Single Twisted Pair – ob nun 100base-T1 oder eine kommendes 10baseT1 mit 1000 m Reichweite – könnte den Einzug von Ethernet auch in kleine und kostensensitive Sensoren und Aktoren ermöglichen. Der Umweg über HART oder IO-Link mit den bei diesen Techniken unvermeidlichen Gateways wäre dann nicht mehr nötig, was zu einer durchgehenden Kommunikation vom Sensor zur Cloud führen würde – ganz im Sinne von I4.0! Damit wäre Ethernet bis zur äußersten Grenze des Netzes ausgedehnt. Die Systemkosten dürften sich durch die damit erreichbare Durchgängigkeit deutlich senken lassen.

Ethernet to the Edge

Die geschilderten Entwicklungen und Anforderungen haben Innovasic veranlasst, unter dem Motto ‚Ethernet to the Edge‘ eine Initiative zu starten mit der Absicht, die Hardware und Software zur Anschaltung von Ethernet zu entschlacken und gleichzeitig skalierbar zu machen.

Im Rahmen des Projektes ‚FIDO05 LES‘ (Low Complexity Switch) wurde eine sehr schnelle 3-Port Switch-En­gine entwickelt, die gerade für kleine Sensoren und Aktoren ideal ist. Während der Sensor/Aktor selbst nur geringe Datenmengen austauschen muss – typisch 64 Byte bei einem Zyklus von 1 ms –, ist es aber gewünscht, dass der Switch das Weiterleiten von anderem Datenverkehr sehr schnell und transparent durchführt. Aus Sicht des Netzwerkes sollte er eher wie ein langsames Kabel als wie eine tendenziell langsame Infrastruktur-Komponente aussehen.

Innovasic konnte bei LES das sogenannte Bridge-Delay in den Bereich um 1 µs bei 100 Mbit/s drücken. Außerdem ist die Technologie für GigB geeignet und dafür auch schnell genug. Gängige Protokolle wie Profinet RT, Ethernet/IP, ModbusTCP und OPC UA werden von LES unterstützt, inklusive der dazu ­gehörigen Ring-Redundanzprotokolle. Und nicht zuletzt wird die Synchronisation von Uhren nach 802.1AS möglich sein.

Als Host-Schnittstelle kommt SPI zum Einsatz. Für die Anforderungen an einen Sensor/Aktor ist SPI schnell genug und erlaubt es, eine Vielzahl von marktüblichen Mikroprozessoren mit LES zu kombinieren. Die Auswahl des Prozessors wird damit wieder von der Applikation bestimmt – zum Beispiel Anzahl und Qualität der ADC-Kanäle. Einen Ethernet-MAC oder einen Embedded-Switch benötigt der Prozessor nicht mehr.

Weil FIDO05 LES im Vergleich zum vielseitigeren und leistungsfähigeren FIDO5000REM mit einem Bruchteil der Siliziumfläche auskommt, soll er günstig genug werden, um auch preissensitive Sensoren und Aktoren für Ethernet zu erschließen.

Autor:
Volker E. Goller ist Manager Europe, Real-Time Ethernet Solutions, bei Innovasic.