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 2 dieser zweiteiligen Serie stellt dazu die Hardware der R-IN Engine (R-IN: Renesas Industrial Network) von Renesas vor. Teil 1 mit der Beschreibung der Ausgangssituation finden Interessenten in Ausgabe 1-2/2016 der elektro AUTOMATION.
Wie in Teil 1 dieser Serie beschrieben – erschienen in Ausgabe 1-2/2016 der elektro AUTOMATION (S. 20 f.) – haben in Industrie-4.0-Szenarien verschiedene Multiprotokoll-Konzepte ihre Stärken und sind unter bestimmten Bedingungen oder in bestimmten Produktphasen (Prototypen, Erweiterung von Legacy-Produkten…) eine gute Wahl. Ein Blick auf die Details zeigt bei allen Lösungen einen gemeinsamen Nachteil – ihren Preis, besonders bei Großserien! Wie lässt sich dieses Dilemma vermeiden? Betrachten wir einmal eine ideale Lösung, die eine einfache Produkt-Struktur (Abb. 3) im Vergleich zum herkömmlichen Vorgehen erlaubt:
- Als erstes sollte eine Lösung auf einem Single-Chip-Bauteil beruhen, das mehr oder weniger die Charakteristika eines kleinen Kommunikationsmoduls aufweist, und durch eine einzige, gut definierte Hardwareverbindung mit unterschiedlichen Schnittstellen-Optionen angebunden werden kann.
- Die Applikationsverarbeitung ist optional, falls das Bauteil lediglich den Kommunikationsanteil im System liefern soll. In diesem Fall muss das Bauteil eine flexible und äußerst schnelle Schnittstelle zur System-CPU (Host) mit bestimmten Synchronisationsfähigkeiten für Event-Handling und Datenaustausch unterstützen. Für den Support einer breiten Palette an Legacy-Systemen sollten auch andere, langsamere Schnittstellen wie UART und SPI verfügbar sein.
- Mit Blick auf kleine Netzwerkknoten mit geringen bis mittleren Rechenleistungsanforderungen für die Anwendung sollte das ideale Bauteil ein SoC (System on Chip) mit eigener CPU sein, das sowohl das Kommunikationsprotokoll als auch die Anwendung ausführen kann.
- Rechenleistung geht oft einher mit hoher Verlustleistung. Viele Produkte im Automatisierungsbereich reagieren empfindlich in Bezug auf Leistung und Temperatur. Sie arbeiten unter hohen Umgebungstemperaturen, nutzen kleine Gehäuse ohne aktive Kühlung und unterliegen auch noch anderen Einschränkungen. Eine Lösung sollte daher Energiesparfunktionen bieten, um die typischen Beschränkungen bei der Verlustleistung einzuhalten.
- Nicht zuletzt bietet das ideale Single-Chip-Bauteil eine Art ‚kommunikationsspezifische Flexibilität‘ zur Unterstützung eines Multiprotokoll-Betriebs für eine breite Palette an Industrial-Ethernet-Protokollen.
- All dies sollte in einem ASSP-Bauteil verfügbar sein, um von kleinen bis hin zu großen Serien von den Kostenvorteilen profitieren zu können.
Klingt gut – aber gibt es ein solches ideales Bauteil?
Die Renesas R-IN Engine
Entsprechend den Anforderungen der Industrie 4.0 und ‚Multiprotokoll‘-Fähigkeiten hat Renesas die Hardware der R-IN Engine (R-IN: Renesas Industrial Network) entwickelt. Die Architektur dieser Funktion eignet sich perfekt für verschiedene Industrial Ethernet Protokolle und kommt bei Renesas bereits als klar definierter und unabhängiger Block in diversen Produktfamilien zum Einsatz. Die in Abb. 4 gezeigte Architektur der R-IN Engine ist zunächst einmal ein eigenständiges Subsystem mit einer ARM-Cortex-M3-CPU und enthält alle erforderlichen Komponenten eines SoCs: Speicherblöcke für Befehle, Daten und andere Funktionen, einen Interrupt-Controller und das zugehörige Multi-Master-Bussystem als Verbindung zu verschiedenen internen und externen Ressourcen des Bausteins, sowie die nötigen Debugging-Funktionen. Der Multi-Master-Bus ermöglicht parallel ablaufende Datentransfers zwischen unterschiedlichen Bereichen ohne die Notwendigkeit, die interne oder externe Host-CPU zu unterbrechen. Für die Vernetzung sind weitere Ethernet-Kommunikationskomponenten integriert: Ein Gigabit-Ethernet-Switch mit drei Ports – einem internen und zwei externen wie oben beschrieben. Weiterhin enthält die R-IN Engine einen Ethernet-MAC mit zugehörigem DMA-Controller und dem erforderlichen Pufferspeicher, der ausschließlich für Ethernet-Datentransfers verwendet wird. Um ein Protokoll aus der zweiten Gruppe zu implementieren (s. Beschreibung in Teil 1 dieses Beitrags), lässt sich der Datenpfad für die Kommunikation mit entsprechenden Multiplexern vom normalen Ethernet-Pfad (IEEE 802.3 Switch und MAC) auf den IE-Protokoll-Controller der zweiten Gruppe umschalten.
R-IN Hardwarebeschleuniger
Neben diesem rein funktionalen Ansatz zur Unterstützung industrieller Netzwerke enthält die R-IN Engine einige Hardware-Beschleuniger für Funktionen, die heute meist ausschließlich in Software implementiert sind. In Bezug auf die Echtzeit-Anforderungen bei der Verarbeitung von Netzwerkfunktionen ermöglichen diese Beschleuniger an zentralen Punkten der Kommunikation neben dem reinen Geschwindigkeitszuwachs eine deutlich erhöhte Effizienz.
Hardware-RTOS
Der HW-RTOS-Beschleuniger unterstützt primär die Software mit einem automatisierten und prioritätsgesteuerten Task-Scheduling. Darüber hinaus bietet diese spezifische Hardware eine Task-Synchronisierung über Event Flags, Semaphore und Mailboxes sowie eine generelle Task- und Zeitverwaltung. Vor allem aber lassen sich auch bestimmte RTOS-Funktionen über eine Anzahl von Interrupt-Signalen direkt und ohne eine Beteiligung der R-IN CPU ausführen. Dank seiner engen Bindung an die CPU kann der HW-RTOS-Beschleuniger sowohl die Verarbeitung der Stack-Software als auch die eigentliche Anwendung oftmals erheblich beschleunigen.
Wie der Begriff ‚Beschleuniger‘ bereits zum Ausdruck bringt, wird alles innerhalb des HW-RTOS-Funktionsblocks über Hardware mit sehr hoher Geschwindigkeit, auf deterministische Weise und ohne die typischen Verzögerungen und Jitter-Effekte von herkömmlichen Softwarelösungen berechnet. Aus Sicht der Software beruht der Einsatz des HW-RTOS auf einer μItron-Bibliothek mit dokumentierter Anwenderschnittstelle, womit ein reibungsloser Einstieg in das Projekt ermöglicht wird. Der HW-RTOS-Funktionsblock ist für den Benutzer vollständig transparent und erfordert kein detailliertes Wissen über seine Funktionsweise und innere Struktur.
CheckSum
Beim Empfangen oder Versenden eines Frame-Bytes berechnet der CheckSum-Beschleuniger automatisch ‚on-the-Fly‘ die 4-Byte-Prüfsumme, die sich am Ende der Ethernet-Frames befindet. Diese Berechnung erfolgt ohne eine Belastung der R-IN-CPU ausschließlich über den Beschleuniger. In Empfangsrichtung lässt sich die Richtigkeit der Daten in einem einzigen Schritt durch einen Vergleich des berechneten FCS-Wertes (Frame Check Sequence) mit dem Inhalt des FCS-Feldes im empfangenen Frame überprüfen. Eine typische Softwarelösung macht im Vergleich dazu bei der Berechnung des 32-Bit CRC-Wertes fast 30 % der gesamten für die Ethernet-Kommunikation benötigten Rechenleistung aus. Der CheckSum-Beschleuniger ermöglicht also bei großem Ethernet-Datenverkehr eine entsprechend große Einsparung an CPU-Leistung.
Header EnDec
Die Organisation des Frame-Datenpuffers für den Sende- oder Empfangsbetrieb erfolgt normalerweise Byte-bezogen. Ein Lesezugriff auf eine bestimmte Header-Information eines Frames erfordert die Erfassung aller benötigten Bytes im Frame-Pufferspeicher und ihre Neuanordnung in der richtigen Reihenfolge. In Senderichtung muss die Neuanordnung in umgekehrter Richtung in ein komprimiertes Frame-Format überführt werden. Diese Datenverarbeitung erfordert bei einem rein Software-gestützten TCP/IP-Stack in der Regel etwa 15 % der gesamten CPU-Leistung. Aufgabe des Header-EnDec-Beschleunigers ist es, automatisch die Daten zwischen dem komprimierten Frame-Format und dem CPU-orientierten 32-Bit-Format umzuarrangieren. Mit diesem Beschleuniger hat die CPU einen schnellen und direkten Lese- und Schreibzugriff ohne jegliche Latenz auf alle Informationen im Frame-Header.
Buffer Management
Der Beschleuniger für das Buffer-Management steuert automatisch in Hardware die für den Pufferspeicher benötigten Zuweisungs- und Freigabefunktionen bei der Ethernet-Verarbeitung.
R-IN Host Interface
Die grundlegende Struktur der R-IN Engine besitzt auch eine flexible Host-Schnittstelle mit den nötigen Funktionen für Prozesssynchronisierung und einen schnellen, direkten Zugriff auf die Kommunikationsdaten. Bei einer Single-Core-Implementierung lässt sich diese Schnittstelle für einen externen Host nutzen, der die System-Anwendung ausführt. In einer Dual-Core-Implementierung dient sie als chipinterne Schnittstelle zwischen der R-IN Engine (Kommunikation) und der Haupt-CPU des Bausteins (Anwendung). In diesem Sinne ist das Host-Interface des R-IN natürlich kein Beschleuniger, doch ohne die Notwendigkeit einer typischen Chip-to-Chip-Kommunikationsschnittstelle erlaubt sie einen direkten, latenzfreien Zugriff auf die R-IN Engine und deren Ressourcen.
Zusammenfassung: R-IN Engine auf einen Blick
Gegenüber anderen Architekturen ermöglicht die R-IN Engine mit ihren diversen Beschleunigern eine höhere CPU-Leistung und Stabilität bei zugleich niedrigerem Gesamtstromverbrauch. Die spezielle Hardware arbeitet effizienter und bewirkt eine Entlastung der CPU. Dadurch können R-IN-Architekturen entweder die Netzwerkkommunikation bei geringerer Verlustleistung ausführen oder mehr Spielraum für zusätzliche Aufgaben geben (Abb. 5). Ein Baustein kann gleichzeitig nicht nur die Netzwerk-Kommunikation, sondern auch komplexe Anwendungen mit extrem geringen Verzögerungen und niedrigem Jitter bei minimalem Stromverbrauch ausführen. Aufgrund der Netzwerkfunktionen und ihrer grundlegenden Struktur deckt die R-IN Engine beides ab – alle Protokolle der ersten Gruppe, die übliche IEEE-8.2.3-Hardware verwenden, sowie ein Protokoll aus der zweiten Gruppe unter Nutzung eines speziellen Kommunikations-Controllers. So lässt sich mit Hilfe des flexiblen und kostengünstigen R-IN-Single-Device-Ansatzes ein ‚Multiprotokoll‘-Produkt für die Industrieautomatisierung einfach implementieren.
Die für industrielle Netzwerke entwickelte R-IN Engine wurde bereits erfolgreich in den R-IN32M3- und RZ/T1-Bausteinfamilien integriert. Während der R-IN32M3 eine Single-Core-Lösung mit Unterstützung für die Protokolle Ethercat und CC-Link IE ist, verfügt die RZ/T1-Familie über eine Dual-Core-Architektur. Prinzipiell besitzt sie zwei separate CPUs für die Kommunikation (ARM Cortex-M3 innerhalb der R-IN Engine) und für die Anwendung (ARM Cortex-R4). Die RZ/T1-Bausteine sind in einer Reihe von Derivaten für unterschiedliche Produkttypen erhältlich. Weitere Produkte auf Basis der R-IN Engine sind bereits in Arbeit oder Planung. Ein weiterer wichtiger Vorteil für die R-IN-Softwareentwicklung ist die relativ einfache Protokoll-Portierung auf der Basis der wiederverwendeten R-IN Engine in verschiedenen Baustein-Familien. Dies gilt vor allem für alle Protokolle der ersten Gruppe, die prinzipiell auf identischer Ethernet-Standard-Hardware laufen.
Ein Blick auf den Baustein R-IN32M3-EC (EC: enthält einen Ethercat-Slave-Controller, s. Abb. 6) zeigt als Beispiel, dass die Grundstruktur direkt einer idealen Lösung entspricht, wie sie weiter oben in Abb. 3 zu sehen ist. Darüber hinaus enthält der Baustein die 100-Mbit/s-Ethernet-PHYs und benötigt nur wenige externe Komponenten für die Ausführung der Anwendung und des Protokolls auf einem einzigen Baustein. Damit empfiehlt er sich und alle anderen R-IN-Engine-basierten Bausteine auch für den Einsatz in vielen kleinen industriellen Ethernet-Produkten und eignet sich damit auch bestens für die Industrie 4.0. 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 1/2 dieses Beitrags findet sich in elektro AUTOMATION 1-2/2016; Infos zu den genannten R-IN Bausteinen hier:
www.renesas.eu/r-in
Teilen:
