Im Jahre 1999 begann eine Entwicklergruppe im Hause B&R mit der Entwicklung eines neuen Feldbusses, der die Grenzen damaliger Systeme ausweiten sollte. Sehr schnell kam man dort auf die Idee, echte Ethernet-Physik als Basis des neuen Systems zu verwenden. Es versprach Störfestigkeit, war schon 1999 milliardenfach installiert und hielt alle international relevanten Vorschriften ein (EMV, FCC usw.). Auch bei B&R gab es während der Analysephase Überlegungen, die Ethernet-Frames zu manipulieren und während des Durchlaufs zu verändern. Man kam allerdings zu dem Schluss, dass nur vollständig Normen konforme Ethernet-Frames den Vorteil von Ethernet wirklich zur Geltung bringen würde, nämlich die Verwendung von Standard-Diagnose-Systemen und Standard-Hardware. Die erforderlichen Maßnahmen, die ergriffen werden müssten, um Ethernet echzeitfähig zu machen, legten eine Lösung in Software nahe. Dies sollte auch einen bestätigten Datenverkehr nach dem Producer/Consumer-Prinzip ermöglichen und eine spätere Migration auf GBit-Ethernet erleichtern. Anforderungen an das System Bereits 1999 waren die Rahmenanforderungen an ein neues System schnell gesteckt, die heute im Wesentlichen das Ethernet Powerlink System kennzeichnen: Die Verdrahtungsanforderungen des Maschinenbaus (Baum, Stern, Linie) sollten abgedeckt werden. Die eindeutige Adressierung aller Teilnehmer im Feld sollte möglichst einfach mit Knotenschaltern möglich sein. Schließlich sollten Geräte während des Betriebs ausgetauscht und dynamisch konfiguriert werden können, ohne dass das Netzwerk neu gestartet werden muss. \“Die größte Schwierigkeit war die Umsetzung von harter Echtzeit, um in allen regelungstechnischen Anwendungen, wie z.B. der Antriebstechnik, bestehen zu können\“, erklärt Meindl. Die technischen Anforderungen hießen: absolute Deterministik, kleiner Jitter und systemweite Synchronität. Ein direkter Querverkehr sollte die Autonomie vom Master gewährleisten und keine unnötige Systembelastung bringen. Zudem sollte Maschinensicherheit (Safety) integrierbar sein. Anton Meindl dazu: \“Ich kann mich noch sehr gut an die Erstpräsentation unserer Ideen bei der Geschäftsführung erinnern. Schon damals hatten wir gelbe Kästchen in der Präsentation vorgesehen. Wir haben uns damals Gedanken gemacht, ob Ethernet Safety-fähig ist. Und auch das konnten wir mit ja beantworten.\“ Zudem sollte stets genügend Bandbreite für Diagnosedaten zur Verfügung stehen. Selbst bei maximaler Maschinengeschwindigkeit sollte eine parallele Analyse des Datenverkehrs möglich sein. Meindl dazu: \“Man muss feststellen können, wenn sich eine Maschine verändert. Wenn man Trace-Daten beispielsweise von den Antrieben aufzeichnet und analysiert, deutet eine erhöhte Stromaufnahme möglicherweise auf einen bevorstehenden Ausfall der Achse hin. Diese Daten müssen asynchron über das Netzwerk übertragen werden, ohne dass das Verhalten der Maschine beeinträchtigt wird.\“ Die präzise Synchronisation mehrerer Maschinen war bereits 1999 eine Anforderung an die Kommunikation, und auch sie ist heute mit Ethernet Powerlink im Einsatz. Fazit Als Entwicklungsverantwortlicher, der die Anforderungen von damals mit der Realität von heute vergleicht, darf Meindl zufrieden sein. Sämtliche der skizzierten Anforderungen von 1999 sind heute umgesetzt. Die integrierte Sicherheitstechnik läuft bereits im Labor. Zur SPS/IPC/Drives 2006 wird eine lauffähige Lösung vorgestellt werden. Das System soll eine frei programmierbare Sicherheitssteuerung enthalten, die dezentral verteilte sicherheitsgerichtete E/As steuern. Durch die EPSG ist gewährleistet, dass Fremdhersteller Powerlink Safety einfach in ihre Geräte integrieren können. Auch die Performancedaten können sich sehen lassen: Ein Regler- und Steuerzyklus von unter 1ms mit einem Netzwerkzyklus von gleiche.\“ (kbn) Das Interview: Die größten Missverständnisse rund um Ethernet Powerlink SPS-Magazin: Ethernet Powerlink setzt auf die Verwendung von Hubs. Ist diese Technologie nicht veraltet? Meindl: Die Tatsache, dass wir auf Hubs setzen, wird immer als vermeintlich schwacher Punkt angeführt. Das Gegenteil ist der Fall: Ein Hub ist im Endeffekt nichts anderes als Funktionalität. Er hat die Aufgabe, Daten zu verteilen. Stand der Technik heute ist die Verwendung von FPGA-Bausteinen – und so haben wir das auch realisiert. Wir haben einen Hub im FPGA realisiert, wir haben einen Mac im FPGA realisiert, und wir fahren Prozessoren im FPGA-Baustein, weil es die günstigste und flexibelste Lösung ist. Die Verwendung von Hubs in FPGAs hat auch noch einen weiteren wichtigen Aspekt: Das Hauptthema, das uns in der Entwicklung beschäftigt, ist die Abkündigung von Bauteilen – insbesondere bei denen aus der IT-Welt. Hier haben FPGAs unschlagbare Vorteile. Im einem Wettbewerbs-System werden für den Master beispielsweise nur zwei Chipsätze unterstützt. Die Wahrscheinlichkeit, das hier eine Abkündigung erfolgt, ist relativ groß. Um sich davon zu überzeugen, braucht man nur auf die Intel-Homepage zu gehen. Dann hat man ein Problem, dass wir komplett umgangen haben. Wimmer: Die Intelectual Properties des Hubs haben wir übrigens offengelegt, sodass jeder andere Hersteller darauf zurückgreifen kann, denn das Interessante an dieser Lösung ist ja die Integration dieses FPGAs in das entsprechende Automatisierungsgerät. Dieses Know-how wird auch bereits von einigen Produktherstellern genutzt. Die Diskussion \“Hub versus Switch\“ haben wir in der Entwicklungsphase von Ethernet Powerlink intern natürlich auch geführt, zu der Zeit war der Switch natürlich schon ein Thema. Wir wissen ja alle, dass ein Profinet-System auf Switchen basiert. Was tut nun so ein Switch? Man kommuniziert über den Switch mit lauter Punkt-zu-Punkt-Verbindungen. In unseren Analysen haben wir festgestellt, dass diese Vorgehensweise von einem Feldbussystem viel zu weit entfernt ist. An einem Feldbus dagegen hängen alle Teilnehmer an einer Leitung. Klassisches Beispiel: CAN-Bus. Die Teilnehmer hören alle, \“was da los ist\“, und zwar jeder zur gleichen Zeit das Gleiche. Deshalb haben wir uns für den Hub entschieden, der nichts anderes ist als ein Verteiler, vergleichbar mit einer Steckdosenleiste. Das ist zum Beispiel unerlässlich für den Querverkehr. Die Aushebelung des CSMA/CD-Verfahrens haben wir mit dem Zeitschlitzverfahren gelöst, dass dem Powerlink zugrunde liegt. Auch die Konfiguration eines solchen System ist gegenüber einem Switch-basierenden System deutlich einfacher. Wir haben beispielsweise eine Maschine bei TetraPak realisiert, die 52 E/A-Stationen und 52 Achsen enthält. Diese sind quasi auf einer Leitung aufgefädelt. Wenn sie sich die gleiche Anlage auf einem Profinet-System vorstellen, wird die Konfiguration sehr komplex, weil man sicherstellen muss, dass die entsprechenden Stationen zur richtigen Zeit miteinander kommunizieren. Die Konfiguration, welche Telegramme zu welcher Zeit wo hingehen müssen, durch viele Switches hinweg, wird beliebig komplex. Wir müssen hingegen lediglich definieren, welche Informationen Broadcast-, Multicast- oder Punkt-zu-Punkt-Informationen sind. Gerade im Diagnosefall hat Powerlink durch die Hubs enorme Vorteile, weil man Diagnose-Notebook an jeden beliebigen Punkt in das Netzwerk koppeln kann. Wir haben dafür ein Konfigurationstool entwickelt, dass sich jedem Anwender kostenfrei zur Verfügung steht. Das geht heute weder mit Profinet noch mit EtherCat oder Sercos III so einfach. Sie sehen also: Die Verwendung von Hubs ist tatsächlich ein Vorteil. Günstiger geht es nicht – und einfacher auch nicht. Letztendlich spricht die Praxis für sich: Würde Ethernet Powerlink nicht so gut funktionieren, hätten wir heute nicht 100.000 Knoten installiert und nicht 150 Maschinenbauer weltweit, die das System verwenden. SPS-Magazin: Es gibt immer wieder Stimmen, die behaupten, Ethernet Powerlink sei im Vergleich zu anderen Systemen verhältnismäßig langsam. Wimmer: Man muss da schon bei der Wahrheit bleiben. Wenn man in die Handbücher der Chiphersteller schaut und die Physik betrachtet, dauert allein die Umsetzung des analog übertragenen Signals in eine für den Prozessor verständliche digitale Form 250ns. Wenn man die Daten nun wieder rausschickt, kommt diese Verzögerungszeit noch einmal hinzu. Dadurch hat man in einer Topologie, wie sie Sercos III oder EtherCat empfehlen, eine Verzögerung von 1µs. Daher ist uns auch unklar, wie man 100 Achsen in 100µs synchronisieren will, wenn das schon der physikalischen Verzögerungszeit entspricht. Wir geben Daten an, die in der Praxis auch funktionieren und auch noch genügend Bandbreite für asynchrone Datenübertragungen bieten. Dafür gibt es ein schönes Beispiel mit 53 Stationen, darin enthalten sind 32 Antriebe mit 32Byte zyklische Daten je Antrieb, 16 E/A-Knoten je 72Byte (320 analoge und 4.096 digitale E/As), drei Visualisierungsgeräte, eine Kamera und ein Datenlogger. Die Zykluszeit beträgt in diesem Beispiel 400µs bei einem Jitter, der kleiner als 20ns ist. Dem Anwender stehen am Ende immer noch 30Mbit/s an Bandbreite für weiteren Datenverkehr zur Verfügung. Eine Basiseigenschaft von Powerlink, die auch ganz wichtig ist: Wir haben immer einen bestätigten Datenverkehr. Auf einen Poll gibt es immer einen Response. Das ist auch eine übliche Methode in der Automatisierung, weil man dadurch sicherstellen kann, dass eine Station, die Daten angefordert hat, diese auch bekommt. Diese Art der Übertragungssicherheit kostet sicher auch ein bisschen Bandbreite. Manche andere Systeme verlassen sich hier zu sehr auf das ständige Funktionieren jeder Station. Hannover Messe:
B&R Industrial Automation GmbH
