Controller Area Network

Der CAN-Bus (Controller Area Network) gehört zu den Feldbussen.

Es handelt sich dabei um ein asynchrones, serielles Bussystem, das seit 1983 von Bosch für die Vernetzung von Steuergeräten im Automobil entwickelt wird und 1985 zusammen mit Intel vorgestellt wurde, um die Kabelbäume (bis zu 2 km pro Fahrzeug) zu reduzieren und dadurch Gewicht zu sparen.

Funktion

Übertragungsverfahren

Der CAN-Bus arbeitet nach dem CSMA- (Carrier Sense Multiple Access) Verfahren (vergleiche Ethernet). Die Daten sind NRZ-L codiert. Des Weiteren wird zur Datensicherung Bit-stuffing verwendet (siehe unten). Der Bus ist entweder mit Kupferleitungen oder über Glasfaser ausgeführt. Im Falle von Kupferleitungen arbeitet der CAN-Bus mit Differenzsignalen. Er wird normalerweise mit 3 Leitungen ausgeführt: CAN_HIGH, CAN_LOW und CAN_GND (Masse). CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse. Dadurch können Gleichtaktstörungen unterdrückt werden, da ja die Differenz gleich bleibt.

Die Übertragung der Daten erfolgt so, dass ein Bit, je nach Zustand, entweder dominant oder rezessiv auf den Busleitungen wirkt. Ein dominantes überschreibt dabei ein rezessives.

Übertragungsrate und Leitungslänge

Die maximale Datenübertragungsrate beträgt 1Mbit/s. Dabei ist eine maximale Leitungslänge von 40m möglich. Bei 500kBit/s sind zum Beispiel 100m möglich und bei 125kBit/s 500m. Als Busmedium werden nach ISO11898-2 (High-Speed Medium Access Unit) Twisted-Pair-Kabel mit einem Wellenwiderstand von 108...132 Ohm empfohlen. Alle Teilnehmer kommunizieren mit der gleichen Baudrate.

Topologie

Das CAN-Netzwerk wird als Linienstruktur mit 2 Abschlusswiderständen von je 120 Ohm (zwischen CAN_HIGH und CAN_LOW) aufgebaut. Stichleitungen sind in eingeschränktem Umfang zugänglich.

Objectidentifier

Der Objectidentifier kennzeichnet den Inhalt der Nachricht, nicht das Gerät. Zum Beispiel kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nachricht für sie relevant ist oder nicht.

Zudem dient der Objektidentifier auch der Priorisierung der Nachrichten.

Die Spezifikation definiert zwei verschiedene Identifier-Formate:

11-bit Identifier, auch "Basic CAN frame" genannt
29-bit Identifier, auch "Extended CAN frame" genannt

Ein Teilnehmer kann Empfänger und Sender von Nachrichten beliebig vieler Identifier sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben (damit die Arbitrierung funktioniert).

Arbitrierung (Aushandeln des Medienzugriffs), Priorität

Der Buszugriff wird verlustfrei mittels der bitweisen Arbitrierung auf Basis der Identifier der zu sendenden Nachrichten aufgelöst. Dazu sensiert jeder Sender den Bus während er gerade den Identifier sendet. Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste dominante Bit eines der beiden, das entsprechend rezessive des anderen, welcher dieses erkennt und seinen Übertragungsversuch beendet, damit der andere seine Daten übertragen kann.

Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die Nachricht mit dem niedrigsten Identifier darf "immer" übertragen werden. Für die Übertragung von zeitkritischen Nachrichten kann also ein Identifier hoher Priorität (= niedrige ID, z.B. 0) vergeben werden um ihnen so Vorrang bei der Übertragung zu gewähren.

Folien zur Erläuterung der Arbitrierung

Übrigens: Die Identifier 2032-2047 (standard CAN) sind reserviert und sollten nicht verwendet werden. Der erste CAN Controller, der Intel 82526, benutzte die Bitfolge 0x7F0 als Ende - Markierung im internen DPRAM.

Frame-Aufbau

Es gibt vier verschiedene Arten von Frames

Daten-Frame dient dem Transport von bis zu 8 Okteten Daten
Remote-Frame dient der Anforderung eines Daten-Frames von einem anderen Teilnehmer
Error-Frame signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in der Übertragung
Overload-Frame dient als Zwangspause zwischen Daten- und Remote-Frames

Ein Daten-Frame ist logisch wie folgt aufgebaut:

Start of Frame (SOF) = ein dominantes bit
Arbitrierungsfeld bestehend aus einem Identifier-Segment (11 bit oder 29+2 bit) plus einem RTR bit (Remote Transmission Request, siehe unten )
Kontrollfeld (CTRL) = 6 bit (2 bit reserviert + 4 bit Länge der Daten)
Datenfeld (DATA) = 0-64 bit (in Einheiten von 8 bit)
Prüfsummenfeld (CRC) = 16 bit (15 bit CRC plus einem rezessiven CRC-Delimiter bit)
Bestätigungsfeld (ACK) 2 bit, bestehend aus einem rezessiven ACK-Slot plus einem rezessiven ACK-Delimiter
End of Frame (EOF) 7 bit (rezessiv)
Intermission = 3 bit (=min. Anzahl der Bits die aufeinanderfolgende Botschaften trennt)

Bit-stuffing kann die physikalische Länge eines Frames vergrößern. Beim Bit-stuffing wird nach fünf gleichpoligen Bits ein komplementäres Bit (sog. Stopfbit) in den logischen Bitstrom eingefügt. Bit-stuffing wirkt auf Start of frame (SOF) bis einschließlich Prüfsummenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der Teilnehmer innerhalb eines Frames.

RTR (Remote Transmission Request)

Ein gesetztes RTR-Bit kennzeichnet einen Remote-Frame (rezessiv). Mit Hilfe eines Remoteframe, kann ein Teilnehmer einen anderen auffordern, seine Daten zu senden.

Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehlerquelle: Viele Entwickler setzen die Datenlänge = 0 - dies ist falsch). Der Objectidentifier ist derselbe, wie der der angeforderten Nachricht.

ACK-Slot

Der Acknowledge-Slot wird verwendet, um den Empfang zu quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pegel an der Stelle des ACK-Slots.

Sicherung der Daten

Error-Frames senden) und bus off (Teilnehmer darf nicht mehr senden).

Der Sender wiederholt nach dem Error-Frame seine Datenübertragung. Auch der Sender kann durch die zuvor erwähnten Fehlerzähler vom Bus getrennt werden, wenn die Datenübertragung dauerhaft fehlschlägt.

CANopen/DeviceNet

CANopen[1] und DeviceNet[2] sind auf CAN basierende Schicht-7-Kommunikationsprotokolle, welche hauptsächlich in der Automatisierungstechnik verwendet werden.

Das Verbreitungsgebiet von CANopen ist dabei mehr Europa. Es wurde vorwiegend von Deutschen Klein- und Mittelständischen Firmen initiiert und im Rahmen eines Esprit Projektes unter Leitung von Bosch erarbeitet. Seit 1995 wird es von der CiA[3] gepflegt und ist inzwischen als Europäische Norm EN 50325-4 standardisiert.

DeviceNet hingegen ist mehr in Amerika verbreitet. Es wurde von Allen-Bradley[4] (gehört zu Rockwell Automation[5]) entwickelt und später als offener Standard an die ODVA[6] (Open DeviceNet Vendor Association) übergeben.

weitere Quellen

Literatur

Wolfhard Lawrenz (Hrsg.): CAN Controller Area Network - Grundlagen und Praxis. Hüthig, ISBN 3-7785-2780-0
Konrad Etschberger (Hrsg.): CAN Controller Area Network - Grundlagen, Protokolle, Bausteine, Anwendungen. Hanser, ISBN 3-446-19431-2