Von Profibus auf Profinet umsteigen

In null Komma nichts auf Profinet IRT migrieren

Seite: 4/4

Firmen zum Thema

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.

Bildergalerie

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)