Eigenständige Anschaltung ermöglicht einheitliche Schnittstelle

Bilder

Übersicht der verschiedenen Architekturen, welche für die Slave-Anschaltungen der einzelnen Protokolle erforderlich sind.

Was die Implementierung der IRT-Gerätehersteller, die mehrere unterschiedliche Protokolle in ihren Geräten unterstützen müssen, haben angesichts dieser Ausgangssituation die Wahl zwischen zwei Realisierungsmöglichkeiten: entweder durch verschiedene Designs der Gerätehardware, oder aber über Aufsatzmodule für die verschiedenen Ethernet-Anschaltungen. Letztere haben den Vorteil, dass das Grunddesign des Geräts unverändert bleibt und trotzdem jede Ethernet-Anschaltung eine eigene Versionierung und Verwaltung hat. Dies vereinfacht die Lagerhaltung sowie 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 selbstständig und unabhängig von der Geräte-CPU abarbeitet und die für das jeweilige Protokoll geforderte Performance besitzt. Die Geräte-CPU steht somit komplett für die Anwendung zur Verfügung und kann entsprechend den Anforderungen der Anwendung selektiert werden; eine bereits vorhandene CPU ist weiterhin verwendbar. Ferner ergibt sich mit einer eigenständigen Anschaltung die Möglichkeit, eine einheitliche Schnittstelle zwischen Geräte-Anwendung und den verschiedenen Protokollen zu definieren, welche die Pflege und zukünftig auch die Integration weiterer Protokolle erheblich vereinfacht.Variante (Isochrones Echtzeit-Ethernet) von Profinet betrifft, stehen derzeit nur dedizierte CPUs zur Verfügung: der Ertec 200/400 von Siemens beziehungsweise NEC sowie der NetX-Chip der Firma Hilscher. Diese CPUs beinhalten den spezifischen Profinet-IRT-Switch und führen auch den Profinet-IO-Device-Protokollstack aus. Es ist aber damit zu rechnen, dass in absehbarer Zeit entsprechende IP-Cores für FPGA-Implementierungen verfügbar sein werden.

Gerätehersteller, die mehrere unterschiedliche Protokolle in ihren Geräten unterstützen müssen, haben angesichts dieser Ausgangssituation die Wahl zwischen zwei Realisierungsmöglichkeiten: entweder durch verschiedene Designs der Gerätehardware, oder aber über Aufsatzmodule für die verschiedenen Ethernet-Anschaltungen. Letztere haben den Vorteil, dass das Grunddesign des Geräts unverändert bleibt und trotzdem jede Ethernet-Anschaltung eine eigene Versionierung und Verwaltung hat. Dies vereinfacht die Lagerhaltung sowie 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 selbstständig und unabhängig von der Geräte-CPU abarbeitet und die für das jeweilige Protokoll geforderte Performance besitzt. Die Geräte-CPU steht somit komplett für die Anwendung zur Verfügung und kann entsprechend den Anforderungen der Anwendung selektiert werden; eine bereits vorhandene CPU ist weiterhin verwendbar. Ferner ergibt sich mit einer eigenständigen Anschaltung die Möglichkeit, eine einheitliche Schnittstelle zwischen Geräte-Anwendung und den verschiedenen Protokollen zu definieren, welche die Pflege und zukünftig auch die Integration weiterer Protokolle erheblich vereinfacht.

FPGAs – Basis für eine universelle Lösung

Da der Physical-Layer bei allen Industrial-Ethernet-Protokollen auf IEEE802.3 basiert, ist es seitens der physikalischen Ankopplung grundsätzlich möglich, eine Hardware zu erstellen, welche alle Protokolle unterstützt. Problematisch ist jedoch, dass einige der Protokolle spezifische Echtzeit-Eigenschaften besitzen, welche wiederum spezifische Verarbeitungsmechanismen erfordern. Unter den heute verfügbaren CPUs gibt es – mit Ausnahme des Hilscher-Chips – keine, welche alle Anforderungen der verschiedenen Protokolle erfüllen kann.

Alternativ lässt sich diese Problematik mit dem Einsatz von frei programmierbaren Logikbausteinen lösen. FPGAs (Field Programmable Gate Arrays), wie zum Beispiel die Cyclone-Familie von Altera, bieten neben einer programmierbaren schnellen Logik optional dynamisch ladbare und skalierbare Prozessorkerne mit 32-Bit-RISC-Architektur – NIOS II genannt. Mit dieser Kombination lassen sich praktisch alle Anforderungen der unterschiedlichen Protokolle erfüllen. Für Protokolle mit speziellen Anforderungen wie Ethercat und Sercos III sind die spezifischen Hardware-Anschaltungen in Form von FPGAIP-Cores verfügbar, die in das FPGA geladen werden und intern an den NIOS-Prozessor anschließbar sind. 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 Hardware-Anschaltung erforderlich, stehen Standard-Ethernet-Controller sowie Switch- und Hub-Funktionen als FPGA-IP-Cores zur Verfügung.

Für die Entwicklung einer FPGA-basierten Ethernet-Anschaltung ist das FPGA wie eine CPU mit externen Komponenten zu beschalten. Erforderlich sind hierfür im Wesentlichen ein Quarz oder Oszillator, ein dynamisches RAM und ein serieller Flash-Baustein. Hinzu kommen die beiden PHYs für die Ethernet-Schnittstellen. Im seriellen Flash werden das Konfigurations-File für das FPGA und das Programm abgelegt, welches auf der CPU im FPGA ausgeführt werden soll. Somit benötigt eine FPGA-basierte Hardware-Lö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 Konfigurations-File für das FPGA dient ein Synthesetool, bei Altera „Quartus II“ genannt. Die benötigten Funktionen (zum Beispiel Prozessor, Memory Interface oder externe Interfaces wie PCI, PCIe, Shared Memory, SPI) lassen sich hierbei aus einer Vielzahl von mitgelieferten IP-Cores auswählen, miteinander verbinden und fehlende Mechanismen in VHDL oder Verilog programmieren. Das Tool ermöglicht zudem die Simulation des erstellten Designs sowie Analysen hinsichtlich des Timing und des tatsächlichen Strombedarfs. Schließlich generiert das Tool eine Binärdatei für das FPGA, welche beispielsweise über eine JTAG-Schnittstelle in den Flash geladen wird. Was die Software-Entwicklung betrifft, so 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 sich mit nur einer Hardware alle Industrial-Ethernet-Protokolle unterstützen lassen. Hierzu sind lediglich die für das jeweilige Protokoll erforderliche FPGA-Konfiguration sowie die Software mit dem Protokollstack in das FPGA zu laden. Dies kann entweder zum Fertigungszeitpunkt erfolgen oder erst zu einem späteren Zeitpunkt durch die Geräte-CPU selbst. Damit ergibt sich die Möglichkeit, jederzeit zukünftige ethernet-basierte Protokollstandards mit derselben Hardware zu unterstützen. Zwar legt sich der Gerätehersteller auch bei diesem Ansatz zunächst auf einen FPGA-Hersteller fest; da VHDL und Verilog jedoch Standardsprachen beim FPGA-Design sind, besteht mit vertretbarem Aufwand immer die Möglichkeit, auf einen anderen FPGA-Hersteller zu wechseln.

Autor:
Christian Schlegel ist Technischer Geschäftsführer der Firma Ixxat Automation.

Die Umsetzung

Die Anwendungs-Programmierschnittstelle des Ethernet-Moduls ermöglicht die Implementierung der Gerätesoftware unabhängig von den verschiedenen Industrial-Ethernet-Protokollen.

Auf Basis der FPGA-Technologe hat Ixxat ein Industrial-Ethernet-Modul entwickelt, welches standardmäßig die Protokolle Profinet-RT-IO, Ethernet/IP, Powerlink, Ethercat, Sercos III und Modus/TCP unterstützt. Für die Integration des Moduls auf der Gerätehardware ist ein Stecker vorgesehen, über den das Modul mit Spannung versorgt wird, und über den sowohl eine serielle Schnittstelle als auch eine parallele Adress-/Datenbus-Schnittstelle für die Kommunikation zwischen Geräte-CPU und Modul zur Verfügung stehen. Zur Ankopplung an die Gerätesoftware dient eine Programmierschnittstelle, welche die Funktionalität der einzelnen Protokolle weitgehend generisch der Gerätesoftware zur Verfügung stellt. Dies bedeutet, dass die Gerätesoftware unabhängig von den Industrial-Ethernet-Protokollen implementierbar ist. Ebenso ist eine zukünftige Erweiterung um zusätzliche Protokolle ohne große Änderungen an der Gerätesoftware jederzeit möglich. Die Programmierschnittstelle ist als C-Code verfügbar und damit leicht auf die verwendete Geräte-CPU anpassbar. Aufgeteilt ist die Programmierschnittstelle in vier Bereiche: Kommandoschnittstelle, Ereignis- und Statusschnittstelle, Parameterschnittstelle und Prozessdatenschnittstelle. Über die Kommandoschnittstelle steuert die Gerätesoftware das Schnittstellenmodul. Hier stehen Kommandos wie Init, Reset oder Connect 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 wie zum Beispiel Antriebe 1000 und mehr Parameter haben können, werden diese Daten nicht auf dem Schnittstellenmodul gehalten, sondern Zugriffe darauf direkt an die Gerätesoftware zur Ausführung weitergeleitet.

Durch die verschiedenen Protokolle werden die Parameter unterschiedlich referenziert. Ein Parametermanager bildet daher auf dem Schnittstellenmodul die verschiedenen Referenzierungsformen auf eine einheitliche und protokoll-unabhängige Referenzierungsform ab, bevor die Zugriffe an die Gerätesoftware weitergereicht werden. In der Prozessdatenschnittstelle befinden sich schließlich die zu übertragenden Prozessdaten getrennt nach Eingangs- und Ausgangsdaten. Um bei den echtzeit-fähigen Protokollen eine synchrone Bearbeitung der Prozessdaten durch die Gerätesoftware zu ermöglichen, kann das Schnittstellenmodul bei jedem Start eines neuen Kommunikations-Zyklus einen Interrupt für die Geräte-CPU generieren.

Die Tatsache, dass das Industrial-Ethernet-Modul auf der FPGA-Technologie basiert, ermöglicht mit wenig Aufwand, auch anwenderspezifische Schnittstellen in das Modul zu integrieren. Dies kann zum Beispiel eine CAN-Schnittstelle für den Anschluss des Moduls an das Gerät sein. Ebenso ist die Programmierschnittstelle gegen eine bereits auf der Geräteseite vorhandene anwenderspezifische Programmierschnittstelle austauschbar.