Implementierung von Industrial Real-Time Ethernet Schnittstellen - universelle Lösung auf Basis der FPGA-Technologie

Transkript

1 Implementierung von Industrial Real-Time Ethernet Schnittstellen - universelle Lösung auf Basis der FPGA-Technologie Fachartikel von: Christian Schlegel, IXXAT Automation Weingarten Der Markt verlangt zunehmend nach Geräten mit Ethernet-basierten Kommunikationsschnittstellen. Da es wie bei den klassischen Feldbussen auch bei Industrial Real-Time Ethernet nicht nur ein Protokoll gibt, das von Geräteherstellern unterstützt werden muss, Ethernet jedoch nicht gleich Ethernet ist, sind Lösungen zur Integration der verschiedenen Industrial Ethernet Protokolle gefragt, welche die Anzahl der verschiedenen Ethernet-Anschaltungen minimieren und damit den Hardwareaufwand als auch den Softwareaufwand minimieren. Vielfältige Systemlösungen Obwohl es mit den Bemühungen der IAONA bereits kurz nach dem ersten Aufkommen von industriellen, Ethernet-basierenden Kommunikationssystemen den Versuch gab, eine möglichst einheitliche Lösung für die industrielle Kommunikation auf Basis von Ethernet zu finden, gibt es in der Zwischenzeit eine Vielzahl von Lösungsansätzen. In der IEC sind derzeit 11 Lösungen standardisiert, die aber lediglich auf der physikalischen Ebene zueinander kompatibel sind und auf teilweise völlig unterschiedlichen Lösungsansätzen beruhen. Wie im Anschluss an den in den achtziger Jahren tobenden sog. "Feldbuskrieg", werden sich letztlich wieder einige Lösungen als wirklich marktfähig erweisen. Neben den Lösungen Profinet und Ethernet/IP der Marktführer für Automatisierungstechnik Siemens/PNO und Rockwell/ODVA ist abzusehen, dass sich im europäischen Raum noch die Lösungen EtherCAT (Beckhoff/ETG), POWERLINK (B & R/EPSG) sowie sercos (Bosch- Rexroth/ITG) durchsetzen werden.

2 Einer der wesentlichen Gründe dafür, dass es trotz ernsthafter Bemühungen um eine einheitliche Lösung nicht möglich war eine solche zu finden lag sicherlich auch daran, dass die Vertreter der langfristig etablierten klassischen Feldbusse Lösungen auf Basis der erweiterten Fähigkeiten von Real-Time Industrial Ethernet wollten, die weitgehend mit den bereits existierenden Lösungen kompatibel bleiben sollten. Eingeführte Funktionsmerkmale, insbesondere in Bezug auf die Anwendungsprotokolle und Profile sollten weitestgehend kompatibel bleiben und damit eine möglichst einfache Migration von bereits bestehenden Lösungen ermöglichen. In besonderem Maße ist dies z.b. der Fall bei Ethernet/IP, wo mit dem sog. Common Industrial Protocol (CIP) praktisch dieselbe Anwendungsschicht wie bei DeviceNet verwendet wird, d.h an Stelle von CAN wird Ethernet als Physikalische- und Datenübertragungsschicht verwendet. Ein ähnlicher Ansatz wurde auch bei Powerlink zu Grunde gelegt. Hierbei werden die für CANopen eingeführten Mechanismen und Anwendungsdienste sowie Geräteprofile mit eigenen Protokollen auf Echtzeit-Ethernet übertragen so dass Powerlink aus Anwendersicht praktisch wie bei CANopen aussieht und damit eine sehr einfache Migration von CAN auf Industrial Real-Time Ethernet ermöglicht. Implementierung von Industrial Real-Time Ethernet Protokollen Auf Grund der verschiedenen Lösungsansätze wie auch Anforderungen der verschiedenen Ethernet-basierenden Protokolle, können einige dieser Protokolle unter Verwendung von Standard Ethernet-Controllern implementiert werden, andere benötigen jedoch spezifische Hardwareunterstützung, die in Form von IP-Cores oder ASICS zur Verfügung steht. Zusätzlich ist auch die im industriellen Bereich vorherrschende Linientopologie bei der Entwicklung von Ethernet-Anschaltungen zu berücksichtigen. Da es bei Ethernet nicht mehr möglich ist einfach nur Kabel zu einer Linie zu verbinden, sondern aktive Komponenten in Form von Hubs oder Switches zwischen den einzelnen Teilnehmern in einem Netzwerk notwendig sind, sollte eine Ethernet-Anschaltung auch gleich die notwendige Voraussetzung zur Unterstützung von Linientopologien mitbringen. Dies bedeutet, dass je nach Protokoll ein Switch, ein Hub oder eine spezifische Anschaltung erforderlich ist. Bild 1 zeigt eine Übersicht der verschiedenen Architekturen welche für die Slave-Anschaltungen der einzelnen Protokolle erforderlich sind. Für die Implementierung der Protokolle Profinet RT IO Device, Ethernet/IP Adapter und Modbus/TCP Client/Server ist ein Standard Ethernet-Controller, wie er heute in vielen CPUs bereits integriert ist ausreichend. Zur Unterstützung der Linientopologie ist die Integration eines Switches auf der Ethernet-Anschaltung sinnvoll. Hierzu gibt es bereits fertige Switch- Bausteine mit integrierten PHYs. Ein POWERLINK Managing Node und Controlled Node kann ebenfalls mit einem Standard Ethernet-Controller implementiert werden. Sofern jedoch sehr kurze Zykluszeiten unterstützt werden sollen ist ein modifizierter Ethernet-Controller sinnvoll, der das schnelle Senden einer Antwort auf eingehende Nachrichten ermöglicht. Ferner ist bei Powerlink zur Unterstützung der Linientopologie die Integration eines Hubs auf der Ethernet-Anschaltung sinnvoll. Da die Switch-Technologie die Hub-Technologie verdrängt hat, gibt es keine Hub-Bausteine mehr. Daher ist für die Realisierung des Hubs ein programmierbarer Baustein zwischen Ethernet- Controller und PHYs erforderlich.

3 Für EtherCAT und sercos Slaves werden spezifische Hardwareanschaltungen benötigt. Diese werden im Fall von EtherCAT von der Firma Beckhoff in Form von ASICs oder eines IP- Cores, im Fall von sercos von Sercos International ebenfalls in Form eines IP-Cores angeboten und lizenziert. Diese Hardwareanschaltungen ersetzen quasi den Ethernet- Controller und stellen auch die für die Unterstützung der Linientopologie erforderliche Infrastruktur zur Verfügung. Zusätzlich ist aber auch eine CPU erforderlich, welche die jeweiligen Real-Time Protokollstacks ausführt. Zur Implementierung von Profinet IRT stehen derzeit nur dedizierte CPUs zur Verfügung: der ERTEC 200/400 als auch der NetX. Diese CPUs beinhalten den spezifischen Profinet IRT Switch und führen auch den Profinet IO Device Protokollstack aus. Wie die Praxis zeigt, zwingt der Markt die Gerätehersteller alle relevanten Protokolle zu unterstützen. Wie die vorstehende Übersicht der verschiedenen Architekturen der Ethernet- Anschaltungen zeigt, müsste ein Gerätehersteller verschiedene Hardwareanschaltungen für Ethernet im Programm haben um alle relevanten Protokolle implementieren zu können. Die unterschiedlichen Hardwareanschaltungen können auf 2 verschiedene Arten gelöst werden: entweder durch verschiedene Designs der gesamten Hardware oder aber über Aufsatzmodule für die verschiedenen Industrial Real-Time Ethernet-Anschaltungen. Der Vorteil von Aufsatzmodulen gegenüber verschiedenen Designs der gesamten Hardware ist, dass das Grunddesign des Geräts unverändert bleibt und auch eigenständig versioniert und verwaltet werden kann und jede Ethernet-Anschaltung eine eigene Versionierung und Verwaltung hat. Dies vereinfacht die Lagerhaltung und Logistik und reduziert die Kosten. Ein weiterer Vorteil einer eigenständigen Ethernet-Anschaltung in Form einer Aufsatzplatine ist, dass diese in der Regel das Protokoll vollkommen selbständig und unabhängig von der Geräte-CPU abarbeitet und die für das jeweilige Protokoll geforderte Performance besitzt. Ferner ergibt sich damit die Möglichkeit eine einheitliche Schnittstelle zwischen Geräteanwendung und den verschiedenen Protokollen zu definieren, welche die Pflege als auch zukünftig die Integration weiterer Protokolle erheblich vereinfacht. Auf Grund der schnellen Zykluszeiten erfordern die Protokollstacks der echtzeitfähigen Ethernet-Protokolle erhebliche Rechenleistung. Dies bedeutet, dass entweder leistungsfähige 32-Bit CPUs eingesetzt werden müssen, wenn Anwendung und Protokollstack auf einer CPU laufen oder die erforderliche Performance nicht erreicht werden kann. Auch hier zeigt sich der Vorteil der Trennung von Geräteanwendung und Ethernet-Anschaltung. Wenn der Protokollstack durch eine CPU auf der Ethernet-Anschaltung ausgeführt wird, steht die Geräte-CPU völlig für die Anwendung zur Verfügung und kann auch entsprechend den Anforderungen der Anwendung selektiert werden bzw. eine bereits vorhandene CPU kann weiterverwendet werden. Wie bereites angedeutet, ist aber die Verwendung von Aufsatzmodulen für die Ethernet- Anschaltung noch nicht die optimale Lösung, da auch hier für die verschiedenen Architekturen verschiedene Aufsatzmodule erforderlich sind.

4 Bild 1: Architekturen der verschiedenen Industrial Real-Time Ethernet Standards Field Programmable Gate Arrays als Basis für eine universelle Lösung Da der Physical Layer bei allen Industrial Ethernet Protokollen auf IEEE802.3 basiert, wäre es also seitens der physikalischen Ankopplung möglich eine Hardware zu erstellen, welche alle Protokolle unterstützt. Problematisch ist jedoch, dass einige der Protokolle spezifische Echtzeiteigenschaften besitzen, welche wiederum spezifische Verarbeitungsmechanismen erfordern. Unter den heute verfügbaren CPUs gibt es bis auf eine Ausnahme keine CPU, welche alle Anforderungen der verschiedenen Protokolle erfüllen kann. Würde man eine solche spezifische CPU einsetzen, die alle Anforderungen erfüllt, so würde man sich aber auch von einem, vielleicht kleinen, Hersteller abhängig machen. Als Lösung für diese Problematik bietet sich der Einsatz von frei programmierbaren Logikbausteinen an. FPGAs (Field Programmable Gate Arrays), wie z.b. die Cyclone Familie von Altera bieten neben einer programmierbaren schnellen Logik, optional auch dynamisch ladbare und skalierbare Prozessorkerne mit 32-Bit RISC Architektur, NIOS II genannt an. Durch diese Kombination lassen sich praktisch alle Anforderungen der unterschiedlichen Protokolle erfüllen. Für Protokolle mit spezifischen Anforderungen wie EtherCAT und sercos sind die spezifischen Hardwareanschaltungen in Form von FPGA IP- Cores verfügbar, die in das FPGA geladen werden und intern an den NIOS Prozessor angeschlossen werden können. Diese FPGA IP-Cores garantieren die schnelle und spezifische Verarbeitung der Ethernet Pakete während auf dem integrierten NIOS II Prozessor der jeweilige busspezifische Protokollstack ausgeführt wird. Ist keine spezifische Hardwareanschaltung erforderliche, so stehen Standard Ethernet-Controller und auch Switch und Hub Funktionen als FPGA IP-Cores zur Verfügung.

5 Für die Entwicklung einer FPGA-basierten Ethernet-Anschaltung ist das FPGA wie eine CPU mit externen Komponenten zu beschalten. Erforderlich sind im wesentlichen ein Quarz oder Oszillator, ein dynamisches RAM und ein serieller Flashbaustein. Hinzu kommen die beiden PHYs für die Ethernet-Schnittstellen. Im seriellen Flash wird das Konfigurationsfile für das FPGA als auch das Programm, welches auf der CPU im FPGA ausgeführt werden soll abgelegt. Somit benötige eine FPGA basierte Hardwarelösung nicht mehr Komponenten als eine CPU basierte Lösung und liegt damit in vergleichbaren Preisregionen bei wesentlich höherer Flexibilität. Zur Erstellung des Konfigurationsfiles für das FPGA dient ein Synthesetool, bei Altera Quartus II genannt. Mit Hilfe dieses Tools lässt sich die Konfiguration des FPGA erstellen (FPGA-Design), in dem man die benötigen Funktionen aus einer Vielzahl von mitgelieferten IP-Cores auswählt, miteinander verbindet (z.b. Prozessor, Memory Interface, externe Interfaces wie PCI, PCIe, Shared Memory, SPI, usw.) und fehlende Mechanismen in VHDL oder Verilog dazu programmiert. Das Tool ermöglicht dann auch die Simulation des erstellten Designs als auch Timinganalysen und die Analyse des tatsächlichen Strombedarfs. Schließlich generiert das Tool eine Binärdatei für das FPGA, welche z.b. über eine JTAG Schnittstelle in den Flash geladen wird. Zur Softwareentwicklung steht für den NIOS II eine kostenlose Entwicklungsumgebung zu Verfügung, welche auf Eclipse und GNU basiert. Der erzeugte Binärcode wird ebenfalls zu den FPGA Konfigurationsdaten in den seriellen Flash geladen. Das Debuggen der Software erfolgt über die JTAG Schnittstelle des FPGA. Der Vorteil einer FPGA-basierten Ethernet-Anschaltung besteht nun darin, dass man mit nur einer Hardware alle Industrial Ethernet Protokolle unterstützen kann. Es muss lediglich die für das jeweilige Protokoll erforderliche FPGA Konfiguration und Software mit dem Protokollstack in das FPGA geladen werden. Dies kann entweder zum Fertigungszeitpunkt erfolgen oder sogar erst zu einem späteren Zeitpunkt durch die Geräte-CPU selber. Damit hat man auch jederzeit die Möglichkeit zukünftige Ethernet-basierte Protokollstandards mit derselben Hardware zu unterstützen. Ein weiterer Vorteil ist, dass man nicht von einem Hersteller abhängig ist. Man legt sich zwar zunächst auf einen Hersteller fest und es gibt quasi kein Second Source, aber es besteht immer die Möglichkeit mit vertretbarem Aufwand auf einen anderen FPGA Hersteller zu wechseln, da VHDL und Verilog Standardsprachen beim FPGA Design sind. Bild 2: Universelles FPGA-basiertes Modul für alle Industrial Real-Time Ethernet Protokolle

6 Universelles Echtzeit-Ethernet Schnittstellenmodul Auf Basis der FPGA Technologe bietet IXXAT ein Industrial Ethernet Modul an, welches eine fertige Lösung zur schnellen Integration einer Ethernet-Schnittstelle in beliebige Geräte darstellt (Bild 2). Das Modul verfügt über alle erforderlichen Komponenten und Schnittstellen und unterstützt die Protokolle Profinet RT IO, Ethernet/IP, Powerlink, EtherCAT, sercos und Modus/TCP. Weitere Protokolle können jederzeit implementiert werden. Für die Integration des Moduls auf der Gerätehardware ist ein Stecker vorgesehen, über den das Modul mit Spannung versorgt werden muss und über den eine serielle Schnittstelle als auch eine parallele Address-/Datenbusschnittstelle für die Kommunikation zwischen Geräte- CPU und Modul zur Verfügung steht. Zur Ankopplung an die Gerätesoftware steht eine Programmierschnittstelle zur Verfügung, welche die Funktionalität der einzelnen Industrial Ethernet Protokolle weitgehend generisch der Gerätesoftware zur Verfügung stellt. Dies bedeutet, dass die Gerätesoftware unabhängig von den Industrial Ethernet Protokollen implementiert werden kann. Ebenso ist eine zukünftige Erweiterung um weitere Protokolle ohne große Änderungen an der Gerätesoftware jederzeit möglich. Die Programmierschnittstelle wird als C-Code geliefert und kann leicht auf die verwendete Geräte-CPU angepasst werden. Bild 3 zeigt, dass die Programmierschnittstelle in 4 verschiedene Bereiche unterteilt ist: Kommandoschnittstelle (CMD), Ereignis- und Statusschnittstelle (EVT/STS), Parameterschnittstelle (PAR) und Prozeßdatenschnittstelle (PI). Über die Kommandoschnittstelle steuert die Gerätesoftware das Schnittstellenmodul. Hier stehen Kommandos wie Init, Reset, Connect, usw. zur Verfügung. Über die Ereignis- und Statusschnittstelle erhält die Gerätesoftware Informationen zum Netzwerk- und Modulstatus sowie zu aufgetretenen Fehlern. Die Parameterschnittstelle dient zur Übergabe von Lese- und Schreibzugriffen auf Geräteparameter. Da Geräte bisweilen 1000 und mehr Parameter haben können (z.b. Antriebe) werden diese Daten nicht auf dem Schnittstellenmodul gehalten, sondern Zugriffe darauf direkt an die Gerätesoftware zur Ausführung weitergeleitet. Die Parameter werden durch die verschiedenen Protokolle unterschiedlich referenziert, daher bildet ein Parametermanager auf dem Schnittstellenmodul die verschiedenen Referenzierungsformen auf eine einheitliche und protokollunabhängige Referenzierungsform ab bevor die Zugriffe an die Gerätesoftware weitergereicht werden. In der Prozeßdatenschnittstelle befinden sich schließlich die zu übertragenden Prozeßdaten getrennt nach Eingangs- und Ausgangsdaten. Um bei den echtzeitfähigen Protokollen eine synchrone Bearbeitung der Prozeßdaten durch die Gerätesoftware zu ermöglichen kann das Schnittstellenmodul bei jedem Start eines neuen Kommunikationszykluses einen Interrupt für die Geräte-CPU generieren. Da das Industrial Ethernet Modul auf der FPGA-Technologie basiert, ist es mit wenig Aufwand möglich auch kundenspezifische Schnittstellen in das Modul zu integrieren. Dies kann z.b. eine CAN-Schnittstelle für den Anschluss des Moduls and das Gerät sein. Ebenso kann die Programmierschnittstelle auch gegen eine bereits auf der Geräteseite vorhandenen kundenspezifischen Programmierschnittstelle ausgetauscht werden. Die Vorteile für den Gerätehersteller bei Einsatz des Industrial Ethernet Moduls sind ein schnelles time-to-market und geringere Entwicklungskosten. Hinzu kommt ein erheblich reduziertes Entwicklungsrisiko, da ein bereits getestetes und vorab zertifiziertes Modul

7 eingesetzt wird. Die Pflege der verschiedenen Protokolle im Rahmen der Produktpflege des Industrial Ethernet Schnittstellenmoduls durch IXXAT erfolgt, daher muss sich der Gerätehersteller auch nicht selber um neuere Protokollversionen und Updates kümmern. Für den schnellen Start steht ein Basisboard zur Verfügung, welches über Steckplätze für einige gebräuchliche CPU-Boards verfügt. Hiermit kann bereits mit der Entwicklung begonnen werden, ohne dass die Zielhardware schon zur Verfügung steht. Bild 3: Einheitliche Programmierschnittstelle für alle Industrial Real-Time Ethernet Protokolle Zusammenfassung Die FPGA-Technologie ist ideal für die Realisierung einer Hardware, welche die verschiedenen echtzeitfähigen und nicht echtzeitfähigen Industrial Ethernet Protokolle unterstützen soll. Neben einer niedrigen Leistungsaufnahme kann damit auch Hardware für den erweiterten Temperaturbereich realisiert werden. Auf der Kostenseite ist eine solche Lösung nicht teurer verglichen mit einer CPU-basierten Lösung. Mit dem Industrial Ethernet Schnittstellenmodul bietet IXXAT auf Basis der FPGA- Technologie eine Lösungen für die schnelle, sichere und flexible Integration einer Ethernet- Schnittstelle für alle industriellen Real-Time Ethernet Protokolle an. Sollte eine Modullösung nicht in Frage kommen, so kann das Industrial Ethernet Schnittstellenmodul auch als Design- In direkt auf die Gerätehardware integriert werden.