Von Profibus auf Profinet umsteigen In null Komma nichts auf Profinet IRT migrieren

Autor / Redakteur: Andreas Schwope* / Dipl. -Ing. Ines Stotz

Heute erwartet die Fertigungsindustrie von vielen Automatisierern den Umstieg vom herkömmlichen Feldbus auf einen Ethernet-basierten Standard, etwa von Profibus auf Profinet. Keine einfache Aufgabe. Eine sorgfältige Untersuchung der Implementierungsalternativen ist hilfreich. Welches Konzept das richtige ist? Es kommt drauf an.

Firmen zum Thema

Damit die Umstellung von Profibus auf Profinet nicht zum Problem wird, sollte beim Umstieg Einiges beachtet werden.
Damit die Umstellung von Profibus auf Profinet nicht zum Problem wird, sollte beim Umstieg Einiges beachtet werden.
(Bild: gemeinfrei / CC0 )

Gegenüber den extrem kurzen Zyklen in der Unterhaltungselektronik ist Industrieautomatisierung bekannt für ihre relativ komfortable Innovationsgeschwindigkeit. Dies hängt mit den enormen Werten zusammen, die hinter Produktionsanlagen stehen, und aus dem großen finanziellen Schaden, der bei einer verfrüht in die Fertigungslinie eingeführten Innovation entstehen kann. Trotz dieser prinzipiell konservativen Denkweise gibt es in der Industrieautomatisierung jedoch Trends zum Beispiel zur Vereinheitlichung der physischen Kommunikationsinfrastruktur vom Schreibtisch des Vorstandsvorsitzenden bis zum Sensor in der Fertigungslinie. Das gängige Medium für solche Kommunikationsaufgaben ist Ethernet. Damit einhergehend entstanden neben den bestehenden Feldbussen jüngere und attraktivere Derivate auf Ethernet-Basis. Heute erwarten die Kunden von vielen Automatisierungsausrüstungsherstellern den Umstieg vom herkömmlichen Feldbus auf einen Ethernet-basierten Standard. Weil diese Unternehmen in der Regel aber nur Experten für ihre spezielle Anwendung, nicht aber so sehr für den Feldbus sind, ist dies keine einfache Aufgabe. Damit kann die Umstellung von Profibus auf Profinet - die entsprechende Technologie auf Ethernet-Basis - zum Problem werden, wenn der Umstieg nicht richtig erfolgt. Eine sorgfältige Untersuchung der Implementierungsalternativen ist hilfreich, um die im Hinblick auf die technischen, kommerziellen und terminbezogenen Anforderungen bzw. Möglichkeiten für den Anwender am besten passenden auszuwählen.

Profinet ist kein monolithischer Standard, eher Welt umspannend und versucht, fast jede mögliche Anforderung eines Industrieautomatisierungssystems abzudecken. Die grundlegende Dokumentation alleine umfasst mehr als 1300 Seiten, Tendenz steigend. Wie bei anderen Standards sind sie auf Vollständigkeit ausgelegt und nicht auf einfache Lesbarkeit. Streng vereinfacht lassen sich Profinet-Geräte einteilen in

Bildergalerie
  • drei Konformitätsklassen (CC-A, CC-B und CC-C), und
  • zwei Echtzeit-Klassen (RT und IRT).

Die Konformitätsklassen beschreiben die Dienste, die in einem Profinet-Gerät implementiert sind. Sie beeinflussen vor allem die Komplexität der Profinet-Stack-Software. Die Echtzeit-Klassen allerdings haben einen direkten Einfluss auf die möglichen Hardware-Optionen. Sie sind rückwärts-kompatibel: Ein CC-C-konformes Profinet-Gerät erfüllt auch CC-B, und ein IRT-fähiges Profinet-Gerät unterstützt ebenfalls RT. Wenn also ein Kunde einen Entwickler um die Implementierung von CC-C und IRT bittet, ist die Entscheidung einfach. Was allerdings, wenn der Kunde zufrieden ist mit CC-B und RT? Sollte man dann nur genau dies implementieren, oder nach dem Optimum streben, und sicherstellen, dass das Profinet-Gerät die Anforderungen aller Profinet-Netzwerke erfüllen kann? Diese Frage lässt sich weder mit einem einfachen „Ja“, noch mit einem „Nein“ beantworten.

Eine IRT-fähige Lösung anstreben

Profinet IRT wurde ursprünglich definiert, um die Anforderungen einer synchronisierten Steuerung von vielen dezentralen Geräten (Antrieben, Sensoren, Aktoren etc.) zu erfüllen, wie sie typisch in komplexen, schnelllaufenden Anlagen zum Einsatz kommen. Eine genaue Planung der Kommunikation zusammen mit einer präzisen Zeitsynchronisierung über die verschiedenen Geräte im Netzwerk ermöglicht eine Steuerung der Geräte zeitgenau bis in den Mikrosekundenbereich.

Ein Nebeneffekt ist, dass immer eine garantierte Bandbreite für die Kommunikation mit einem Profinet IRT-Gerät verfügbar ist – selbst unter Worst-Case Netzlast-Bedingungen. Aus Expertensicht ist dies ein großer Vorteil in sicherheitsrelevanten Anwendungen. Was dazu führt, dass IRT auch in Profinet-Anwendungen genutzt wird, die diese Synchronisierungs- und Echtzeit-Fähigkeiten nicht wirklich benötigen. Darüber hinaus ist zu berücksichtigen, dass Profinet-Geräte, die für sich gesehen nicht wirklich IRT benötigen, in der Lage sein müssen, IRT zu unterstützen, wenn sie in einer IRT-Umgebung zum Einsatz kommen. Es spricht also einiges dafür, eine IRT-fähige Lösung anzustreben, selbst wenn keine unmittelbare Notwendigkeit dafür besteht. Aber welchen Preis muss man dafür zahlen?

Was kostet IRT?

Der Preis, der für IRT zu zahlen ist, setzt sich aus zwei Komponenten zusammen:

  • Eine unmittelbar kommerzielle Komponente, denn ein Chip für Profinet IRT ist teurer als einer für Profinet RT, und die Lizenzgebühren für einen IRT-fähigen Stack können höher sein als die für einen RT-fähigen Stack.
  • Eine mittelbar kommerzielle Komponente, da IRT die Entwicklung schwieriger macht, die Markteinführungszeit verlängert und die Zertifizierung des Endproduktes komplexer machten könnte.

Der erste Punkt ist offen gesagt unvermeidlich, doch die zweite Komponente lässt sich auf Null reduzieren, wenn man die richtigen Entscheidungen trifft.

Alternativen für die Implementierung

Bei der Implementierung von RT- oder IRT-Profinet-Fähigkeit in ein Produkt gibt es verschiedene Möglichkeiten. Die Fertigungsmenge bestimmt, welche am attraktivsten ist.

  • Bei der Nutzung von Modulen muss der Anwender keine eigene Profinet-Hardware entwickeln. Es muss lediglich eine generische Schnittstelle, Platz und Geld bereitgestellt werden. Wegen der erforderlichen Verbindungen sind Module in der Regel weniger kompakt als eine Lösung, die man bereits in sein System integriert hat. Natürlich gibt es eine Lösung mit nur minimalem Hardware-Designrisiko von Modulherstellern nicht umsonst. Bei Stückzahlen im Bereich von n x 10 Systemen könnte dies ein faires Angebot sein.
  • Eine FPGA-gestützte Implementierung eröffnet dem Anwender viele Optionen in Bezug auf die Integrationsszenarien. Falls gewünscht, kann ein FPGA ausschließlich die Profinet-Funktionen enthalten, es kann aber auch eine Applikations-CPU umfassen, sofern es akzeptabel ist, eine der CPUs zu nutzen, die sich in einem FPGA synthetisieren lassen. Je mehr in das FPGA gepackt wird, umso höher ist das Design-Risiko. Auch ist zu bedenken, dass man für eine gute Lösung mehr tun muss, als nur einfach ein paar Buttons im FPGA-Designwerkzeug zu drücken. Außerdem haben alle FPGA-gestützten Lösungen eines gemeinsam: Man benötigt externe PHYs zum Anschluss an das Profinet-Netzwerk.
  • Viele Standard-Mikrocontroller kommen mit einer oder womöglich zwei auf dem Chip integrierten Ethernet-Schnittstellen, was sie zu Kandidaten für eine Low-Cost Profinet-Implementierung machen könnte. Vom Preis her sind Standard-Mikrocontroller schwer zu schlagen, gehen aber auch mit bedeutenden Funktionseinschränkungen einher. Bausteine mit einer einzigen Ethernet-Schnittstelle lassen sich nicht in der typischen Linien-Struktur einsetzen. Zudem sind sie auf den Einsatz in Steuerschränken mit einer einzigen Port-Verbindung zu einem Switch beschränkt. Selbst Standard-Mikrocontroller mit zwei Ethernet-Ports sind nicht ideal, da ihnen meist eine für eine solide Profinet-Implementierung nötige Switch-Funktion fehlt.
  • Ein ASSP (Application Specific Standard Product) gilt häufig als attraktiver Kompromiss. Einerseits ist es für Profinet konzipiert, und nicht nur einfach etwas, was man „auch“ für Profinet nutzen kann. Andererseits ist es ein Standard-Produkt und als solches bedienerfreundlich und einfach zu verarbeiten sowie mit Standard-Unterstützung vom Halbleiterhersteller erhältlich. ASSPs können problemlos Stückzahlen im Bereich von n x 10 bis zu n x 10000 Systemen unterstützen.
  • Der Vollständigkeit halber soll auch das zu 100 Prozent an Benutzeranforderungen anpassbare eigene ASIC erwähnt werden. Allerdings ist diese Lösung aufgrund der enorm hohen Investitionen und des tiefgreifenden System-Know-hows für dieses Konzept nur für sehr wenige große Profinet-Anbieter eine praktikable Lösung.

Bei diesem an der Hardware orientierten Vergleich der unterschiedlichen Implementierungs-Alternativen sollte man allerdings nicht vergessen, dass alle Alternativen eine Profinet-Stack-Software benötigen. Eine solche Software möchte der Anwender wohl kaum selbst entwickeln, außer er verfügt über unbegrenzte personelle Ressourcen und beliebigen Spielraum, was die Markteinführungszeit betrifft. Der Aufwand für Entwicklung und Test einer solchen Stack-Software kann Mannjahre betragen. Logischerweise gibt es daher auf dem Markt einige Profinet-Stack-Software-Implementierungen, die im Zusammenhang mit der darunterliegenden Hardwareplattform betrachtet werden können bzw. müssen. Manche Anpassungen sind möglich und/oder erforderlich, manche auch nicht. Jedenfalls kosten solche Anpassungen Zeit und Geld.

ASSP-Alternativen

An diesem Punkt dürfte das ASSP ein attraktiver Weg sein, um ein bestehendes Industrieautomatisierungs- oder Kommunikationssystem um Profinet zu erweitern. Es sind jedoch noch immer einige weitere Entscheidungen zu fällen: Bei den speziellen ASSPs für Profinet gibt es zwei wichtige Bausteine:

  • Den Ertec (Enhanced Real-Time Ethernet Controller) und
  • den TPS-1 (Tiger Profinet Single-Chip).

Da beide Bausteine aus der Entwicklung und Fertigung von Renesas Electronics stammen, geht es hier weniger um eine Anbieter-, sondern eher um eine Konzeptentscheidung. Beide Bausteine unterstützen die neueste Profinet-IRT-Version mit vorzertifizierten Stacks. Sie bieten dem Anwender damit ein Höchstmaß an Sicherheit für die unvermeidlichen Zertifizierungstests, die das System vor einem Markteintritt durchlaufen muss. Die Profinet-Stacks wurden von den führenden Profinet-Unterstützern und -Anbietern Siemens und Phoenix Contact Software entwickelt. Sie durchlaufen umfassende Compliance- und Interoperabilitätstests, um zu gewährleisten, dass die Profinet-Produkte beim Anwender im Feld korrekt arbeiten.

Beide Bausteine – Ertec wie auch TPS-1 – bieten gegenüber FPGAs und Standard-Mikrocontrollern den Vorteil integrierter PHYs. Ebenfalls erwähnenswert ist, dass in beiden Renesas-PHYs speziell für Industrial-Ethernet-Anwendungen enthalten sind. Außerdem sind beide bekannt für außerordentliche Qualität, Robustheit und ESD-Ratings.

Der grundlegende Unterschied zwischen Ertec und TPS-1 besteht darin, dass man den TPS-1 meist im Zusammenspiel mit einer Host-CPU einsetzt, während der Ertec für einen Betrieb ohne CPU konzipiert ist. Damit scheint die Entscheidung für den Ertec einfach, weil kein Host benötigt wird, aber dieser konzeptionelle Unterschied verdient eine eingehendere Diskussion.

Ertec für erfahrene Softwareentwickler

Von der Software her betrachtet kommt der Ertec mit einem Profinet-Stack, einem Echtzeit-Betriebssystem und einer Muster-Applikation. Das Anwendungsprogramm des Kunden muss auf dem gleichen Baustein und auf dem gleichen Core unter dem gleichen Betriebssystem arbeiten. Die Interaktion des Stacks mit einer Kundenanwendung wird über eine Funktionsbibliothek und zwei Muster-Applikationen unterstützt. Beide bilden eine Art Framework für die Kundenanwendung. Ein erfahrener Softwareentwickler muss vor der Aufgabe, die Kundenanwendung in dieses Framework zu integrieren, keine Angst haben. Allerdings gibt es das immanente Risiko, das RTOS und den Profinet-Stack durcheinanderzubringen, da beide (zumindest teilweise) die gleiche Hardware nutzen und letztendlich ein gemeinsames Software-Projekt bilden. Dies ist für Benutzer mit begrenzter Profinet-Erfahrung verständlicherweise eine große Herausforderung.

TPS-1: einfache Software-Integration über eine Standard-C API

Im Gegensatz dazu umfasst der TPS-1 den Profinet-Stack: Einfach gesagt, erzeugt der Kunde ein Flash-Image des Profinet-Stacks und einen Konfigurationsblock, der die Kommunikationsschnittstelle zum Host und die Identifizierungsdaten im weitesten Sinne bestimmt. Beim Hochfahren bootet TPS-1 vom Flash-Speicher und führt den Stack aus – das ist alles. Natürlich ist die Wirklichkeit etwas komplexer, aber es gibt immer noch den Vorteil einer vollständigen Trennung der (Profinet) Kommunikationstasks auf dem TPS-1 und der Anwendungstasks auf der Host-CPU. Dies gewährleistet, dass die Profinet-Kommunikation immer korrekt abläuft, selbst wenn der Entwickler zuvor nicht das Profinet-Spezifikationsbuch durchgearbeitet hat.

Die Kommunikation zwischen TPS-1 und der Host-CPU wird implementiert anhand

  • eines dualen Port-Speichers auf dem TPS-1 auf der Hardwareseite, und
  • einer API, die auf der Host-CPU auf der Softwareseite ausgeführt wird.

Die API ist in Standard-C geschrieben und lässt sich einfach auf die CPU-Architektur des Kunden portieren. Daraus ergibt sich ein weiterer Grund, warum der Einsatz von TPS-1 so attraktiv ist: Der Anwender kann weiterhin seine gewohnte CPU-Architektur und seine Tool-Umgebung nutzen. Dies vereinfacht die Implementierung und verkürzt die Markteinführungszeit erheblich.

* Andreas Schwope, Principal Engineer für Smart Factory in der ICBG, Renesas Electronics Europe

(ID:44358745)