Startseite » Industrial Ethernet »

Teil1: R-IN-Multiprotokoll-Controller für die Industrie 4.0

R-IN Multiprotokoll-Controller für die Industrie 4.0 – Teil 1/2
Hochgeschwindigkeits-Kommunikation (1/2)

Industrie 4.0 beruht auf cyber-physikalischen Systemen, die Technologien wie die Internetkommunikation mit einem automatisierten, über Sensor-Netzwerke gesteuerten Betrieb unter Echtzeit-Bedingungen kombinieren. Dazu müssen die verschiedenen Systemkomponenten über ein sicheres Hochgeschwindigkeits-Netzwerk miteinander verbunden sein, das einen deterministischen und schnellen Datenaustausch gewährleistet. Teil 1 dieser zweiteiligen Serie beleuchtet zunächst die Ausgangssituation, bevor in Teil 2 in der kommenden Ausgabe 3/2016 der elektro AUTOMATION dazu die Hardware der R-IN Engine (R-IN: Renesas Industrial Network) von Renesas vorgestellt wird.

Eine häufige Anforderung in der Industrie-4.0-Produktion (s. Abb. 1) ist die Echtzeit-Verarbeitung mit extrem kurzen Zykluszeiten. Neben der notwendigen reinen Geschwindigkeit müssen weitere, sogar noch zeitkritischere Parameter unter allen Umständen erfüllt werden. Die wichtigsten von ihnen sind ein geringer Jitter (kleine Abweichungen im System bedingt durch wiederkehrende, nicht konstante Verzögerungen) und isochrones Verhalten (identische Zeitbasis für synchronisierte Prozesse an allen Netzwerkknoten). Vor allem diese extreme Echtzeit-Fähigkeit dedizierter Systemkomponenten erfordert besondere Hardwarefunktionen an bestimmten Punkten innerhalb der Kommunikationsschichten. Dies ermöglicht einen schnellen und reibungslosen Datenaustausch unter allen für die Industrie 4.0 anzunehmenden Systemzuständen.

Ist die Kommunikation immer dieselbe?
Betrachtet man die verschiedenen, in der Automatisierung angewendeten Standards, ist die Antwort ziemlich einfach: Leider nicht – es gibt unterschiedliche Arten der Kommunikation im Bereich der industriellen Vernetzung. In der Vergangenheit wurden viele Kommunikationsprotokolle entwickelt, die fast alle auf dem gleichen Ethernet-Standard IEEE 802.3 beruhen. Aufgrund unterschiedlicher Firmeninteressen, Strategien und weltweit differierender Verteilung sind nur die unteren zwei Schichten des OSI-Modells zwischen den verschiedenen IE-Standards (Industrial Ethernet) kompatibel. So sind die physikalische Schicht des IEEE-802.3-Ethernets und das allgemeine Frame-Format über alle verschiedenen Standards hinweg die gleichen. Einige Beispiele für etablierte industrielle Netzwerkprotokolle sind Ethercat, Profinet, Ethernet/IP, CC-Link IE, Modbus TCP, Sercos III und Powerlink.
Ausgehend von einem vereinfachten Modell lassen sich alle diese Kommunikationstechnologien in zwei Gruppen aufteilen. Zur ersten Gruppe zählen die Protokolle, die auf einer Standard-IEEE-802.3-Hardware laufen, die praktisch in jedem PC auf der Welt zu finden ist. In den meisten Implementierungen besteht diese Kommunikationsschnittstelle aus einem Ethernet-MAC und einem Ethernet-Switch mit einem internen und zwei externen Ports. Über die zwei externen Ports lassen sich sichere Ring-Strukturen realisieren, mit dem einen internen Port werden sowohl Daten eingespeist als auch zur lokalen Ausführung extrahiert.
Die protokollspezifischen Funktionen dieser ersten Gruppe sind nur in den oberen Kommunikationsschichten in Software implementiert. Zu dieser Gruppe zählen Profinet, Profinet RT (Real-Time), Ethernet/IP und Modbus TCP. Genauer gesagt, beruhen die meisten dieser Protokolle sogar auf den gleichen TCP/IP- und UDP/IP-Software-Stacks, die auf der IEEE-802.3-Standard-Hardware laufen. Andere, wie Profinet RT, nutzen einen modifizierten Stack mit geringeren Verarbeitungsverzögerungen, was ihre Geschwindigkeit und Echtzeit-Fähigkeit optimiert.
Die unteren Kommunikationsschichten der zweiten IE-Protokollgruppe benötigen bestimmte, nicht standardisierte und manchmal nur in einem einzigen Standard vorhandene Funktionen. Diese werden unter anderem zur Echtzeitverwaltung einschließlich Netzwerksynchronisierung genutzt und steuern automatisch die Extraktion und das Einfügen von Ethernet-Framedaten. Da dieser Vorgang in hoher Geschwindigkeit unter Echtzeit-Bedingungen abläuft, weichen diese Protokolle vom Ethernet-Standard ab und lassen sich nur in Hardware über einen Protokoll-Controller implementieren. Die Port-Struktur solcher Controller, die in Protokollen wie Profinet IRT (Isochronous Real Time), Ethercat, Sercos III und CC-Link IE genutzt wird, ist prinzipiell die gleiche wie für die erste Gruppe oben. Abb. 2 stellt für die beiden Gruppen die Protokoll-Hardware bzw. Software-Layer für einige der oben erwähnten Industrial-Ethernet-Standards einander gegenüber.
Wer als Hersteller alle diese verschiedenen Protokolle berücksichtigen will, muss vor allem diese Kommunikationstypen mit allen Netzwerk-Produkten abdecken können. Neben funktionalen Aspekten sind dabei auch kommerzielle Gesichtspunkte von Bedeutung, um auf dem Automatisierungsmarkt erfolgreich zu sein. Unter Berücksichtigung von Kostenparametern wie Einfachheit des Systems, Time-to-Market, Support oder Wartung sollte eine Produktumstellung von einem Protokoll auf das andere bei identischer Produkt-Hardware möglich sein. In diesem Kontext spricht man auch von „Multiprotokoll-Bausteinen“. Diese lassen sich einfach durch den Austausch der Software ohne jegliche Hardware-Modifikation an ein bestimmtes Protokoll anpassen.
Die Multiprotokoll-Unterstützung eines Industrieautomatisierungs-Produkts ist über verschiedene Strategien realisierbar. Hersteller haben zur Ausführung mehrerer Protokolle unterschiedliche Lösungen entwickelt, die im Folgenden allgemein beschrieben werden, wobei auch eine Kombination möglich ist. Sie alle haben ihre Vor- und Nachteile. Der Fokus einer Ideallösung kann sich auch durchaus ändern, vor allem dann, wenn man unterschiedliche Produkt-Phasen und deren Stückzahlen über den Lebenszyklus eines Produktes zur Bewertung heranzieht.
    • Architekturen auf FPGA-Basis:FPGAs sind äußerst flexible Bauteile, die eine Veränderung der Hardwarefunktion beim gleichen Baustein erlauben. Dies gilt für unterschiedliche Situationen bei der Veränderung der Funktion als solcher (Änderung der Spezifikation), bei der Modifizierung eines bestimmten Teils davon (kundenspezifische Anpassung oder Optimierung) oder bei der Hardware-Fehlerbehebung (Bug Fix). FPGAs sind auch eine gute Wahl, wenn gewisse Systemkomponenten in einen Baustein integriert werden sollen, um Platz auf der Leiterplatte zu sparen oder die PCB-Komplexität zu verringern. Manchmal besitzen Boards einzelne logische Gatter oder eine andere niedrig-komplexe Logik (sogenannte Glue Logic), die sich vollständig in den FPGA integrieren lassen. FPGAs sind außerdem flexibel, wenn das Komplexitätsniveau einer implementierten Funktion geändert werden muss. Pin-kompatible FPGAs ermöglichen die Auswahl der richtigen Anzahl nutzbarer Gates. Mit einem „größeren“ FPGA lässt sich beim Austausch eines „kleineren“ FPGAs eine komplexere Funktion implementieren. In umgekehrter Richtung können durch Optimierung die Hardwarekosten gesenkt werden, wenn sich z. B. die neue, weniger komplexe Funktion in einem kleineren FPGA realisieren lässt. Dennoch: Aufgrund ihrer hohen Kosten kommen FPGAs hauptsächlich in der Prototypen-Phase eines Produktes weit weg vor jeglicher Kostenoptimierung zum Einsatz.
    • Anwendungsspezifische Bausteine:Anwendungsspezifische Bausteine oder ASSPs (Application Specific Standard Products) sind normalerweise hochintegriert und enthalten einige oder mehrere dedizierte Funktionen, die eine bestimmte Anwendung erfordert. Anders als ein ASIC (Application Specific IC) lassen sich ASSPs für eine breitere Produktpalette in dem spezialisierten Marktsegment einsetzen. Trotz allem haben ASSPs oft einen wichtigen kommerziellen Fokus. Sie müssen so billig wie möglich sein, wobei ihr Preis mit größer werdender Flexibilität oder Funktionserweiterung steigt. Durch ihren Fokus auf eine spezifische Funktion und die dazu erforderliche Logik bieten ASSPs prinzipiell keine große Flexibilität. Nutzt ein herkömmliches Leiterplattendesign ausschließlich solche Bauteile, entstehen dabei komplexe Boards, die viele unterschiedliche Bauteile integrieren müssen. Dies hat somit unmittelbar einen großen Arbeitsaufwand für Entwicklung, Test und Zertifizierung sowie nicht zuletzt auch für System-Support und -Wartung während der Produktlebenszeit zur Folge. Demgegenüber bieten ASICs mit ihrem spezifischen Funktionssatz die ideale Lösung für ein bestimmtes Bauteil. Per Definition entwickeln und spezifizieren Unternehmen ASICs ausschließlich für ihre eigenen Produkte, weshalb die Bauteile normalerweise nicht an andere Unternehmen weiterverkauft werden. Aktuell nimmt die Entwicklung von ASICs viel Zeit in Anspruch und ist extrem teuer. Aus diesem Grund sind diese Bauteile nur für sehr hohe Stückzahlen die richtige Wahl.
    • Kommunikationsmodule:Ein anderer Weg für eine Multiprotokoll-Lösung ist die Kombination aus den beiden oben beschriebenen Konzepten. Bei Automatisierungsprodukten kann ein Modul-basierter Ansatz den Austausch von relativ kleinen Kommunikationsmodulen vorsehen, wenn ein anderes Protokoll benötigt wird. Die Nutzung kleiner Module von externen Anbietern zur Änderung des Systemprotokolls folgt der Idee einer nicht-modifizierten Hardware nur teilweise: Das komplexere Hauptsystem bleibt unverändert, während nur das weniger komplexe Modul ausgetauscht wird. Dies ist ein guter Ansatz für Prototypen und Produkte mit geringer Stückzahlfertigung. Dies gilt jedoch auch für Legacy-Produkte, die nicht verändert werden sollen, denn das Modulkonzept erlaubt problemlos die Anpassung eines bestehenden Systems an ein neues Kommunikationsprotokoll. Ein weiterer Vorteil des Modulkonzepts ist die vollständige Trennung der Anwendungsseite von der Kommunikationshardware und -software. Da Kommunikationsmodule vergleichsweise teuer sind, haben sie deutliche kommerzielle Nachteile. Weiterhin erfordert ihre mechanische Integration in ein System manchmal mehr Platz und Volumen (Fläche x Höhe des Moduls plus zugehörige Steckverbinder) als zur Verfügung steht. Dies ist oft das entscheidende Argument gegen Module für ein kleines Produkt in einem engen oder flachen Gehäuse. co

Der Autor:Andreas Schwope, Renesas Electronics Europe GmbH, Smart Factory Industrial & Communications Business Group

Kontakt

info

Renesas Electronics Europe GmbH
Düsseldorf
Tel. +49 211 6503-0
www.renesas.eu
Teil 2/2 dieses Beitrags folgt in elektro AUTOMATION 3/2016; Infos zu den genannten R-IN Bausteinen finden sich hier:
www.renesas.eu/r-in
Newsletter

Abonnieren Sie unseren Newsletter

Jetzt unseren Newsletter abonnieren

Webinare & Webcasts

Technisches Wissen aus erster Hand

Whitepaper

Hier finden Sie aktuelle Whitepaper

Videos

Hier finden Sie alle aktuellen Videos


Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de