A&D:
Welche Anwendungen adressieren die neuen Multiprotokoll-Chips RZ/N1?
Basarovski:
Mit der erweiterten Prozessor- und Netzwerkleistung der RZ/N1 Produktlinie haben wir unser Portfolio an Industrial-Communication-Chips ergänzt. Nun bieten wir einen Multiprotokoll-Kommunikations-Baustein auch für performantere Anwendungen des Automatisierungsnetzwerks an. Das heißt, ein Chip, der ausreichend Leistung bietet, damit man PLCs oder HMI-Lösungen abbilden kann, mit uneingeschränkter Unterstützung für industrielle Netzwerke. Wir haben vor rund vier Jahren den R-IN32M3 als Multiprotokoll-Chip vorgestellt, der primär für Endpunktanwendungen auf der Feldebene geeignet ist. Er unterstützt ein breites Spektrum von industriellen Ethernet-Protokollen. Auf Basis dieses R-IN32M3 gibt es seit zwei Jahren den RZ/T1, der insbesondere für Motion Control geeignet ist. Alle drei Produktfamilien basieren dabei auf der R-IN Kommunikations-Engine. Die Akzeptanz im Markt hat bewiesen, dass die R-IN Engine eine zukunftssichere Lösung ist.
Schwope:
Es zählen zwei Aspekte. Wir erweiterten die Performance und haben als wichtigeren Teil einen zusätzlichen Funktionsbereich erschlossen. Vorher war es eben der Industrial-Ethernet-Controller R-IN32M3, der im Wesentlichen für Slave-Applikationen sinnvoll ist, während jetzt beim RZ/N1 durch mehr Performance und auch funktionale Erweiterungen über die Switches oder das Display-Interface andere Applikationsbereiche möglich sind. Und die Performance geht einher mit der internen Struktur, also Multi-Core sowie anderen Arten von Schnittstellen, so dass anspruchsvollere Anwendungen wie PLC, HMI oder industrielle Switches entwickelt werden können, die mit zwei Ports nicht auskommen.
War das ein von Renesas initiierter Schritt in die Zukunft, eine logische Weiterentwicklung Ihrer Roadmap oder erfüllten Sie Kundenwünsche?
Basarovski:
Sowohl als auch. Die RZ/N1 Spezifikation ist eng mit Renesas Kunden abgestimmt und gleichzeitig eine logische Erweiterung. Mit der RZ/N1 Familie haben wir einen auf der R-IN Engine basierten Kommunikationsblock und einen Applikationsblock gemeinsam auf einem Chip integriert. Die Blöcke sind über eine transparente Kommunikations-API verbunden. Je nach Ausführung befinden sich auf der Applikationsseite eine oder zwei Cortex-A7 CPUs, mit reichlich Performance etwa für Micro/Nano-PLC-Applikationen. Zudem ist mit dem RZ/N1 und der neuen Softwareplattform der Wechsel zwischen verschiedenen Kommunikationsprotokollen recht einfach geworden.
Können also auch Kunden ohne tiefgreifende Kenntnisse der Protokolle den RZ/N1 einsetzen?
Schwope:
Das ist definitiv ein Gesichtspunkt, der hier eine Rolle spielt. Renesas liefert neben der RZ/N1 Hardware bereits vorintegrierte und vorzertifizierte Protokoll-Stacks, die auf der R-IN Engine laufen und über eine einheitliche Software-Schnittstelle an die Applikation angebunden werden. Die unterschiedlichen Stacks bestehen häufig aus vergleichbaren Funktionen und Parametern. Die Applikation hat daher eine gewisse Abhängigkeit zu den Stacks. Jedoch wird die Anbindung unterschiedlicher Stacks an die Applikation unserer Kunden durch die einheitliche Schnittstelle zur R-IN Engine deutlich vereinfacht.
Die R-IN Engine übernimmt also die gesamte Kommunikation im Produkt?
Schwope:
Ja, und zwar bereits im R-IN32M3. Die R-IN Engine besteht aus einem CPU-System mit internem Speicher, einem Industrial-Switch und bestimmten Hardware-Beschleunigern, die die Echtzeit-Performance erhöhen. Diese sorgen neben der Geschwindigkeitssteigerung dafür, dass einerseits die CPU entlastet, andererseits die Verlustleistung des Systems verringert wird. Antworten auf Events oder Interrupts geschehen einfach schneller und vor allem mit deutlich weniger Jitter. Das heißt, die Varianz einer Antwortzeit ist extrem gering. Dieses ist vor allem für isochrone Echtzeit-Netzwerke von enormer Wichtigkeit, weil alle Teilnehmer darin zeitidentisch agieren müssen. Die R-IN Engine ist also der Basisblock für isochrone Kommunikation innerhalb eines Systems und ist bisher im R-IN32M3 und RZ/T1 sowie jetzt auch im RZ/N1 enthalten.
Die R-IN Engine ist aber nicht alles…
Schwope:
Genau. Daneben ist der RZ/N1 auf der Applikationsseite mit einer oder zwei Cortex A7-CPUs für z. B. Managed-Switch-Applikationen und Gateways ausgestattet. Die Betriebssysteme Linux bzw. VxWorks agieren hier unabhängig von der R-IN Engine und können über einen dedizierten Kommunikationskanal Informationen mit ihr austauschen.
Basarovski:
Eine der Besonderheiten liegt in der Ausgestaltung der API zur Anwendungssoftware. Über diese ‚Unified Communication API’ können Kommunikationsprotokolle, welche unter dieser API implementiert worden sind, ohne große Änderung in der Anwendungssoftware ausgetauscht werden. Auch eine einfache Migration zwischen Renesas Kommunikations-Bausteinen ist mit geringem Aufwand möglich. Das vereinfacht den Entwicklungsprozess und senkt die Kosten.
War eine Single-Chip-Lösung Ausgangspunkt Ihrer Überlegungen?
Schwope:
Das ist ein allgemeiner Trend, doch in unserem Falle macht er besonders Sinn, weil wir es mit Echtzeit zu tun haben. Je enger die Bereiche Applikation und Kommunikation in einer gemeinsamen Hardware- und Software-Architektur zusammenhängen und miteinander agieren, desto einfacher ist es, eine extreme Echtzeit-Performance auch hinzukriegen. Echtzeit heißt ja nur ‚Antwortgarantie innerhalb eines definierten Zeitraums’, der auch rein theoretisch eine Stunde betragen könnte. Doch hier reden wir über Hochgeschwindigkeit, beispielsweise in Motorsteuerungsapplikationen. In diesen können sich Achsen mit mehr als 1000 U/min drehen, deren Positionen 100-mal oder mehr pro Sekunde abgescannt und mit einem Sollwert verglichen werden, und aus deren Abweichung dann eine Korrektur errechnet werden muss. Und das bei Netzwerken in großen Maschinen, deren Ausdehnung zuweilen Hunderte von Metern betragen kann. Dennoch ist die Echtzeit nur ein Aspekt. Ebenso wichtig sind, neben den Kosten, die hohe Performance und die geringe Verlustleistung des RZ/N1.
Spricht nicht auch eine erhöhte Sicherheit für die Single-Chip-Lösung?
Schwope:
Stimmt. In Ein-Chip-Lösungen lassen sich die Datenprozesse komplett integrieren, während Boards und Busse vom Security-Aspekt her im Prinzip offen sind und daher nicht überall sicher sein können. So lässt sich beispielsweise auf einem Board ein Logikanalysator zwischenschalten, mit dem das Mitlesen und die Analyse der Prozesse einfach wird.
Wie weit sind Sie mit dem RZ/N1?
Basarovski:
Lead-Kunden erhielten Evaluation-Boards, und Rückmeldungen zeigen, dass diese mit der exzellenten Verbindung von Hardware und Software sehr zufrieden sind. Geliefert wird unser Produkt ab März. Weil die Technologie ausgereift ist, ist die Zahl der Überraschungen deutlich gesunken, obwohl die RZ/N1 Familie von der Architektur her deutlich komplexer ist als vor drei Jahren der R-IN32M3.
