Wie funktioniert das CAN-Bus-Protokoll?

Das Controller Area Network (CAN) verbindet gleichberechtigte Komponenten mit einem 2-Draht-Bus miteinander. Dabei spielen Konzepte wie die Bitübertragungsschicht (Physical Layer) und verschiedene Hardwarestandards eine Rolle, wie HS-CAN und Low-Speed-Fehlertoleranz-CAN. Das wichtigste Konzept, das wir im Auge behalten müssen, um die übergeordneten Schichten des CAN-Busses zu verstehen, ist jedoch das der rezessiven und dominanten Bits.

Der Roh-Bitstrom unterscheidet sich von den meisten anderen digitalen Bussen, die einfach zwei unterschiedliche Spannungspegel verwenden, um 1 und 0 zu kodieren. Der Bus wird dominant angesteuert, während er sich durch die Abschlusswiderstände rezessiv verhält, wenn er nicht aktiv angesteuert wird. Mit anderen Worten: Ein dominantes Bit ist 0, ein rezessives Bit ist 1.

Während die Bitübertragungsschicht für die Unterdrückung elektromagnetischer Störungen (EMI) und die allgemeine „Robustheit“ des Standards verantwortlich ist, so sorgt das Protokoll für die Eigenschaften, die den CAN-Bus vom Wettbewerb abheben, wie z. B. die zerstörungsfreie Arbitrierung oder die Kollisionserkennung.

Das CAN-Bus-Protokoll

Das CAN-Bus-Protokoll eignet sich am besten für kurze, maximal 8-Byte-lange Broadcast-Nachrichten, die nicht an einen bestimmten Teilnehmer (Knoten) gerichtet sind, sondern von einem Knoten an das gesamte Netzwerk verschickt werden.

Die Website kvaser.com, einer der führenden Anbieter von CAN-Bus Hard- und Software, erklärt es so:

„Hallo zusammen, hier sind ein paar Daten mit der Kennzeichnung X, ich hoffe, sie gefallen euch!“

Und damit liegen sie goldrichtig!

Diese Kennzeichnung wird Identifier genannt und er ist das schlagende Herz des CAN-Bus-Protokolls. Der Identifier ist ein 11-Bit-Feld im Standard-CAN-Bus-Protokoll bzw. ein 29-Bit-Feld im erweiterten CAN-Protokoll.

Ihre Majestät, der (11-Bit)-Identifier

Da sich alle Knoten die gleiche Übertragungsleitung teilen, muss es eine Möglichkeit geben, zu entscheiden, wer sprechen darf und wer schweigen soll. Im CAN-Bus lauscht immer jeder Knoten, auch der, der gerade sendet. Diese Betriebsart schlägt sich in den internen Schaltungen der Transceiver wieder, wie z. B. nachstehend von TI, wo Eingangs- und Ausgangsschaltungen zusammen verdrahtet sind:

Nachrichten mit höherer Priorität haben einen niederwertigen Identifier. Angenommen, zwei Knoten wollen gleichzeitig 0b0100000 (Knoten A) und 0b0110000 (Knoten B) übertragen. Dann passiert Folgendes:

• (Bit 6): A und B treiben den Bus auf dominant. Sie lauschen, der Bus ist dominant. Alles läuft wie geplant.
• (Bit 5): A und B treiben den Bus nicht und bleiben im rezessiven Zustand. Sie lauschen, der Bus ist rezessiv. Alles läuft wie geplant.
• (Bit 4): A steuert den Bus rezessiv und lauscht: alles in Ordnung! B steuert den Bus nicht, da das Bit rezessiv sein soll. Aber der Bus wird von A gesteuert. B schweigt nicht, da A die Arbitration gewonnen hat. B kann eine Fehlermeldung senden, um beim nächsten Mal zu warnen, dass es eine Kollision gegeben hat.
• (Bit 3–0): wiederholen den Vorgang.

Die Arbitrierung ist nicht destruktiv, da der Knoten, der das Verfahren gewinnt, die Übertragung ohne Beeinträchtigung fortsetzt. Das System funktioniert genauso mit einem 29-Bit-Identifier. Allerdings gibt es ein paar Bits in der Mitte, da er in zwei Felder von 11-Bit bzw. 18-Bit aufgeteilt ist.

Der Standard-CAN-Bus-Frame

Nachdem wir nun besprochen haben, wie die Arbitrierung funktioniert, wollen wir einen Blick auf die Bits einer Standard-CAN-Bus-Nachricht mit einem 11-Bit-Identifier werfen.

• SOF: Start-of-Frame. Wie die meisten Protokolle beginnt auch der CAN-Bus mit einem netten kleinen Bit; in diesem Fall einem dominanten Bit. Die Vorderkante wird auch zur Synchronisierung der Knoten verwendet.
• Identifier: Dies ist, wie besprochen, der Identifier. Wie zu erkennen ist, steht er am Anfang eines Frames, sodass immer klar ist, welcher Knoten während der Kommunikation das Senderecht hat.
• RTR: Remote Transmission Request. Dominant, wenn die Nachricht verwendet wird, um Informationen von einem anderen Knoten anzufordern, statt diese zu bestätigen. „Hey Kumpel, erzähl mir was über X“.
• IDE: Identifier Extension. Ist dieses Bit dominant, handelt es sich bei dem Frame um eine Standard-CAN-Bus-Nachricht mit einem 11-Bit-Identifier.
• r0: reserviertes Bit für zukünftige Erweiterungen.
• DLC: 4-Bit-Datenlängencode, zählt die Anzahl der übertragenen Bytes.
• Daten: die lieben, kleinen Daten, die übertragen werden.
• CRC: 15 Bit der guten alten zyklischen Redundanzprüfung.
• CRC-Delimiter: Ein rezessives Füllbit.
• ACK: Dieses Bit ist sehr speziell. Jeder empfangende Knoten überschreibt das rezessive ACK-Bit mit einem dominanten Bit und quittiert damit den Empfang (bei korrektem CRC) durch mindestens einen Knoten. Wenn ein Knoten Probleme beim Lesen der Nachricht hatte, muss er beim nächsten Mal einen Fehler-Frame senden.
• ACK-Delimiter: ein rezessives Füllbit.
• EOF: End-of-Frame, eine Abfolge von sieben rezessiven Bits.

Zum Glück müssen Sie sich um nichts von alledem kümmern. CAN-Bus-Controller sind unglaublich ausgeklügelte Systeme und handhaben automatisch das gesamte Netzwerkprotokoll, die Fehlerkommunikation, CRC und ähnliches. Sie werden in der Regel nur durch Angabe von Identifier, Daten und eventuellen Filtern für die eingehenden Frames bedient.

Zu beachtende Dinge – Datenfeldlänge

Die maximale Länge des Datenfeldes in einem CAN-Bus-Frame beträgt 64 Bit bzw. 8 Byte. Die 8 Bytes machen den Umgang mit Standard-Binärformaten wie 32- und 64-Bit-Fließkommazahlen viel einfacher als bei konkurrierenden Verfahren wie z. B. Modbus, bei dem nur auf 16-Bit-Speicherbereiche nacheinander zugegriffen werden kann.

Gleichzeitig sind 8 Byte nicht viel. Wenn man versucht, binäre Daten zu übertragen, dann wird der Platz schnell knapp. Wie wir noch sehen werden, sorgen High-Level-Protokolle, wie CANopen, hier für Abhilfe.

Zu beachtende Dinge – Bit-Stuffing

CAN verwendet eine Technik namens Bit-Stuffing. Nach fünf aufeinanderfolgenden Bits des gleichen logischen Zustands wird ein Bit des entgegengesetzten Pegels in den Bitstrom eingefügt. Das Bit-Stuffing geschieht nur zwischen einem SOF (Start-of-Frame) und den sieben rezessiven Bits, die ein EOF definieren und ist integraler Bestandteil der automatischen Fehlererkennung der CAN-Bus-Hardware. Getreu dem Motto: Wenn man zu oft die gleichen Werte sieht, ist irgendetwas kaputt!

Beim Debuggen können zufällige Bits außerordentlich nerven. Behalten Sie dies also im Hinterkopf, wenn Sie ein Oszilloskop oder einen Logikanalysator verwenden.

Zu beachtende Dinge – zum Tango gehören immer zwei

Damit ein CAN-Bus-Frame gültig ist, muss der Frame quittiert werden, indem ein rezessives ACK mit einem dominanten überschrieben wird. Somit benötigt das kleinstmögliche CAN-Bus-Netzwerk zwei Knoten. Um die Entwicklung zu vereinfachen, empfehle ich die Verwendung eines gut getesteten kommerziellen Entwicklungsboards als zweiten Knoten.

Übergeordnete Standards – CANopen

Angenommen, Sie wollen, dass Ihre Knoten eine Möglichkeit haben, Informationen von bis zu 8 Byte mit einer prioritätskodierten Identifizierung zu „quittieren“. In diesem Fall benötigen Sie keine höhere Ebene als das CAN-Bus-Protokoll selbst.

Dieser Ansatz ähnelt der Funktionsweise des CAN-Bus-Protokolls in vielen Fahrzeugnetzwerken: Ein Knoten meldet die Gaspedalstellung, und alle anderen lesen diese. Man kann die Identifier geschickt unterteilen, sodass sie mit den Funktionen, die die meisten CAN-Bus-Controller bereitstellen, oder durch das Schreiben eigener Firmware leicht zu maskieren sind.

Es gibt einige Performance-Einschränkungen: Wenn Sie die Identifier nicht geschickt einsetzen und die Nachrichten zeitgenau zugestellt werden müssen, kann es passieren, dass die Bandbreite nur ein Drittel der nominalen Bandbreite beträgt.

Weil die Bitübertragungsschicht und Netzwerkprotokolle des CAN-Busses fast so gut sind wie Mousse au Chocolat, entstanden mehrere übergeordnete Protokolle. Das populärste Protokoll, dass nicht hinter einer hohen Mauer von NDAs und einseitigen Vereinbarungen abgeschottet ist, ist CANopen.

Objektverzeichnis (Object Directory)

Das Objektverzeichnis ist eine Datenstruktur, die eine Reihe von Einträgen enthält, ein bisschen wie eine Datenbanktabelle mit einem „Daten“-Feld, das nahezu jeden binären Typ annehmen kann.

Einige Einträge müssen definiert werden, wie z. B. Fehlerregistrierungen und ein Heartbeat, doch der Rest ist optional. Da der Verzeichnisindex 16-Bit lang ist, sind viele Einträge möglich.

Jeder Eintrag hat die folgenden Attribute:

• Index: 16-Bit-Index
• Objektname: eine den Eintrag beschreibende Zeichenkette
• Größe: einzelner Datensatz oder Array
• Typ: Datentyp des Eintrags: Float, Integer, Array, usw.
• Lesen/Schreiben, Nur-Lesen oder Nur-Schreiben
• Pflichtfeld/Wahlfeld

Dienste

Mittels der CANopen-Dienste kann man auf das Objektverzeichnis zugreifen sowie das Netzwerk und die Knoten steuern. Handelt es sich bei dem Objektverzeichnis um Daten, dann sind Dienste ausführbare Aktionen.

PDO und SDO

Der Service-Data-Object-(SDO)-Dienst ermöglicht das Lesen und Schreiben von Daten von entfernten Notizen innerhalb des Objektverzeichnisses auf Client/Server-Basis. Es kann Daten beliebiger Länge und alle unterstützten Datentypen lesen/schreiben, verwendet aber für jeden Daten-Frame einen Confirmation-Frame, zusätzlich werden 4 der 8 Byte, die für die Kommunikationsverwaltung zur Verfügung stehen, verwendet, und hat somit einen erheblichen Overhead.

Der Process-Data-Object-(PDO)-Dienst ermöglicht das Streamen von Daten mit einer Broadcast-Nachricht in ziemlich genau der gleichen Weise, für die der CAN-Bus konzipiert wurde. PDO ist der Dienst, der z. B. zum Streamen von Sensormesswerten verwendet wird.

Im Gegensatz zu SDO kann der PDO-Dienst mehrere Objektverzeichniseinträge auf einmal übertragen, solange sie sich in 8 Byte quetschen lassen. Jedes PDO hat auch einen eigenen Eintrag im Objektverzeichnis. Da jeder Knoten das Objektverzeichnis lesen kann, z. B. beim Einrichten des Netzwerks zum Zeitpunkt des Hochfahrens, kann auch jeder Teilnehmer nachschlagen, wie die Daten innerhalb einer PDO-Nachricht organisiert sind.

PDOs lassen sich asynchron verwenden, z. B. um eine Nachricht zu senden, wenn ein neuer Sensormesswert auftritt, oder synchron, wenn ein SYNC-Frame empfangen wird. Eine Reihe von ausgeklügelten Timern ermöglicht es, diese Aufgabe zu automatisieren und eine Netzüberlastung mit zu vielen Nachrichten zu vermeiden.

NMT

Die Network-Management-(NMT)-Protokolle werden benutzt, um Knoten zu starten bzw. zu stoppen. Sie erkennen, wann Knoten hochfahren (und damit dem Netzwerk beitreten), und ob sie betriebsbereit sind bzw. Fehlerbedingungen auftreten.

Heartbeat

Das Heartbeat-Protokoll arbeitet mit einer Producer-/Subscriber-Kommunikation: Ein Knoten abonniert den Heartbeat eines anderen, der in regelmäßigen Abständen „Ich lebe noch!“-Nachrichten sendet.

Ähnlich wie beim Heartbeat-Protokoll gibt es Node Guarding, um einen Slave-Knoten im Master/Slave-Betrieb zu überprüfen, und Life Guarding, um den Master vom Slave überprüfen zu lassen.

Zeitstempel

Das Timestamp-Protokoll ermöglicht die Synchronisierung der Uhren mehrerer Knoten bis auf die Mikrosekunde genau. Vom Konzept her ähnelt es dem NTP-Protokoll, das von jedem modernen Computer verwendet wird. Dank der Broadcast-Natur des CAN-Busses können jedoch alle Knoten gleichzeitig synchronisiert werden.

Sync

Das Sync-Protokoll ermöglicht es mehreren Knoten, eine Aktion gleichzeitig auszuführen. Ein Master kann z. B. mehrere Slaves so einrichten, dass sie ihre Sensoren auslesen, wenn eine Sync-Nachricht empfangen wird, und dann den Sync-Frame übertragen, um die Aktion auszulösen.

Notfall

Ein Knoten, bei dem ein schwerwiegender Fehler auftritt, kann eine Notfallmeldung komplett mit benutzerdefinierten Fehlercodes und anderen Daten senden. Der Emergency-Frame hat eine höhere Priorität als Standard-Frames.

Elektronisches Datenblatt

Das Electronic Data Sheet (EDS) ist ein standardisiertes Dateiformat, das das Verhalten von CANopen-Geräten beschreibt. Viele EDS-Editoren erlauben den Export einer umfangreichen Dokumentation des Objektverzeichnisses und des Template-C-Codes, was die Entwicklung deutlich erleichtert.

EDS ist Voraussetzung für die CANopen-Zertifizierung.

Das EDS kann verwendet werden, um den CANopen-Netzwerkverkehr mit Metadaten zu versehen bzw. anzureichern, um die Fehlersuche im Netzwerk zu erleichtern.

Wie man Hilfsdokumentationen verwaltet (das ungeschminkte Verkaufsargument)

Das CAN-Bus-Protokoll kann...unglaublich viel!

Hier ein kleiner Trick, den ich ständig anwende, um die unterstützende Dokumentation über Altium Concord Pro™ auf Altium 365® zu synchronisieren: Der erste Schritt ist die Konvertierung jeder Webseite in PDF-Dateien, die sich einfacher verwalten lassen.

Ich erinnere mich nicht mehr, wie viele verschiedene Anwendungen ich in den letzten Jahren ausprobiert habe, um dies zu bewerkstelligen. Letztlich habe ich mich für die Browser-Erweiterung PrintFriendly entschieden. Sie ist für alle gängigen Browser verfügbar und lässt sich über ein einfaches Javascript-Bookmark verwenden, wodurch es auch mit Android-, iOS- und iPadOS-Geräten kompatibel ist.

In diesem Beispiel konvertiere ich „CAN Bus Explained – A Simple Intro“, ein Tutorial von CSS Electronics; eines, das mein Tutorial in technischer Tiefe und Lesbarkeit bei weitem übertrifft. Überflüssiger Inhalt, wie z. B. die Autoren-Bio oder Werbung, lässt sich leicht entfernen.

Die Dokumente können nun über den Befehl „Add Existing to Project“ zu den Projektdateien hinzugefügt werden. Da die Versionskontrolle auf GIT basiert, ist es wichtig, dass sich alle Projektdokumente im gleichen Stammverzeichnis befinden, da sie sonst nicht in das Repository eingefügt werden können.

Beim Speichern auf dem Server werden die neuen Dokumente beim Commit-Prozess automatisch ausgewählt und sind im Projektbaum zu finden.

Indem Sie Ihre gesamte Dokumentation zusammen mit Ihren Projekten aufbewahren, haben Sie über Altium Designer® darauf bequem Zugriff und können die Freigabe-Funktionen von Altium 365 und die Concord Pro-Projektsynchronisationsfunktionen voll ausschöpfen. Sobald Ihre Dokumentation in Ihrem Projektordner gespeichert ist, wird sie revisionskontrolliert und zusammen mit Ihren Projektdateien verteilt, wodurch das Risiko von Unstimmigkeiten reduziert wird.

Weitere Ressourcen

CAN-Code:

• Canpie C-Bibliothek
• BUSMASTER
• Cantools C-Bibliothek
• Python-Bibliothek
• Canbus Tripe offene HW/SW

CAN-Dokumentation:

• Can-Bus erklärt von CSS Electronics
• Texas Instruments SLLA270: „Controller Area Network Physical Layer Requirements“
• Microchip AN228” „A CAN Physical Layer Discussion“
• Analog Devices AN-1123: „Controller Area Network (CAN) Implementation Guide“
• Wolfhard Lawrenz: „CAN System Engineering“, Springer, ISBN: 978-1-4471-5613-0
• Steve Corrigan (Kvaser): „Minimum distance between CAN nodes“
• Texas Instruments SLLA279A: „Critical Spacing of CAN Bus Connections“

CANopen-Dokumentation:

• CANopen erklärt von CSS Electronics
• Produkthandbücher
• Wikipedia
• Offizielle Website

CANopen Code:

• CANopenNode C-Bibliothek
• CANopenSocket Linux-Bibliothek
• Python-Bibliothek
• Libedssharp Object Dictionary Editor

CANopen Software:

• CANopen Magic (kommerziell)
• CANopen Architect (Kommerziell)
• Caneds kostenloser Object Dictionary Editor
• Linux Can-utils

Fazit

Der CAN-Bus verfügt über eine robuste, zuverlässige Bitübertragungsschicht und ein Protokoll von besonderer Eleganz, das Kollisionserkennung und zerstörungsfreie Arbitrierung ermöglicht und die stetig wachsende Popularität des Standards fördert. Projekte, die den CAN-Bus verwenden, erfordern in der Regel eine umfangreiche Dokumentation. Mit Altium Concord Pro können Sie die gesamte Power von GIT nutzen, um sicherzustellen, dass Ihre Dokumentation einer Versionsverwaltung unterliegt. Außerdem können Sie sie über die Altium-365-Plattform ganz einfach mit Ihren Kollegen und Mitarbeitern teilen. Sprechen Sie noch heute mit einem Altium-Experten, um mehr zu erfahren.