Finger weg von CAN Remote Frames –
und welche Alternativen es heute gibt

Die Verwendung von CAN Remote Frames ist in der Praxis seit Jahren umstritten. Zwar sind sie im klassischen CAN-Protokoll vorgesehen, in modernen Systemen haben sie sich jedoch kaum bewährt. Viele Higher-Layer-Protokolle verzichten bewusst darauf oder verbieten ihren Einsatz sogar. Das hat gute Gründe: Remote Frames führen in realen Anwendungen häufig zu Inkonsistenzen, Implementierungsproblemen und unnötiger Komplexität.

Hinzu kommt, dass sich die technologische Entwicklung klar von diesem Mechanismus entfernt hat: In CAN FD kommen Remote Frames nicht mehr vor, und auch CAN XL sieht sie nicht mehr vor. Damit ist deutlich, dass Remote Frames heute eher ein Altlast-Thema des klassischen CAN sind als eine sinnvolle Grundlage für neue Architekturen.

Ein Remote Frame enthält selbst keine Nutzdaten. Er dient lediglich dazu, die Übertragung eines Data Frames mit derselben CAN-ID anzufordern. Was in der Theorie elegant wirkt, führt in der Praxis oft zu Schwierigkeiten. Denn schon die Frage, wie ein CAN-Controller auf einen Remote Frame reagiert, ist nicht bei allen Implementierungen einheitlich gelöst.

Besonders kritisch ist die automatische Antwort eines CAN-Controllers auf einen Remote Frame. In diesem Fall kann es vorkommen, dass Daten gesendet werden, ohne dass die Applikation kurz zuvor noch einmal prüfen oder aktualisieren konnte, ob diese Daten überhaupt noch gültig sind. Im ungünstigsten Fall antwortet der Controller also mit veralteten Informationen.

Ein weiteres Risiko besteht darin, dass ein CAN-Controller unter Umständen noch auf Remote Frames antwortet, solange seine Protocol Engine aktiv ist – selbst dann, wenn der restliche Mikrocontroller oder die Applikation bereits in einem fehlerhaften Zustand sind. Das bedeutet: Ein Knoten kann nach außen hin noch funktionsfähig erscheinen, obwohl die eigentliche Anwendung intern bereits nicht mehr korrekt arbeitet. Genau das ist in sicherheitskritischen oder diagnostisch relevanten Anwendungen hochproblematisch.

Daher kann die Empfehlung nur lauten: “Finger weg von CAN Remote Frames!”

Bei Remote Frames bleibt oft unklar, wie aktuell die angeforderte Information tatsächlich ist, welcher Knoten in Grenzfällen verantwortlich ist und wie sich Mehrdeutigkeiten sauber vermeiden lassen. Das erschwert nicht nur die Implementierung, sondern auch die Dokumentation und das Testen.

Im Umfeld von CANopen wurden Remote Frames historisch in einzelnen Diensten verwendet oder zumindest berücksichtigt. Die Problematik ist dort seit langem bekannt; unter anderem wurde beschrieben, wie sich CANopen-Netzwerke auch ohne RTR-basierte Kommunikation betreiben lassen (siehe /2/).

Das Node-Guarding wird einfach durch den Heartbeat Service ersetzt, was zudem den Vorteil hat, dass CANopen NMT Slave Geräte sich gegenseitig überwachen können (Node-Guarding kann nur vom NMT Master durchgeführt werden).

Das Anfordern von PDO Nachrichten erfolgt über eine SYNC Botschaft, das Verhalten kann zudem noch in weiten Grenzen eingestellt werden.

Remote Frames gehören zu den Funktionen des klassischen CAN, die auf dem Papier interessant wirken, in realen Systemen aber mehr Probleme verursachen als lösen. Uneinheitliche Implementierungen, potenziell veraltete Daten, schwierige Testbarkeit und die fehlende Unterstützung in modernen CAN-Varianten sprechen klar gegen ihren Einsatz.

Die Empfehlung ist daher eindeutig: Remote Frames sollen nicht verwendet werden. Stattdessen sind zyklische Übertragung, ereignisgesteuerte Kommunikation oder explizite Request-/Response-Mechanismen mit normalen Datenframes die deutlich robusteren und zukunftssicheren Lösungen. Dass CAN FD und CAN XL ohne Remote Frames auskommen, unterstreicht diese Empfehlung zusätzlich.

/1/ ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
/2/ CiA Application Note AN802 – Version 1.1.1, Avoiding CAN Remote Frames in CANopen networks