Controller Area Network

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

Es handelt sich dabei um ein asynchrones, serielles Bussystem, das von Bosch für die Vernetzung von Steuergeräten im Automobil entwickelt 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. Desweiteren 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 30m möglich. Bei 500kBit/s sind zum Beispiel 100m möglich und bei 125kBit/s 500m. Als Busmedium werden nach ISO11898(CAN High-Speed) 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 CAN Spezifikation definiert zwei verschiedene Identifier-Formate:

11-bit Identifier, auch "Standard CAN" genannt
29-bit Identifier, auch "Extended CAN" 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). Somit limitiert die Länge des Identifier Feldes auch die maximale Anzahl von Sendern auf dem Bus.

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 vergeben werden um ihnen so Vorrang bei der Übertragung zu gewähren.

Frame-Aufbau

Es gibt vier verschiedene Arten von Frames

Daten-Frame dient dem Transport von bis zu 8 Byte 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, entfällt bei Remote-Frame siehe unten )
Datenfeld (DATA) = 0-64 bit (in Einheiten von 8 bit)
Prüfsummenfeld (CRC) = 16 bit (15 bit CRC plus einem dominanten CRC-Delimiter bit)
Bestätigungsfeld (ACK) 2 bit, bestehend aus einem dominanten 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 (siehe unten ) kann die physikalische Länge eines Frames vergrößern.

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.

Das CTRL-Feld wird ignoriert. Datenlänge = 0. 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

Der CAN-Bus erreicht Bitfehlerraten (BER Bit Error Rate) in der Größenordnung von 0.00003. Zum einen verwendet man einen CRC (Cyclic Redundancy Check = Prüfsumme) von 15 Bit und zum anderen "Bit-stuffing".

Beim Bit-stuffing wird nach fünf gleichpoligen Bits ein komplementäres Bit (sog. Stuff-bit) 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.

Erkennt ein Empfänger eine Fehlerbedingung sendet er einen Error-Frame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer diese Fehlerbedingung nicht erkannt haben, senden sie ihrerseits direkt im Anschluss ein weiteres Error-Frame. Hiermit wird eine weitere Sicherheitsfunktion des CAN Protokolls möglich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingungen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler. Diese Zähler erlauben nach den Regeln der Spezifikation einen fehlerhaft arbeitenden Teilnehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler erkennt, welche andere Teilnehmer nicht erkennen oder wiederholt fehlerhafte Frames versendet. Die Zustände nennen sich error active (normal), error passive (Teilnehmer darf nur noch passive --das heißt rezessive-- 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äischen 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