Auf Initiative der Automobilindustrie hat Bosch vor zwei Jahren in Diskussion mit anderen CAN-Experten das Protokoll CAN-FD (Flexible Datenrate) entwickelt. Dabei wurde auf eine Rückwärtskompatibilität zum bisherigen in ISO 11898-1 international genormten CAN-Protokoll geachtet. Der Grundgedanke der Verbesserung ist einfach: Wenn die Busarbitrierung abgeschlossen ist - also nur noch ein Teilnehmer senden darf - wird auf eine höhere Geschwindigkeit umgeschaltet und vor dem Acknowledgement-Feld wird die Datenrate wieder gedrosselt. Gleichzeitig wurde das Datenfeld auf maximal 64Byte verlängert. Bei einer achtfachen Geschwindigkeit bleibt die Übertragungszeit eines Telegrammes mit achtfachen Nutzdaten ungefähr gleich. Dabei sind nur die zusätzlichen Steuerbits nicht berücksichtigt. Außerdem variiert die Telegrammlänge des Bitstuffings in Abhängigkeit von dem Dateninhalt um einige Bits.Die Unterscheidung, ob es sich um ein klassisches CAN-Telegramm handelt oder um ein CAN-FD-Frame, entscheidet sich mit dem ehemals reservierten ersten Bit (r1). Ist dieses FDF-Bit rezessiv, handelt es sich um eine CAN-FD-Nachricht. Da bisherige CAN-Controller ein rezessives r1-Bit mit einem Fehlertelegramm beantworten, dürfen in einem Netzwerk nur CAN-FD-tolerante Teilnehmer aktiv sein, wenn eine CAN-FD-Nachricht übertragen wird. Die in Überarbeitung befindliche Norm (ISO 11898-1) wird dies von zukünftigen CAN-Controllern verlangen. Zwischenzeitlich kann man klassische CAN-Controller während der CAN-FD-Kommunikation in den Ruhezustand versetzten und anschließend wieder aufwecken. Dies wird durch die CAN-Transceiver nach ISO 11898-6 unterstützt, die ein selektives Aufwachen ermöglichen. Bei ihnen wurde bereits eine CAN-FD-Toleranz vorgesehen. Abbildung 1 zeigt den Aufbau einer CAN-FD-Nachricht. Nach dem Start-of-Frame-Bit folgt der CAN-Identifier. Das RTR-Bit wird ignoriert, da das CAN-FD-Protokoll keine Remote-Frames unterstützt. Mit dem IDE-Bit erfolgt die Unterscheidung, ob die Nachricht den 11-Bit-Identifier (IDE ist dominant) oder den 29-Bit-Identifier (IDE ist rezessiv) verwendet. Das folgende FDF-Bit dient zur Unterscheidung zwischen dem klassischen CAN-Format und dem CAN-FD-Format. Nach dem reservierten Bit (r0) schaltet der CAN-Controller im BRS-Bit gegebenenfalls (rezessiv) auf die höhere Datenrate um. Im Falle, dass es dominant übertragen wird, wird die Geschwindigkeit beibehalten und abhängig vom Datenlängencode (DLC) können bis zu 64 Byte Nutzdaten gesendet werden. Vor dem 4-Bit-DLC wird noch das ESI-Bit übertragen. Es signalisiert den Zustand des CAN-Controllers (dominant = aktiver Fehlerzustand, rezessiv = passiver Fehlerzustand). Das folgende Datenfeld hat eine minimale Länge von 0Byte und eine maximale Länge von 64 Byte. Das anschließende CRC-Feld ist für CAN-FD-Telegramme entweder 18 Bit (bis zu 16 Byte Nutzdaten) oder 22 Bit lang (Nutzdaten über 16 Byte). Im CRC-Delimiter-Bit (das 18. bzw. 22. Bit) erfolgt die Umschaltung auf die Arbitration-Bitrate. Der Rest des CAN-FD-Telegramms ist identisch mit dem der klassischen CAN-Nachricht einschließlich des 3 Bit langen Inter-frame-space.
Theorie und Praxis
Theoretisch hängt die höhere Geschwindigkeit nur von der Laufzeiten-Kompensation ab. Im Labor wurden mit herkömmlichen CAN-Transceivern Datenraten bis zu 15 MBit/s erreicht. In der Praxis, d. h. über den gesamten Temperaturbereich, sind jedoch Einschränkungen zu berücksichtigen. Dies resultiert vor allem aus dem unsymmetrischen Verhalten der Transceiver bei niedrigen Temperaturen: Die dominanten Bits werden länger und die rezessiven werden kürzer. Außerdem dürfen die in der Arbitrierungsphase erlaubten Zeittoleranzen nicht zu Problemen in der schnellen Phase führen. Deshalb ist das Verhältnis von den Geschwindigkeiten praktisch auf 1:8 begrenzt (bei einer Arbitrierungsbitrate von 250 kBit/s ist also eine maximale Datenrate von 2 MBit/s zu empfehlen). Die CiA-Anwendervereinigung erarbeitet derzeit an weiteren Empfehlungen für den Einsatz von CAN-FD-Netzwerken, die in der Dokumentenreihe CiA 601 zusammengefasst sind. Darin wird untern anderem empfohlen, dass in allen Teilnehmer das gleiche Bittiming verwendet wird, dies schließt auch die Oszillatorfrequenz ein. Derzeit werden 80, 40, und 20 MHz empfohlen.Eine wesentliche Forderung der PKW-Hersteller ist die Verwendung der gleichen Kabel und Topologien. Dies wurde bei dem ersten CAN-FD-Plugfest in den CiA-Räumlichkeiten getestet. Neben Buslinien-Topologien wurden auch passive Sterne (mit und ohne zentralem Anschlusswiderstand) aufgebaut. Die Hersteller von Transceivern arbeiten daran, ihre Bausteine für höhere Datenraten zu qualifizieren. Die ersten Chips für Datenraten bis 2 MBit/s sind bereits angekündigt.
Auswirkungen auf höhere Protokolle
Da heute die meisten industriellen CAN-Anwender standardisierte höhere Protokolle wie CANopen verwenden, stellt sich die Frage, welche Auswirkungen hat CAN-FD auf die in CANopen zur Verfügung gestellten Kommunikationsdienste - besonders auf die Servicedatenobjekte (SDO) und die Prozessdatenobjekte (PDO). Bezüglich der bestätigten SDO-Dienste lassen sich mit CAN-FD längere Parameter mit einer Nachricht übertragen. Bei einem SDO-Overhead von 4Byte sind mit einer Nachricht 60-Byte-Parameter les- und schreibbar. Auch beim segmentierten SDO-Transfer ist eine beschleunigte Übertragung möglich, da der Overhead relativ sinkt. Meines Erachtens wichtiger ist der Vorteil bei der unbestätigten PDO-Übertragung. Mit CAN-FD kann beispielsweise ein Hostcontroller mit einem PDO mehrere Achsen mit einem Steuerwort (16-Bit) und mit unterschiedlichen Sollwerten versorgen. Da nur eine CAN-FD-Nachricht verwendet wird (sie wird von allen Servocontrollern empfangen), ist eine Synchronisierung wie bisher nicht notwendig. Die Statusmeldungen müssen selbstverständlich immer noch synchronisiert werden, damit alle Istwerte zum gleichen Zeitpunkt erfasst werden. Allerdings müssen die CANopen-Geräteprofile und -Anwendungsprofile entsprechend erweitert werden. Auch für komplexe Sensoren ist eine Erweiterung der Nutzdaten auf bis 64 Byte sehr interessant: In der Erdölindustrie werden CANopen-Netzwerke beispielsweise für die Überwachung der Bohrungen verwendet, wobei beispielsweise auch mehrphasige Durchflussmessgeräte zum Einsatz kommen. Das wohl am weitesten verbreitete Antriebsprofil CiA 402 wird mit CAN-FD eine deutliche Leistungssteigerung erfahren. Denkbar sind mit CAN-FD auch „höherwertige“ CANopen-Profile für Mehrachssysteme (z. B. Kreuztische, Dispenser und Dilutoren für die Laborautomation sowie komplexe Greifer für Roboter). �?hnliche Überlegungen können auch für andere Transport-Protokolle (z. B. ISO-TP für die Automobilindustrie) und Anwendungsprotokolle (e.g. J1939, Isobus und NMEA2000) angestellt werden. Die entsprechenden Organisationen und Normungsgremien sind informiert und diskutieren bereits die Auswirkungen auf die bestehenden Spezifikationen bzw. Normen. Für das in ISO 15765-2 genormte Transport-Protokoll gibt es bereits mehrere Vorschläge, wie man es mit CAN-FD-Telegrammen verwenden kann. Auf der diesjährigen internationalen CAN-Konferenz, die im November in Paris stattfindet, werden sicherlich weitere Anwendungsmöglichkeiten diskutiert.
