1. Überblick: Feldbusse sind offene, digitale, bidirektionale serielle Kommunikationsbusse für mehrere Knoten, die für intelligente Feldgeräte und Automatisierungssysteme eingesetzt werden. In der Praxis, z. B. in der Produktion und im Bauwesen, besteht häufig die Herausforderung, Geräte verschiedener Feldbusse zu integrieren oder Geräte mit anderen Feldbusprotokollen innerhalb eines einzigen Feldbusses zu nutzen. Dies erfordert eine Protokollkonvertierung zwischen verschiedenen Feldbusprotokollen. Die Frame-Konvertierung auf der Datenschlüsselschicht ist dabei ein entscheidender Faktor. In diesem Artikel untersuchen wir die Frame-Konvertierung von Feldbussen anhand von Profibus-DP und CAN, zwei heute weit verbreiteten Feldbussen. 2. Einführung in das Transportprotokoll des CAN-Feldbusses Die Transportschicht ist der Kern des CAN-Protokolls. Sie stellt der Objektschicht empfangene Nachrichten bereit und empfängt Nachrichten von ihr. Die Transportschicht ist verantwortlich für Bit-Timing und -Synchronisierung, Nachrichtenrahmen, Arbitrierung, Bestätigung, Fehlererkennung und -markierung sowie Fehlerabgrenzung. Nachrichtenrouting: Der Inhalt einer Nachricht wird durch einen Bezeichner benannt. Dieser Bezeichner gibt nicht das Ziel der Nachricht an, sondern interpretiert die Bedeutung der Daten. Daher können alle Knoten im Netzwerk durch Nachrichtenfilterung entscheiden, ob sie auf die Daten reagieren. Die Nachrichtenübertragung wird durch die folgenden vier verschiedenen Rahmentypen dargestellt und gesteuert: • Datenrahmen: Ein Datenrahmen transportiert Daten vom Sender zum Empfänger. • Remote-Rahmen: Eine Buseinheit sendet einen Remote-Rahmen, um die Übertragung eines Datenrahmens mit derselben Kennung anzufordern. • Fehlerrahmen: Jede Einheit, die einen Busfehler erkennt, sendet einen Fehlerrahmen. • Überlastrahmen: Ein Überlastrahmen dient dazu, eine zusätzliche Verzögerung zwischen vorhergehenden und nachfolgenden Datenrahmen (oder Remote-Rahmen) zu schaffen. Datenrahmen (oder Remote-Rahmen) sind durch den Inter-Frame-Bereich von den oben genannten Rahmen getrennt. Im Folgenden wird der Datenrahmen als Beispiel verwendet, um die CAN-Rahmenstruktur zu analysieren. 2.1 Datenrahmen Ein Datenrahmen besteht aus sieben verschiedenen Bitfeldern, wie in Abbildung 1 dargestellt: (1) Rahmenstart: Er markiert den Beginn des Datenrahmens und des Remote-Rahmens und besteht aus einem einzelnen „dominanten“ Bit. (2) Arbitrierungsfeld: Das Arbitrierungsfeld enthält die Kennung (ID) und das Remote-Transmit-Request-Bit (RTR). Kennung (ID): Die Kennung ist 11 Bit lang. Diese Bits werden in der Reihenfolge von ID-10 bis ID-0 gesendet. Das niedrigstwertige Bit ist ID-0. Die 7 höchstwertigen Bits (ID-10 bis ID-4) dürfen nicht alle „rezessiv“ sein. RTR-Bit: Dieses Bit muss im Datenrahmen „dominant“ und im Remote-Rahmen „rezessiv“ sein. (3) Steuerfeld: Das Steuerfeld besteht aus 6 Bits, einschließlich des Datenlängencodes und zwei reservierten Bits für zukünftige Erweiterungen. Die gesendeten reservierten Bits müssen „dominant“ sein. Der Datenlängencode gibt die Anzahl der Bytes im Datenfeld an und ist 4 Bit lang. (4) CRC-Feld: Das CRC-Feld enthält die CRC-Sequenz, gefolgt vom CRC-Trennzeichen, das ein einzelnes „rezessives“ Bit enthält. (5) Bestätigungsfeld: Das Bestätigungsfeld ist 2 Bit lang und enthält die Bestätigungslücke und das Bestätigungstrennzeichen. Im Bestätigungsfeld sendet die sendende Station zwei „rezessive“ Bits. Wenn der Empfänger eine gültige Nachricht korrekt empfängt, sendet er während der Bestätigungslücke ein ACK-Signal (eine „dominante“ Bit) zur Bestätigung an den Sender. (6) Ende des Frames Jeder Daten- und Remote-Frame wird durch eine Flag-Sequenz begrenzt. Diese Flag-Sequenz besteht aus 7 „rezessiven“ Bits. 2.2 Übertragungssteuerung (1) Interframe-Abstand Für Stationen, die nicht „fehlerpassiv“ sind oder die vorherige Nachricht empfangen haben, ist der Interframe-Abstand in Abbildung 4 dargestellt. Für Stationen, die die vorherige Nachricht „fehlerpassiv“ gesendet haben, ist der Interframe-Abstand in Abbildung 5 dargestellt. Die Pause besteht aus drei obligatorischen rezessiven Bits. (2) Bitstromcodierung Teile des Frames, wie der Frame-Start, das Arbitrierungsfeld, das Steuerfeld, das Datenfeld und die CRC-Sequenz, werden durch Bit-Stuffing codiert. Sobald der Sender fünf aufeinanderfolgende Identifikationswerte im Bitstrom erkennt, fügt er automatisch ein Komplementärbit ein. Die übrigen Bitfelder von Daten- oder Remote-Frames (CRC-Trennzeichen, Bestätigungsfeld und Frame-Ende) bleiben unverändert und werden nicht mit Bit-Stuffing überschrieben. Fehler- und Überlastungs-Frames verhalten sich ebenfalls gleich, werden aber nicht durch Bit-Stuffing codiert. Der Bitstrom in ihren Nachrichten wird gemäß dem „Do Not Return to Zero“-Prinzip codiert. Das heißt, der Bitpegel ist während der gesamten Bitzeit entweder „dominant“ oder „rezessiv“. Das CAN-Protokoll spezifiziert lediglich die beiden logischen Werte „dominant“ und „rezessiv“, ohne den physikalischen Zustand dieser Pegel explizit zu definieren. Basierend auf der logischen Beziehung kann der „dominante“ Wert auf „0“ und der „rezessive“ Wert auf „1“ gesetzt werden. 3 Profibus-Datenverbindungsschicht-Frame-Format und zugehörige Adressspezifikationen (1) Frame-Zeichen (UART-Zeichen): Ein Frame besteht aus Frame-Zeichen. Jedes Frame-Zeichen besteht aus 11 Bits: 1 Startbit (ST), 8 Informationsbits, 1 Paritätsbit (P) und 1 Stoppbit. (2) Beispiele für Frame-Formate: Profibus-Frames gibt es in vier Typen: 1) Frames fester Länge ohne Datenfelder, 2) Frames fester Länge mit Datenfeldern, 3) Frames mit variabler Datenfeldlänge und 4) Token-Frames. Dabei gilt: SYN (Synchronisierungszeit) muss vor allen aktiven Frames vorhanden sein. SD1 (Starttrennzeichen, Wert 10H), SD2 (Starttrennzeichen, Wert 68H), SD1 (Starttrennzeichen, Wert A2H), SD1 (Starttrennzeichen, Wert DCH). LE (Informationsbyte-Länge) umfasst DA, SA, FC und DATA_UNIT. LE ist die Länge der sich wiederholenden Informationsbytes. DA ist die Zieladresse, SA die Quelladresse, FC die Frame-Steuerung und DATA_UNIT das Datenfeld. Es umfasst 8 Zeichen in einem Frame fester Länge und wird durch LE in einem Frame mit variabler Datenfeldlänge bestimmt, bis maximal 246 Zeichen. FCS ist die Frame-Prüfsequenz, ED das Endtrennzeichen mit dem Wert 16H. SC ist das einzelne Zeichen des kurzen Bestätigungsframes mit dem Wert E5H. (3) Die Adresszeichenstruktur im Frame-Header ist wie folgt: Die unteren 7 Bits der Adressbitgruppe geben die Stationsadresse an. Ohne Erweiterung stehen somit 127 Stationsadressen (0 bis 126) für Master- und Slave-Stationen zur Verfügung (wobei 127 als globale Adresse verwendet wird). Das EXT-Bit zeigt an, ob eine Adresserweiterung in der Dateneinheit (DATA UNIT) vorliegt. Aus Effizienzgründen ist die Adresserweiterung in Profibus-DP nicht zulässig. (4) Service Access Point (SAP): Das Profibus-DP-Protokoll verwendet den FDL-Service-Access-Point (SAP) als Basisfunktionscode. Dieser SAP ist vergleichbar mit einem Port im bekannten TCP/IP-Protokoll. Das im Profibus-DP-Protokoll üblicherweise verwendete Frame-Format sieht wie folgt aus, wobei das höchstwertige Bit des Adressfelds auf 1 gesetzt ist. Frame-Inhaltskonvertierung: Im Allgemeinen ist der Profibus-Feldbus als Master-Slave-Architektur aufgebaut, wobei Master und Slave über Polling kommunizieren. CAN verfügt ebenfalls über eine Master-Slave-Architektur, verwendet jedoch ein prioritätsbasiertes, bitweises Arbitrierungsverfahren (CSMA/MBA). Werden diese beiden Feldbusse miteinander verbunden, sollte in den meisten Fällen das CAN-Segment als Profibus-Slave verwendet werden. CAN-Frames sind kürzer und unterliegen einer strengen Fehlerkontrolle; das Datenfeld in jedem CAN-Frame umfasst maximal 8 Byte. Profibus hingegen verwendet üblicherweise einen einzelnen Frame mit variablen Datenfeldern, die bis zu 246 Byte umfassen können, wobei jedes Byte (UART-Zeichen) eine bessere Fehlerkontrolle aufweist. Bei dieser Konvertierung müssen wir uns auf die Adressübersetzung und die Frame-Aufteilung konzentrieren. 4.1 Adressübersetzung Wie bereits erwähnt, wird die Profibus-DP-Stationsadresse (DA/SA) durch die unteren 7 Bit eines Bytes im Frame dargestellt; Das CAN-Protokoll-Frame besitzt jedoch kein explizites Adressbit. Es verwendet eine 11-Bit- (CAN2.OA) bzw. 29-Bit-Kennung (CAN2.OB) im Arbitrierungsfeld, um die relevanten Empfangsinformationen des Frames darzustellen. Dadurch kann der empfangende Knoten entscheiden, ob er den Frame empfangen möchte. Die eigentlichen Adressinformationen müssen daher in der Kennung enthalten sein. Das CAN-Protokoll legt die Zuordnung der Informationskennungen (IDs) nicht fest; je nach Anwendung können unterschiedliche Methoden verwendet werden. Die Bestimmung der Kennungszuordnung ist von großer Bedeutung und ein wichtiges Forschungsgebiet für Protokolle höherer Schichten und Anwendungsprotokolle. In dieser Arbeit verwenden wir der Einfachheit halber nur das CAN2.OA-Frame-Format. Zunächst untersuchen wir dessen Kennungszuordnungsmethode. Viele Feldbusprotokolle höherer Schichten weltweit basieren auf dem CAN-Protokoll, beispielsweise CANopen, Modbus und DeviceNet. Zur Vereinfachung der Untersuchung verwenden wir im Folgenden das „HiLon Protocol B“-Protokoll. Im Folgenden geben wir eine kurze Einführung in das „HiLon Protocol B“. Das HiLon Protocol B ist ein allgemeines Protokoll. Dieses Protokoll basiert auf einer symmetrischen Multi-Master-Netzwerkstruktur und unterstützt Broadcast- und Punkt-zu-Punkt-Übertragung von Befehlsdaten. Befehlsdatenpakete können bis zu 256 Byte lang sein. Das Protokoll basiert auf der CAN2.OA-Frame-Struktur. Das folgende Diagramm zeigt das Frame-Nachrichtenformat. Ein Standard-CAN2.OA-Frame besteht aus einer 11-Bit-ID, einem 1-Bit-RTR, einem 4-Bit-DLC und einem Datenbereich (maximal 8 Byte). PRI: Reserviertes Bit (kann als Prioritätsbit verwendet werden). Normalerweise ist das reservierte Bit auf 1 gesetzt. Es kann auch als Prioritätsbit verwendet werden, wobei 1 für niedrige Priorität, 0 für hohe Priorität steht und die restliche Priorität durch die Quelladresse bestimmt wird (niedrigere Adressen haben höhere Priorität). Diese reservierte Funktion kann die Übertragung von Notfallinformationen wie Alarmen effektiv unterstützen. Quelladresse: Die Adresse des Knotens, der Daten sendet. Sie kann nur zwischen 0 und 125 eingestellt werden. TYP: Frame-Typ. Siehe die Beschreibung der Frame-Typen in der folgenden Tabelle. DLC: Anzahl der Bytes pro Frame (1 bis 8). Zieladresse: Die Adresse des Knotens, der die Daten empfängt. Sie kann nur zwischen 0 und 125 eingestellt werden. Index: Indexbyte. Bei Einzelframe-Daten repräsentiert dieses Byte das erste Byte der übertragenen Daten; bei Mehrframe-Daten repräsentiert dieses Byte das Indexbyte, d. h. die Position dieses Frames im Datenpaket. `data`: Daten. Profibus verfügt über 127 Stationsadressen im Bereich von 0 bis 126, wobei 127 die globale Adresse ist. Der Unterschied zwischen den beiden ist nicht signifikant. Da dies nur zu Forschungszwecken dient, können wir das HilonB-Protokoll leicht modifizieren und den Adressbereich auf 0–126 erweitern. Dies hat keinen Einfluss auf die Länge und Struktur des gesamten CAN-Frames. Daher können wir alle Profibus- und CAN-Geräte einheitlich adressieren. Die Stationsadresse ist im gesamten System eindeutig; bei der Frame-Konvertierung müssen wir lediglich die Adressinformationen der entsprechenden Bits direkt kopieren. 4.2 Frame-Aufteilung und -Zusammenführung Um einen langen Profibus-Frame in einen kurzen CAN-Frame zu laden, müssen die Daten im Profibus-Frame in für die CAN-Frame-Übertragung geeignete Abschnitte aufgeteilt werden. Die maximale Länge des Datenfelds in einem CAN-Frame beträgt nur 8 Byte. Darüber hinaus werden in unserem verwendeten High-Level-Protokoll HiLon B zwei Byte des Datenfelds als Zieladresse und Frame-Index verwendet, sodass nur 6 Byte für die Datenübertragung verbleiben. Der längste Profibus-Datenframe enthält 246 Datenbyte. Daher werden 246/6 = 41 CAN-Frames benötigt, um diesen langen Frame aufzunehmen. Wir haben zuvor ein Byte als Frame-Index-Byte im CAN-Frame verwendet. Bei der Frame-Konvertierung teilen wir den Profibus-Frame in 6-Byte-Abschnitte auf, fügen die Zieladresse und den Frame-Index hinzu, und dies bildet den Inhalt des CAN-Frames. Der Zielknoten empfängt diese Frames und setzt sie wieder zusammen, um die zu übertragenden Informationen zu erhalten. Die Rückübertragung erfolgt einfach in umgekehrter Reihenfolge. 4.3 Konvertierung von Frame-Steuerinformationen Weitere Steuerinformationen in PROFIBUS-Datenframes umfassen SD2 (68H), LE (Datenlänge), FC (Frame-Steueroktett), FCS (Frame-Prüfsequenz) und ED (16H). Diese Informationen werden anhand der Frame-Daten selbst berechnet und vom Empfänger zur Datenidentifizierung verwendet. Daher werden diese Informationen nicht mehr benötigt, sobald der Protokollkonverter den Frame korrekt empfangen hat. Im nächsten Schritt werden die empfangenen Informationen in einen CAN-Frame codiert, die CAN-Steuerinformationen hinzugefügt, die CRC-Sequenz berechnet und zu einem CAN-Frame kombiniert, der anschließend an den CAN-Knoten gesendet wird. Umgekehrt extrahiert der Protokollkonverter nach dem korrekten Empfang des CAN-Frames lediglich dessen Dateninhalt und generiert dann gemäß dem PROFIBUS-Protokoll einen PROFIBUS-Frame, wenn er einen CAN-Frame in einen PROFIBUS-Frame konvertieren muss. 5 Fehlerbehandlung Jeder Feldbus-Kommunikationsprotokoll-Frame verfügt über ein eigenes Fehlererkennungsverfahren. Fehler müssen auf beiden Seiten der Protokollkonvertierung gemäß den jeweiligen Verfahren erkannt werden. Erkennt der Protokollkonverter einen Fehler, muss er diesen abfangen. 5.1 Profibus-Fehlererkennung und -steuerung Wie bereits erwähnt, verwenden Profibus-Frames UART-Zeichen. Das 10. Bit ist das Paritätsbit. Wird eine fehlerhafte Parität eines Zeichens erkannt, ist dieses fehlerhaft. Der Profibus-Datenframe enthält ein FCS-Bit, ein Prüfoktett, das sich aus der arithmetischen Summe von DA, SA, FC und DATA UNIT ergibt. Dieses Oktett ermöglicht die Überprüfung der Datenkorrektheit beim Empfang eines Frames. Darüber hinaus gibt es einige offensichtliche Fehler, wie z. B. Timeout, fehlerhafte Start- und Endbegrenzer, ungültige Frame-Länge, Antwortanzahl usw. Der Protokollkonverter fungiert als Profibus-Knoten auf der Profibus-Busseite. Empfängt er einen aktiven Frame fehlerhaft, verarbeitet, bestätigt oder antwortet er nicht. Nach Ablauf des Zeitschlitzes wiederholt der Initiator die Anfrage. Die Anfrage gilt erst dann als abgeschlossen, wenn eine gültige Antwort empfangen wurde oder mehrere Wiederholungsversuche erfolglos waren. Wenn der Protokollkonverter nach dem Senden eines aktiven Frames keinen korrekten Antwort-Frame empfängt, wiederholt er die Übertragung so lange, bis die Gegenstelle als nicht aktiv markiert wird. 5.2 Fehlererkennung und -behandlung von CAN 5.2.1 Fehlertypen Das CAN-Protokoll definiert die folgenden fünf Fehlertypen. Der Protokollkonverter muss diese Fehler erkennen und behandeln. (1) Bitfehler: Die Station überwacht den Bus während des Sendens von Bits. Stimmt der gesendete Bitwert nicht mit dem überwachten Bitwert überein, wird während dieser Bitzeit ein Bitfehler erkannt. (2) Bit-Stuffing-Fehler: Tritt in den mit Bit-Stuffing codierten Informationen ein sechstes aufeinanderfolgendes identisches Bit auf, wird ein Bit-Stuffing-Fehler erkannt. (3) CRC-Fehler: Die CRC-Sequenz enthält das Ergebnis der CRC-Berechnung des Senders. Der Empfänger berechnet die CRC auf dieselbe Weise wie der Sender. Stimmt das Berechnungsergebnis nicht mit dem Ergebnis der empfangenen CRC-Sequenz überein, wird ein CRC-Fehler erkannt. (4) Formfehler: Enthält ein Bitfeld mit fester Form ein oder mehrere ungültige Bits, wird ein Formfehler erkannt. (5) Bestätigungsfehler: Der Sender erkennt einen Bestätigungsfehler, solange das überwachte Bit im ACK-Slot nicht dominant ist. 5.2.2 Fehlerzustand: CAN definiert einen Mechanismus zur Fehlerzustandserkennung. Ein Knoten kann sich in einem der folgenden drei Fehlerzustände befinden: (1) Aktiver Fehler: Erkennt ein Knoten im aktiven Fehlerzustand einen der oben genannten Fehler, sendet er einen aktiven Fehler-Frame mit 6 aufeinanderfolgenden dominanten Bits. Dieser Frame überdeckt alle gleichzeitig gesendeten Frames und führt dazu, dass andere Knoten einen Padding-Fehler erkennen und den aktuellen Frame verwerfen. (2) Passiver Fehler: Erkennt ein Knoten im passiven Fehlerzustand einen der oben genannten Fehler, sendet er einen passiven Fehler-Frame mit 6 aufeinanderfolgenden rezessiven Bits. Dieser Frame wird von anderen gleichzeitig gesendeten Frames überdeckt. Erkennen andere Stationen diesen Fehler nicht, verwerfen sie den aktuellen Frame nicht. (3) Offline: 5.2.3 Fehlerbehandlung: Zur Fehlererkennung sollte unser Protokollkonverter zwei Zähler einrichten: einen Sendefehlerzähler und einen Empfangsfehlerzähler. Anschließend kann der Knoten wie ein gewöhnlicher CAN-Knoten im CAN-Netzwerk verwendet werden, wobei die Fehlerbehandlungsmethode identisch ist. (1) Der Fehlerzähler wird initialisiert. Er setzt seinen Wert auf 0, und der Knoten befindet sich im aktiven Fehlerzustand. In diesem Zustand wird angenommen, dass alle erkannten Fehler nicht von diesem Knoten verursacht werden. (2) Der Wert des entsprechenden Zählers wird je nach Fehlertyp inkrementiert. Erfolgreiches Senden oder Empfangen dekrementiert die Zähler bis auf 0. (3) Sobald einer dieser Zähler den von CAN definierten Schwellenwert überschreitet, wechselt der Knoten in den passiven Fehlerzustand. Er gilt nun als Fehlerursache. (4) Sobald die Werte der Sende- und Empfangsfehlerzähler des passiven Knotens unter den von CAN definierten Schwellenwert fallen, wechselt der Knoten wieder in den aktiven Fehlerzustand. (5) Überschreitet der Wert der Sendefehlerzähler einen weiteren von CAN definierten Schwellenwert, wechselt der Knoten in den Offline-Zustand. Ein manueller Eingriff ist erforderlich, um den Knoten aus dem Offline-Zustand wieder in den aktiven Fehlerzustand zu versetzen. Die obigen Ausführungen beschreiben die Fehlerkontroll- und -verarbeitungsmethoden des Feldbus-Protokollkonverters, den wir in den jeweiligen Feldbusbereichen auf beiden Seiten untersucht haben. Die Fehler beider Seiten müssen behoben werden, bevor die Frame-Konvertierung erfolgen kann. Bei der Konvertierung von einem Profibus-Frame in einen CAN-Frame wird die Adress- und Inhaltskonvertierung erst durchgeführt, nachdem der Inhalt des Frames auf Korrektheit geprüft wurde. Anschließend wird die CRC-Sequenz des Frames für die CAN-Segment-Kommunikation berechnet. Das Gleiche gilt auch umgekehrt. 6. Fazit: Dieser Artikel analysiert die Eigenschaften von Profibus- und CAN-Frames und stellt eine Methode zur Implementierung der Frame-Konvertierung zwischen diesen beiden Bussystemen vor. Eine einfache Frame-Konvertierung ist jedoch nicht ausreichend; sie ist nur ein Teil der Protokollkonvertierung des Feldbusses. Um die Zusammenarbeit mehrerer Feldbusse zu ermöglichen, ist noch viel Arbeit nötig. Die Internationale Elektrotechnische Kommission (IEC) begann 1984 mit den Vorbereitungen zur Entwicklung eines einheitlichen internationalen Standards für Feldbusse. Aufgrund historischer Gegebenheiten wie der Branchen- und Regionalentwicklung sowie der Eigeninteressen verschiedener Unternehmen und Konzerne entbrannte jedoch ein heftiger Kampf um die Standardisierung der Feldbustechnologie. Nach zahlreichen Kompromissen wurde Ende 1999 die IEC 61158 verabschiedet, die acht Bussysteme wie FF und Profibus umfasste. Das Ziel, einen einheitlichen Standard zu etablieren, wurde damit nicht erreicht. Dies deutet darauf hin, dass mehrere Feldbussysteme noch längere Zeit parallel existieren werden und die System- und Informationsintegration von Steuerungsnetzwerken vor komplexen und anspruchsvollen Herausforderungen steht. Sowohl Anwender als auch Hersteller verfolgen die Entwicklungen in der Feldbustechnologie aufmerksam und suchen nach leistungsstarken und kostengünstigen Lösungen.