Protokollmigration

Was umfasst eine Feldbus-Ethernet-Migration?

Eine Feldbus-Ethernet-Migration bringt ein Gerät von einem älteren Netz auf Industrial Ethernet.

Unsere Kunden sind meist Gerätehersteller, Maschinenbauer und Instrumentenhersteller. Wir migrieren ein Gerät von einem älteren Netz, also CANopen, PROFIBUS DP, einer seriellen Verbindung oder HART, auf POWERLINK, EtherCAT, PROFINET, Modbus TCP oder Ethernet-APL und übernehmen die Anwendungslogik, ohne sie neu zu schreiben. Migrationen umfassen meist einen oder mehrere dieser Punkte:

• Eine Bewertung, bevor sich jemand festlegt. Was sich ändert, was bleibt und was das neue Netz an Zykluszeit, Knotenzahl und Nutzdaten kostet. Am Ende läuft ein Prototyp auf Ihrer Hardware.
• Ein Produkt, ein neues Netz. Die vollständige Migration eines einzelnen Geräts oder Controllers, vom Austausch des Stacks bis zur Abnahme mit Produktionsgeschwindigkeit.
• Nur die Übernahme der Logik, wenn Sie die neue Plattform schon haben und die gewachsene Logik korrekt darauf portiert werden muss.
• Eine Phase des Parallelbetriebs, in der alte und neue Variante nebeneinander bestehen, solange die installierte Basis ausgeliefert wird, mit einer geplanten Umstellung anstelle eines Stichtags für alles.
• Neue Prüfung auf dem neuen Netz. Vorzertifizierung und Abnahme für eine Migration, die jemand anderes durchgeführt hat.
• Ihre Ingenieure gehen den Weg mit. Die Schulung läuft parallel zur Migration des ersten Produkts, und wenn später weitere Produkte umziehen, stehen wir hinter Ihrem Team.

Wir migrieren das Produkt und die Geräte darum herum. Migrationen in der Halle und die Inbetriebnahme von Maschinen übernehmen wir nicht. Unsere Ingenieure arbeiten mit Ihren durch Integration und Abnahme, in dieser Phase vor Ort und danach remote.

Was ändert sich bei einer Migration, und was bleibt?

Stack, Treiber und Zeitbudget ändern sich; Anwendungslogik und Datenmodell bleiben erhalten.

Vier Dinge ändern sich, und nur das erste ist das Protokoll:

1. Der Stack ändert sich.
2. Der Treiber darunter ändert sich.
3. Die Anwendungslogik darüber wird portiert, nicht neu geschrieben.
4. Das Zeitbudget, um das herum das ganze Produkt entworfen wurde, verschiebt sich.

Das Zeitbudget überrascht Programme am häufigsten. Ein neues Netz ändert mehr als die Geschwindigkeit. Es verändert das Verhältnis zwischen Zykluszeit, Knotenzahl und Nutzdaten je Zyklus, und ein Gerät, das an einem Punkt dieser Kurve bequem lag, kann an einem anderen knapp werden. Für jedes Protokoll sind diese drei Größen spezifiziert. Die Bewertung beginnt deshalb dort und misst dann Ihr tatsächliches Gerät daran.

Was meist unverändert bleibt, ist Ihre angesammelte Entwicklungsinvestition: die Verarbeitungslogik, das Datenmodell des Geräts, die Kalibrier- und Parametersätze und die Bedeutung Ihrer Diagnosedaten.

Welche Protokollmigrationen übernehmen Sie?

Wir migrieren CANopen-, PROFIBUS-DP-, serielle und HART-Geräte auf POWERLINK, EtherCAT, PROFINET, Modbus TCP und Ethernet-APL.

Sechs Paare kommen immer wieder vor, und jedes hat seinen eigenen Charakter:

• CANopen auf POWERLINK oder EtherCAT. Die häufigste Anfrage, getrieben von Knotenzahl und Zykluszeit. Das Objektverzeichnis lässt sich am saubersten übernehmen; die in der Anwendung versteckten Annahmen zum Zeitverhalten meist nicht. Ein Beispiel: Unser Team hat ein Gerätenetz von CANopen auf POWERLINK migriert, und das Ergebnis hält einen Zyklus von 2 ms.
• POWERLINK auf EtherCAT. Selten eine Frage der Leistungsfähigkeit, meist eine der installierten Basis eines Kunden oder eines Beschaffungsdokuments. Die beiden liegen nah genug beieinander, dass sich die Arbeit auf das Prozessabbild und die Beziehung zum Master konzentriert.
• PROFIBUS DP auf PROFINET. Der am besten unterstützte Weg der Branche, weil beide unter derselben Organisation stehen und die Migration von Anfang an vorgesehen war. Aus der GSD wird eine GSDML, und das Gerätemodell bleibt weitgehend erhalten.
• Seriell auf Modbus TCP. Die Registertabelle bleibt fast unverändert, und deshalb wirkt dieser Weg wie der einfachste. Die Schwierigkeit kommt später, wenn die Anwendung auf eine TCP-Verbindung trifft, die anders ausfällt als eine RS-485-Verbindung. Ein serieller Timeout und ein abgebrochener TCP-Socket sind verschiedene Fehlerereignisse, und Anwendungscode, der für das eine geschrieben wurde, behandelt das andere nicht korrekt.
• HART auf Ethernet-APL. Die Migration für Instrumente, und hier ist die Bitübertragungsschicht der Kern: zwei Adern übertragen Energie und Daten in einen explosionsgefährdeten Bereich, nach dem Eigensicherheitskonzept 2-WISE. Die digitalen Daten, die HART schon immer übertragen hat, kommen endlich mit voller Rate an und nicht mehr über eine 4–20-mA-Schleife.

Trägt die vorhandene Hardware den neuen Stack?

Oft nicht, und genau das klärt die Bewertung als Erstes.

Industrial Ethernet verlangt mehr als ein Feldbus: einen MAC und meist zwei Ports mit integriertem Switch, damit das Gerät in einer Linientopologie sitzen kann, mehr Flash und RAM für den Stack und bei den isochronen Protokollen einen Chip mit Protokollbeschleunigung oder ein FPGA dahinter. Eine MCU, die vor Jahren für einen CANopen-Knoten ausgewählt wurde, hat davon selten etwas. Eine Feldbus-Ethernet-Migration bedeutet deshalb oft auch eine neue Baugruppe, und das entscheidet die Bewertung, bevor Hardware festgelegt wird. Wird die Hardware ohnehin ersetzt, sind beide Aufgaben zusammen günstiger: Embedded-Systeme übernimmt die neue Baugruppe, und das Obsoleszenzmanagement den Fall, in dem ein abgekündigtes Bauteil die Änderung überhaupt erst erzwungen hat.

Soll ich das Gerät migrieren oder einen Proxy davorsetzen?

Manchmal ist der Proxy die richtige Antwort, und dann sagen wir das.

PROFINET legt den Proxy in seiner eigenen Spezifikation fest: ein Gerät im Ethernet-Netz, das ein ganzes PROFIBUS-Segment dahinter vertritt, sodass die vorhandenen Slaves unverändert weiterlaufen. Für andere Paare leisten Gateways das Gleiche.

• Was er bringt. Nichts muss neu zertifiziert oder neu geprüft werden, und ein funktionierendes Segment funktioniert weiter.
• Was er kostet. Er überträgt Prozessdaten zuverlässig, oft aber wenig mehr. Diagnose, Parametrierung und gerätespezifische Dienste gehen bei der Übersetzung häufig verloren, und der Ingenieur an der Steuerung sieht das Gerät dahinter nicht mehr. Er fügt einen Übersetzungsschritt hinzu, den der ursprüngliche Entwurf nicht hatte, und er lässt das veraltete Netz im Feld. Dort müssen die Teile weiter beschafft und das Fachwissen weiter gehalten werden.

Die praktische Prüfung ist, was Sie verkaufen. Ein Maschinenbauer, der eine Anlage am Laufen hält, wählt den Proxy. Ein Gerätehersteller, dessen Kunden inzwischen Ethernet vorschreiben, hat davon nichts, weil sein Produkt weiterhin ein PROFIBUS-Produkt ist. Ist der Proxy die Antwort, gehört die Arbeit zur Geräte- und Netzwerkintegration.

Was bedeutet eine Migration für die Zertifizierung?

Mit einer Migration beginnt die Zertifizierung von vorn.

Ein Gerät, das für PROFIBUS DP zertifiziert war, ist nicht für PROFINET zertifiziert, und die Testsuite, die es bestehen muss, gehört zum neuen Netz, nicht zum alten. Migrationsbudgets übersehen das häufig, und es fällt spät auf, wenn der Zeitplan schon öffentlich ist. Wir führen die Konformitätstestfälle des neuen Netzes im eigenen Labor aus, bevor das Prüflabor gebucht wird, und zwar am migrierten Gerät selbst. Das Zertifikat stellt das akkreditierte Prüflabor aus, wie beim ersten Mal.

Wann ist eine Migration die falsche Antwort?

Eine Migration ist die falsche Antwort, wenn das Netz nicht die Einschränkung ist.

• Ein Bauteil wurde abgekündigt. Muss ein Produkt auf neue Hardware, weil ein Controller, Prozessor oder FPGA abgekündigt wurde, ist das ein Problem der Plattform. Es gehört zum Obsoleszenzmanagement, wo Netz und Logik bleiben, wie sie sind.
• Mehrere Geräte müssen zusammenarbeiten. Besteht die eigentliche Anforderung darin, dass mehrere Geräte an verschiedenen Netzen zusammenarbeiten, ist das Geräte- und Netzwerkintegration, und migriert werden muss gar nichts.

Das sagen wir schon bei der Bewertung, denn die teure Variante dieses Fehlers ist, ihn erst zu bemerken, wenn der Stack schon ausgetauscht ist.

Wie bleibt die installierte Basis während einer Migration betreut?

Wir verlangen nicht, dass die installierte Basis umzieht.

Eine Flotte im Feld bringt weiter Umsatz und unterliegt weiter Supportpflichten. Eine Migration, die sie zurücklässt, ist gescheitert, wie gut die neue Variante auch funktioniert. Praktisch heißt das: eine Phase, in der beide Varianten aus einer Codebasis gebaut und betreut werden, mit einer Netzschicht, die gut genug gekapselt ist, damit der Unterschied auf sie begrenzt bleibt und sich nicht durch die Anwendung zieht. Die Kapselung hilft doppelt: Die aktuelle Migration bleibt beherrschbar, und die nächste wird günstiger, weil die Lebenszyklen der Module von Anbietern oft außerhalb Ihrer Kontrolle liegen.